[Bug 94315] AMDGPU 290X Refresh rate issue at 144Hz

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94315

--- Comment #6 from Damien  ---
Issue on all kernels + AMDGPU and Radeon driver. But i'm actually on mainline/
AMDGPU CIK

Ok on Catalyst FGLRX.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/5b2f6b72/attachment.html>


[Bug 94315] AMDGPU 290X Refresh rate issue at 144Hz

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94315

--- Comment #5 from Damien  ---
Created attachment 121998
  --> https://bugs.freedesktop.org/attachment.cgi?id=121998=edit
290X tested

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/fe245082/attachment.html>


[Bug 94315] AMDGPU 290X Refresh rate issue at 144Hz

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94315

--- Comment #4 from Damien  ---
Created attachment 121997
  --> https://bugs.freedesktop.org/attachment.cgi?id=121997=edit
Left

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/3fd99b76/attachment.html>


[Bug 94315] AMDGPU 290X Refresh rate issue at 144Hz

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94315

--- Comment #3 from Damien  ---
Created attachment 121996
  --> https://bugs.freedesktop.org/attachment.cgi?id=121996=edit
Left pixel repeat

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/088757da/attachment.html>


[Bug 94315] AMDGPU 290X Refresh rate issue at 144Hz

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94315

--- Comment #2 from Damien  ---
Created attachment 121995
  --> https://bugs.freedesktop.org/attachment.cgi?id=121995=edit
Text2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/f645ec1a/attachment.html>


[Bug 94315] AMDGPU 290X Refresh rate issue at 144Hz

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94315

--- Comment #1 from Damien  ---
Created attachment 121994
  --> https://bugs.freedesktop.org/attachment.cgi?id=121994=edit
text

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/31dd0c6a/attachment.html>


[Bug 94315] AMDGPU 290X Refresh rate issue at 144Hz

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94315

Bug ID: 94315
   Summary: AMDGPU 290X Refresh rate issue at 144Hz
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: dherault at hotmail.com

Created attachment 121993
  --> https://bugs.freedesktop.org/attachment.cgi?id=121993=edit
xrandr + OSD 139Hz

Hello,

I have Arch linux with an asus MG279Q (27 "144Hz) connected in DisplayPort 1.2.
Everything worked with Sapphire 7950 and also R9 Fury. 
Unfortunately I have trouble with my Sapphire 290x. I've tested three 290X to
be sure it's not an hardware issue. 
Of course freesync is off.
I just tested the combo with multiple users 290 (X and not X) + MG279Q.
Sometimes on livecd. Everyone have the issue.

I can't have a real 144Hz with the amdgpu or radeon driver. Everything work
only @60Hz or with FGLRX driver.
At 144Hz , i have a bad 139Hz with artifacts :
http://reho.st/self/b98c1c955cb7d42c3af6f82ea71bbc94be8aee6a.jpg

Glitches on the left. Blur on all screen, Text glitches...

What i've tried :
- Windows 10 : All works !
- FGLRX : All works @144Hz. But other problems make it difficult to use: in
firefox lag among others ... And I love the free driver! Finally ... When he
worked with my 7950
- Kernel mainline : Same issue .
- New mode line with cvt 2560 1440 144 and xrandr --newmode : Same issue.
- Contact Sapphire and upload to a new vbios : Same issue and as long as it
works on windows it's not their problem...

It can be an incompatibility between the MG279Q and the 290X on linux. But
something in FGLRX make my 290X works, but not present on AMDGPU/Radeon driver.

I just tested the combo with multiple users 290 (X and not X) + MG279Q.
Sometimes on livecd. Everyone have the issue.

Thanks for your help

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/452da901/attachment-0001.html>


[Bug 87316] [radeonsi][bonaire][drm-next-3.19] unable to handle kernel NULL pointer dereference: radeon_fence_signaled

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=87316

Shawn Starr  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #2 from Shawn Starr  ---
Close it, this is old, I haven't tried PRIME in a while to confirm, create new
BZ if I can trigger this on new kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/410c93c8/attachment.html>


[Bug 91061] [4.1-rc8][radeonsi] GPU lockup from chrome - radeon_ttm_bo_destroy

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91061

Shawn Starr  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Shawn Starr  ---
Close it, can't reproduce and this is old now

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/0843c8ae/attachment.html>


[PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

2016-02-26 Thread Gustavo Padovan
From: Gustavo Padovan 

Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer allocation. In the new approach the ioctl needs to be called
twice to retrieve the array of fence_infos pointed by info->sync_fence_info.

The first call should pass num_fences = 0, the kernel will then fill
info->num_fences. Userspace receives back the number of fences and
allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
info->sync_fence_info.

It then call the ioctl again passing num_fences received in info->num_fences.
The kernel checks if info->num_fences > 0 and if yes it fill
info->sync_fence_info with an array containing all fence_infos.

info->len now represents the length of the buffer sync_fence_info points
to. Also, info->sync_fence_info was converted to __u64 pointer.

An example userspace code would be:

struct sync_file_info *info;
int err, size, num_fences;

info = malloc(sizeof(*info));

memset(info, 0, sizeof(*info));

err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;

if (num_fences) {
memset(info, 0, sizeof(*info));
size = sizeof(struct sync_fence_info) * num_fences;
info->len = size;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
  sizeof(struct 
sync_fence_info));

err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}

v2: fix fence_info memory leak

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 52 +
 drivers/staging/android/uapi/sync.h |  9 +++
 2 files changed, 45 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..2379f23 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
 {
-   struct sync_file_info *info;
+   struct sync_file_info in, *info;
+   struct sync_fence_info *fence_info = NULL;
__u32 size;
__u32 len = 0;
int ret, i;

-   if (copy_from_user(, (void __user *)arg, sizeof(size)))
+   if (copy_from_user(, (void __user *)arg, sizeof(*info)))
return -EFAULT;

-   if (size < sizeof(struct sync_file_info))
-   return -EINVAL;
+   if (in.status || strcmp(in.name, "\0"))
+   return -EFAULT;

-   if (size > 4096)
-   size = 4096;
+   if (in.num_fences && !in.sync_fence_info)
+   return -EFAULT;

-   info = kzalloc(size, GFP_KERNEL);
+   info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;

@@ -525,14 +526,33 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (info->status >= 0)
info->status = !info->status;

-   info->num_fences = sync_file->num_fences;
+   /*
+* Passing num_fences = 0 means that userspace want to know how
+* many fences are in the sync_file to be able to allocate a buffer to
+* fit all sync_fence_infos and call the ioctl again with the buffer
+* assigned to info->sync_fence_info. The second call pass the
+* num_fences value received in the first call.
+*/
+   if (!in.num_fences)
+   goto no_fences;
+
+   size = sync_file->num_fences * sizeof(*fence_info);
+   if (in.len != size) {
+   ret = -EFAULT;
+   goto out;
+   }

-   len = sizeof(struct sync_file_info);
+   fence_info = kzalloc(size, GFP_KERNEL);
+   if (!fence_info) {
+   ret = -ENOMEM;
+   goto out;
+   }

for (i = 0; i < sync_file->num_fences; ++i) {
struct fence *fence = sync_file->cbs[i].fence;

-   ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
+   ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
+  size - len);

if (ret < 0)
goto out;
@@ -540,14 +560,24 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
len += ret;
}

+   if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
+   ret = -EFAULT;
+   goto out;
+   }
+
info->len = len;
+   info->sync_fence_info = (__u64) in.sync_fence_info;
+
+no_fences:
+   info->num_fences = sync_file->num_fences;

-   if (copy_to_user((void __user *)arg, info, len))
+   if (copy_to_user((void __user *)arg, info, 

[PATCH v6 02/11] drm/hisilicon: Add hisilicon kirin drm master driver

2016-02-26 Thread Xinliang Liu
Hi,

On 26 February 2016 at 16:54, Archit Taneja  wrote:
> Hi,
>
> I had some minor comments. Sorry about sharing this late. Otherwise,
> the looks good to me.

Hi Archit,  you are welcome :-)
Thanks for review again.

>
>
> On 02/26/2016 02:10 PM, Xinliang Liu wrote:
>>
>> Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
>> Add dumb buffer feature.
>> Add prime dmabuf feature.
>>
>> v6: None.
>> v5: None.
>> v4: None.
>> v3:
>> - Move and rename all the files to kirin sub-directory.
>>So that we could separate different seires SoCs' driver.
>> - Replace drm_platform_init, load, unload implementation.
>> v2:
>> - Remove abtraction layer.
>>
>> Signed-off-by: Xinliang Liu 
>> ---
>>   drivers/gpu/drm/Kconfig |   2 +
>>   drivers/gpu/drm/Makefile|   1 +
>>   drivers/gpu/drm/hisilicon/Kconfig   |   5 +
>>   drivers/gpu/drm/hisilicon/Makefile  |   5 +
>>   drivers/gpu/drm/hisilicon/kirin/Kconfig |   9 +
>>   drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +
>>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321
>> 
>>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
>>   8 files changed, 366 insertions(+)
>>   create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
>>   create mode 100644 drivers/gpu/drm/hisilicon/Makefile
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index b50ae60f5f50..f5c5656e2547 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
>>   source "drivers/gpu/drm/vc4/Kconfig"
>>
>>   source "drivers/gpu/drm/etnaviv/Kconfig"
>> +
>> +source "drivers/gpu/drm/hisilicon/Kconfig"
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 61766dec6a8d..60554832079c 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -74,3 +74,4 @@ obj-y += panel/
>>   obj-y += bridge/
>>   obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>>   obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
>> +obj-y  += hisilicon/
>> diff --git a/drivers/gpu/drm/hisilicon/Kconfig
>> b/drivers/gpu/drm/hisilicon/Kconfig
>> new file mode 100644
>> index ..558c61b1b8e8
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/Kconfig
>> @@ -0,0 +1,5 @@
>> +#
>> +# hisilicon drm device configuration.
>> +# Please keep this list sorted alphabetically
>> +
>> +source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
>> diff --git a/drivers/gpu/drm/hisilicon/Makefile
>> b/drivers/gpu/drm/hisilicon/Makefile
>> new file mode 100644
>> index ..e3f6d493c996
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/Makefile
>> @@ -0,0 +1,5 @@
>> +#
>> +# Makefile for hisilicon drm drivers.
>> +# Please keep this list sorted alphabetically
>> +
>> +obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig
>> b/drivers/gpu/drm/hisilicon/kirin/Kconfig
>> new file mode 100644
>> index ..3ac4b8edeac1
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
>> @@ -0,0 +1,9 @@
>> +config DRM_HISI_KIRIN
>> +   tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
>> +   depends on DRM
>> +   select DRM_KMS_HELPER
>> +   select DRM_GEM_CMA_HELPER
>> +   select DRM_KMS_CMA_HELPER
>> +   help
>> + Choose this option if you have a hisilicon Kirin
>> chipsets(hi6220).
>> + If M is selected the module will be called kirin-drm.
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile
>> b/drivers/gpu/drm/hisilicon/kirin/Makefile
>> new file mode 100644
>> index ..cb346de47d48
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
>> @@ -0,0 +1,3 @@
>> +kirin-drm-y := kirin_drm_drv.o
>> +
>> +obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> new file mode 100644
>> index ..789ebd1f5922
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> @@ -0,0 +1,321 @@
>> +/*
>> + * Hisilicon Kirin SoCs drm master driver
>> + *
>> + * Copyright (c) 2016 Linaro Limited.
>> + * Copyright (c) 2014-2016 Hisilicon Limited.
>> + *
>> + * Author:
>> + * Xinliang Liu 
>> + * Xinliang Liu 
>> + * Xinwei Kong 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> 

[PATCH 5/5] drm/i915: Implement color management on chv

2016-02-26 Thread Lionel Landwerlin
Patch based on a previous series by Shashank Sharma.

v2: Update contributors

v3: Refactor degamma/gamma LUTs load into a single function

v4: Remove unused variable

Signed-off-by: Shashank Sharma 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.c|   3 +
 drivers/gpu/drm/i915/i915_reg.h|  31 +
 drivers/gpu/drm/i915/intel_color.c | 133 +++--
 3 files changed, 161 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3807b73..8a2aaa7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -68,6 +68,8 @@ static struct drm_driver driver;

 #define BDW_COLORS \
.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+#define CHV_COLORS \
+   .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }

 static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
@@ -325,6 +327,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
+   CHV_COLORS,
 };

 static const struct intel_device_info intel_skylake_info = {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 76a9e49..ea599a9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7673,6 +7673,37 @@ enum skl_disp_power_wells {
 #define PREC_PAL_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A, 
_PAL_PREC_GC_MAX_B) + (i) * 4)
 #define PREC_PAL_EXT_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, 
_PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)

+/* pipe CSC & degamma/gamma LUTs on CHV */
+#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
+#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
+#define _CGM_PIPE_A_CSC_COEFF45(VLV_DISPLAY_BASE + 0x67908)
+#define _CGM_PIPE_A_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6790C)
+#define _CGM_PIPE_A_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x67910)
+#define _CGM_PIPE_A_DEGAMMA(VLV_DISPLAY_BASE + 0x66000)
+#define _CGM_PIPE_A_GAMMA  (VLV_DISPLAY_BASE + 0x67000)
+#define _CGM_PIPE_A_MODE   (VLV_DISPLAY_BASE + 0x67A00)
+#define   CGM_PIPE_MODE_GAMMA  (1 << 2)
+#define   CGM_PIPE_MODE_CSC(1 << 1)
+#define   CGM_PIPE_MODE_DEGAMMA(1 << 0)
+
+#define _CGM_PIPE_B_CSC_COEFF01(VLV_DISPLAY_BASE + 0x69900)
+#define _CGM_PIPE_B_CSC_COEFF23(VLV_DISPLAY_BASE + 0x69904)
+#define _CGM_PIPE_B_CSC_COEFF45(VLV_DISPLAY_BASE + 0x69908)
+#define _CGM_PIPE_B_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6990C)
+#define _CGM_PIPE_B_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x69910)
+#define _CGM_PIPE_B_DEGAMMA(VLV_DISPLAY_BASE + 0x68000)
+#define _CGM_PIPE_B_GAMMA  (VLV_DISPLAY_BASE + 0x69000)
+#define _CGM_PIPE_B_MODE   (VLV_DISPLAY_BASE + 0x69A00)
+
+#define CGM_PIPE_CSC_COEFF01(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF01, _CGM_PIPE_B_CSC_COEFF01)
+#define CGM_PIPE_CSC_COEFF23(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF23, _CGM_PIPE_B_CSC_COEFF23)
+#define CGM_PIPE_CSC_COEFF45(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF45, _CGM_PIPE_B_CSC_COEFF45)
+#define CGM_PIPE_CSC_COEFF67(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF67, _CGM_PIPE_B_CSC_COEFF67)
+#define CGM_PIPE_CSC_COEFF8(pipe)  _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF8, _CGM_PIPE_B_CSC_COEFF8)
+#define CGM_PIPE_DEGAMMA(pipe, i, w)   _MMIO(_PIPE(pipe, _CGM_PIPE_A_DEGAMMA, 
_CGM_PIPE_B_DEGAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_GAMMA(pipe, i, w) _MMIO(_PIPE(pipe, _CGM_PIPE_A_GAMMA, 
_CGM_PIPE_B_GAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_MODE(pipe)_MMIO_PIPE(pipe, _CGM_PIPE_A_MODE, 
_CGM_PIPE_B_MODE)
+
 /* MIPI DSI registers */

 #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index c6340d8..aa0b20d 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -29,6 +29,7 @@
 #define CTM_COEFF_1_0  (1ULL << 32)
 #define CTM_COEFF_2_0  (CTM_COEFF_1_0 << 1)
 #define CTM_COEFF_4_0  (CTM_COEFF_2_0 << 1)
+#define CTM_COEFF_8_0  (CTM_COEFF_4_0 << 1)
 #define CTM_COEFF_0_5  (CTM_COEFF_1_0 >> 1)
 #define CTM_COEFF_0_25 (CTM_COEFF_0_5 >> 1)
 #define CTM_COEFF_0_125(CTM_COEFF_0_25 >> 1)
@@ -199,6 +200,58 @@ static void i9xx_load_csc_matrix(struct drm_crtc *crtc)
}
 }

+/*
+ * Set up the pipe CSC unit on CherryView.
+ */
+static void cherryview_load_csc_matrix(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_crtc_state *state = crtc->state;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int pipe = to_intel_crtc(crtc)->pipe;
+

[PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

2016-02-26 Thread Lionel Landwerlin
Patch based on a previous series by Shashank Sharma.

v2: Do not read GAMMA_MODE register to figure what mode we're in

v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0

Add documentation on how the Broadcast RGB property is affected by CTM

v4: Update contributors

v5: Refactor degamma/gamma LUTs load into a single function

v6: Fix missing intel_crtc variable (bisect issue)

v7: Fix & simplify limited range matrix multiplication (Matt Roper's
comment)

Signed-off-by: Shashank Sharma 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
Signed-off-by: Lionel Landwerlin 
Acknowledged-by: Matt Roper 
---
 Documentation/DocBook/gpu.tmpl   |   6 +-
 drivers/gpu/drm/i915/i915_drv.c  |  24 ++-
 drivers/gpu/drm/i915/i915_drv.h  |   6 +
 drivers/gpu/drm/i915/i915_reg.h  |  22 +++
 drivers/gpu/drm/i915/intel_color.c   | 345 +--
 drivers/gpu/drm/i915/intel_display.c |  22 ++-
 drivers/gpu/drm/i915/intel_drv.h |   3 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |   8 +
 8 files changed, 371 insertions(+), 65 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1692c4d..430e99b 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2153,7 +2153,11 @@ void intel_crt_init(struct drm_device *dev)
ENUM
{ "Automatic", "Full", "Limited 16:235" }
Connector
-   TBD
+   When this property is set to Limited 16:235
+   and CTM is set, the hardware will be programmed with the
+   result of the multiplication of CTM by the limited range
+   matrix to ensure the pixels normaly in the range 0..1.0 are
+   remapped to the range 16/255..235/255.


“audio”
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 20e8200..3807b73 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -66,6 +66,9 @@ static struct drm_driver driver;
 #define IVB_CURSOR_OFFSETS \
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, 
IVB_CURSOR_C_OFFSET }

+#define BDW_COLORS \
+   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+
 static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
.has_overlay = 1, .overlay_needs_physical = 1,
@@ -288,24 +291,28 @@ static const struct intel_device_info 
intel_haswell_m_info = {
.is_mobile = 1,
 };

+#define BDW_FEATURES \
+   HSW_FEATURES, \
+   BDW_COLORS
+
 static const struct intel_device_info intel_broadwell_d_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8,
 };

 static const struct intel_device_info intel_broadwell_m_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8, .is_mobile = 1,
 };

 static const struct intel_device_info intel_broadwell_gt3d_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };

 static const struct intel_device_info intel_broadwell_gt3m_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8, .is_mobile = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
@@ -321,13 +328,13 @@ static const struct intel_device_info 
intel_cherryview_info = {
 };

 static const struct intel_device_info intel_skylake_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
 };

 static const struct intel_device_info intel_skylake_gt3_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
@@ -345,17 +352,18 @@ static const struct intel_device_info intel_broxton_info 
= {
.has_fbc = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
+   BDW_COLORS,
 };

 static const struct intel_device_info intel_kabylake_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_preliminary = 1,
.is_kabylake = 1,
.gen = 9,
 };

 static const struct intel_device_info intel_kabylake_gt3_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_preliminary = 1,
.is_kabylake = 1,
.gen = 9,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d46d5e7..5d11d74 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -663,6 +663,7 @@ struct drm_i915_display_funcs {
/* display clock increase/decrease */
/* pll clock increase/decrease */

+   void (*load_csc_matrix)(struct drm_crtc *crtc);
void (*load_luts)(struct drm_crtc *crtc);
 };

@@ -812,6 +813,11 @@ struct intel_device_info {
u8 has_slice_pg:1;
u8 has_subslice_pg:1;
u8 has_eu_pg:1;
+
+   struct color_luts {

[PATCH 3/5] drm: introduce pipe color correction properties

2016-02-26 Thread Lionel Landwerlin
Patch based on a previous series by Shashank Sharma.

This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix and finally another lookup into
a gamma table.

The following properties can be added to a pipe :
  - DEGAMMA_LUT : blob containing degamma LUT
  - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
  - CTM : transformation matrix applied after the degamma LUT
  - GAMMA_LUT : blob containing gamma LUT
  - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT

DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
the driver to tell userspace applications what sizes should be the
lookup tables in DEGAMMA_LUT and GAMMA_LUT.

A helper is also provided so legacy gamma correction is redirected
through these new properties.

v2: Register LUT size properties as range

v3: Fix round in drm_color_lut_get_value() helper
More docs on how degamma/gamma properties are used

v4: Update contributors

v5: Rename CTM_MATRIX property to CTM (Doh!)
Add legacy gamma_set atomic helper
Describe CTM/LUT acronyms in the kernel doc

v6: Fix missing blob unref in drm_atomic_helper_crtc_reset

Signed-off-by: Shashank Sharma 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matt Roper 
---
 Documentation/DocBook/gpu.tmpl  |  59 ++-
 drivers/gpu/drm/drm_atomic.c|  88 -
 drivers/gpu/drm/drm_atomic_helper.c | 110 +++-
 drivers/gpu/drm/drm_crtc.c  |  35 
 drivers/gpu/drm/drm_crtc_helper.c   |  33 +++
 include/drm/drm_atomic_helper.h |   3 +
 include/drm/drm_crtc.h  |  46 ++-
 include/drm/drm_crtc_helper.h   |   3 +
 include/uapi/drm/drm_mode.h |  15 +
 9 files changed, 386 insertions(+), 6 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index fe6b36a..1692c4d 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
“rotation”
BITMASK
@@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector


-   Optional
+   Optional
“scaling mode”
ENUM
{ "None", "Full", "Center", "Full aspect" }
@@ -2092,6 +2092,61 @@ void intel_crt_init(struct drm_device *dev)
TBD


+   “DEGAMMA_LUT”
+   BLOB
+   0
+   CRTC
+   DRM property to set the degamma lookup table
+   (LUT) mapping pixel data from the framebuffer before it is
+   given to the transformation matrix. The data is an interpreted
+   as an array of struct drm_color_lut elements. Hardware might
+   choose not to use the full precision of the LUT elements nor
+   use all the elements of the LUT (for example the hardware
+   might choose to interpolate between LUT[0] and LUT[4]). 
+   
+   
+   “DEGAMMA_LUT_SIZE”
+   RANGE | IMMUTABLE
+   Min=0, Max=UINT_MAX
+   CRTC
+   DRM property to gives the size of the lookup
+   table to be set on the DEGAMMA_LUT property (the size depends
+   on the underlying hardware).
+   
+   
+   “CTM”
+   BLOB
+   0
+   CRTC
+   DRM property to set the current
+   transformation matrix (CTM) apply to pixel data after the
+   lookup through the degamma LUT and before the lookup through
+   the gamma LUT. The data is an interpreted as a struct
+   drm_color_ctm.
+   
+   
+   “GAMMA_LUT”
+   BLOB
+   0
+   CRTC
+   DRM property to set the gamma lookup table
+   (LUT) mapping pixel data after to the transformation matrix to
+   data sent to the connector. The data is an interpreted as an
+   array of struct drm_color_lut elements. Hardware might choose
+   not to use the full precision of the LUT elements nor use all
+   the elements of the LUT (for example the hardware might choose
+   to interpolate between LUT[0] and LUT[4]).
+   
+   
+   “GAMMA_LUT_SIZE”
+   RANGE | IMMUTABLE
+   Min=0, Max=UINT_MAX
+   CRTC
+   DRM property to gives the size of the lookup
+   table to be set on the GAMMA_LUT property (the size depends on
+   the underlying hardware).
+   
+   
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/drm_atomic.c 

[PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

2016-02-26 Thread Lionel Landwerlin
Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.

v2: Read GAMMA_MODE register value at init (Matt Roper's comment)

v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
with other registers (Matt Roper's comment).

v4: Mask GAMMA_MODE register with interesting bits when reading

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_color.c   | 7 +--
 drivers/gpu/drm/i915/intel_display.c | 3 +++
 drivers/gpu/drm/i915/intel_drv.h | 3 +++
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 35b7f62..16657eb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -121,6 +121,8 @@ static void haswell_load_luts(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *intel_crtc_state =
+   to_intel_crtc_state(crtc->state);
bool reenable_ips = false;

/*
@@ -128,11 +130,12 @@ static void haswell_load_luts(struct drm_crtc *crtc)
 * GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
 */
if (IS_HASWELL(dev) && intel_crtc->config->ips_enabled &&
-   ((I915_READ(GAMMA_MODE(intel_crtc->pipe)) & GAMMA_MODE_MODE_MASK) ==
-GAMMA_MODE_MODE_SPLIT)) {
+   (intel_crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
hsw_disable_ips(intel_crtc);
reenable_ips = true;
}
+
+   intel_crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);

i9xx_load_luts(crtc);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 66d6820..a5f57cd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9870,6 +9870,9 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,

intel_get_pipe_timings(crtc, pipe_config);

+   pipe_config->gamma_mode =
+   I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
+
if (INTEL_INFO(dev)->gen >= 9) {
skl_init_scalers(dev, crtc, pipe_config);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dc29816..d2855c7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -518,6 +518,9 @@ struct intel_crtc_state {
struct skl_pipe_wm skl;
} optimal;
} wm;
+
+   /* Gamma mode programmed on the pipe */
+   uint32_t gamma_mode;
 };

 struct vlv_wm_state {
-- 
2.7.0



[PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

2016-02-26 Thread Lionel Landwerlin
The moves a couple of functions programming the gamma LUT and CSC
units into their own file.

On generations prior to Haswell there is only a gamma LUT. From
haswell on there is also a new enhanced color correction unit that
isn't used yet. This is why we need to set the GAMMA_MODE register,
either we're using the legacy 8bits LUT or enhanced LUTs (of 10 or
12bits).

The CSC unit is only available from Haswell on.

We also need to make a special case for CherryView which is recognized
as a gen 8 but doesn't have the same enhanced color correction unit
from Haswell on.

v2: Fix access to GAMMA_MODE register on older generations than
Haswell (from Matt Roper's comments)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_color.c   | 191 +++
 drivers/gpu/drm/i915/intel_display.c | 163 +++---
 drivers/gpu/drm/i915/intel_drv.h |  10 ++
 5 files changed, 216 insertions(+), 151 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..0516300 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,6 +55,7 @@ i915-y += intel_audio.o \
  intel_atomic.o \
  intel_atomic_plane.o \
  intel_bios.o \
+ intel_color.o \
  intel_display.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4dcb74..d46d5e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -662,6 +662,8 @@ struct drm_i915_display_funcs {
/* render clock increase/decrease */
/* display clock increase/decrease */
/* pll clock increase/decrease */
+
+   void (*load_luts)(struct drm_crtc *crtc);
 };

 enum forcewake_domain_id {
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
new file mode 100644
index 000..35b7f62
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_drv.h"
+
+/*
+ * Set up the pipe CSC unit.
+ *
+ * Currently only full range RGB to limited range RGB conversion
+ * is supported, but eventually this should handle various
+ * RGB<->YCbCr scenarios as well.
+ */
+static void i9xx_load_csc_matrix(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   int pipe = intel_crtc->pipe;
+   uint16_t coeff = 0x7800; /* 1.0 */
+
+   /*
+* TODO: Check what kind of values actually come out of the pipe
+* with these coeff/postoff values and adjust to get the best
+* accuracy. Perhaps we even need to take the bpc value into
+* consideration.
+*/
+
+   if (intel_crtc->config->limited_color_range)
+   coeff = ((235 - 16) * (1 << 12) / 255) & 0xff8; /* 0.xxx... */
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), coeff << 16);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), coeff);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), 0);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), coeff << 16);
+
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   if (INTEL_INFO(dev)->gen > 6) {
+   uint16_t postoff = 0;
+
+   if (intel_crtc->config->limited_color_range)
+   postoff = 

[PATCH 0/5] Pipe level color management V10

2016-02-26 Thread Lionel Landwerlin
This series introduces pipe level color management through a set of properties
attached to the CRTC. It also provides an implementation for some Intel
platforms.

This series is based of a previous set of patches by Shashank Sharma.

Cheers,

Lionel

v9: Rebase on nightly

v10: Mask GAMMA_MODE register value (Matt Roper)
 Cleanup legacy LUT helper (Emil Velikov)

Lionel Landwerlin (5):
  drm/i915: Extract out gamma table and CSC to their own file
  drm/i915: Do not read GAMMA_MODE register
  drm: introduce pipe color correction properties
  drm/i915: Implement color management on bdw/skl/bxt/kbl
  drm/i915: Implement color management on chv

 Documentation/DocBook/gpu.tmpl   |  65 +++-
 drivers/gpu/drm/drm_atomic.c |  88 +-
 drivers/gpu/drm/drm_atomic_helper.c  | 110 ++-
 drivers/gpu/drm/drm_crtc.c   |  35 +++
 drivers/gpu/drm/drm_crtc_helper.c|  33 +++
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.c  |  27 +-
 drivers/gpu/drm/i915/i915_drv.h  |   8 +
 drivers/gpu/drm/i915/i915_reg.h  |  53 
 drivers/gpu/drm/i915/intel_color.c   | 556 +++
 drivers/gpu/drm/i915/intel_display.c | 184 +++-
 drivers/gpu/drm/i915/intel_drv.h |  12 +
 drivers/gpu/drm/i915/intel_fbdev.c   |   8 +
 include/drm/drm_atomic_helper.h  |   3 +
 include/drm/drm_crtc.h   |  46 ++-
 include/drm/drm_crtc_helper.h|   3 +
 include/uapi/drm/drm_mode.h  |  15 +
 17 files changed, 1081 insertions(+), 166 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color.c

--
2.7.0


[PATCH v6 11/11] arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

2016-02-26 Thread Xinliang Liu
Add ade, dsi and adv7533 DT nodes for hikey board.

Signed-off-by: Xinliang Liu 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 40 +++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 55 ++
 2 files changed, 95 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 818525197508..40239fba0572 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -39,3 +39,43 @@
  {
label = "LS-UART1";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "ok";
+
+   ports {
+   /* 1 for output port */
+   port at 1 {
+   reg = <1>;
+
+   dsi_out0: endpoint at 0 {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
+
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "ok";
+
+   adv7533: adv7533 at 39 {
+   compatible = "adi,adv7533";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <1 2>;
+   pd-gpio = < 4 0>;
+   adi,dsi-lanes = <4>;
+
+   port {
+   adv7533_in: endpoint {
+   remote-endpoint = <_out0>;
+   };
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index ad1f1ebcb05c..991568bb3ea1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -162,6 +162,11 @@
#clock-cells = <1>;
};

+   medianoc_ade: medianoc_ade at f452 {
+   compatible = "syscon";
+   reg = <0x0 0xf452 0x0 0x4000>;
+   };
+
uart0: uart at f8015000 {   /* console */
compatible = "arm,pl011", "arm,primecell";
reg = <0x0 0xf8015000 0x0 0x1000>;
@@ -209,5 +214,55 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+   ade: ade at f410 {
+   compatible = "hisilicon,hi6220-ade";
+   reg = <0x0 0xf410 0x0 0x7800>;
+   reg-names = "ade_base";
+   hisilicon,noc-syscon = <_ade>;
+   resets = <_ctrl MEDIA_ADE>;
+   interrupts = <0 115 4>; /* ldi interrupt */
+
+   clocks = <_ctrl HI6220_ADE_CORE>,
+<_ctrl HI6220_CODEC_JPEG>,
+<_ctrl HI6220_ADE_PIX_SRC>;
+   /*clock name*/
+   clock-names  = "clk_ade_core",
+  "clk_codec_jpeg",
+  "clk_ade_pix";
+
+   assigned-clocks = <_ctrl HI6220_ADE_CORE>,
+   <_ctrl HI6220_CODEC_JPEG>;
+   assigned-clock-rates = <36000>, <28800>;
+   dma-coherent;
+   status = "disabled";
+
+   port {
+   ade_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
+   dsi: dsi at f4107800 {
+   compatible = "hisilicon,hi6220-dsi";
+   reg = <0x0 0xf4107800 0x0 0x100>;
+   clocks = <_ctrl  HI6220_DSI_PCLK>;
+   clock-names = "pclk";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* 0 for input port */
+   port at 0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
};
 };
-- 
2.7.1



[PATCH v6 10/11] MAINTAINERS: Add maintainer for hisilicon DRM driver

2016-02-26 Thread Xinliang Liu
Add maintainer and reviewer for hisilicon DRM driver.

v6: None.
v5: None.
v4:
- Add Chen Feng  as Designated reviewer.
v3: First version.

Signed-off-by: Xinliang Liu 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4978dc19a4d2..b94ac713916a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3774,6 +3774,16 @@ S:   Maintained
 F: drivers/gpu/drm/gma500
 F: include/drm/gma500*

+DRM DRIVERS FOR HISILICON
+M: Xinliang Liu 
+R: Xinwei Kong 
+R: Chen Feng 
+L: dri-devel at lists.freedesktop.org
+T: git git://github.com/xin3liang/linux.git
+S: Maintained
+F: drivers/gpu/drm/hisilicon
+F: Documentation/devicetree/bindings/display/hisilicon
+
 DRM DRIVERS FOR NVIDIA TEGRA
 M: Thierry Reding 
 M: Terje Bergström 
-- 
2.7.1



[PATCH v6 09/11] drm/hisilicon: Add support for external bridge

2016-02-26 Thread Xinliang Liu
Add support for external HDMI bridge.

v6: None.
v5: None.
v4: None.
v3:
- Fix a typo: s/exteranl/external.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 52 
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index f15798b61451..c2c406446513 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {

 struct dw_dsi {
struct drm_encoder encoder;
+   struct drm_bridge *bridge;
struct mipi_dsi_host host;
struct drm_display_mode cur_mode;
struct dsi_hw_ctx *ctx;
@@ -688,6 +689,25 @@ static int dsi_host_init(struct device *dev, struct dw_dsi 
*dsi)
return 0;
 }

+static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
+{
+   struct drm_encoder *encoder = >encoder;
+   struct drm_bridge *bridge = dsi->bridge;
+   int ret;
+
+   /* associate the bridge to dsi encoder */
+   encoder->bridge = bridge;
+   bridge->encoder = encoder;
+
+   ret = drm_bridge_attach(dev, bridge);
+   if (ret) {
+   DRM_ERROR("failed to attach external bridge\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -703,6 +723,10 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;

+   ret = dsi_bridge_init(drm_dev, dsi);
+   if (ret)
+   return ret;
+
return 0;
 }

@@ -719,8 +743,36 @@ static const struct component_ops dsi_ops = {
 static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
 {
struct dsi_hw_ctx *ctx = dsi->ctx;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *endpoint, *bridge_node;
+   struct drm_bridge *bridge;
struct resource *res;

+   /*
+* Get the endpoint node. In our case, dsi has one output port1
+* to which the external HDMI bridge is connected.
+*/
+   endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
+   if (!endpoint) {
+   DRM_ERROR("no valid endpoint node\n");
+   return -ENODEV;
+   }
+   of_node_put(endpoint);
+
+   bridge_node = of_graph_get_remote_port_parent(endpoint);
+   if (!bridge_node) {
+   DRM_ERROR("no valid bridge node\n");
+   return -ENODEV;
+   }
+   of_node_put(bridge_node);
+
+   bridge = of_drm_find_bridge(bridge_node);
+   if (!bridge) {
+   DRM_INFO("wait for external HDMI bridge driver.\n");
+   return -EPROBE_DEFER;
+   }
+   dsi->bridge = bridge;
+
ctx->pclk = devm_clk_get(>dev, "pclk");
if (IS_ERR(ctx->pclk)) {
DRM_ERROR("failed to get pclk clock\n");
-- 
2.7.1



[PATCH v6 08/11] drm/hisilicon: Add designware dsi host driver

2016-02-26 Thread Xinliang Liu
Add DesignWare dsi host driver for hi6220 SoC.

v6: None.
v5: None.
v4: None.
v3: None.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 50 
 1 file changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 8329148cc89d..f15798b61451 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {

 struct dw_dsi {
struct drm_encoder encoder;
+   struct mipi_dsi_host host;
struct drm_display_mode cur_mode;
struct dsi_hw_ctx *ctx;
struct mipi_phy_params phy;
@@ -642,6 +643,51 @@ static int dw_drm_encoder_init(struct device *dev,
return 0;
 }

+static int dsi_host_attach(struct mipi_dsi_host *host,
+  struct mipi_dsi_device *mdsi)
+{
+   struct dw_dsi *dsi = host_to_dsi(host);
+
+   if (mdsi->lanes < 1 || mdsi->lanes > 4) {
+   DRM_ERROR("dsi device params invalid\n");
+   return -EINVAL;
+   }
+
+   dsi->lanes = mdsi->lanes;
+   dsi->format = mdsi->format;
+   dsi->mode_flags = mdsi->mode_flags;
+
+   return 0;
+}
+
+static int dsi_host_detach(struct mipi_dsi_host *host,
+  struct mipi_dsi_device *mdsi)
+{
+   /* do nothing */
+   return 0;
+}
+
+static const struct mipi_dsi_host_ops dsi_host_ops = {
+   .attach = dsi_host_attach,
+   .detach = dsi_host_detach,
+};
+
+static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
+{
+   struct mipi_dsi_host *host = >host;
+   int ret;
+
+   host->dev = dev;
+   host->ops = _host_ops;
+   ret = mipi_dsi_host_register(host);
+   if (ret) {
+   DRM_ERROR("failed to register dsi host\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -653,6 +699,10 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;

+   ret = dsi_host_init(dev, dsi);
+   if (ret)
+   return ret;
+
return 0;
 }

-- 
2.7.1



[PATCH v6 07/11] drm/hisilicon: Add designware dsi encoder driver

2016-02-26 Thread Xinliang Liu
Add DesignWare MIPI DSI Host Controller v1.02 encoder driver
for hi6220 SoC.

v6:
- Change "pclk_dsi" to "pclk".
v5: None.
v4: None.
v3:
- Rename file name to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Andy Green 
---
 drivers/gpu/drm/hisilicon/kirin/Kconfig  |   1 +
 drivers/gpu/drm/hisilicon/kirin/Makefile |   3 +-
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 743 +++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h |  83 +++
 4 files changed, 829 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h

diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig 
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index 3ac4b8edeac1..de0d454c5c13 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -4,6 +4,7 @@ config DRM_HISI_KIRIN
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
+   select DRM_MIPI_DSI
help
  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
  If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
index 2a61ab006ddb..5dcd0d4328b6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,4 +1,5 @@
 kirin-drm-y := kirin_drm_drv.o \
-  kirin_drm_ade.o
+  kirin_drm_ade.o \
+  dw_drm_dsi.o

 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
new file mode 100644
index ..8329148cc89d
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -0,0 +1,743 @@
+/*
+ * DesignWare MIPI DSI Host Controller v1.02 driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ * Xinliang Liu 
+ * Xinliang Liu 
+ * Xinwei Kong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dw_dsi_reg.h"
+
+#define MAX_TX_ESC_CLK(10)
+#define ROUND(x, y) ((x) / (y) + ((x) % (y) * 10 / (y) >= 5 ? 1 : 0))
+#define PHY_REF_CLK_RATE   1920
+#define PHY_REF_CLK_PERIOD_PS (10 / (PHY_REF_CLK_RATE / 1000))
+
+#define encoder_to_dsi(encoder) \
+   container_of(encoder, struct dw_dsi, encoder)
+#define host_to_dsi(host) \
+   container_of(host, struct dw_dsi, host)
+
+struct mipi_phy_params {
+   u32 clk_t_lpx;
+   u32 clk_t_hs_prepare;
+   u32 clk_t_hs_zero;
+   u32 clk_t_hs_trial;
+   u32 clk_t_wakeup;
+   u32 data_t_lpx;
+   u32 data_t_hs_prepare;
+   u32 data_t_hs_zero;
+   u32 data_t_hs_trial;
+   u32 data_t_ta_go;
+   u32 data_t_ta_get;
+   u32 data_t_wakeup;
+   u32 hstx_ckg_sel;
+   u32 pll_fbd_div5f;
+   u32 pll_fbd_div1f;
+   u32 pll_fbd_2p;
+   u32 pll_enbwt;
+   u32 pll_fbd_p;
+   u32 pll_fbd_s;
+   u32 pll_pre_div1p;
+   u32 pll_pre_p;
+   u32 pll_vco_750M;
+   u32 pll_lpf_rs;
+   u32 pll_lpf_cs;
+   u32 clklp2hs_time;
+   u32 clkhs2lp_time;
+   u32 lp2hs_time;
+   u32 hs2lp_time;
+   u32 clk_to_data_delay;
+   u32 data_to_clk_delay;
+   u32 lane_byte_clk_kHz;
+   u32 clk_division;
+};
+
+struct dsi_hw_ctx {
+   void __iomem *base;
+   struct clk *pclk;
+};
+
+struct dw_dsi {
+   struct drm_encoder encoder;
+   struct drm_display_mode cur_mode;
+   struct dsi_hw_ctx *ctx;
+   struct mipi_phy_params phy;
+
+   u32 lanes;
+   enum mipi_dsi_pixel_format format;
+   unsigned long mode_flags;
+   bool enable;
+};
+
+struct dsi_data {
+   struct dw_dsi dsi;
+   struct dsi_hw_ctx ctx;
+};
+
+struct dsi_phy_range {
+   u32 min_range_kHz;
+   u32 max_range_kHz;
+   u32 pll_vco_750M;
+   u32 hstx_ckg_sel;
+};
+
+static const struct dsi_phy_range dphy_range_info[] = {
+   {   46875,62500,   1,7 },
+   {   62500,93750,   0,7 },
+   {   93750,   125000,   1,6 },
+   {  125000,   187500,   0,6 },
+   {  187500,   25,   1,5 },
+   {  25,   375000,   0,5 },
+   {  375000,   50,   1,4 },
+   {  50,   75,   0,4 },
+   {  75,  100,   1,0 },
+   { 100,  150,   0,0 }
+};
+
+static void dsi_get_phy_params(u32 phy_freq_kHz,
+  struct mipi_phy_params *phy)
+{
+   

[PATCH v6 06/11] drm/hisilicon: Add cma fbdev and hotplug

2016-02-26 Thread Xinliang Liu
Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by
configuring DRM_FBDEV_EMULATION.
Add hotplug.

v6: None.
v5: None.
v4: None.
v3: None.
v2:
- Use CONFIG_DRM_FBDEV_EMULATION instead of CONFIG_DRM_HISI_FBDEV.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 34 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  3 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 723888feb760..d57b9fa0ce3e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "kirin_drm_drv.h"

@@ -32,6 +33,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;

+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   if (priv->fbdev) {
+   drm_fbdev_cma_fini(priv->fbdev);
+   priv->fbdev = NULL;
+   }
+#endif
+   drm_kms_helper_poll_fini(dev);
drm_vblank_cleanup(dev);
dc_ops->cleanup(dev);
drm_mode_config_cleanup(dev);
@@ -41,8 +49,28 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
return 0;
 }

+#ifdef CONFIG_DRM_FBDEV_EMULATION
+static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+
+   if (priv->fbdev) {
+   drm_fbdev_cma_hotplug_event(priv->fbdev);
+   } else {
+   priv->fbdev = drm_fbdev_cma_init(dev, 32,
+   dev->mode_config.num_crtc,
+   dev->mode_config.num_connector);
+   if (IS_ERR(priv->fbdev))
+   priv->fbdev = NULL;
+   }
+}
+#endif
+
 static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   .output_poll_changed = kirin_fbdev_output_poll_changed,
+#endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
@@ -98,6 +126,12 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);

+   /* init kms poll for handling hpd */
+   drm_kms_helper_poll_init(dev);
+
+   /* force detection after connectors init */
+   (void)drm_helper_hpd_irq_event(dev);
+
return 0;

 err_unbind_all:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 5a05ad6a81db..1a07caf8e7f4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -21,6 +21,9 @@ struct kirin_dc_ops {

 struct kirin_drm_private {
struct drm_crtc *crtc[MAX_CRTC];
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   struct drm_fbdev_cma *fbdev;
+#endif
 };

 extern const struct kirin_dc_ops ade_dc_ops;
-- 
2.7.1



[PATCH v6 05/11] drm/hisilicon: Add vblank driver for ADE

2016-02-26 Thread Xinliang Liu
Add vblank irq handle.

v6: None.
v5: None.
v4: None.
v3:
- Remove hisi_get_crtc_from_index func.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 62 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 14 +-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index aa2cf75cab39..749382952ab7 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -292,6 +292,59 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
   SOCKET_QOS_EN, SOCKET_QOS_EN);
 }

+static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+   struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   void __iomem *base = ctx->base;
+
+   if (!ctx->power_on)
+   (void)ade_power_up(ctx);
+
+   ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+   MASK(1), 1);
+
+   return 0;
+}
+
+static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+   struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   void __iomem *base = ctx->base;
+
+   if (!ctx->power_on) {
+   DRM_ERROR("power is down! vblank disable fail\n");
+   return;
+   }
+
+   ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+   MASK(1), 0);
+}
+
+static irqreturn_t ade_irq_handler(int irq, void *data)
+{
+   struct ade_crtc *acrtc = data;
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   struct drm_crtc *crtc = >base;
+   void __iomem *base = ctx->base;
+   u32 status;
+
+   status = readl(base + LDI_MSK_INT);
+   DRM_DEBUG_VBL("LDI IRQ: status=0x%X\n", status);
+
+   /* vblank irq */
+   if (status & BIT(FRAME_END_INT_EN_OFST)) {
+   ade_update_bits(base + LDI_INT_CLR, FRAME_END_INT_EN_OFST,
+   MASK(1), 1);
+   drm_crtc_handle_vblank(crtc);
+   }
+
+   return IRQ_HANDLED;
+}
+
 static void ade_display_enable(struct ade_crtc *acrtc)
 {
struct ade_hw_ctx *ctx = acrtc->ctx;
@@ -967,6 +1020,15 @@ int ade_drm_init(struct drm_device *dev)
if (ret)
return ret;

+   /* vblank irq init */
+   ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
+  DRIVER_IRQ_SHARED, dev->driver->name, acrtc);
+   if (ret)
+   return ret;
+   dev->driver->get_vblank_counter = drm_vblank_no_hw_counter;
+   dev->driver->enable_vblank = ade_enable_vblank;
+   dev->driver->disable_vblank = ade_disable_vblank;
+
return 0;
 }

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 055729c1889c..723888feb760 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -32,6 +32,7 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;

+   drm_vblank_cleanup(dev);
dc_ops->cleanup(dev);
drm_mode_config_cleanup(dev);
devm_kfree(dev->dev, priv);
@@ -85,11 +86,22 @@ static int kirin_drm_kms_init(struct drm_device *dev)
goto err_dc_cleanup;
}

+   /* vblank init */
+   ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
+   if (ret) {
+   DRM_ERROR("failed to initialize vblank.\n");
+   goto err_unbind_all;
+   }
+   /* with irq_enabled = true, we can use the vblank feature. */
+   dev->irq_enabled = true;
+
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);

return 0;

+err_unbind_all:
+   component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
dc_ops->cleanup(dev);
 err_mode_config_cleanup:
@@ -123,7 +135,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file *file,

 static struct drm_driver kirin_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_ATOMIC,
+ DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
.fops   = _drm_fops,
.set_busid  = drm_platform_set_busid,

-- 
2.7.1



[PATCH v6 04/11] drm/hisilicon: Add plane driver for ADE

2016-02-26 Thread Xinliang Liu
Add plane funcs and helper funcs for ADE.

v6: None.
v5: None.
v4: None.
v3:
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 535 +++-
 1 file changed, 534 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index bb93616dcf3d..aa2cf75cab39 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -27,13 +27,23 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 

 #include "kirin_drm_drv.h"
 #include "kirin_ade_reg.h"

+#define PRIMARY_CH ADE_CH1 /* primary plane */
+#define OUT_OVLY   ADE_OVLY2 /* output overlay compositor */
+#define ADE_DEBUG  1
+
 #define to_ade_crtc(crtc) \
container_of(crtc, struct ade_crtc, base)

+#define to_ade_plane(plane) \
+   container_of(plane, struct ade_plane, base)
+
 struct ade_hw_ctx {
void __iomem  *base;
struct regmap *noc_regmap;
@@ -52,11 +62,76 @@ struct ade_crtc {
u32 out_format;
 };

+struct ade_plane {
+   struct drm_plane base;
+   void *ctx;
+   u8 ch; /* channel */
+};
+
 struct ade_data {
struct ade_crtc acrtc;
+   struct ade_plane aplane[ADE_CH_NUM];
struct ade_hw_ctx ctx;
 };

+/* ade-format info: */
+struct ade_format {
+   u32 pixel_format;
+   enum ade_fb_format ade_format;
+};
+
+static const struct ade_format ade_formats[] = {
+   /* 16bpp RGB: */
+   { DRM_FORMAT_RGB565, ADE_RGB_565 },
+   { DRM_FORMAT_BGR565, ADE_BGR_565 },
+   /* 24bpp RGB: */
+   { DRM_FORMAT_RGB888, ADE_RGB_888 },
+   { DRM_FORMAT_BGR888, ADE_BGR_888 },
+   /* 32bpp [A]RGB: */
+   { DRM_FORMAT_XRGB, ADE_XRGB_ },
+   { DRM_FORMAT_XBGR, ADE_XBGR_ },
+   { DRM_FORMAT_RGBA, ADE_RGBA_ },
+   { DRM_FORMAT_BGRA, ADE_BGRA_ },
+   { DRM_FORMAT_ARGB, ADE_ARGB_ },
+   { DRM_FORMAT_ABGR, ADE_ABGR_ },
+};
+
+static const u32 channel_formats1[] = {
+   /* channel 1,2,3,4 */
+   DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
+   DRM_FORMAT_BGR888, DRM_FORMAT_XRGB, DRM_FORMAT_XBGR,
+   DRM_FORMAT_RGBA, DRM_FORMAT_BGRA, DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR
+};
+
+u32 ade_get_channel_formats(u8 ch, const u32 **formats)
+{
+   switch (ch) {
+   case ADE_CH1:
+   *formats = channel_formats1;
+   return ARRAY_SIZE(channel_formats1);
+   default:
+   DRM_ERROR("no this channel %d\n", ch);
+   *formats = NULL;
+   return 0;
+   }
+}
+
+/* convert from fourcc format to ade format */
+static u32 ade_get_format(u32 pixel_format)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(ade_formats); i++)
+   if (ade_formats[i].pixel_format == pixel_format)
+   return ade_formats[i].ade_format;
+
+   /* not found */
+   DRM_ERROR("Not found pixel format!!fourcc_format= %d\n",
+ pixel_format);
+   return ADE_FORMAT_NOT_SUPPORT;
+}
+
 static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
 {
u32 bit_ofst, reg_num;
@@ -89,7 +164,7 @@ static void ade_init(struct ade_hw_ctx *ctx)
/* clear overlay */
writel(0, base + ADE_OVLY1_TRANS_CFG);
writel(0, base + ADE_OVLY_CTL);
-   writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+   writel(0, base + ADE_OVLYX_CTL(OUT_OVLY));
/* clear reset and reload regs */
writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
@@ -147,6 +222,10 @@ static void ade_ldi_set_mode(struct ade_crtc *acrtc,
  mode->clock * 1000, ret);
adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;

+   /* set overlay compositor output size */
+   writel(((width - 1) << OUTPUT_XSIZE_OFST) | (height - 1),
+  base + ADE_OVLY_OUTPUT_SIZE(OUT_OVLY));
+
/* ctran6 setting */
writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
 /* the configured value is actual value - 1 */
@@ -219,6 +298,10 @@ static void ade_display_enable(struct ade_crtc *acrtc)
void __iomem *base = ctx->base;
u32 out_fmt = acrtc->out_format;

+   /* enable output overlay compositor */
+   writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY));
+   ade_update_reload_bit(base, OVLY_OFST + OUT_OVLY, 0);
+
/* display source setting */
writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);

@@ -232,6 +315,97 @@ static void ade_display_enable(struct ade_crtc *acrtc)
writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
 }

+#if ADE_DEBUG
+static void ade_rdma_dump_regs(void __iomem *base, u32 ch)
+{
+   u32 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space, reg_en;
+   

[PATCH v6 03/11] drm/hisilicon: Add crtc driver for ADE

2016-02-26 Thread Xinliang Liu
Add crtc funcs and helper funcs for ADE.

v6:
- Cleanup reg-names dt parsing.
v5:
- Use syscon to access ADE media NOC QoS registers instread of directly
  writing registers.
- Use reset controller to reset ADE instead of directly writing registers.
v4: None.
v3:
- Make ade as the master driver.
- Use port to connect with encoder.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 290 +++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 452 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  15 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
 5 files changed, 767 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c

diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
index cb346de47d48..2a61ab006ddb 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,3 +1,4 @@
-kirin-drm-y := kirin_drm_drv.o
+kirin-drm-y := kirin_drm_drv.o \
+  kirin_drm_ade.o

 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
new file mode 100644
index ..eb444b899c7b
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -0,0 +1,290 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __KIRIN_ADE_REG_H__
+#define __KIRIN_ADE_REG_H__
+
+/*
+ * ADE Registers
+ */
+#define MASK(x)(BIT(x) - 1)
+
+#define ADE_CTRL   0x0004
+#define FRM_END_START_OFST 0
+#define FRM_END_START_MASK MASK(2)
+#define ADE_CTRL1  0x008C
+#define AUTO_CLK_GATE_EN_OFST  0
+#define AUTO_CLK_GATE_EN   BIT(0)
+#define ADE_ROT_SRC_CFG0x0010
+#define ADE_DISP_SRC_CFG   0x0018
+#define ADE_WDMA2_SRC_CFG  0x001C
+#define ADE_SEC_OVLY_SRC_CFG   0x0020
+#define ADE_WDMA3_SRC_CFG  0x0024
+#define ADE_OVLY1_TRANS_CFG0x002C
+#define ADE_EN 0x0100
+#define ADE_DISABLE0
+#define ADE_ENABLE 1
+#define INTR_MASK_CPU(x)   (0x0C10 + (x) * 0x4)
+#define ADE_FRM_DISGARD_CTRL   0x00A4
+/* reset and reload regs */
+#define ADE_SOFT_RST_SEL(x)(0x0078 + (x) * 0x4)
+#define ADE_RELOAD_DIS(x)  (0x00AC + (x) * 0x4)
+#define RDMA_OFST  0
+#define CLIP_OFST  15
+#define SCL_OFST   21
+#define CTRAN_OFST 24
+#define OVLY_OFST  37 /* 32+5 */
+/* channel regs */
+#define RD_CH_PE(x)(0x1000 + (x) * 0x80)
+#define RD_CH_CTRL(x)  (0x1004 + (x) * 0x80)
+#define RD_CH_ADDR(x)  (0x1008 + (x) * 0x80)
+#define RD_CH_SIZE(x)  (0x100C + (x) * 0x80)
+#define RD_CH_STRIDE(x)(0x1010 + (x) * 0x80)
+#define RD_CH_SPACE(x) (0x1014 + (x) * 0x80)
+#define RD_CH_PARTIAL_SIZE(x)  (0x1018 + (x) * 0x80)
+#define RD_CH_PARTIAL_SPACE(x) (0x101C + (x) * 0x80)
+#define RD_CH_EN(x)(0x1020 + (x) * 0x80)
+#define RD_CH_STATUS(x)(0x1024 + (x) * 0x80)
+#define RD_CH_DISP_CTRL0x1404
+#define RD_CH_DISP_ADDR0x1408
+#define RD_CH_DISP_SIZE0x140C
+#define RD_CH_DISP_STRIDE  0x1410
+#define RD_CH_DISP_SPACE   0x1414
+#define RD_CH_DISP_EN  0x142C
+/* clip regs */
+#define ADE_CLIP_DISABLE(x)(0x6800 + (x) * 0x100)
+#define ADE_CLIP_SIZE0(x)  (0x6804 + (x) * 0x100)
+#define ADE_CLIP_SIZE1(x)  (0x6808 + (x) * 0x100)
+#define ADE_CLIP_SIZE2(x)  (0x680C + (x) * 0x100)
+#define ADE_CLIP_CFG_OK(x) (0x6810 + (x) * 0x100)
+/* scale regs */
+#define ADE_SCL1_MUX_CFG   0x000C
+#define ADE_SCL2_SRC_CFG   0x0014
+#define ADE_SCL3_MUX_CFG   0x0008
+#define ADE_SCL_CTRL(x)(0x3000 + (x) * 0x800)
+#define ADE_SCL_HSP(x) (0x3004 + (x) * 0x800)
+#define ADE_SCL_UV_HSP(x)  (0x3008 + (x) * 0x800)
+#define ADE_SCL_VSP(x) (0x300C + (x) * 0x800)
+#define ADE_SCL_UV_VSP(x)  (0x3010 + (x) * 0x800)
+#define ADE_SCL_ORES(x)   

[PATCH v6 02/11] drm/hisilicon: Add hisilicon kirin drm master driver

2016-02-26 Thread Xinliang Liu
Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

v6: None.
v5: None.
v4: None.
v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Replace drm_platform_init, load, unload implementation.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/hisilicon/Kconfig   |   5 +
 drivers/gpu/drm/hisilicon/Makefile  |   5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig |   9 +
 drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
 8 files changed, 366 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b50ae60f5f50..f5c5656e2547 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"

 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/hisilicon/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766dec6a8d..60554832079c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-y  += hisilicon/
diff --git a/drivers/gpu/drm/hisilicon/Kconfig 
b/drivers/gpu/drm/hisilicon/Kconfig
new file mode 100644
index ..558c61b1b8e8
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+#
+# hisilicon drm device configuration.
+# Please keep this list sorted alphabetically
+
+source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
diff --git a/drivers/gpu/drm/hisilicon/Makefile 
b/drivers/gpu/drm/hisilicon/Makefile
new file mode 100644
index ..e3f6d493c996
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for hisilicon drm drivers.
+# Please keep this list sorted alphabetically
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig 
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
new file mode 100644
index ..3ac4b8edeac1
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -0,0 +1,9 @@
+config DRM_HISI_KIRIN
+   tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have a hisilicon Kirin chipsets(hi6220).
+ If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
new file mode 100644
index ..cb346de47d48
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -0,0 +1,3 @@
+kirin-drm-y := kirin_drm_drv.o
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
new file mode 100644
index ..789ebd1f5922
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -0,0 +1,321 @@
+/*
+ * Hisilicon Kirin SoCs drm master driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ * Xinliang Liu 
+ * Xinliang Liu 
+ * Xinwei Kong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "kirin_drm_drv.h"
+
+static struct kirin_dc_ops *dc_ops;
+
+static int kirin_drm_kms_cleanup(struct drm_device *dev)
+{
+   dc_ops->cleanup(dev);
+   drm_mode_config_cleanup(dev);
+
+   return 0;
+}
+
+static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
+   .fb_create = drm_fb_cma_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void kirin_drm_mode_config_init(struct drm_device *dev)
+{
+   dev->mode_config.min_width = 0;
+   dev->mode_config.min_height = 0;
+
+   dev->mode_config.max_width = 2048;
+   

[PATCH v6 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem

2016-02-26 Thread Xinliang Liu
Add ADE display controller binding doc.
Add DesignWare DSI Host Controller v1.20a binding doc.

v6:
- Cleanup values part of reg and clocks properties.
- Change "pclk_dsi" clock name to "pclk".
v5:
- Remove endpoint unit address of dsi output port.
- Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
- Add "resets" property for ADE reset.
v4:
- Describe more specific of clocks and ports.
- Fix indentation.
v3:
- Make ade as the drm master node.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
v2:
- Move dt binding docs to bindings/display/hisilicon directory.

Signed-off-by: Xinliang Liu 
---
 .../bindings/display/hisilicon/dw-dsi.txt  | 72 ++
 .../bindings/display/hisilicon/hisi-ade.txt| 64 +++
 2 files changed, 136 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt

diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt 
b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
new file mode 100644
index ..d270bfe4e4e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
@@ -0,0 +1,72 @@
+Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
+
+A DSI Host Controller resides in the middle of display controller and external
+HDMI converter or panel.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-dsi".
+- reg: physical base address and length of dsi controller's registers.
+- clocks: contains APB clock phandle + clock-specifier pair.
+- clock-names: should be "pclk".
+- ports: contains DSI controller input and output sub port.
+  The input port connects to ADE output port with the reg value "0".
+  The output port with the reg value "1", it could connect to panel or
+  any other bridge endpoints.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+A example of HiKey board hi6220 SoC and board specific DT entry:
+Example:
+
+SoC specific:
+   dsi: dsi at f4107800 {
+   compatible = "hisilicon,hi6220-dsi";
+   reg = <0x0 0xf4107800 0x0 0x100>;
+   clocks = <_ctrl  HI6220_DSI_PCLK>;
+   clock-names = "pclk";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* 0 for input port */
+   port at 0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+
+
+Board specific:
+{
+   status = "ok";
+
+   ports {
+   /* 1 for output port */
+   port at 1 {
+   reg = <1>;
+
+   dsi_out0: endpoint at 0 {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+{
+   ...
+
+   adv7533: adv7533 at 39 {
+   ...
+
+   port {
+   adv7533_in: endpoint {
+   remote-endpoint = <_out0>;
+   };
+   };
+   };
+   };
+
diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt 
b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
new file mode 100644
index ..38dc9d60eef8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
@@ -0,0 +1,64 @@
+Device-Tree bindings for hisilicon ADE display controller driver
+
+ADE (Advanced Display Engine) is the display controller which grab image
+data from memory, do composition, do post image processing, generate RGB
+timing stream and transfer to DSI.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-ade".
+- reg: physical base address and length of the ADE controller's registers.
+- hisilicon,noc-syscon: ADE NOC QoS syscon.
+- resets: The ADE reset controller node.
+- interrupt: the ldi vblank interrupt number used.
+- clocks: a list of phandle + clock-specifier pairs, one for each entry
+  in clock-names.
+- clock-names: should contain:
+  "clk_ade_core" for the ADE core clock.
+  "clk_codec_jpeg" for the media NOC QoS clock, which use the same clock with
+  jpeg codec.
+  "clk_ade_pix" for the ADE pixel clok.
+- assigned-clocks: Should contain "clk_ade_core" and "clk_codec_jpeg" clocks'
+  phandle + clock-specifier pairs.
+- assigned-clock-rates: clock rates, one for each entry in assigned-clocks.
+  The rate of 

[PATCH v6 00/11] Add DRM Driver for HiSilicon Kirin hi6220 SoC

2016-02-26 Thread Xinliang Liu
This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
Current testing and support board is Hikey board which is one of Linaro
96boards. It is an arm64 open source board. For more information about
this board, please access https://www.96boards.org.

Hardware Detail
---
  The display subsystem of Hi6220 SoC is shown as bellow:
 +-+   +--+ +-+ +-+
 | |   |  | | | | | 
 | FB  |-->|   ADE|>| DSI |>|   External  |
 | |   |  | | | |  HDMI/panel |
 +-+   +--+ +-+ +-+

- ADE(Advanced Display Engine) is the display controller. It contains 7
channels, 3 overlay compositors and a LDI.
  - A channel looks like: DMA-->clip-->scale-->ctrans(or called csc).
  - Overlay compositor is response to compose planes which come from 7
  channels and pass composed image to LDI.
  - LDI is response to generate timings and RGB data stream.
- DSI converts the RGB data stream from ADE to DSI packets.
- External HDMI/panel module is connected with DSI bus. Now Hikey use a
  ADI's ADV7533 external HDMI chip.

Change History
-
Changes in v6:
- Cleanup values part of reg and clocks relevant properties.
- Change "pclk_dsi" clock name to "pclk".

Changes in v5:
- Remove endpoint unit address of dsi output port.
- Use syscon to access ADE media NOC QoS registers instread of directly
  writing registers.
- Use reset controller to reset ADE instead of directly writing registers.

Changes in v4:
- Describe more specific of clocks and ports of binding docs.
- Fix indentation of binding docs.

Changes in v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Make ade as the drm master node.
- Replace drm_platform_init, load, unload implementation.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
- Rename hisi_drm_dsi.c to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup on regs and code.

Changes in v2:
- Remove abtraction layer of plane/crtc/encoder/connector.
- Refactor atomic implementation according to Daniel Vetter's guides:
http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
http://blog.ffwll.ch/2015/09/xdc-2015-atomic-modesetting-for-drivers.html
http://blog.ffwll.ch/2015/08/atomic-modesetting-design-overview.html
- Use bridge instead of slave encoder to connect external HDMI.
- Move dt binding docs to bindings/display/hisilicon directory.

Xinliang Liu (11):
  drm/hisilicon: Add device tree binding for hi6220 display subsystem
  drm/hisilicon: Add hisilicon kirin drm master driver
  drm/hisilicon: Add crtc driver for ADE
  drm/hisilicon: Add plane driver for ADE
  drm/hisilicon: Add vblank driver for ADE
  drm/hisilicon: Add cma fbdev and hotplug
  drm/hisilicon: Add designware dsi encoder driver
  drm/hisilicon: Add designware dsi host driver
  drm/hisilicon: Add support for external bridge
  MAINTAINERS: Add maintainer for hisilicon DRM driver
  arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

 .../bindings/display/hisilicon/dw-dsi.txt  |   72 ++
 .../bindings/display/hisilicon/hisi-ade.txt|   64 ++
 MAINTAINERS|   10 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   40 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |   55 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/hisilicon/Kconfig  |5 +
 drivers/gpu/drm/hisilicon/Makefile |5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig|   10 +
 drivers/gpu/drm/hisilicon/kirin/Makefile   |5 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c   |  845 
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h   |   83 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h|  290 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 1047 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  382 +++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h|   31 +
 17 files changed, 2947 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
 

[Bug 94242] [radeonsi] Crash while running Fedora mock tool for prompting root (gtksu)

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94242

--- Comment #11 from Marek Olšák  ---
The problematic shader is attached. It has "s_branch" at the end "ret"
somewhere in the middle. My initial theory is that the shader fails to jump to
the epilog, which is outside of the binary, and jumps somewhere else. It may be
even stuck in an infinite loop due to an incorrect jump.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/7d65fd7d/attachment.html>


[Bug 94242] [radeonsi] Crash while running Fedora mock tool for prompting root (gtksu)

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94242

--- Comment #10 from Marek Olšák  ---
Created attachment 121988
  --> https://bugs.freedesktop.org/attachment.cgi?id=121988=edit
problematic shader

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/db331661/attachment.html>


[Intel-gfx] [PATCH] drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)

2016-02-26 Thread Imre Deak
On pe, 2016-02-26 at 00:20 +0200, Imre Deak wrote:
> On Thu, 2016-02-25 at 21:10 +, Chris Wilson wrote:
> > commit 09731280028ce03e6a27e1998137f1775a2839f3
> > Author: Imre Deak 
> > Date:   Wed Feb 17 14:17:42 2016 +0200
> > 
> >     drm/i915: Add helper to get a display power ref if it was
> > already
> > enabled
> > 
> > left the rpm wakelock assertions unbalanced if CONFIG_PM was
> > disabled
> > as
> > intel_runtime_pm_get_if_in_use() would return true without
> > incrementing
> > the local bookkeeping required for the assertions.
> > 
> > Signed-off-by: Chris Wilson 
> > CC: Mika Kuoppala 
> > CC: Joonas Lahtinen 
> > CC: Ville Syrjälä 
> > Cc: Imre Deak 
> 
> Arg, I broke this in v3. Thanks for catching it:
> Reviewed-by: Imre Deak 

Thanks for the patch I pushed it to drm-intel-next-queued.

Dave, this fixes one patch in the following pull request:
https://lists.freedesktop.org/archives/intel-gfx/2016-February/088249.html

--Imre

> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 26 -
> > --
> > ---
> >  1 file changed, 12 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index e2329768902c..4172e73212cd 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -2365,22 +2365,20 @@ bool intel_runtime_pm_get_if_in_use(struct
> > drm_i915_private *dev_priv)
> >  {
> >    struct drm_device *dev = dev_priv->dev;
> >    struct device *device = >pdev->dev;
> > -   int ret;
> >  
> > -   if (!IS_ENABLED(CONFIG_PM))
> > -   return true;
> > +   if (IS_ENABLED(CONFIG_PM)) {
> > +   int ret = pm_runtime_get_if_in_use(device);
> >  
> > -   ret = pm_runtime_get_if_in_use(device);
> > -
> > -   /*
> > -    * In cases runtime PM is disabled by the RPM core and we
> > get an
> > -    * -EINVAL return value we are not supposed to call this
> > function,
> > -    * since the power state is undefined. This applies atm to
> > the
> > -    * late/early system suspend/resume handlers.
> > -    */
> > -   WARN_ON_ONCE(ret < 0);
> > -   if (ret <= 0)
> > -   return false;
> > +   /*
> > +    * In cases runtime PM is disabled by the RPM core
> > and we get
> > +    * an -EINVAL return value we are not supposed to
> > call this
> > +    * function, since the power state is undefined.
> > This applies
> > +    * atm to the late/early system suspend/resume
> > handlers.
> > +    */
> > +   WARN_ON_ONCE(ret < 0);
> > +   if (ret <= 0)
> > +   return false;
> > +   }
> >  
> >    atomic_inc(_priv->pm.wakeref_count);
> >    assert_rpm_wakelock_held(dev_priv);
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[PATCH 3/5] drm: introduce pipe color correction properties

2016-02-26 Thread Lionel Landwerlin
On 26/02/16 00:36, Emil Velikov wrote:
> Hi Lionel,
>
> A bunch of suggestions - feel free to take or ignore them :-)
>
> On 25 February 2016 at 10:58, Lionel Landwerlin
>  wrote:
>> Patch based on a previous series by Shashank Sharma.
>>
>> This introduces optional properties to enable color correction at the
>> pipe level. It relies on 3 transformations applied to every pixels
>> displayed. First a lookup into a degamma table, then a multiplication
>> of the rgb components by a 3x3 matrix and finally another lookup into
>> a gamma table.
>>
>> The following properties can be added to a pipe :
>>- DEGAMMA_LUT : blob containing degamma LUT
>>- DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
>>- CTM : transformation matrix applied after the degamma LUT
>>- GAMMA_LUT : blob containing gamma LUT
>>- GAMMA_LUT_SIZE : number of elements in GAMMA_LUT
>>
>> DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
>> the driver to tell userspace applications what sizes should be the
>> lookup tables in DEGAMMA_LUT and GAMMA_LUT.
>>
>> A helper is also provided so legacy gamma correction is redirected
>> through these new properties.
>>
>> v2: Register LUT size properties as range
>>
>> v3: Fix round in drm_color_lut_get_value() helper
>>  More docs on how degamma/gamma properties are used
>>
>> v4: Update contributors
>>
>> v5: Rename CTM_MATRIX property to CTM (Doh!)
>>  Add legacy gamma_set atomic helper
>>  Describe CTM/LUT acronyms in the kernel doc
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Lionel Landwerlin 
>> Signed-off-by: Kumar, Kiran S 
>> Signed-off-by: Kausal Malladi 
> The above should be kept in the order of which people worked on them.
>
>> Reviewed-by: Matt Roper 
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -376,6 +377,57 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
>> drm_crtc_state *state,
>>   EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
>>
>>   /**
>> + * drm_atomic_replace_property_blob - replace a blob property
>> + * @blob: a pointer to the member blob to be replaced
>> + * @new_blob: the new blob to replace with
>> + * @expected_size: the expected size of the new blob
>> + * @replaced: whether the blob has been replaced
>> + *
>> + * RETURNS:
>> + * Zero on success, error code on failure
>> + */
>> +static int
>> +drm_atomic_replace_property_blob(struct drm_property_blob **blob,
>> +struct drm_property_blob *new_blob,
>> +bool *replaced)
> "Replaced" here and though the rest of the patch is used as "changed".
> Worth naming it that way ?
I think the former describes the action, the later the state.

>
>> +{
>> +   struct drm_property_blob *old_blob = *blob;
>> +
>> +   if (old_blob == new_blob)
>> +   return 0;
>> +
>> +   if (old_blob)
>> +   drm_property_unreference_blob(old_blob);
>> +   if (new_blob)
>> +   drm_property_reference_blob(new_blob);
>> +   *blob = new_blob;
>> +   *replaced = true;
>> +
>> +   return 0;
> The function always succeeds - drop the return value ?
Well spotted, dropping.

>> +}
>> +
>> +static int
>> +drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc,
>> +struct drm_property_blob **blob,
>> +uint64_t blob_id,
>> +ssize_t expected_size,
>> +bool *replaced)
>> +{
>> +   struct drm_device *dev = crtc->dev;
>> +   struct drm_property_blob *new_blob = NULL;
>> +
>> +   if (blob_id != 0) {
>> +   new_blob = drm_property_lookup_blob(dev, blob_id);
>> +   if (new_blob == NULL)
>> +   return -EINVAL;
>> +   if (expected_size > 0 && expected_size != new_blob->length)
>> +   return -EINVAL;
>> +   }
>> +
> Having a look at drm_atomic_set_mode_prop_for_crtc() I think I can
> spot a bug - it shouldn't drop/unref the old blob in case of an error.
> A case you handle nicely here. Perhaps it's worth using the
> drm_atomic_replace_property_blob() in there ?

I'm not sure it matters as the drm_crtc_state you're set properties on 
will be discarded if there is an error.
The current drm_crtc_state that has been applied onto the hardware 
should be untouched.

>
>> @@ -397,6 +449,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>>   {
>>  struct drm_device *dev = crtc->dev;
>>  struct drm_mode_config *config = >mode_config;
>> +   bool replaced = false;
>>  int ret;
>>
>>  if (property == config->prop_active)
>> @@ -407,8 +460,31 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>>  ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
>>  drm_property_unreference_blob(mode);
>>  

[PATCH v4 5/5] staging/android: add flags member to sync ioctl structs

2016-02-26 Thread Gustavo Padovan
From: Gustavo Padovan 

Play safe and add flags member to all structs. So we don't need to
break API or create new IOCTL in the future if new features that requires
flags arises.

v2: check if flags are valid (zero, in this case)

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 7 ++-
 drivers/staging/android/uapi/sync.h | 6 ++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 837cff5..54fd5ab 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
goto err_put_fd;
}

+   if (data.flags) {
+   err = -EFAULT;
+   goto err_put_fd;
+   }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -511,7 +516,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (copy_from_user(, (void __user *)arg, sizeof(*info)))
return -EFAULT;

-   if (in.status || strcmp(in.name, "\0"))
+   if (in.status || in.flags || strcmp(in.name, "\0"))
return -EFAULT;

if (in.num_fences && !in.sync_fence_info)
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index 9aad623..f56a6c2 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -19,11 +19,13 @@
  * @fd2:   file descriptor of second fence
  * @name:  name of new fence
  * @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
  */
 struct sync_merge_data {
__s32   fd2;
charname[32];
__s32   fence;
+   __u32   flags;
 };

 /**
@@ -31,12 +33,14 @@ struct sync_merge_data {
  * @obj_name:  name of parent sync_timeline
  * @driver_name:   name of driver implementing the parent
  * @status:status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
  * @timestamp_ns:  timestamp of status change in nanoseconds
  */
 struct sync_fence_info {
charobj_name[32];
chardriver_name[32];
__s32   status;
+   __u32   flags;
__u64   timestamp_ns;
 };

@@ -44,6 +48,7 @@ struct sync_fence_info {
  * struct sync_file_info - data returned from fence info ioctl
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
  * @num_fences number of fences in the sync_file
  * @len:   ioctl caller writes the size of the buffer its passing in.
  * ioctl returns length of all fence_infos summed.
@@ -52,6 +57,7 @@ struct sync_fence_info {
 struct sync_file_info {
charname[32];
__s32   status;
+   __u32   flags;
__u32   num_fences;
__u32   len;

-- 
2.5.0



[PATCH v4 4/5] staging/android: refactor SYNC_IOC_FILE_INFO

2016-02-26 Thread Gustavo Padovan
From: Gustavo Padovan 

Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer allocation. In the new approach the ioctl needs to be called
twice to retrieve the array of fence_infos pointed by info->sync_fence_info.

The first call should pass num_fences = 0, the kernel will then fill
info->num_fences. Userspace receives back the number of fences and
allocates a buffer size num_fences * sizeof(struct sync_fence_info) on
info->sync_fence_info.

It then call the ioctl again passing num_fences received in info->num_fences.
The kernel checks if info->num_fences > 0 and if yes it fill
info->sync_fence_info with an array containing all fence_infos.

info->len now represents the length of the buffer sync_fence_info points
to. Also, info->sync_fence_info was converted to __u64 pointer.

An example userspace code would be:

struct sync_file_info *info;
int err, size, num_fences;

info = malloc(sizeof(*info));

memset(info, 0, sizeof(*info));

err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;

if (num_fences) {
memset(info, 0, sizeof(*info));
size = sizeof(struct sync_fence_info) * num_fences;
info->len = size;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
  sizeof(struct 
sync_fence_info));

err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 56 +
 drivers/staging/android/uapi/sync.h |  9 +++---
 2 files changed, 48 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..837cff5 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -502,21 +502,22 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
 {
-   struct sync_file_info *info;
+   struct sync_file_info in, *info;
+   struct sync_fence_info *fence_info;
__u32 size;
__u32 len = 0;
int ret, i;

-   if (copy_from_user(, (void __user *)arg, sizeof(size)))
+   if (copy_from_user(, (void __user *)arg, sizeof(*info)))
return -EFAULT;

-   if (size < sizeof(struct sync_file_info))
-   return -EINVAL;
+   if (in.status || strcmp(in.name, "\0"))
+   return -EFAULT;

-   if (size > 4096)
-   size = 4096;
+   if (in.num_fences && !in.sync_fence_info)
+   return -EFAULT;

-   info = kzalloc(size, GFP_KERNEL);
+   info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;

@@ -525,24 +526,55 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (info->status >= 0)
info->status = !info->status;

-   info->num_fences = sync_file->num_fences;
+   /*
+* Passing num_fences = 0 means that userspace want to know how
+* many fences are in the sync_file to be able to allocate a buffer to
+* fit all sync_fence_infos and call the ioctl again with the buffer
+* assigned to info->sync_fence_info. The second call pass the
+* num_fences value received in the first call.
+*/
+   if (!in.num_fences)
+   goto no_fences;

-   len = sizeof(struct sync_file_info);
+   size = sync_file->num_fences * sizeof(*fence_info);
+   if (in.len != size) {
+   ret = -EFAULT;
+   goto out;
+   }
+
+   fence_info = kzalloc(size, GFP_KERNEL);
+   if (!fence_info) {
+   ret = -ENOMEM;
+   goto out;
+   }

for (i = 0; i < sync_file->num_fences; ++i) {
struct fence *fence = sync_file->cbs[i].fence;

-   ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
+   ret = sync_fill_fence_info(fence, (u8 *)fence_info + len,
+  size - len);

-   if (ret < 0)
+   if (ret < 0) {
+   kfree(fence_info);
goto out;
+   }

len += ret;
}

+   if (copy_to_user((void __user *)in.sync_fence_info, fence_info, size)) {
+   ret = -EFAULT;
+   kfree(fence_info);
+   goto out;
+   }
+
info->len = len;
+   info->sync_fence_info = (__u64) in.sync_fence_info;
+
+no_fences:
+   info->num_fences = sync_file->num_fences;

-   if (copy_to_user((void __user *)arg, info, len))
+   if (copy_to_user((void __user *)arg, info, sizeof(*info)))

[PATCH v4 3/5] staging/android: remove redundant comments on sync_merge_data

2016-02-26 Thread Gustavo Padovan
From: Gustavo Padovan 

struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/uapi/sync.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index dd0dd84..f0b41ce 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
  * @fence: returns the fd of the new fence to userspace
  */
 struct sync_merge_data {
-   __s32   fd2; /* fd of second fence */
-   charname[32]; /* name of new fence */
-   __s32   fence; /* fd on newly created fence */
+   __s32   fd2;
+   charname[32];
+   __s32   fence;
 };

 /**
-- 
2.5.0



[PATCH v4 2/5] staging/android: rename SYNC_IOC_FENCE_INFO

2016-02-26 Thread Gustavo Padovan
From: Gustavo Padovan 

We don't use the 'fence' name to refer to sync_file anymore. So rename it
to SYNC_IOC_FILE_INFO.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 2 +-
 drivers/staging/android/uapi/sync.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 31aa462..dc5f382 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -562,7 +562,7 @@ static long sync_file_ioctl(struct file *file, unsigned int 
cmd,
case SYNC_IOC_MERGE:
return sync_file_ioctl_merge(sync_file, arg);

-   case SYNC_IOC_FENCE_INFO:
+   case SYNC_IOC_FILE_INFO:
return sync_file_ioctl_fence_info(sync_file, arg);

default:
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index 4ffb7cc..dd0dd84 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -81,6 +81,6 @@ struct sync_file_info {
  * pt_info is a buffer containing sync_pt_infos for every sync_pt in the fence.
  * To iterate over the sync_pt_infos, use the sync_pt_info.len field.
  */
-#define SYNC_IOC_FENCE_INFO_IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
+#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)

 #endif /* _UAPI_LINUX_SYNC_H */
-- 
2.5.0



[PATCH v4 1/5] staging/android: add num_fences field to struct sync_file_info

2016-02-26 Thread Gustavo Padovan
From: Gustavo Padovan 

Inform userspace how many fences are in the sync_fence_info field.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 2 ++
 drivers/staging/android/uapi/sync.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..31aa462 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -525,6 +525,8 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (info->status >= 0)
info->status = !info->status;

+   info->num_fences = sync_file->num_fences;
+
len = sizeof(struct sync_file_info);

for (i = 0; i < sync_file->num_fences; ++i) {
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index a0cf357..4ffb7cc 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -47,12 +47,14 @@ struct sync_fence_info {
  * userspace including pt_info.
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @num_fences number of fences in the sync_file
  * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
  */
 struct sync_file_info {
__u32   len;
charname[32];
__s32   status;
+   __u32   num_fences;

__u8sync_fence_info[0];
 };
-- 
2.5.0



[PATCH v3 2/2] drm: remove drm_device_is_unplugged and related code

2016-02-26 Thread David Herrmann
Hi

On Fri, Feb 12, 2016 at 8:50 PM, Haixia Shi  wrote:
> v1: Remove the general drm_device_is_unplugged() checks, and move the 
> unplugged
> flag handling logic into drm/udl. In general we want to keep driver-specific
> logic out of common drm code.
>
> v2: Based on discussion with Stephane and David, drop most of the unplugged
> flag handling logic in drm/udl except for udl_detect() and udl_fb_open().
> The intention is to treat the device removal as a connector-unplug, and kep
> the UDL device fully functional.
>
> v3: Based on feedback from David, entirely drop the "unplugged" flag and all
> related code. There is no need to check for the unplugged flag as the existing
> udl_usb_disconnect() behavior already ensures the controller is removed, and
> all code paths that uses the usb-device are not reachable after unplug.
>
> When a UDL monitor is unplugged, we need to still treat it as a fully
> functional device which just happens to have its connector unplugged.
> This allows user-space to properly deallocate fbs and dumb buffers
> before closing the device.
>
> This drops the "unplugged" flag hack, which puts the device in a
> non-functional state after USB unplug and rejects most operations on
> the device such as ioctls with error -ENODEV.
>
> Signed-off-by: Haixia Shi 
> Reviewed-by: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_drv.c   |  6 --
>  drivers/gpu/drm/drm_fops.c  |  2 --
>  drivers/gpu/drm/drm_gem.c   |  3 ---
>  drivers/gpu/drm/drm_ioctl.c |  3 ---
>  drivers/gpu/drm/drm_vm.c|  3 ---
>  drivers/gpu/drm/udl/udl_connector.c |  2 --
>  drivers/gpu/drm/udl/udl_fb.c|  6 --
>  include/drm/drmP.h  | 14 --
>  8 files changed, 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 167c8d3..f93ee12 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -376,9 +376,6 @@ struct drm_minor *drm_minor_acquire(unsigned int minor_id)
>
> if (!minor) {
> return ERR_PTR(-ENODEV);
> -   } else if (drm_device_is_unplugged(minor->dev)) {
> -   drm_dev_unref(minor->dev);
> -   return ERR_PTR(-ENODEV);
> }
>
> return minor;
> @@ -464,9 +461,6 @@ void drm_unplug_dev(struct drm_device *dev)
> drm_minor_unregister(dev, DRM_MINOR_CONTROL);
>
> mutex_lock(_global_mutex);
> -
> -   drm_device_set_unplugged(dev);
> -
> if (dev->open_count == 0) {
> drm_put_dev(dev);
> }
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 1ea8790..b4332d4 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -497,8 +497,6 @@ int drm_release(struct inode *inode, struct file *filp)
>
> if (!--dev->open_count) {
> retcode = drm_lastclose(dev);
> -   if (drm_device_is_unplugged(dev))
> -   drm_put_dev(dev);

Who frees the udl device now? What code-path is responsible to call
drm_dev_unregister() for udl devices? This hunk looks bogus to me.
Please elaborate.

> }
> mutex_unlock(_global_mutex);
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 2e8c77e..c622e32 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -900,9 +900,6 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct 
> *vma)
> struct drm_vma_offset_node *node;
> int ret;
>
> -   if (drm_device_is_unplugged(dev))
> -   return -ENODEV;
> -
> drm_vma_offset_lock_lookup(dev->vma_offset_manager);
> node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
>   vma->vm_pgoff,
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 8ce2a0c..f959074 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -695,9 +695,6 @@ long drm_ioctl(struct file *filp,
>
> dev = file_priv->minor->dev;
>
> -   if (drm_device_is_unplugged(dev))
> -   return -ENODEV;
> -
> is_driver_ioctl = nr >= DRM_COMMAND_BASE && nr < DRM_COMMAND_END;
>
> if (is_driver_ioctl) {
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index f90bd5f..3a68be4 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -657,9 +657,6 @@ int drm_legacy_mmap(struct file *filp, struct 
> vm_area_struct *vma)
> struct drm_device *dev = priv->minor->dev;
> int ret;
>
> -   if (drm_device_is_unplugged(dev))
> -   return -ENODEV;
> -
> mutex_lock(>struct_mutex);
> ret = drm_mmap_locked(filp, vma);
> mutex_unlock(>struct_mutex);
> diff --git a/drivers/gpu/drm/udl/udl_connector.c 
> b/drivers/gpu/drm/udl/udl_connector.c
> index 4709b54..a6d5e21 

[PATCH] drm/ast: Fix incorrect register check for DRAM width

2016-02-26 Thread Timothy Pearson
During DRAM initialization on certain ASpeed devices, an incorrect
bit (bit 10) was checked in the "SDRAM Bus Width Status" register
to determine DRAM width.

Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.

Signed-off-by: Timothy Pearson 
---
 drivers/gpu/drm/ast/ast_main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 9759009..b1480ac 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -227,7 +227,7 @@ static int ast_get_dram_info(struct drm_device *dev)
} while (ast_read32(ast, 0x1) != 0x01);
data = ast_read32(ast, 0x10004);

-   if (data & 0x400)
+   if (data & 0x40)
ast->dram_bus_width = 16;
else
ast->dram_bus_width = 32;
-- 
1.7.9.5


[Bug 94242] [radeonsi] Crash while running Fedora mock tool for prompting root (gtksu)

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94242

--- Comment #9 from Marek Olšák  ---
The first bad commit:

commit 98ef4478258fda9028cd1786841eca952c136319
Author: Tom Stellard 
Date:   Fri Feb 12 23:45:29 2016 +

AMDGPU/SI: Detect uniform branches and emit s_cbranch instructions

Reviewers: arsenm

Subscribers: mareko, MatzeB, qcolombet, arsenm, llvm-commits

Differential Revision: http://reviews.llvm.org/D16603

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 260765
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/78033e7f/attachment.html>


[PATCH, RESEND] drm: avoid uninitialized timestamp use in wait_vblank

2016-02-26 Thread David Herrmann
Hi

On Thu, Feb 25, 2016 at 10:09 PM, Arnd Bergmann  wrote:
> gcc warns about the timestamp in drm_wait_vblank being possibly
> used without an initialization:
>
> drivers/gpu/drm/drm_irq.c: In function 'drm_wait_vblank':
> drivers/gpu/drm/drm_irq.c:1755:28: warning: 'now.tv_usec' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>vblwait->reply.tval_usec = now.tv_usec;
> drivers/gpu/drm/drm_irq.c:1754:27: warning: 'now.tv_sec' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>vblwait->reply.tval_sec = now.tv_sec;
>
> This can happen if drm_vblank_count_and_time() returns 0 in its
> error path. To sanitize the error case, I'm changing that function
> to return a zero timestamp when it fails.
>
> Signed-off-by: Arnd Bergmann 
> Fixes: e6ae8687a87b ("drm: idiot-proof vblank")
> ---
>  drivers/gpu/drm/drm_irq.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> I'm going through the maybe-unused warnings in randconfig builds, this one is
> apparently not a false positive, although it only happens if something
> else has already gone wrong.
>
> Originally sent out on Jan 13, but I received no reply, so resending now.
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 881c5a6c180c..6f41ddfbe061 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -997,8 +997,10 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, 
> unsigned int pipe,
> int count = DRM_TIMESTAMP_MAXRETRIES;
> u32 cur_vblank;
>
> -   if (WARN_ON(pipe >= dev->num_crtcs))
> +   if (WARN_ON(pipe >= dev->num_crtcs)) {
> +   *vblanktime = (struct timeval) { 0 };

The '0' is redundant. Anyway, this is:

Reviewed-by: David Herrmann 

(CC: Daniel, for drm-misc)

Thanks
David

> return 0;
> +   }
>
> /*
>  * Vblank timestamps are read lockless. To ensure consistency the 
> vblank
> --
> 2.7.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[patch] drm/rockchip: inno_hdmi: fix an error code

2016-02-26 Thread Yakir Yang
Dan,

On 02/26/2016 05:30 AM, Dan Carpenter wrote:
> We were accidentally returning PTR_ERR(NULL) which means success when we
> wanted to return a negative error code.
>
> Fixes: 412d4ae6b7a5 ('drm/rockchip: hdmi: add Innosilicon HDMI support')
> Signed-off-by: Dan Carpenter 
Reviewed-by: Yakir Yang 

Thanks,
- Yakir
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index 10d62ff..f252441 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -855,8 +855,9 @@ static int inno_hdmi_bind(struct device *dev, struct 
> device *master,
>   
>   hdmi->ddc = inno_hdmi_i2c_adapter(hdmi);
>   if (IS_ERR(hdmi->ddc)) {
> + ret = PTR_ERR(hdmi->ddc);
>   hdmi->ddc = NULL;
> - return PTR_ERR(hdmi->ddc);
> + return ret;
>   }
>   
>   /*
>
>
>




[PATCH v6 02/11] drm/hisilicon: Add hisilicon kirin drm master driver

2016-02-26 Thread Archit Taneja
Hi,

I had some minor comments. Sorry about sharing this late. Otherwise,
the looks good to me.

On 02/26/2016 02:10 PM, Xinliang Liu wrote:
> Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
> Add dumb buffer feature.
> Add prime dmabuf feature.
>
> v6: None.
> v5: None.
> v4: None.
> v3:
> - Move and rename all the files to kirin sub-directory.
>So that we could separate different seires SoCs' driver.
> - Replace drm_platform_init, load, unload implementation.
> v2:
> - Remove abtraction layer.
>
> Signed-off-by: Xinliang Liu 
> ---
>   drivers/gpu/drm/Kconfig |   2 +
>   drivers/gpu/drm/Makefile|   1 +
>   drivers/gpu/drm/hisilicon/Kconfig   |   5 +
>   drivers/gpu/drm/hisilicon/Makefile  |   5 +
>   drivers/gpu/drm/hisilicon/kirin/Kconfig |   9 +
>   drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321 
> 
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
>   8 files changed, 366 insertions(+)
>   create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
>   create mode 100644 drivers/gpu/drm/hisilicon/Makefile
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b50ae60f5f50..f5c5656e2547 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
>   source "drivers/gpu/drm/vc4/Kconfig"
>
>   source "drivers/gpu/drm/etnaviv/Kconfig"
> +
> +source "drivers/gpu/drm/hisilicon/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 61766dec6a8d..60554832079c 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -74,3 +74,4 @@ obj-y   += panel/
>   obj-y   += bridge/
>   obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>   obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> +obj-y+= hisilicon/
> diff --git a/drivers/gpu/drm/hisilicon/Kconfig 
> b/drivers/gpu/drm/hisilicon/Kconfig
> new file mode 100644
> index ..558c61b1b8e8
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/Kconfig
> @@ -0,0 +1,5 @@
> +#
> +# hisilicon drm device configuration.
> +# Please keep this list sorted alphabetically
> +
> +source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
> diff --git a/drivers/gpu/drm/hisilicon/Makefile 
> b/drivers/gpu/drm/hisilicon/Makefile
> new file mode 100644
> index ..e3f6d493c996
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for hisilicon drm drivers.
> +# Please keep this list sorted alphabetically
> +
> +obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
> diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig 
> b/drivers/gpu/drm/hisilicon/kirin/Kconfig
> new file mode 100644
> index ..3ac4b8edeac1
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
> @@ -0,0 +1,9 @@
> +config DRM_HISI_KIRIN
> + tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_CMA_HELPER
> + help
> +   Choose this option if you have a hisilicon Kirin chipsets(hi6220).
> +   If M is selected the module will be called kirin-drm.
> diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
> b/drivers/gpu/drm/hisilicon/kirin/Makefile
> new file mode 100644
> index ..cb346de47d48
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
> @@ -0,0 +1,3 @@
> +kirin-drm-y := kirin_drm_drv.o
> +
> +obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> new file mode 100644
> index ..789ebd1f5922
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -0,0 +1,321 @@
> +/*
> + * Hisilicon Kirin SoCs drm master driver
> + *
> + * Copyright (c) 2016 Linaro Limited.
> + * Copyright (c) 2014-2016 Hisilicon Limited.
> + *
> + * Author:
> + *   Xinliang Liu 
> + *   Xinliang Liu 
> + *   Xinwei Kong 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "kirin_drm_drv.h"
> +
> +static struct kirin_dc_ops *dc_ops;
> +
> +static int kirin_drm_kms_cleanup(struct drm_device *dev)
> +{
> + dc_ops->cleanup(dev);
> + drm_mode_config_cleanup(dev);
> +
> + return 0;

[RFC] drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder

2016-02-26 Thread Archit Taneja


On 02/26/2016 04:34 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> Thank you for the patch, I finally got around to testing it. Sorry for the
> delay.
>
> On Saturday 09 January 2016 22:22:26 Archit Taneja wrote:
>> The hdmi output in rcar-du uses the i2c slave encoder interface to link
>> to the adv7511 encoder chip. The kms driver creates encoder and connector
>> entities that internally uses the drm_encoder_slave_funcs ops provided by
>> the slave encoder driver.
>>
>> Change the driver such that it expects a bridge entity instead of a slave
>> encoder. The hdmi connector code isn't needed anymore as we expect the
>> adv7511 bridge driver to create/manage the connector.
>>
>> Note that the kms driver still expects a connector node for hdmi to be
>> present in DT. This node has no connection to the connector created
>> by the bridge driver.
>>
>> Compile tested only.
>
> And doesn't apply anymore, but that's my fault for not reviewing it fast
> enough, so I've rebased it (as well as your "[PATCH] drm: i2c: adv7511:
> Convert to drm_bridge" patch). I've pushed the result to
>
>   git://linuxtv.org/pinchartl/media.git drm/du/bridge
>
> The rebase wasn't difficult, I don't have much to say about that. What I must
> report, however, is that it doesn't work :-/ I receive the following kernel
> warning:
>
> [2.165569] [ cut here ]
> [2.170205] WARNING: CPU: 2 PID: 6 at
> /home/laurent/src/iob/renesas/linux/lib/kobject.c:244
> kobject_add_internal+0x134/0x364()
> [2.181627] kobject_add_internal failed for card0-HDMI-A-1 (error: -2
> parent: card0)
> [2.189394] Modules linked in:
> [2.192466] CPU: 2 PID: 6 Comm: kworker/u16:0 Not tainted 4.5.0-rc5-00677-
> g6e2d7cd77473 #649
> [2.200914] Hardware name: Generic R8A7790 (Flattened Device Tree)
> [2.207103] Workqueue: deferwq deferred_probe_work_func
> [2.212341] Backtrace:
> [2.214816] [] (dump_backtrace) from []
> (show_stack+0x20/0x24)
> [2.222396]  r6:c0591910 r5: r4:6013 r3:ea0e4000
> [2.228104] [] (show_stack) from []
> (dump_stack+0x8c/0xac)
> [2.235339] [] (dump_stack) from []
> (warn_slowpath_common+0x88/0xc4)
> [2.243438]  r5:00f4 r4:ea0e5b48
> [2.247038] [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x40/0x48)
> [2.255746]  r8:ea38ac08 r7:ea38ac00 r6:fffe r5: r4:ea38aa08
> [2.262503] [] (warn_slowpath_fmt) from []
> (kobject_add_internal+0x134/0x364)
> [2.271385]  r3:c04715c8 r2:c0591bf4
> [2.274986] [] (kobject_add_internal) from []
> (kobject_add+0x54/0x9c)
> [2.283173]  r8: r7:ea38ac00 r6:ea38ac08 r5: r4:ea38aa08
> [2.289938] [] (kobject_add) from []
> (device_add+0xe0/0x558)
> [2.297343]  r3: r2:
> [2.300938]  r6:ea38aa08 r5: r4:ea38aa00
> [2.305592] [] (device_add) from []
> (device_create_groups_vargs+0xb0/0xe0)
> [2.314213]  r10:e87af86c r9:e87c826c r8: r7:ea38ac00 r6:e9a1f960
> r5:e9a18a40
> [2.322101]  r4:ea38aa00
> [2.324651] [] (device_create_groups_vargs) from []
> (device_create_with_groups+0x34/0x3c)
> [2.334575]  r8:e9a1f940 r7:c069ccec r6:c08d4a54 r5:ea388c00 r4:c069ccec
> r3:e9a1f960
> [2.342385] [] (device_create_with_groups) from []
> (drm_sysfs_connector_add+0x6c/0xe0)
> [2.352048]  r4:e9a1f960
> [2.354600] [] (drm_sysfs_connector_add) from []
> (drm_connector_register+0x4c/0x7c)
> [2.364002]  r7:ea388c00 r6:ea388d70 r5:e9a1f974 r4:e9a1f960
> [2.369709] [] (drm_connector_register) from []
> (adv7511_bridge_attach+0x5c/0xa8)
> [2.378938]  r7:e99fa550 r6: r5:e9a1f960 r4:e9a1f940
> [2.384643] [] (adv7511_bridge_attach) from []
> (drm_bridge_attach+0x48/0x64)
> [2.393438]  r6: r5:e9814010 r4:e99f1c90 r3:c02c3214
> [2.399142] [] (drm_bridge_attach) from []
> (rcar_du_hdmienc_init+0x94/0x108)
> [2.407942] [] (rcar_du_hdmienc_init) from []
> (rcar_du_encoder_init+0x14c/0x19c)
> [2.417084]  r8:0002 r7:0004 r6:0002 r5:e9814010 r4:e99f1c90
> [2.423840] [] (rcar_du_encoder_init) from []
> (rcar_du_modeset_init+0x4a4/0x574)
> [2.432982]  r10:0002 r8:0001 r7:c04b7e10 r6:e87af86c r5:e87b88b4
> r4:e9814010
> [2.440873] [] (rcar_du_modeset_init) from []
> (rcar_du_probe+0xfc/0x230)
> [2.449319]  r10:0001 r9: r8: r7:ea315c10 r6:ea388c00
> r5:ea315c00
> [2.457206]  r4:e9814010
> [2.459756] [] (rcar_du_probe) from []
> (platform_drv_probe+0x60/0xc0)
> [2.467943]  r10:0005 r8:c069d31c r7:c069d31c r6:fdfb r5:ea315c10
> r4:fffe
> [2.475833] [] (platform_drv_probe) from []
> (driver_probe_device+0x224/0x440)
> [2.484715]  r7:c06b4bd0 r6:c08d4b04 r5:c08d4afc r4:ea315c10
> [2.490419] [] (driver_probe_device) from []
> (__device_attach_driver+0x90/0x9c)
> [2.499474]  r10: r9: r8:ea2f9f00 r7:0001 r6:ea315c10
> r5:ea0e5e70
> [2.507360]  r4:c069d31c
> [2.509907] [] 

[git pull] drm fixes

2016-02-26 Thread Dave Airlie
On 26 February 2016 at 13:04, Linus Torvalds
 wrote:
> On Thu, Feb 25, 2016 at 6:20 PM, Dave Airlie  wrote:
>>
>> This is a bit larger than Id like, but I asked the Intel guys to pull in
>> some Skylake fixes in the possibly vain hope that Skylake might be more
>> functional now that I'm seeing production hardware shipping.
>>
>> For i915, it's mostly the same patch in a few places, making sure the hw
>> doesn't turn off when we are programming it.
>>
>> Apart from that are two nouveau fixes, one for a module defer bug, and
>> one for using nouveau on new Lenovo P50 models.
>>
>> Then there are a bunch of AMDGPU fixes, one is a fix for v4.4
>> vblank regressions, and some PM fixes.
>
> Ok, pulled.
>
> But I have to ask: what the hell have you done to the _real_ Dave Airlie?
>
> I'm seeing sentences with proper capitalization. I'm even seeing
> paragraph breaks. I didn't do a single edit on your pull request
> message when using it to make the merge commit log.
>
> If somebody is holding a gun to your head, blink once.

.

Oh wait, that's a baby. It's possible a lack of sleep has made me more careful
in my pull request writing. As the year tends towards Kernel Summit I'll make
sure to tend towards less editing, so you have something to complain about.
Unless someone breaks userspace and tries to weasel out of it before then.

Dave.


[PATCH] drm: exynos: mark pm functions __maybe_unused

2016-02-26 Thread Arnd Bergmann
The exynos drm driver implements power management functions that
are hidden inside of #ifdef, but when they are all disabled,
we get a warning about another unused function that is not
called from elsewhere:

drivers/gpu/drm/exynos/exynos_drm_gsc.c:1219:12: error: 'gsc_clk_ctrl' defined 
but not used [-Werror=unused-function]

This removes the #ifdef and instead uses a __maybe_unused annotation
that avoids the problem because now gcc can see how the function is
(not) used and silently drop it.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 5d20da8f957e..b0a773790f85 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1760,8 +1760,7 @@ static int gsc_remove(struct platform_device *pdev)
return 0;
 }

-#ifdef CONFIG_PM_SLEEP
-static int gsc_suspend(struct device *dev)
+static int __maybe_unused gsc_suspend(struct device *dev)
 {
struct gsc_context *ctx = get_gsc_context(dev);

@@ -1773,7 +1772,7 @@ static int gsc_suspend(struct device *dev)
return gsc_clk_ctrl(ctx, false);
 }

-static int gsc_resume(struct device *dev)
+static int __maybe_unused gsc_resume(struct device *dev)
 {
struct gsc_context *ctx = get_gsc_context(dev);

@@ -1784,10 +1783,8 @@ static int gsc_resume(struct device *dev)

return 0;
 }
-#endif

-#ifdef CONFIG_PM
-static int gsc_runtime_suspend(struct device *dev)
+static int __maybe_unused gsc_runtime_suspend(struct device *dev)
 {
struct gsc_context *ctx = get_gsc_context(dev);

@@ -1796,7 +1793,7 @@ static int gsc_runtime_suspend(struct device *dev)
return  gsc_clk_ctrl(ctx, false);
 }

-static int gsc_runtime_resume(struct device *dev)
+static int __maybe_unused gsc_runtime_resume(struct device *dev)
 {
struct gsc_context *ctx = get_gsc_context(dev);

@@ -1804,7 +1801,6 @@ static int gsc_runtime_resume(struct device *dev)

return  gsc_clk_ctrl(ctx, true);
 }
-#endif

 static const struct dev_pm_ops gsc_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
-- 
2.7.0



[PATCH] drm: rcar-du: clarify vsp dependency

2016-02-26 Thread Arnd Bergmann
The VSP1 compositor code in DRM links against the respective V4L
driver, but the dependency is not expressed correctly in Kconfig,
which leads to a build error when the DRM driver is built-in
and the V4L driver is a module:

drivers/gpu/built-in.o: In function `rcar_du_vsp_plane_atomic_update':
rcar-du/rcar_du_vsp.c:183: undefined reference to `vsp1_du_atomic_update'

This patch avoids the problem by ensuring that the DRM VSP code can
only be enabled if the V4L driver is linked into the kernel, or
both are loadable modules.

Signed-off-by: Arnd Bergmann 
Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS 
planes")
---
 drivers/gpu/drm/rcar-du/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1f10fa0928b4..eb1e6d5cfed9 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -27,6 +27,6 @@ config DRM_RCAR_LVDS
 config DRM_RCAR_VSP
bool "R-Car DU VSP Compositor Support"
depends on DRM_RCAR_DU
-   depends on VIDEO_RENESAS_VSP1
+   depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m)
help
  Enable support to expose the R-Car VSP Compositor as KMS planes.
-- 
2.7.0



[patch] drm/amd: cleanup get_mfd_cell_dev()

2016-02-26 Thread Alex Deucher
On Thu, Feb 25, 2016 at 2:47 AM, Dan Carpenter  
wrote:
> It's simpler to just use snprintf() to print this to one buffer instead
> of using strcpy() and strcat().  Also using snprintf() is slightly safer
> than using sprintf().
>
> Signed-off-by: Dan Carpenter 

Applied.  Thanks!

>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> index 9f8cfaa..d6b0bff 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -240,12 +240,10 @@ static int acp_poweron(struct generic_pm_domain *genpd)
>  static struct device *get_mfd_cell_dev(const char *device_name, int r)
>  {
> char auto_dev_name[25];
> -   char buf[8];
> struct device *dev;
>
> -   sprintf(buf, ".%d.auto", r);
> -   strcpy(auto_dev_name, device_name);
> -   strcat(auto_dev_name, buf);
> +   snprintf(auto_dev_name, sizeof(auto_dev_name),
> +"%s.%d.auto", device_name, r);
> dev = bus_find_device_by_name(_bus_type, NULL, 
> auto_dev_name);
> dev_info(dev, "device %s added to pm domain\n", auto_dev_name);
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

2016-02-26 Thread Jyri Sarha
On 02/26/16 02:43, Russell King - ARM Linux wrote:
> On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote:
>> On 02/18/16 16:35, Rob Herring wrote:
>>> This should be implied from the port unit address. In other words,
>>> port at 0 is defined to be the rgb port. Now, if this is one of several
>>> modes for the video port, then that is a different story.
>>>
>>
>> Do you suggest that also the audio i2s and s/p-dif port-types should be
>> coded in the port unit addresses? Something like: port at 0 is always rgb,
>> port at 1 is i2s, and port at 2 is spdif?
>
> For the audio inputs, the port address corresponds to the input pin.
> TDA998x devices can have multiple streams routed to the pins, and can
> select between them.
>
> For example, there may be four I2S data pins and one I2S clock pin.
> When using stereo, you can select which of the four I2S data pins
> carries the audio data.
>

Sure, but I do not think that would be the usual setup. The only 
"normal" situation I can think for having a need to have two alternative 
audio setups would one for i2s and another for s/p-dif. But then again 
it is possible to come up with a design with multiple alternative audio 
wirings and it relatively simple handle that in DT binding, so why not.

> When using SPDIF, there may be two SPDIF inputs, and you can select
> which SPDIF input is used.
>
> So, "reg" may not be an address in terms of a CPU visible address, but
> it's an address as far as selecting the appropriate input - and it
> fits in with the requirements of ePAPR, which are that if you have
> a unit-address (which is required to distinguish different port nodes)
> then you must have a matching "reg" property.
>

Still I do not see why it is desirable to reuse reg property, when we 
can introduce new property for describing the audio wiring.

> I don't particularly like the video node using the RGB routing register
> value either for the reg property, but I've kept quiet because I have
> nothing to offer there: again, this comes down to ePAPR requirements
> and the need to specify multiple "port { }" nodes.  You can't have two
> "port { }" nodes without using a unit-address, and we'd need to chose
> a unit-address for it which doesn't conflict with the audio ports...
> so there's a kind of logic to using the RGB routing value, which will
> never conflict.
>

If we after all decide to go with using reg property for audio wiring 
(and essentially writing the value directly to AP_ENA register), then we 
could also agree that video port's unit address is always 0 as it 
corresponds to audio disabled in AP_ENA register and would not collide 
with any audio "address". Then we could keep the old video-ports 
property to configure the video wiring. How does this sound?

Best regards,
Jyri

ps. Then we still have the alternative of not using the graph/ports 
binding for audio at all. No other audio driver is currently using that 
and the graph binding is not particularly well suited for i2s 
connections as there may be more than two components connected to the 
same wires and sharing the bandwidth with both TDM and different data 
wires. But I am not sure if I want to go there any more as I have a 
feeling that I have been running in circles for couple of years with 
this now.






[PATCH] drm: bridge: Make (pre/post) enable/disable callbacks optional

2016-02-26 Thread Laurent Pinchart
Instead of forcing bridges to implement empty callbacks make them all
optional.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_bridge.c | 12 
 include/drm/drm_crtc.h   |  8 
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index bd93453afa61..b3654404abd0 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -186,7 +186,8 @@ void drm_bridge_disable(struct drm_bridge *bridge)

drm_bridge_disable(bridge->next);

-   bridge->funcs->disable(bridge);
+   if (bridge->funcs->disable)
+   bridge->funcs->disable(bridge);
 }
 EXPORT_SYMBOL(drm_bridge_disable);

@@ -206,7 +207,8 @@ void drm_bridge_post_disable(struct drm_bridge *bridge)
if (!bridge)
return;

-   bridge->funcs->post_disable(bridge);
+   if (bridge->funcs->post_disable)
+   bridge->funcs->post_disable(bridge);

drm_bridge_post_disable(bridge->next);
 }
@@ -256,7 +258,8 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge)

drm_bridge_pre_enable(bridge->next);

-   bridge->funcs->pre_enable(bridge);
+   if (bridge->funcs->pre_enable)
+   bridge->funcs->pre_enable(bridge);
 }
 EXPORT_SYMBOL(drm_bridge_pre_enable);

@@ -276,7 +279,8 @@ void drm_bridge_enable(struct drm_bridge *bridge)
if (!bridge)
return;

-   bridge->funcs->enable(bridge);
+   if (bridge->funcs->enable)
+   bridge->funcs->enable(bridge);

drm_bridge_enable(bridge->next);
 }
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7fad193dc645..fbc225414f01 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1584,6 +1584,8 @@ struct drm_bridge_funcs {
 *
 * The bridge can assume that the display pipe (i.e. clocks and timing
 * signals) feeding it is still running when this callback is called.
+*
+* The disable callback is optional.
 */
void (*disable)(struct drm_bridge *bridge);

@@ -1600,6 +1602,8 @@ struct drm_bridge_funcs {
 * The bridge must assume that the display pipe (i.e. clocks and timing
 * singals) feeding it is no longer running when this callback is
 * called.
+*
+* The post_disable callback is optional.
 */
void (*post_disable)(struct drm_bridge *bridge);

@@ -1628,6 +1632,8 @@ struct drm_bridge_funcs {
 * will not yet be running when this callback is called. The bridge must
 * not enable the display link feeding the next bridge in the chain (if
 * there is one) when this callback is called.
+*
+* The pre_enable callback is optional.
 */
void (*pre_enable)(struct drm_bridge *bridge);

@@ -1645,6 +1651,8 @@ struct drm_bridge_funcs {
 * signals) feeding it is running when this callback is called. This
 * callback must enable the display link feeding the next bridge in the
 * chain if there is one.
+*
+* The enable callback is optional.
 */
void (*enable)(struct drm_bridge *bridge);
 };
-- 
Regards,

Laurent Pinchart



[4.4-rc1][Regression] drm/i915: Check live status before reading edid

2016-02-26 Thread Jindal, Sonika


On 2/26/2016 12:11 AM, Joseph Salisbury wrote:
> On 02/24/2016 10:53 PM, Jindal, Sonika wrote:
>> Hi Joe,
>>
>> Yes, first thing to try is to increase the tries.
> We testing with 300 retries, but the second monitor still did not show
> up.  However, it did show up in lspci.
>
>
>> Can you please point me to the bug and provide more details like platform, 
>> monitor, cable.
> The bug is at: http://pad.lv/1543683 .  All the hardware details should
> be in the bug report.  The cable is a single link dvi-d cable.
> Unfortunately the bug reporter does not have a dual link cable to test.
> If you need any additional info, we can ask the bug reporter.
If this is with single link cable, the issue could be the same.
As Ville suggested for the other issue to use video=HDMI-A-1:e as 
command line argument, can you please give it a try?
The logs shared in the bug doesn't have drm logs enabled, so couldnt get 
much out of it.
Which platform is this?

Alternatively you can add something like following in intel_hdmi_detect 
to make it ignore the live status checks.

@@ -1419,7 +1419,7 @@ intel_hdmi_detect(struct drm_connector *connector, 
bool force)

 intel_hdmi_unset_edid(connector);
-
+   live_status = live_status | force;
 if (intel_hdmi_set_edid(connector, live_status)) {
 struct intel_hdmi *intel_hdmi = 
intel_attached_hdmi(connector);


Regards,
Sonika
>> Are you referring to the same issue as Oleksandr reported where a single 
>> link dvi/hdmi cable didn’t work and dual link worked?
> I'm not sure if this is the exact issue or not.  I'll review the other
> thread and compare.
>
>> Regards,
>> Sonika
>>
>> -Original Message-
>> From: Joseph Salisbury [mailto:joseph.salisbury at canonical.com]
>> Sent: Thursday, February 25, 2016 3:09 AM
>> To: Jindal, Sonika 
>> Cc: Sharma, Shashank ; Vivi, Rodrigo 
>> ; Daniel Vetter ; Jani 
>> Nikula ; David Airlie ; 
>> intel-gfx ; dri-devel > lists.freedesktop.org>; LKML 
>> Subject: [4.4-rc1][Regression] drm/i915: Check live status before reading 
>> edid
>>
>> Hi Sonika,
>>
>> A kernel bug report was opened against Ubuntu [0].  After a kernel bisect, 
>> it was found that reverting the following commit resolved this bug:
>>
>> commit 237ed86c693d8a8e4db476976aeb30df4deac74b
>> Author: Sonika Jindal 
>> Date:   Tue Sep 15 09:44:20 2015 +0530
>>
>>  drm/i915: Check live status before reading edid
>>
>>
>>
>> The regression was introduced as of v4.4-rc1.
>>
>> I was hoping to get your feedback, since you are the patch author.  Do think 
>> increasing the number of tries in intel_hdmi_detect() is worth trying?  Do 
>> you think gathering any additional data will help diagnose this issue, or 
>> would it be best to submit a revert request?
>>  
>>
>> Thanks,
>>  
>> Joe
>>
>> [0] http://pad.lv/lp1543683
>>
>



[PATCHv2 31/31] drm/omap: check if rotation is supported before commit

2016-02-26 Thread Tomi Valkeinen
omapdrm is missing a check on the validity of the rotation property.
This leads to omapdrm possibly trying to use rotation on non-rotateable
framebuffer, which causes the overlay setup to fail.

This patch adds the necessary check to omap_plane_atomic_check().

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_drv.h   | 1 +
 drivers/gpu/drm/omapdrm/omap_fb.c| 8 
 drivers/gpu/drm/omapdrm/omap_plane.c | 6 ++
 3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index c077367dcb1a..16c3eeeae668 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -189,6 +189,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
struct omap_drm_window *win, struct omap_overlay_info *info);
 struct drm_connector *omap_framebuffer_get_next_connector(
struct drm_framebuffer *fb, struct drm_connector *from);
+bool omap_framebuffer_supports_rotation(struct drm_framebuffer *fb);

 void omap_gem_init(struct drm_device *dev);
 void omap_gem_deinit(struct drm_device *dev);
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 481512db2656..610962396eb0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -145,6 +145,14 @@ static uint32_t get_linear_addr(struct plane *plane,
return plane->paddr + offset;
 }

+bool omap_framebuffer_supports_rotation(struct drm_framebuffer *fb)
+{
+   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
+   struct plane *plane = _fb->planes[0];
+
+   return omap_gem_flags(plane->bo) & OMAP_BO_TILED;
+}
+
 /* update ovl info for scanout, handles cases of multi-planar fb's, etc.
  */
 void omap_framebuffer_update_scanout(struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index d75b197eff46..93ee538a99f5 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -177,6 +177,12 @@ static int omap_plane_atomic_check(struct drm_plane *plane,
if (state->crtc_y + state->crtc_h > crtc_state->adjusted_mode.vdisplay)
return -EINVAL;

+   if (state->fb) {
+   if (state->rotation != BIT(DRM_ROTATE_0) &&
+   !omap_framebuffer_supports_rotation(state->fb))
+   return -EINVAL;
+   }
+
return 0;
 }

-- 
2.5.0



[PATCHv2 30/31] drm/omap: fix crtc->plane property delegation

2016-02-26 Thread Tomi Valkeinen
Before universal planes we had to have plane specific properties for the
crtc too, as on the hardware level a crtc uses a plane. In other words,
e.g. 'zorder' property was added to both planes and crtcs, and
omap_crtc.c would delegate the property set/get to the primary plane.

However, the delegation was a bit too generic, delegating all property
set/get calls to planes. Thus it's possible to set, say, FB_ID, on a
crtc, which gets redirected to  the primary plane.

This is not standard, and shouldn't be allowed. To keep backward
compatibility, we still need to redirect the properties we supported
earlier for crtcs, namely 'zorder' and 'rotation'.

This patch redirects only the allowed properties from crtcs to planes.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 58 +
 1 file changed, 40 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index f1cd2800055b..8c5caf8bb1b9 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -423,24 +423,40 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
}
 }

+static bool omap_crtc_is_plane_prop(struct drm_device *dev,
+   struct drm_property *property)
+{
+   struct omap_drm_private *priv = dev->dev_private;
+
+   return property == priv->zorder_prop ||
+   property == dev->mode_config.rotation_property;
+}
+
 static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
 struct drm_crtc_state *state,
 struct drm_property *property,
 uint64_t val)
 {
-   struct drm_plane_state *plane_state;
-   struct drm_plane *plane = crtc->primary;
+   struct drm_device *dev = crtc->dev;

-   /*
-* Delegate property set to the primary plane. Get the plane state and
-* set the property directly.
-*/
+   if (omap_crtc_is_plane_prop(dev, property)) {
+   struct drm_plane_state *plane_state;
+   struct drm_plane *plane = crtc->primary;
+
+   /*
+* Delegate property set to the primary plane. Get the plane
+* state and set the property directly.
+*/

-   plane_state = drm_atomic_get_plane_state(state->state, plane);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
+   plane_state = drm_atomic_get_plane_state(state->state, plane);
+   if (IS_ERR(plane_state))
+   return PTR_ERR(plane_state);

-   return drm_atomic_plane_set_property(plane, plane_state, property, val);
+   return drm_atomic_plane_set_property(plane, plane_state,
+   property, val);
+   }
+
+   return -EINVAL;
 }

 static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
@@ -448,14 +464,20 @@ static int omap_crtc_atomic_get_property(struct drm_crtc 
*crtc,
 struct drm_property *property,
 uint64_t *val)
 {
-   /*
-* Delegate property get to the primary plane. The
-* drm_atomic_plane_get_property() function isn't exported, but can be
-* called through drm_object_property_get_value() as that will call
-* drm_atomic_get_property() for atomic drivers.
-*/
-   return drm_object_property_get_value(>primary->base, property,
-val);
+   struct drm_device *dev = crtc->dev;
+
+   if (omap_crtc_is_plane_prop(dev, property)) {
+   /*
+* Delegate property get to the primary plane. The
+* drm_atomic_plane_get_property() function isn't exported, but
+* can be called through drm_object_property_get_value() as that
+* will call drm_atomic_get_property() for atomic drivers.
+*/
+   return drm_object_property_get_value(>primary->base,
+   property, val);
+   }
+
+   return -EINVAL;
 }

 static const struct drm_crtc_funcs omap_crtc_funcs = {
-- 
2.5.0



[PATCHv2 29/31] drm/omap: EBUSY status handling in omap_gem_fault()

2016-02-26 Thread Tomi Valkeinen
From: Rob Clark 

Subsequent threads returning EBUSY from vm_insert_pfn() was not
handled correctly. As a result concurrent access from new threads
to mmapped data caused SIGBUS.

See e79e0fe380847493266fba557217e2773c61bd1b ("drm/i915: EBUSY status
handling added to i915_gem_fault()").

Signed-off-by: Rob Clark 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index baa714c8ec70..9ac30560e9b1 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -578,6 +578,11 @@ fail:
case 0:
case -ERESTARTSYS:
case -EINTR:
+   case -EBUSY:
+   /*
+* EBUSY is ok: this just means that another thread
+* already did the job.
+*/
return VM_FAULT_NOPAGE;
case -ENOMEM:
return VM_FAULT_OOM;
-- 
2.5.0



[PATCHv2 28/31] drm/omap: verify that fb plane pitches are the same

2016-02-26 Thread Tomi Valkeinen
The DSS hardware uses the same ROW_INC value for both Y and UV planes
for NV12 format. This means that the pitches of the Y and UV planes have
to match. omapdrm doesn't check this at the moment, and this can lead
into a broken NV12 fb on the screen.

This patch adds the check.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_fb.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index ad202dfc1a49..481512db2656 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -449,6 +449,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
drm_device *dev,
goto fail;
}

+   if (i > 0 && pitch != mode_cmd->pitches[i - 1]) {
+   dev_err(dev->dev,
+   "pitches are not the same between framebuffer 
planes %d != %d\n",
+   pitch, mode_cmd->pitches[i - 1]);
+   ret = -EINVAL;
+   goto fail;
+   }
+
plane->bo = bos[i];
plane->offset = mode_cmd->offsets[i];
plane->pitch  = pitch;
-- 
2.5.0



[PATCHv2 27/31] drm/omap: verify that display x-res is divisible by 8

2016-02-26 Thread Tomi Valkeinen
DISPC requires the x resolution to be divisible by 8 when stall mode is
not used.

Add a check to the DPI driver to verify this.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dpi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 7953e6a52346..557cf3bdcc4e 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -513,6 +513,9 @@ static int dpi_check_timings(struct omap_dss_device *dssdev,
struct dpi_clk_calc_ctx ctx;
bool ok;

+   if (timings->x_res % 8 != 0)
+   return -EINVAL;
+
if (mgr && !dispc_mgr_timings_ok(mgr->id, timings))
return -EINVAL;

-- 
2.5.0



[PATCHv2 26/31] drm/omap: HDMI5: allow interlace

2016-02-26 Thread Tomi Valkeinen
Now that interlace support has been added, we can remove the check that
prevents interlace.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 34174ea85a54..b2dd4c9f20d5 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -284,10 +284,6 @@ static int hdmi_display_check_timing(struct 
omap_dss_device *dssdev,
 {
struct omap_dss_device *out = 

-   /* TODO: proper interlace support */
-   if (timings->interlace)
-   return -EINVAL;
-
if (!dispc_mgr_timings_ok(out->dispc_channel, timings))
return -EINVAL;

-- 
2.5.0



[PATCHv2 25/31] drm/omap: HDMI5: Add interlace support

2016-02-26 Thread Tomi Valkeinen
Add the missing bits for interlace:

* Set VBLANK_OSC if the videomode's vblank is fractional
* Halve the vertical timings for interlace
* Double the horizontal timings for double-pixel mode
* Set FC_PRCONF properly for double-pixel mode

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 947edb9d4275..6a397520cae5 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -298,10 +298,30 @@ static void hdmi_core_init(struct hdmi_core_vid_config 
*video_cfg,
video_cfg->data_enable_pol = 1; /* It is always 1*/
video_cfg->hblank = cfg->timings.hfp +
cfg->timings.hbp + cfg->timings.hsw;
-   video_cfg->vblank_osc = 0; /* Always 0 - need to confirm */
+   video_cfg->vblank_osc = 0;
video_cfg->vblank = cfg->timings.vsw +
cfg->timings.vfp + cfg->timings.vbp;
video_cfg->v_fc_config.hdmi_dvi_mode = cfg->hdmi_dvi_mode;
+
+   if (cfg->timings.interlace) {
+   /* set vblank_osc if vblank is fractional */
+   if (video_cfg->vblank % 2 != 0)
+   video_cfg->vblank_osc = 1;
+
+   video_cfg->v_fc_config.timings.y_res /= 2;
+   video_cfg->vblank /= 2;
+   video_cfg->v_fc_config.timings.vfp /= 2;
+   video_cfg->v_fc_config.timings.vsw /= 2;
+   video_cfg->v_fc_config.timings.vbp /= 2;
+   }
+
+   if (cfg->timings.double_pixel) {
+   video_cfg->v_fc_config.timings.x_res *= 2;
+   video_cfg->hblank *= 2;
+   video_cfg->v_fc_config.timings.hfp *= 2;
+   video_cfg->v_fc_config.timings.hsw *= 2;
+   video_cfg->v_fc_config.timings.hbp *= 2;
+   }
 }

 /* DSS_HDMI_CORE_VIDEO_CONFIG */
@@ -368,6 +388,11 @@ static void hdmi_core_video_config(struct hdmi_core_data 
*core,
/* select DVI mode */
REG_FLD_MOD(base, HDMI_CORE_FC_INVIDCONF,
cfg->v_fc_config.hdmi_dvi_mode, 3, 3);
+
+   if (cfg->v_fc_config.timings.double_pixel)
+   REG_FLD_MOD(base, HDMI_CORE_FC_PRCONF, 2, 7, 4);
+   else
+   REG_FLD_MOD(base, HDMI_CORE_FC_PRCONF, 1, 7, 4);
 }

 static void hdmi_core_config_video_packetizer(struct hdmi_core_data *core)
-- 
2.5.0



[PATCHv2 24/31] drm/omap: HDMI5: clean up timings copy

2016-02-26 Thread Tomi Valkeinen
The HDMI driver copies the timing values one by one. Instead we can just
copy the whole struct.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index ec9223e514fa..947edb9d4275 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -292,25 +292,16 @@ static void hdmi_core_init(struct hdmi_core_vid_config 
*video_cfg,
 {
DSSDBG("hdmi_core_init\n");

+   video_cfg->v_fc_config.timings = cfg->timings;
+
/* video core */
video_cfg->data_enable_pol = 1; /* It is always 1*/
-   video_cfg->v_fc_config.timings.hsync_level = cfg->timings.hsync_level;
-   video_cfg->v_fc_config.timings.x_res = cfg->timings.x_res;
-   video_cfg->v_fc_config.timings.hsw = cfg->timings.hsw;
-   video_cfg->v_fc_config.timings.hbp = cfg->timings.hbp;
-   video_cfg->v_fc_config.timings.hfp = cfg->timings.hfp;
video_cfg->hblank = cfg->timings.hfp +
cfg->timings.hbp + cfg->timings.hsw;
-   video_cfg->v_fc_config.timings.vsync_level = cfg->timings.vsync_level;
-   video_cfg->v_fc_config.timings.y_res = cfg->timings.y_res;
-   video_cfg->v_fc_config.timings.vsw = cfg->timings.vsw;
-   video_cfg->v_fc_config.timings.vfp = cfg->timings.vfp;
-   video_cfg->v_fc_config.timings.vbp = cfg->timings.vbp;
video_cfg->vblank_osc = 0; /* Always 0 - need to confirm */
video_cfg->vblank = cfg->timings.vsw +
cfg->timings.vfp + cfg->timings.vbp;
video_cfg->v_fc_config.hdmi_dvi_mode = cfg->hdmi_dvi_mode;
-   video_cfg->v_fc_config.timings.interlace = cfg->timings.interlace;
 }

 /* DSS_HDMI_CORE_VIDEO_CONFIG */
-- 
2.5.0



[PATCHv2 23/31] drm/omap: HDMI5: Fix FC HSW value

2016-02-26 Thread Tomi Valkeinen
For some reason the HDMI FC's HSW value is programmed to hsw-1. There's
no indication in the documentation that this would be correct, and no
other blanking value needs -1 either.

So remove the -1.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 8ea531d2652c..ec9223e514fa 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -296,11 +296,11 @@ static void hdmi_core_init(struct hdmi_core_vid_config 
*video_cfg,
video_cfg->data_enable_pol = 1; /* It is always 1*/
video_cfg->v_fc_config.timings.hsync_level = cfg->timings.hsync_level;
video_cfg->v_fc_config.timings.x_res = cfg->timings.x_res;
-   video_cfg->v_fc_config.timings.hsw = cfg->timings.hsw - 1;
+   video_cfg->v_fc_config.timings.hsw = cfg->timings.hsw;
video_cfg->v_fc_config.timings.hbp = cfg->timings.hbp;
video_cfg->v_fc_config.timings.hfp = cfg->timings.hfp;
video_cfg->hblank = cfg->timings.hfp +
-   cfg->timings.hbp + cfg->timings.hsw - 1;
+   cfg->timings.hbp + cfg->timings.hsw;
video_cfg->v_fc_config.timings.vsync_level = cfg->timings.vsync_level;
video_cfg->v_fc_config.timings.y_res = cfg->timings.y_res;
video_cfg->v_fc_config.timings.vsw = cfg->timings.vsw;
-- 
2.5.0



[PATCHv2 22/31] drm/omap: DISPC: Fix field order for HDMI

2016-02-26 Thread Tomi Valkeinen
Interlace field order is different between VENC and HDMI. The driver
currently sets the field order for VENC.

This patch adds the code to set the field order for HDMI.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 1e7f26985bda..a4274dca384a 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -106,6 +106,13 @@ struct dispc_features {
bool has_writeback:1;

bool supports_double_pixel:1;
+
+   /*
+* Field order for VENC is different than HDMI. We should handle this in
+* some intelligent manner, but as the SoCs have either HDMI or VENC,
+* never both, we can just use this flag for now.
+*/
+   bool reverse_ilace_field_order:1;
 };

 #define DISPC_MAX_NR_FIFOS 5
@@ -2749,6 +2756,9 @@ static int dispc_ovl_setup_common(enum omap_plane plane,

dispc_ovl_configure_burst_type(plane, rotation_type);

+   if (dispc.feat->reverse_ilace_field_order)
+   swap(offset0, offset1);
+
dispc_ovl_set_ba0(plane, paddr + offset0);
dispc_ovl_set_ba1(plane, paddr + offset1);

@@ -3958,6 +3968,7 @@ static const struct dispc_features omap44xx_dispc_feats = 
{
.supports_sync_align=   true,
.has_writeback  =   true,
.supports_double_pixel  =   true,
+   .reverse_ilace_field_order =true,
 };

 static const struct dispc_features omap54xx_dispc_feats = {
@@ -3982,6 +3993,7 @@ static const struct dispc_features omap54xx_dispc_feats = 
{
.supports_sync_align=   true,
.has_writeback  =   true,
.supports_double_pixel  =   true,
+   .reverse_ilace_field_order =true,
 };

 static int dispc_init_features(struct platform_device *pdev)
-- 
2.5.0



[PATCHv2 21/31] drm/omap: HDMI: fix WP timings for ilace

2016-02-26 Thread Tomi Valkeinen
The HDMI WP timings are not programmed correctly for interlace.

We need to halve the vertical timings when interlace is used, and double
the horizontal timings when pixel doubling is used.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
index 48ffb39663c8..5f4af41830b1 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
@@ -199,8 +199,6 @@ void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format 
*video_fmt,
video_fmt->packing_mode = HDMI_PACK_10b_RGB_YUV444;
video_fmt->y_res = param->timings.y_res;
video_fmt->x_res = param->timings.x_res;
-   if (param->timings.interlace)
-   video_fmt->y_res /= 2;

timings->hbp = param->timings.hbp;
timings->hfp = param->timings.hfp;
@@ -208,9 +206,25 @@ void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format 
*video_fmt,
timings->vbp = param->timings.vbp;
timings->vfp = param->timings.vfp;
timings->vsw = param->timings.vsw;
+
timings->vsync_level = param->timings.vsync_level;
timings->hsync_level = param->timings.hsync_level;
timings->interlace = param->timings.interlace;
+   timings->double_pixel = param->timings.double_pixel;
+
+   if (param->timings.interlace) {
+   video_fmt->y_res /= 2;
+   timings->vbp /= 2;
+   timings->vfp /= 2;
+   timings->vsw /= 2;
+   }
+
+   if (param->timings.double_pixel) {
+   video_fmt->x_res *= 2;
+   timings->hfp *= 2;
+   timings->hsw *= 2;
+   timings->hbp *= 2;
+   }
 }

 void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
-- 
2.5.0



[PATCHv2 20/31] drm/omap: HDMI: Fix HSW value

2016-02-26 Thread Tomi Valkeinen
On OMAP4 and OMAP5 ES1.0 the HDMI_WP_VIDEO_TIMING_H:HSW field is
set directly to the HSW value. On later SoCs the field needs to be
programmed with the value of HSW-1.

Currently the driver always programs the field with the HSW value. Most
videomodes seem to work fine with that, but at least low resolution
interlaced modes don't work at all.

This patch fixes the HSW for OMAP5 ES2.0+ SoCs.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
index 7c544bc56fb5..48ffb39663c8 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
@@ -165,12 +165,24 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp,
 {
u32 timing_h = 0;
u32 timing_v = 0;
+   bool hsw_minus_one = true;

DSSDBG("Enter hdmi_wp_video_config_timing\n");

+   /*
+* On OMAP4 and OMAP5 ES1 the HSW field is programmed as is. On OMAP5
+* ES2+ (including DRA7/AM5 SoCs) HSW field is programmed to hsw-1.
+* However, we don't support OMAP5 ES1 at all, so we can just check for
+* OMAP4 here.
+*/
+   if (omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES1 ||
+   omapdss_get_version() == OMAPDSS_VER_OMAP4430_ES2 ||
+   omapdss_get_version() == OMAPDSS_VER_OMAP4)
+   hsw_minus_one = false;
+
timing_h |= FLD_VAL(timings->hbp, 31, 20);
timing_h |= FLD_VAL(timings->hfp, 19, 8);
-   timing_h |= FLD_VAL(timings->hsw, 7, 0);
+   timing_h |= FLD_VAL(timings->hsw - (hsw_minus_one ? 1 : 0), 7, 0);
hdmi_write_reg(wp->base, HDMI_WP_VIDEO_TIMING_H, timing_h);

timing_v |= FLD_VAL(timings->vbp, 31, 20);
-- 
2.5.0



[PATCHv2 19/31] drm/omap: HDMI: support double-pixel pixel clock

2016-02-26 Thread Tomi Valkeinen
We need double-pixel mode (pixel repetition) for interlace modes. This
patch adds the necessary support to HDMI to double the pixel clock when
double-pixel mode is used.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 7 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 7 ++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index b09ce9ee82fa..ddd6a331df39 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -168,6 +168,7 @@ static int hdmi_power_on_full(struct omap_dss_device 
*dssdev)
struct omap_overlay_manager *mgr = hdmi.output.manager;
struct hdmi_wp_data *wp = 
struct dss_pll_clock_info hdmi_cinfo = { 0 };
+   unsigned pc;

r = hdmi_power_on_core(dssdev);
if (r)
@@ -181,7 +182,11 @@ static int hdmi_power_on_full(struct omap_dss_device 
*dssdev)

DSSDBG("hdmi_power_on x_res= %d y_res = %d\n", p->x_res, p->y_res);

-   hdmi_pll_compute(, p->pixelclock, _cinfo);
+   pc = p->pixelclock;
+   if (p->double_pixel)
+   pc *= 2;
+
+   hdmi_pll_compute(, pc, _cinfo);

r = dss_pll_enable();
if (r) {
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 4485a1c37bd8..34174ea85a54 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -184,6 +184,7 @@ static int hdmi_power_on_full(struct omap_dss_device 
*dssdev)
struct omap_video_timings *p;
struct omap_overlay_manager *mgr = hdmi.output.manager;
struct dss_pll_clock_info hdmi_cinfo = { 0 };
+   unsigned pc;

r = hdmi_power_on_core(dssdev);
if (r)
@@ -193,7 +194,11 @@ static int hdmi_power_on_full(struct omap_dss_device 
*dssdev)

DSSDBG("hdmi_power_on x_res= %d y_res = %d\n", p->x_res, p->y_res);

-   hdmi_pll_compute(, p->pixelclock, _cinfo);
+   pc = p->pixelclock;
+   if (p->double_pixel)
+   pc *= 2;
+
+   hdmi_pll_compute(, pc, _cinfo);

/* disable and clear irqs */
hdmi_wp_clear_irqenable(, 0x);
-- 
2.5.0



[PATCHv2 18/31] drm/omap: support double-pixel

2016-02-26 Thread Tomi Valkeinen
We need double-pixel mode (pixel repetition) for interlace modes. This
patch adds the necessary support to omapdrm to output double-pixel mode.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_connector.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index 83f2a9177c14..ce2d67b6a8c7 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -63,6 +63,9 @@ void copy_timings_omap_to_drm(struct drm_display_mode *mode,
if (timings->interlace)
mode->flags |= DRM_MODE_FLAG_INTERLACE;

+   if (timings->double_pixel)
+   mode->flags |= DRM_MODE_FLAG_DBLCLK;
+
if (timings->hsync_level == OMAPDSS_SIG_ACTIVE_HIGH)
mode->flags |= DRM_MODE_FLAG_PHSYNC;
else
@@ -90,6 +93,7 @@ void copy_timings_drm_to_omap(struct omap_video_timings 
*timings,
timings->vbp = mode->vtotal - mode->vsync_end;

timings->interlace = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+   timings->double_pixel = !!(mode->flags & DRM_MODE_FLAG_DBLCLK);

if (mode->flags & DRM_MODE_FLAG_PHSYNC)
timings->hsync_level = OMAPDSS_SIG_ACTIVE_HIGH;
-- 
2.5.0



[PATCHv2 17/31] drm/omap: DISPC: support double-pixel mode

2016-02-26 Thread Tomi Valkeinen
We need double-pixel mode (pixel repetition) for interlace modes. This
patch adds the necessary support to DISPC to output double-pixel mode.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 8 
 include/video/omapdss.h | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 6b50476ec669..1e7f26985bda 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -104,6 +104,8 @@ struct dispc_features {
bool supports_sync_align:1;

bool has_writeback:1;
+
+   bool supports_double_pixel:1;
 };

 #define DISPC_MAX_NR_FIFOS 5
@@ -3287,6 +3289,10 @@ void dispc_mgr_set_timings(enum omap_channel channel,
} else {
if (t.interlace)
t.y_res /= 2;
+
+   if (dispc.feat->supports_double_pixel)
+   REG_FLD_MOD(DISPC_CONTROL, t.double_pixel ? 1 : 0,
+   19, 17);
}

dispc_mgr_set_size(channel, t.x_res, t.y_res);
@@ -3951,6 +3957,7 @@ static const struct dispc_features omap44xx_dispc_feats = 
{
.set_max_preload=   true,
.supports_sync_align=   true,
.has_writeback  =   true,
+   .supports_double_pixel  =   true,
 };

 static const struct dispc_features omap54xx_dispc_feats = {
@@ -3974,6 +3981,7 @@ static const struct dispc_features omap54xx_dispc_feats = 
{
.set_max_preload=   true,
.supports_sync_align=   true,
.has_writeback  =   true,
+   .supports_double_pixel  =   true,
 };

 static int dispc_init_features(struct platform_device *pdev)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 86f28a92281a..6c1a3e1b4d55 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -367,6 +367,8 @@ struct omap_video_timings {
enum omap_dss_signal_level de_level;
/* Pixel clock edges to drive HSYNC and VSYNC signals */
enum omap_dss_signal_edge sync_pclk_edge;
+
+   bool double_pixel;
 };

 /* Hardcoded timings for tv modes. Venc only uses these to
-- 
2.5.0



[PATCHv2 16/31] drm/omap: increase vblank wait timeout

2016-02-26 Thread Tomi Valkeinen
omap_crtc_wait_pending() waits until the config changes have been taken
into use, usually at next vblank. The wait-timeout used is 50ms, which
usually is enough, but in some rare cases not.

As time wait-timeout is just a safety measure for cases where something
is broken, we can just as well increase the timeout considerably.

This patch makes the timeout 250ms.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index f5b19d18fa8b..f1cd2800055b 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -80,9 +80,13 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);

+   /*
+* Timeout is set to a "sufficiently" high value, which should cover
+* a single frame refresh even on slower displays.
+*/
return wait_event_timeout(omap_crtc->pending_wait,
  !omap_crtc->pending,
- msecs_to_jiffies(50));
+ msecs_to_jiffies(250));
 }

 /* 
-
-- 
2.5.0



[PATCHv2 15/31] drm/omap: remove support for ext mem & sync

2016-02-26 Thread Tomi Valkeinen
We no longer have the omapdrm plugin system for SGX, and we can thus
remove the support for external memory and sync objects from omap_gem.c.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 105 +++--
 1 file changed, 18 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 5ffe3865614d..baa714c8ec70 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -33,9 +33,7 @@
 /* note: we use upper 8 bits of flags for driver-internal flags: */
 #define OMAP_BO_MEM_DMA_API0x0100  /* memory allocated with the 
dma_alloc_* API */
 #define OMAP_BO_MEM_SHMEM  0x0200  /* memory allocated through 
shmem backing */
-#define OMAP_BO_MEM_EXT0x0400  /* memory allocated 
externally */
 #define OMAP_BO_MEM_DMABUF 0x0800  /* memory imported from a 
dmabuf */
-#define OMAP_BO_EXT_SYNC   0x1000  /* externally allocated sync 
object */

 struct omap_gem_object {
struct drm_gem_object base;
@@ -107,17 +105,7 @@ struct omap_gem_object {
 * sync-object allocated on demand (if needed)
 *
 * Per-buffer sync-object for tracking pending and completed hw/dma
-* read and write operations.  The layout in memory is dictated by
-* the SGX firmware, which uses this information to stall the command
-* stream if a surface is not ready yet.
-*
-* Note that when buffer is used by SGX, the sync-object needs to be
-* allocated from a special heap of sync-objects.  This way many sync
-* objects can be packed in a page, and not waste GPU virtual address
-* space.  Because of this we have to have a omap_gem_set_sync_object()
-* API to allow replacement of the syncobj after it has (potentially)
-* already been allocated.  A bit ugly but I haven't thought of a
-* better alternative.
+* read and write operations.
 */
struct {
uint32_t write_pending;
@@ -1180,20 +1168,6 @@ unlock:
return ret;
 }

-/* it is a bit lame to handle updates in this sort of polling way, but
- * in case of PVR, the GPU can directly update read/write complete
- * values, and not really tell us which ones it updated.. this also
- * means that sync_lock is not quite sufficient.  So we'll need to
- * do something a bit better when it comes time to add support for
- * separate 2d hw..
- */
-void omap_gem_op_update(void)
-{
-   spin_lock(_lock);
-   sync_op_update();
-   spin_unlock(_lock);
-}
-
 /* mark the start of read and/or write operation */
 int omap_gem_op_start(struct drm_gem_object *obj, enum omap_gem_op op)
 {
@@ -1261,7 +1235,7 @@ int omap_gem_op_sync(struct drm_gem_object *obj, enum 
omap_gem_op op)
  * is currently blocked..  fxn() can be called from any context
  *
  * (TODO for now fxn is called back from whichever context calls
- * omap_gem_op_update().. but this could be better defined later
+ * omap_gem_op_finish().. but this could be better defined later
  * if needed)
  *
  * TODO more code in common w/ _sync()..
@@ -1303,43 +1277,6 @@ int omap_gem_op_async(struct drm_gem_object *obj, enum 
omap_gem_op op,
return 0;
 }

-/* special API so PVR can update the buffer to use a sync-object allocated
- * from it's sync-obj heap.  Only used for a newly allocated (from PVR's
- * perspective) sync-object, so we overwrite the new syncobj w/ values
- * from the already allocated syncobj (if there is one)
- */
-int omap_gem_set_sync_object(struct drm_gem_object *obj, void *syncobj)
-{
-   struct omap_gem_object *omap_obj = to_omap_bo(obj);
-   int ret = 0;
-
-   spin_lock(_lock);
-
-   if ((omap_obj->flags & OMAP_BO_EXT_SYNC) && !syncobj) {
-   /* clearing a previously set syncobj */
-   syncobj = kmemdup(omap_obj->sync, sizeof(*omap_obj->sync),
- GFP_ATOMIC);
-   if (!syncobj) {
-   ret = -ENOMEM;
-   goto unlock;
-   }
-   omap_obj->flags &= ~OMAP_BO_EXT_SYNC;
-   omap_obj->sync = syncobj;
-   } else if (syncobj && !(omap_obj->flags & OMAP_BO_EXT_SYNC)) {
-   /* replacing an existing syncobj */
-   if (omap_obj->sync) {
-   memcpy(syncobj, omap_obj->sync, 
sizeof(*omap_obj->sync));
-   kfree(omap_obj->sync);
-   }
-   omap_obj->flags |= OMAP_BO_EXT_SYNC;
-   omap_obj->sync = syncobj;
-   }
-
-unlock:
-   spin_unlock(_lock);
-   return ret;
-}
-
 /* 
-
  * Constructor & Destructor
  */
@@ -1363,28 +1300,23 @@ void omap_gem_free_object(struct drm_gem_object *obj)
 */

[PATCHv2 14/31] drm/omap: gem: Implement dma_buf import

2016-02-26 Thread Tomi Valkeinen
From: Laurent Pinchart 

OMAP GEM objects backed by dma_buf reuse the current OMAP GEM object
support as much as possible. If the imported buffer is physically
contiguous its physical address will be used directly, reusing the
OMAP_BO_MEM_DMA_API code paths. Otherwise it will be mapped through the
TILER using a pages list created from the scatterlist instead of the
shmem backing storage.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.h|   2 +
 drivers/gpu/drm/omapdrm/omap_gem.c| 138 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  53 +---
 3 files changed, 159 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 9e0030731c37..c077367dcb1a 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -195,6 +195,8 @@ void omap_gem_deinit(struct drm_device *dev);

 struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, uint32_t flags);
+struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device *dev, size_t size,
+   struct sg_table *sgt);
 int omap_gem_new_handle(struct drm_device *dev, struct drm_file *file,
union omap_gem_size gsize, uint32_t flags, uint32_t *handle);
 void omap_gem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 36302e7b496b..5ffe3865614d 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -34,6 +34,7 @@
 #define OMAP_BO_MEM_DMA_API0x0100  /* memory allocated with the 
dma_alloc_* API */
 #define OMAP_BO_MEM_SHMEM  0x0200  /* memory allocated through 
shmem backing */
 #define OMAP_BO_MEM_EXT0x0400  /* memory allocated 
externally */
+#define OMAP_BO_MEM_DMABUF 0x0800  /* memory imported from a 
dmabuf */
 #define OMAP_BO_EXT_SYNC   0x1000  /* externally allocated sync 
object */

 struct omap_gem_object {
@@ -50,17 +51,25 @@ struct omap_gem_object {
uint32_t roll;

/**
-* If buffer is allocated physically contiguous, the OMAP_BO_MEM_DMA_API
-* flag is set and the paddr is valid.  Also if the buffer is remapped
-* in TILER and paddr_cnt > 0, then paddr is valid. But if you are using
-* the physical address and OMAP_BO_MEM_DMA_API is not set, then you
-* should be going thru omap_gem_{get,put}_paddr() to ensure the mapping
-* is not removed from under your feet.
+* paddr contains the buffer DMA address. It is valid for
 *
-* Note that OMAP_BO_SCANOUT is a hint from userspace that DMA capable
-* buffer is requested, but doesn't mean that it is. Use the
-* OMAP_BO_MEM_DMA_API flag to determine if the buffer has a DMA capable
-* physical address.
+* - buffers allocated through the DMA mapping API (with the
+*   OMAP_BO_MEM_DMA_API flag set)
+*
+* - buffers imported from dmabuf (with the OMAP_BO_MEM_DMABUF flag set)
+*   if they are physically contiguous (when sgt->orig_nents == 1)
+*
+* - buffers mapped through the TILER when paddr_cnt is not zero, in
+*   which case the DMA address points to the TILER aperture
+*
+* Physically contiguous buffers have their DMA address equal to the
+* physical address as we don't remap those buffers through the TILER.
+*
+* Buffers mapped to the TILER have their DMA address pointing to the
+* TILER aperture. As TILER mappings are refcounted (through paddr_cnt)
+* the DMA address must be accessed through omap_get_get_paddr() to
+* ensure that the mapping won't disappear unexpectedly. References must
+* be released with omap_gem_put_paddr().
 */
dma_addr_t paddr;

@@ -70,6 +79,12 @@ struct omap_gem_object {
uint32_t paddr_cnt;

/**
+* If the buffer has been imported from a dmabuf the OMAP_DB_DMABUF flag
+* is set and the sgt field is valid.
+*/
+   struct sg_table *sgt;
+
+   /**
 * tiler block used when buffer is remapped in DMM/TILER.
 */
struct tiler_block *block;
@@ -167,6 +182,17 @@ static uint64_t mmap_offset(struct drm_gem_object *obj)
return drm_vma_node_offset_addr(>vma_node);
 }

+static bool is_contiguous(struct omap_gem_object *omap_obj)
+{
+   if (omap_obj->flags & OMAP_BO_MEM_DMA_API)
+   return true;
+
+   if ((omap_obj->flags & OMAP_BO_MEM_DMABUF) && omap_obj->sgt->nents == 1)
+   return true;
+
+   return false;
+}
+
 /* 
-
  * Eviction
  */
@@ -400,7 +426,7 @@ static int 

[PATCHv2 13/31] drm/omap: gem: Refactor GEM object allocation

2016-02-26 Thread Tomi Valkeinen
From: Laurent Pinchart 

Split the individual steps of GEM object allocation and initialization
clearly. This improves readability and prepares for dma_buf import
support.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 75 ++
 1 file changed, 43 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index c45752078558..36302e7b496b 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1374,67 +1374,80 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
size_t size;
int ret;

+   /* Validate the flags and compute the memory and cache flags. */
if (flags & OMAP_BO_TILED) {
if (!priv->usergart) {
dev_err(dev->dev, "Tiled buffers require DMM\n");
return NULL;
}

-   /* tiled buffers are always shmem paged backed.. when they are
-* scanned out, they are remapped into DMM/TILER
+   /*
+* Tiled buffers are always shmem paged backed. When they are
+* scanned out, they are remapped into DMM/TILER.
 */
flags &= ~OMAP_BO_SCANOUT;
+   flags |= OMAP_BO_MEM_SHMEM;

-   /* currently don't allow cached buffers.. there is some caching
-* stuff that needs to be handled better
+   /*
+* Currently don't allow cached buffers. There is some caching
+* stuff that needs to be handled better.
 */
flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
flags |= tiler_get_cpu_cache_flags();
-
-   /* align dimensions to slot boundaries... */
-   tiler_align(gem2fmt(flags),
-   , );
-
-   /* ...and calculate size based on aligned dimensions */
-   size = tiler_size(gem2fmt(flags),
-   gsize.tiled.width, gsize.tiled.height);
-   } else {
-   size = PAGE_ALIGN(gsize.bytes);
+   } else if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
+   /*
+* Use contiguous memory if we don't have DMM to remap
+* discontiguous buffers.
+*/
+   flags |= OMAP_BO_MEM_DMA_API;
+   } else if (!(flags & OMAP_BO_MEM_EXT)) {
+   /*
+* All other buffers not backed with external memory are
+* shmem-backed.
+*/
+   flags |= OMAP_BO_MEM_SHMEM;
}

+   /* Allocate the initialize the OMAP GEM object. */
omap_obj = kzalloc(sizeof(*omap_obj), GFP_KERNEL);
if (!omap_obj)
return NULL;

obj = _obj->base;
+   omap_obj->flags = flags;

-   if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
-   /* attempt to allocate contiguous memory if we don't
-* have DMM for remappign discontiguous buffers
+   if (flags & OMAP_BO_TILED) {
+   /*
+* For tiled buffers align dimensions to slot boundaries and
+* calculate size based on aligned dimensions.
 */
-   omap_obj->vaddr =  dma_alloc_writecombine(dev->dev, size,
-   _obj->paddr, GFP_KERNEL);
-   if (!omap_obj->vaddr) {
-   kfree(omap_obj);
+   tiler_align(gem2fmt(flags), ,
+   );

-   return NULL;
-   }
+   size = tiler_size(gem2fmt(flags), gsize.tiled.width,
+ gsize.tiled.height);

-   flags |= OMAP_BO_MEM_DMA_API;
+   omap_obj->width = gsize.tiled.width;
+   omap_obj->height = gsize.tiled.height;
+   } else {
+   size = PAGE_ALIGN(gsize.bytes);
}

spin_lock(>list_lock);
list_add(_obj->mm_list, >obj_list);
spin_unlock(>list_lock);

-   omap_obj->flags = flags;
-
-   if (flags & OMAP_BO_TILED) {
-   omap_obj->width = gsize.tiled.width;
-   omap_obj->height = gsize.tiled.height;
+   /* Allocate memory if needed. */
+   if (flags & OMAP_BO_MEM_DMA_API) {
+   omap_obj->vaddr = dma_alloc_writecombine(dev->dev, size,
+_obj->paddr,
+GFP_KERNEL);
+   if (!omap_obj->vaddr)
+   goto fail;
}

-   if (flags & (OMAP_BO_MEM_DMA_API | OMAP_BO_MEM_EXT)) {
+   /* Initialize the GEM object. */
+   if (!(flags & OMAP_BO_MEM_SHMEM)) {
drm_gem_private_object_init(dev, 

[PATCHv2 12/31] drm/omap: gem: Clean up GEM objects memory flags

2016-02-26 Thread Tomi Valkeinen
From: Laurent Pinchart 

The driver assumes that only objects backed by shmem need to be mapped
through DMM. While this is true with the current code, the assumption
won't hold with dma_buf import support.

Condition the mapping based on whether the buffer has been allocated
using the DMA mapping API instead and clean up the flags to avoid having
to check both flags and GEM object filp field to decide how to process
buffers. Flags are not the authoritative source of information regarding
where the buffer memory comes from, and are renamed to make that
clearer.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 57 +-
 1 file changed, 25 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 21989d3518f2..c45752078558 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -31,9 +31,10 @@
  */

 /* note: we use upper 8 bits of flags for driver-internal flags: */
-#define OMAP_BO_DMA0x0100  /* actually is physically 
contiguous */
-#define OMAP_BO_EXT_SYNC   0x0200  /* externally allocated sync 
object */
-#define OMAP_BO_EXT_MEM0x0400  /* externally allocated 
memory */
+#define OMAP_BO_MEM_DMA_API0x0100  /* memory allocated with the 
dma_alloc_* API */
+#define OMAP_BO_MEM_SHMEM  0x0200  /* memory allocated through 
shmem backing */
+#define OMAP_BO_MEM_EXT0x0400  /* memory allocated 
externally */
+#define OMAP_BO_EXT_SYNC   0x1000  /* externally allocated sync 
object */

 struct omap_gem_object {
struct drm_gem_object base;
@@ -49,16 +50,16 @@ struct omap_gem_object {
uint32_t roll;

/**
-* If buffer is allocated physically contiguous, the OMAP_BO_DMA flag
-* is set and the paddr is valid.  Also if the buffer is remapped in
-* TILER and paddr_cnt > 0, then paddr is valid.  But if you are using
-* the physical address and OMAP_BO_DMA is not set, then you should
-* be going thru omap_gem_{get,put}_paddr() to ensure the mapping is
-* not removed from under your feet.
+* If buffer is allocated physically contiguous, the OMAP_BO_MEM_DMA_API
+* flag is set and the paddr is valid.  Also if the buffer is remapped
+* in TILER and paddr_cnt > 0, then paddr is valid. But if you are using
+* the physical address and OMAP_BO_MEM_DMA_API is not set, then you
+* should be going thru omap_gem_{get,put}_paddr() to ensure the mapping
+* is not removed from under your feet.
 *
 * Note that OMAP_BO_SCANOUT is a hint from userspace that DMA capable
-* buffer is requested, but doesn't mean that it is.  Use the
-* OMAP_BO_DMA flag to determine if the buffer has a DMA capable
+* buffer is requested, but doesn't mean that it is. Use the
+* OMAP_BO_MEM_DMA_API flag to determine if the buffer has a DMA capable
 * physical address.
 */
dma_addr_t paddr;
@@ -166,18 +167,6 @@ static uint64_t mmap_offset(struct drm_gem_object *obj)
return drm_vma_node_offset_addr(>vma_node);
 }

-/* GEM objects can either be allocated from contiguous memory (in which
- * case obj->filp==NULL), or w/ shmem backing (obj->filp!=NULL).  But non
- * contiguous buffers can be remapped in TILER/DMM if they need to be
- * contiguous... but we don't do this all the time to reduce pressure
- * on TILER/DMM space when we know at allocation time that the buffer
- * will need to be scanned out.
- */
-static inline bool is_shmem(struct drm_gem_object *obj)
-{
-   return obj->filp != NULL;
-}
-
 /* 
-
  * Eviction
  */
@@ -307,7 +296,7 @@ static int get_pages(struct drm_gem_object *obj, struct 
page ***pages)
struct omap_gem_object *omap_obj = to_omap_bo(obj);
int ret = 0;

-   if (is_shmem(obj) && !omap_obj->pages) {
+   if ((omap_obj->flags & OMAP_BO_MEM_SHMEM) && !omap_obj->pages) {
ret = omap_gem_attach_pages(obj);
if (ret) {
dev_err(obj->dev->dev, "could not attach pages\n");
@@ -411,7 +400,7 @@ static int fault_1d(struct drm_gem_object *obj,
omap_gem_cpu_sync(obj, pgoff);
pfn = page_to_pfn(omap_obj->pages[pgoff]);
} else {
-   BUG_ON(!(omap_obj->flags & OMAP_BO_DMA));
+   BUG_ON(!(omap_obj->flags & OMAP_BO_MEM_DMA_API));
pfn = (omap_obj->paddr >> PAGE_SHIFT) + pgoff;
}

@@ -743,7 +732,8 @@ fail:
 static inline bool is_cached_coherent(struct drm_gem_object *obj)
 {
struct omap_gem_object *omap_obj = to_omap_bo(obj);
-   return is_shmem(obj) &&
+
+   return 

[PATCHv2 11/31] drm/omap: print an error if display enable fails

2016-02-26 Thread Tomi Valkeinen
If the panel's enable fails, omap_encoder silently ignores the failure.
omapdrm should really handle the failure, but unfortunately the whole
encoder enable codepath is expected to always succeed.

So for now, catch the enable failure and print an error.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_encoder.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c 
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index 61714e9670ae..ae347cc19f01 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -139,11 +139,15 @@ static void omap_encoder_enable(struct drm_encoder 
*encoder)
struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
struct omap_dss_device *dssdev = omap_encoder->dssdev;
struct omap_dss_driver *dssdrv = dssdev->driver;
+   int r;

omap_encoder_update(encoder, omap_crtc_channel(encoder->crtc),
omap_crtc_timings(encoder->crtc));

-   dssdrv->enable(dssdev);
+   r = dssdrv->enable(dssdev);
+   if (r)
+   dev_err(encoder->dev->dev, "Failed to enable display '%s': 
%d\n",
+   dssdev->name, r);
 }

 static int omap_encoder_atomic_check(struct drm_encoder *encoder,
-- 
2.5.0



[PATCHv2 10/31] drm/omap: use dma_mapping_error in omap_gem_dma_sync

2016-02-26 Thread Tomi Valkeinen
omap_gem_dma_sync() calls dma_map_page() but does not check the possible
error with dma_mapping_error(). If DMA-API debugging is enabled, the
debug layer will give a warning if dma_mapping_error() has not been
used.

This patch adds proper error handling to omap_gem_dma_sync().

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index cb541d6b3c2b..21989d3518f2 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -776,9 +776,20 @@ void omap_gem_dma_sync(struct drm_gem_object *obj,

for (i = 0; i < npages; i++) {
if (!omap_obj->addrs[i]) {
-   omap_obj->addrs[i] = dma_map_page(dev->dev, 
pages[i], 0,
+   dma_addr_t addr;
+
+   addr = dma_map_page(dev->dev, pages[i], 0,
PAGE_SIZE, DMA_BIDIRECTIONAL);
+
+   if (dma_mapping_error(dev->dev, addr)) {
+   dev_warn(dev->dev,
+   "%s: failed to map page\n",
+   __func__);
+   break;
+   }
+
dirty = true;
+   omap_obj->addrs[i] = addr;
}
}

-- 
2.5.0



[PATCHv2 09/31] drm/omap: use dma_mapping_error in omap_gem_attach_pages

2016-02-26 Thread Tomi Valkeinen
omap_gem_attach_pages() calls dma_map_page() but does not check the
possible error with dma_mapping_error(). If DMA-API debugging is
enabled, the debug layer will give a warning if dma_mapping_error() has
not been used.

This patch adds proper error handling to omap_gem_attach_pages().

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 8495a1a4b617..cb541d6b3c2b 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -264,6 +264,19 @@ static int omap_gem_attach_pages(struct drm_gem_object 
*obj)
for (i = 0; i < npages; i++) {
addrs[i] = dma_map_page(dev->dev, pages[i],
0, PAGE_SIZE, DMA_BIDIRECTIONAL);
+
+   if (dma_mapping_error(dev->dev, addrs[i])) {
+   dev_warn(dev->dev,
+   "%s: failed to map page\n", __func__);
+
+   for (i = i - 1; i >= 0; --i) {
+   dma_unmap_page(dev->dev, addrs[i],
+   PAGE_SIZE, DMA_BIDIRECTIONAL);
+   }
+
+   ret = -ENOMEM;
+   goto free_addrs;
+   }
}
} else {
addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
@@ -278,6 +291,8 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)

return 0;

+free_addrs:
+   kfree(addrs);
 free_pages:
drm_gem_put_pages(obj, pages, true, false);

-- 
2.5.0



[PATCHv2 08/31] drm/omap: add define for DISPC_IRQ_WBUNCOMPLETEERROR

2016-02-26 Thread Tomi Valkeinen
OMAP4+ DSS has WBUNCOMPLETEERROR irq, which was not defined in the irq
list. Add the define.

Signed-off-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
---
 include/video/omapdss.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 295b41e20d8e..86f28a92281a 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -51,6 +51,7 @@
 #define DISPC_IRQ_FRAMEDONEWB  (1 << 23)
 #define DISPC_IRQ_FRAMEDONETV  (1 << 24)
 #define DISPC_IRQ_WBBUFFEROVERFLOW (1 << 25)
+#define DISPC_IRQ_WBUNCOMPLETEERROR(1 << 26)
 #define DISPC_IRQ_SYNC_LOST3   (1 << 27)
 #define DISPC_IRQ_VSYNC3   (1 << 28)
 #define DISPC_IRQ_ACBIAS_COUNT_STAT3   (1 << 29)
-- 
2.5.0



[PATCHv2 07/31] drm/omap: tpd12s015: CT_CP_HPD as optional gpio

2016-02-26 Thread Tomi Valkeinen
From: Manisha Agrawal 

tpd12s015 HW has LS_OE, CT_CP_HPD and HPD gpios. Out of these gpios,
driver only handled LS_OE as optional. The CT_CP_HPD gpio should also
be treated as optional gpio as it is just a power saving feature. Some
boards hardwire this gpio to be always enable. In this patch, all access
to CT_CP_HPD gpio is made optional.

Signed-off-by: Manisha Agrawal 
Acked-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 7fa80f5b4c6b..916a89978387 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -236,7 +236,7 @@ static int tpd_probe(struct platform_device *pdev)
return r;


-   gpio = devm_gpiod_get_index(>dev, NULL, 0,
+   gpio = devm_gpiod_get_index_optional(>dev, NULL, 0,
 GPIOD_OUT_LOW);
if (IS_ERR(gpio))
goto err_gpio;
-- 
2.5.0



[PATCHv2 06/31] drm/omap: tpd12s015: gpio descriptor API

2016-02-26 Thread Tomi Valkeinen
From: Manisha Agrawal 

Migrated the gpio APIs to descriptor-interface based.

Signed-off-by: Manisha Agrawal 
Acked-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
---
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   | 79 --
 1 file changed, 28 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 49fbad03a814..7fa80f5b4c6b 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -13,9 +13,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
+#include 

 #include 
 #include 
@@ -24,9 +23,9 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;

-   int ct_cp_hpd_gpio;
-   int ls_oe_gpio;
-   int hpd_gpio;
+   struct gpio_desc *ct_cp_hpd_gpio;
+   struct gpio_desc *ls_oe_gpio;
+   struct gpio_desc *hpd_gpio;

struct omap_video_timings timings;
 };
@@ -47,7 +46,7 @@ static int tpd_connect(struct omap_dss_device *dssdev,
dst->src = dssdev;
dssdev->dst = dst;

-   gpio_set_value_cansleep(ddata->ct_cp_hpd_gpio, 1);
+   gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 1);
/* DC-DC converter needs at max 300us to get to 90% of 5V */
udelay(300);

@@ -65,7 +64,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev,
if (dst != dssdev->dst)
return;

-   gpio_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0);
+   gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0);

dst->src = NULL;
dssdev->dst = NULL;
@@ -145,16 +144,14 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
struct omap_dss_device *in = ddata->in;
int r;

-   if (!gpio_get_value_cansleep(ddata->hpd_gpio))
+   if (!gpiod_get_value_cansleep(ddata->hpd_gpio))
return -ENODEV;

-   if (gpio_is_valid(ddata->ls_oe_gpio))
-   gpio_set_value_cansleep(ddata->ls_oe_gpio, 1);
+   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1);

r = in->ops.hdmi->read_edid(in, edid, len);

-   if (gpio_is_valid(ddata->ls_oe_gpio))
-   gpio_set_value_cansleep(ddata->ls_oe_gpio, 0);
+   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);

return r;
 }
@@ -163,7 +160,7 @@ static bool tpd_detect(struct omap_dss_device *dssdev)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);

-   return gpio_get_value_cansleep(ddata->hpd_gpio);
+   return gpiod_get_value_cansleep(ddata->hpd_gpio);
 }

 static int tpd_set_infoframe(struct omap_dss_device *dssdev,
@@ -206,32 +203,6 @@ static int tpd_probe_of(struct platform_device *pdev)
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct device_node *node = pdev->dev.of_node;
struct omap_dss_device *in;
-   int gpio;
-
-   /* CT CP HPD GPIO */
-   gpio = of_get_gpio(node, 0);
-   if (!gpio_is_valid(gpio)) {
-   dev_err(>dev, "failed to parse CT CP HPD gpio\n");
-   return gpio;
-   }
-   ddata->ct_cp_hpd_gpio = gpio;
-
-   /* LS OE GPIO */
-   gpio = of_get_gpio(node, 1);
-   if (gpio_is_valid(gpio) || gpio == -ENOENT) {
-   ddata->ls_oe_gpio = gpio;
-   } else {
-   dev_err(>dev, "failed to parse LS OE gpio\n");
-   return gpio;
-   }
-
-   /* HPD GPIO */
-   gpio = of_get_gpio(node, 2);
-   if (!gpio_is_valid(gpio)) {
-   dev_err(>dev, "failed to parse HPD gpio\n");
-   return gpio;
-   }
-   ddata->hpd_gpio = gpio;

in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
@@ -249,6 +220,7 @@ static int tpd_probe(struct platform_device *pdev)
struct omap_dss_device *in, *dssdev;
struct panel_drv_data *ddata;
int r;
+   struct gpio_desc *gpio;

ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
@@ -263,23 +235,28 @@ static int tpd_probe(struct platform_device *pdev)
if (r)
return r;

-   r = devm_gpio_request_one(>dev, ddata->ct_cp_hpd_gpio,
-   GPIOF_OUT_INIT_LOW, "hdmi_ct_cp_hpd");
-   if (r)
+
+   gpio = devm_gpiod_get_index(>dev, NULL, 0,
+GPIOD_OUT_LOW);
+   if (IS_ERR(gpio))
goto err_gpio;

-   if (gpio_is_valid(ddata->ls_oe_gpio)) {
-   r = devm_gpio_request_one(>dev, ddata->ls_oe_gpio,
-   GPIOF_OUT_INIT_LOW, "hdmi_ls_oe");
-   if (r)
-   goto err_gpio;
-   }
+   ddata->ct_cp_hpd_gpio = gpio;

-   r = devm_gpio_request_one(>dev, ddata->hpd_gpio,
-   GPIOF_DIR_IN, "hdmi_hpd");
-   if (r)
+   gpio = devm_gpiod_get_index_optional(>dev, NULL, 1,
+   

[PATCHv2 05/31] drm/omap: tpd12s015: remove platform data support

2016-02-26 Thread Tomi Valkeinen
From: Manisha Agrawal 

All devices using tpd12s015 driver are doing DT boot. No need of further
supporting the platform data. This patch removes support for platform
data.

Signed-off-by: Manisha Agrawal 
[tomi.valkeinen at ti.com: minor adjustments]
Acked-by: Tomi Valkeinen 
Acked-by: Laurent Pinchart 
---
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   | 41 +++---
 include/video/omap-panel-data.h| 15 
 2 files changed, 5 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 990af6baeb0f..49fbad03a814 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -201,32 +201,6 @@ static const struct omapdss_hdmi_ops tpd_hdmi_ops = {
.set_hdmi_mode  = tpd_set_hdmi_mode,
 };

-static int tpd_probe_pdata(struct platform_device *pdev)
-{
-   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
-   struct encoder_tpd12s015_platform_data *pdata;
-   struct omap_dss_device *dssdev, *in;
-
-   pdata = dev_get_platdata(>dev);
-
-   ddata->ct_cp_hpd_gpio = pdata->ct_cp_hpd_gpio;
-   ddata->ls_oe_gpio = pdata->ls_oe_gpio;
-   ddata->hpd_gpio = pdata->hpd_gpio;
-
-   in = omap_dss_find_output(pdata->source);
-   if (in == NULL) {
-   dev_err(>dev, "Failed to find video source\n");
-   return -ENODEV;
-   }
-
-   ddata->in = in;
-
-   dssdev = >dssdev;
-   dssdev->name = pdata->name;
-
-   return 0;
-}
-
 static int tpd_probe_of(struct platform_device *pdev)
 {
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
@@ -282,17 +256,12 @@ static int tpd_probe(struct platform_device *pdev)

platform_set_drvdata(pdev, ddata);

-   if (dev_get_platdata(>dev)) {
-   r = tpd_probe_pdata(pdev);
-   if (r)
-   return r;
-   } else if (pdev->dev.of_node) {
-   r = tpd_probe_of(pdev);
-   if (r)
-   return r;
-   } else {
+   if (!pdev->dev.of_node)
return -ENODEV;
-   }
+
+   r = tpd_probe_of(pdev);
+   if (r)
+   return r;

r = devm_gpio_request_one(>dev, ddata->ct_cp_hpd_gpio,
GPIOF_OUT_INIT_LOW, "hdmi_ct_cp_hpd");
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 69279c013ac4..56830d1dc762 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -45,21 +45,6 @@ struct encoder_tfp410_platform_data {
int data_lines;
 };

-/**
- * encoder_tpd12s015 platform data
- * @name: name for this display entity
- * @ct_cp_hpd_gpio: CT_CP_HPD gpio number
- * @ls_oe_gpio: LS_OE gpio number
- * @hpd_gpio: HPD gpio number
- */
-struct encoder_tpd12s015_platform_data {
-   const char *name;
-   const char *source;
-
-   int ct_cp_hpd_gpio;
-   int ls_oe_gpio;
-   int hpd_gpio;
-};

 /**
  * connector_dvi platform data
-- 
2.5.0



[PATCHv2 04/31] drm/omap: drm_atomic_get_plane_state() may return ERR_PTR

2016-02-26 Thread Tomi Valkeinen
From: Jyri Sarha 

drm_atomic_get_plane_state() may return ERR_PTR. Handle
drm_atomic_get_plane_state() return values right in
omap_crtc_atomic_set_property().

Signed-off-by: Jyri Sarha 
Acked-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 7dd3d44a93e5..f5b19d18fa8b 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -433,8 +433,8 @@ static int omap_crtc_atomic_set_property(struct drm_crtc 
*crtc,
 */

plane_state = drm_atomic_get_plane_state(state->state, plane);
-   if (!plane_state)
-   return -EINVAL;
+   if (IS_ERR(plane_state))
+   return PTR_ERR(plane_state);

return drm_atomic_plane_set_property(plane, plane_state, property, val);
 }
-- 
2.5.0



[PATCHv2 03/31] drm/omap: add dmm_read() and dmm_write() wrappers

2016-02-26 Thread Tomi Valkeinen
This patch adds wrapper functions for readl() and writel(), dmm_read()
and dmm_write(), so that we can implement workaround for DRA7 errata
i878.

Signed-off-by: Tomi Valkeinen 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 39 
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 67edf839dce3..9f94576c435d 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -79,6 +79,16 @@ static const uint32_t reg[][4] = {
DMM_PAT_DESCR__2, DMM_PAT_DESCR__3},
 };

+static u32 dmm_read(struct dmm *dmm, u32 reg)
+{
+   return readl(dmm->base + reg);
+}
+
+static void dmm_write(struct dmm *dmm, u32 val, u32 reg)
+{
+   writel(val, dmm->base + reg);
+}
+
 /* simple allocator to grab next 16 byte aligned memory from txn */
 static void *alloc_dma(struct dmm_txn *txn, size_t sz, dma_addr_t *pa)
 {
@@ -108,7 +118,7 @@ static int wait_status(struct refill_engine *engine, 
uint32_t wait_mask)

i = DMM_FIXED_RETRY_COUNT;
while (true) {
-   r = readl(dmm->base + reg[PAT_STATUS][engine->id]);
+   r = dmm_read(dmm, reg[PAT_STATUS][engine->id]);
err = r & DMM_PATSTATUS_ERR;
if (err)
return -EFAULT;
@@ -140,11 +150,11 @@ static void release_engine(struct refill_engine *engine)
 static irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
 {
struct dmm *dmm = arg;
-   uint32_t status = readl(dmm->base + DMM_PAT_IRQSTATUS);
+   uint32_t status = dmm_read(dmm, DMM_PAT_IRQSTATUS);
int i;

/* ack IRQ */
-   writel(status, dmm->base + DMM_PAT_IRQSTATUS);
+   dmm_write(dmm, status, DMM_PAT_IRQSTATUS);

for (i = 0; i < dmm->num_engines; i++) {
if (status & DMM_IRQSTAT_LST) {
@@ -264,7 +274,7 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
txn->last_pat->next_pa = 0;

/* write to PAT_DESCR to clear out any pending transaction */
-   writel(0x0, dmm->base + reg[PAT_DESCR][engine->id]);
+   dmm_write(dmm, 0x0, reg[PAT_DESCR][engine->id]);

/* wait for engine ready: */
ret = wait_status(engine, DMM_PATSTATUS_READY);
@@ -280,8 +290,7 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
smp_mb();

/* kick reload */
-   writel(engine->refill_pa,
-   dmm->base + reg[PAT_DESCR][engine->id]);
+   dmm_write(dmm, engine->refill_pa, reg[PAT_DESCR][engine->id]);

if (wait) {
if (!wait_for_completion_timeout(>compl,
@@ -657,7 +666,7 @@ static int omap_dmm_probe(struct platform_device *dev)

omap_dmm->dev = >dev;

-   hwinfo = readl(omap_dmm->base + DMM_PAT_HWINFO);
+   hwinfo = dmm_read(omap_dmm, DMM_PAT_HWINFO);
omap_dmm->num_engines = (hwinfo >> 24) & 0x1F;
omap_dmm->num_lut = (hwinfo >> 16) & 0x1F;
omap_dmm->container_width = 256;
@@ -666,7 +675,7 @@ static int omap_dmm_probe(struct platform_device *dev)
atomic_set(_dmm->engine_counter, omap_dmm->num_engines);

/* read out actual LUT width and height */
-   pat_geom = readl(omap_dmm->base + DMM_PAT_GEOMETRY);
+   pat_geom = dmm_read(omap_dmm, DMM_PAT_GEOMETRY);
omap_dmm->lut_width = ((pat_geom >> 16) & 0xF) << 5;
omap_dmm->lut_height = ((pat_geom >> 24) & 0xF) << 5;

@@ -676,12 +685,12 @@ static int omap_dmm_probe(struct platform_device *dev)
omap_dmm->num_lut++;

/* initialize DMM registers */
-   writel(0x, omap_dmm->base + DMM_PAT_VIEW__0);
-   writel(0x, omap_dmm->base + DMM_PAT_VIEW__1);
-   writel(0x80808080, omap_dmm->base + DMM_PAT_VIEW_MAP__0);
-   writel(0x8000, omap_dmm->base + DMM_PAT_VIEW_MAP_BASE);
-   writel(0x, omap_dmm->base + DMM_TILER_OR__0);
-   writel(0x, omap_dmm->base + DMM_TILER_OR__1);
+   dmm_write(omap_dmm, 0x, DMM_PAT_VIEW__0);
+   dmm_write(omap_dmm, 0x, DMM_PAT_VIEW__1);
+   dmm_write(omap_dmm, 0x80808080, DMM_PAT_VIEW_MAP__0);
+   dmm_write(omap_dmm, 0x8000, DMM_PAT_VIEW_MAP_BASE);
+   dmm_write(omap_dmm, 0x, DMM_TILER_OR__0);
+   dmm_write(omap_dmm, 0x, DMM_TILER_OR__1);

ret = request_irq(omap_dmm->irq, omap_dmm_irq_handler, IRQF_SHARED,
"omap_dmm_irq_handler", omap_dmm);
@@ -699,7 +708,7 @@ static int omap_dmm_probe(struct platform_device *dev)
 * buffers for accelerated pan/scroll) and FILL_DSC which
 * we just generally don't care about.
 */
-   writel(0x7e7e7e7e, omap_dmm->base + DMM_PAT_IRQENABLE_SET);
+   dmm_write(omap_dmm, 0x7e7e7e7e, DMM_PAT_IRQENABLE_SET);

omap_dmm->dummy_page = alloc_page(GFP_KERNEL | __GFP_DMA32);
if 

[PATCHv2 02/31] HACK: drm/omap: always use blocking DMM fill

2016-02-26 Thread Tomi Valkeinen
The current driver uses non-blocking DMM fill when releasing memory.
This gives us a small performance increase as we don't have to wait for
the fill operation to finish.

However, the driver does not have any error handling for non-blocking
fill. In case of an error, the fill operation may silently fail, leading
to leaking DMM engines, which may eventually lead to deadlock if we run
out of DMM engines.

This patch makes the DMM driver always use blocking fills, so that we
can catch the errors. A more complex option would be to allow
non-blocking fills, and implement proper error handling, but that is
left for the future.

This patch is a HACK, as the proper fix is to either decide to always
use sync fills and remove all the async related code, or fix the async
code.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index dfebdc4aa0f2..67edf839dce3 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -309,6 +309,21 @@ static int fill(struct tcm_area *area, struct page **pages,
struct tcm_area slice, area_s;
struct dmm_txn *txn;

+   /*
+* FIXME
+*
+* Asynchronous fill does not work reliably, as the driver does not
+* handle errors in the async code paths. The fill operation may
+* silently fail, leading to leaking DMM engines, which may eventually
+* lead to deadlock if we run out of DMM engines.
+*
+* For now, always set 'wait' so that we only use sync fills. Async
+* fills should be fixed, or alternatively we could decide to only
+* support sync fills and so the whole async code path could be removed.
+*/
+
+   wait = true;
+
txn = dmm_txn_init(omap_dmm, area->tcm);
if (IS_ERR_OR_NULL(txn))
return -ENOMEM;
-- 
2.5.0



[PATCHv2 01/31] drm/omap: HDMI: change enable/disable to avoid sync-losts

2016-02-26 Thread Tomi Valkeinen
We occasionally see DISPC sync-lost errors when enabling and disabling
HDMI. Sometimes we get only a few, which get handled (ignored) by the
driver, but sometimes there's a flood of the errors which doesn't seem
to stop.

The HW team has root caused this to the order in which HDMI and DISPC
are enabled/disabled. Currently we enable HDMI first, and then DISPC,
and vice versa when disabling. HW team's suggestion is to do it the
other way around.

This patch changes the order, but this has two side effects as the pixel
clock is produced by HDMI, and the clock is not running when we
enable/disable DISPC:

* When enabling DISPC first, we don't get vertical sync events
* When disabling DISPC last, we don't get FRAMEDONE event

At the moment we use both of those to verify that DISPC has been
enabled/disabled properly. Thus this patch also needs to change the
omapdrm and omapdss which handle the DISPC side.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 16 
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 16 
 drivers/gpu/drm/omapdrm/omap_crtc.c |  5 +
 3 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 7103c659a534..b09ce9ee82fa 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -214,22 +214,22 @@ static int hdmi_power_on_full(struct omap_dss_device 
*dssdev)
/* tv size */
dss_mgr_set_timings(mgr, p);

-   r = hdmi_wp_video_start();
-   if (r)
-   goto err_vid_enable;
-
r = dss_mgr_enable(mgr);
if (r)
goto err_mgr_enable;

+   r = hdmi_wp_video_start();
+   if (r)
+   goto err_vid_enable;
+
hdmi_wp_set_irqenable(wp,
HDMI_IRQ_LINK_CONNECT | HDMI_IRQ_LINK_DISCONNECT);

return 0;

-err_mgr_enable:
-   hdmi_wp_video_stop();
 err_vid_enable:
+   dss_mgr_disable(mgr);
+err_mgr_enable:
hdmi_wp_set_phy_pwr(, HDMI_PHYPWRCMD_OFF);
 err_phy_pwr:
 err_phy_cfg:
@@ -246,10 +246,10 @@ static void hdmi_power_off_full(struct omap_dss_device 
*dssdev)

hdmi_wp_clear_irqenable(, 0x);

-   dss_mgr_disable(mgr);
-
hdmi_wp_video_stop();

+   dss_mgr_disable(mgr);
+
hdmi_wp_set_phy_pwr(, HDMI_PHYPWRCMD_OFF);

dss_pll_disable();
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index a955a2c4c061..4485a1c37bd8 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -231,22 +231,22 @@ static int hdmi_power_on_full(struct omap_dss_device 
*dssdev)
/* tv size */
dss_mgr_set_timings(mgr, p);

-   r = hdmi_wp_video_start();
-   if (r)
-   goto err_vid_enable;
-
r = dss_mgr_enable(mgr);
if (r)
goto err_mgr_enable;

+   r = hdmi_wp_video_start();
+   if (r)
+   goto err_vid_enable;
+
hdmi_wp_set_irqenable(,
HDMI_IRQ_LINK_CONNECT | HDMI_IRQ_LINK_DISCONNECT);

return 0;

-err_mgr_enable:
-   hdmi_wp_video_stop();
 err_vid_enable:
+   dss_mgr_disable(mgr);
+err_mgr_enable:
hdmi_wp_set_phy_pwr(, HDMI_PHYPWRCMD_OFF);
 err_phy_pwr:
 err_phy_cfg:
@@ -263,10 +263,10 @@ static void hdmi_power_off_full(struct omap_dss_device 
*dssdev)

hdmi_wp_clear_irqenable(, 0x);

-   dss_mgr_disable(mgr);
-
hdmi_wp_video_stop();

+   dss_mgr_disable(mgr);
+
hdmi_wp_set_phy_pwr(, HDMI_PHYPWRCMD_OFF);

dss_pll_disable();
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 2ed0754ed19e..7dd3d44a93e5 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -138,6 +138,11 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
u32 framedone_irq, vsync_irq;
int ret;

+   if (omap_crtc->mgr->output->output_type == OMAP_DISPLAY_TYPE_HDMI) {
+   dispc_mgr_enable(channel, enable);
+   return;
+   }
+
if (dispc_mgr_is_enabled(channel) == enable)
return;

-- 
2.5.0



[PATCHv2 00/31] drm/omap: patches for v4.6 part 1

2016-02-26 Thread Tomi Valkeinen
Hi,

Here's a collection of patches for omapdrm. Some of them have been sent for
review at some point, most of them haven't.

There are two bigger features in the series: dmabuf import support and HDMI
interlace output support. Otherwise they are smaller improvements, fixes and
cleanups.

Changes to v1 of the series:

- Dropped the following patches, which need a bit more work:
  * HACK: drm/omap: fix memory barrier bug in DMM driver
  * drm/omap: partial workaround for DRA7 DMM errata i878

- Cosmetic fixes addressing the review comments

 Tomi

Jyri Sarha (1):
  drm/omap: drm_atomic_get_plane_state() may return ERR_PTR

Laurent Pinchart (3):
  drm/omap: gem: Clean up GEM objects memory flags
  drm/omap: gem: Refactor GEM object allocation
  drm/omap: gem: Implement dma_buf import

Manisha Agrawal (3):
  drm/omap: tpd12s015: remove platform data support
  drm/omap: tpd12s015: gpio descriptor API
  drm/omap: tpd12s015: CT_CP_HPD as optional gpio

Rob Clark (1):
  drm/omap: EBUSY status handling in omap_gem_fault()

Tomi Valkeinen (23):
  drm/omap: HDMI: change enable/disable to avoid sync-losts
  HACK: drm/omap: always use blocking DMM fill
  drm/omap: add dmm_read() and dmm_write() wrappers
  drm/omap: add define for DISPC_IRQ_WBUNCOMPLETEERROR
  drm/omap: use dma_mapping_error in omap_gem_attach_pages
  drm/omap: use dma_mapping_error in omap_gem_dma_sync
  drm/omap: print an error if display enable fails
  drm/omap: remove support for ext mem & sync
  drm/omap: increase vblank wait timeout
  drm/omap: DISPC: support double-pixel mode
  drm/omap: support double-pixel
  drm/omap: HDMI: support double-pixel pixel clock
  drm/omap: HDMI: Fix HSW value
  drm/omap: HDMI: fix WP timings for ilace
  drm/omap: DISPC: Fix field order for HDMI
  drm/omap: HDMI5: Fix FC HSW value
  drm/omap: HDMI5: clean up timings copy
  drm/omap: HDMI5: Add interlace support
  drm/omap: HDMI5: allow interlace
  drm/omap: verify that display x-res is divisible by 8
  drm/omap: verify that fb plane pitches are the same
  drm/omap: fix crtc->plane property delegation
  drm/omap: check if rotation is supported before commit

 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   | 118 ++--
 drivers/gpu/drm/omapdrm/dss/dispc.c|  20 ++
 drivers/gpu/drm/omapdrm/dss/dpi.c  |   3 +
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  23 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|  27 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   |  42 ++-
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |  32 +-
 drivers/gpu/drm/omapdrm/omap_connector.c   |   4 +
 drivers/gpu/drm/omapdrm/omap_crtc.c|  69 +++--
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   |  54 +++-
 drivers/gpu/drm/omapdrm/omap_drv.h |   3 +
 drivers/gpu/drm/omapdrm/omap_encoder.c |   6 +-
 drivers/gpu/drm/omapdrm/omap_fb.c  |  16 +
 drivers/gpu/drm/omapdrm/omap_gem.c | 328 -
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  53 +++-
 drivers/gpu/drm/omapdrm/omap_plane.c   |   6 +
 include/video/omap-panel-data.h|  15 -
 include/video/omapdss.h|   3 +
 18 files changed, 502 insertions(+), 320 deletions(-)

-- 
2.5.0



[PATCH 1/2] drm: Add DRM_MODE_FB_BFF flag definition

2016-02-26 Thread Vincent ABRIOU
Hi,

Have you any comment for this proposal?

BR
Vincent

On 02/12/2016 10:26 AM, Vincent Abriou wrote:
> From: Fabien Dessenne 
>
> If a buffer is interlaced, this "Bottom Field First" flag specifies
> which of the top or the bottom field shall be displayed first.
> When set, the bottom field shall be displayed first.
> When unset the top field shall be displayed first.
>
> Signed-off-by: Fabien Dessenne 
> ---
>   drivers/gpu/drm/drm_crtc.c  | 3 ++-
>   include/uapi/drm/drm_mode.h | 1 +
>   2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d40bab2..64b4fdac 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3315,7 +3315,8 @@ internal_framebuffer_create(struct drm_device *dev,
>   struct drm_framebuffer *fb;
>   int ret;
>
> - if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
> + if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS
> + | DRM_MODE_FB_BFF)) {
>   DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
>   return ERR_PTR(-EINVAL);
>   }
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 50adb46..f7c9111 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -354,6 +354,7 @@ struct drm_mode_fb_cmd {
>
>   #define DRM_MODE_FB_INTERLACED  (1<<0) /* for interlaced framebuffers */
>   #define DRM_MODE_FB_MODIFIERS   (1<<1) /* enables ->modifer[] */
> +#define DRM_MODE_FB_BFF  (1<<2) /* if interlaced, bottom field 
> first */
>
>   struct drm_mode_fb_cmd2 {
>   __u32 fb_id;
>


[PATCH 30/33] drm/omap: verify that fb plane pitches are the same

2016-02-26 Thread Laurent Pinchart
Hi Tomi,

On Friday 26 February 2016 11:12:21 Tomi Valkeinen wrote:
> On 26/02/16 10:55, Laurent Pinchart wrote:
> >> I don't quite understand what you mean. The checks apply to all planes.
> > 
> > My point is that if you add a check to ensure that the pitch is identical
> > in all planes, the other tests on the pitch don't have to be repeated for
> > every plane.
> 
> Hmm... The other tests also depend on the plane's bpp, so I'm not sure
> if any of those can be skipped.
> 
> But I agree, the loop with the checks does look somewhat complex, and
> there's probably room for improvement.

It doesn't have to be cleaned as part of this patch though, we can handle that 
later.

-- 
Regards,

Laurent Pinchart



[PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

2016-02-26 Thread Russell King - ARM Linux
On Fri, Feb 26, 2016 at 12:14:44PM +0200, Jyri Sarha wrote:
> On 02/26/16 02:43, Russell King - ARM Linux wrote:
> >On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote:
> >>On 02/18/16 16:35, Rob Herring wrote:
> >>>This should be implied from the port unit address. In other words,
> >>>port at 0 is defined to be the rgb port. Now, if this is one of several
> >>>modes for the video port, then that is a different story.
> >>>
> >>
> >>Do you suggest that also the audio i2s and s/p-dif port-types should be
> >>coded in the port unit addresses? Something like: port at 0 is always rgb,
> >>port at 1 is i2s, and port at 2 is spdif?
> >
> >For the audio inputs, the port address corresponds to the input pin.
> >TDA998x devices can have multiple streams routed to the pins, and can
> >select between them.
> >
> >For example, there may be four I2S data pins and one I2S clock pin.
> >When using stereo, you can select which of the four I2S data pins
> >carries the audio data.
> >
> 
> Sure, but I do not think that would be the usual setup. The only "normal"
> situation I can think for having a need to have two alternative audio setups
> would one for i2s and another for s/p-dif. But then again it is possible to
> come up with a design with multiple alternative audio wirings and it
> relatively simple handle that in DT binding, so why not.

There's another reason: if you want to support 8 channel audio using I2S
rather than SPDIF, then you need to use four I2S data inputs.  Each I2S
data input can support only two channels.

> >When using SPDIF, there may be two SPDIF inputs, and you can select
> >which SPDIF input is used.
> >
> >So, "reg" may not be an address in terms of a CPU visible address, but
> >it's an address as far as selecting the appropriate input - and it
> >fits in with the requirements of ePAPR, which are that if you have
> >a unit-address (which is required to distinguish different port nodes)
> >then you must have a matching "reg" property.
> 
> Still I do not see why it is desirable to reuse reg property, when we can
> introduce new property for describing the audio wiring.

Different people have different opinions.  Your opinion is just another
example of someone holding a different view.

You _have_ to have a unit address, and therefore you _have_ to have a
reg property.  If you want to use some other property to describe the
audio input pin, then you will need to make up a totally ficticious
unit-address and reg property for each audio input pin.

That's adding complexity, arguably unnecessary complexity, and making
the binding unnecessarily more complex for no good reason.

> >I don't particularly like the video node using the RGB routing register
> >value either for the reg property, but I've kept quiet because I have
> >nothing to offer there: again, this comes down to ePAPR requirements
> >and the need to specify multiple "port { }" nodes.  You can't have two
> >"port { }" nodes without using a unit-address, and we'd need to chose
> >a unit-address for it which doesn't conflict with the audio ports...
> >so there's a kind of logic to using the RGB routing value, which will
> >never conflict.
> >
> 
> If we after all decide to go with using reg property for audio wiring (and
> essentially writing the value directly to AP_ENA register), then we could
> also agree that video port's unit address is always 0 as it corresponds to
> audio disabled in AP_ENA register and would not collide with any audio
> "address". Then we could keep the old video-ports property to configure the
> video wiring. How does this sound?

Sub-standard :)

This has actually been discussed before.  See the thread:

"[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio"

from January 2015.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


[Bug 94242] [radeonsi] Crash while running Fedora mock tool for prompting root (gtksu)

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94242

--- Comment #8 from Marek Olšák  ---
The bad news is the check_vm report probably doesn't contain the problematic
shaders. The good news is I can reproduce this after updating LLVM, thus this
is an LLVM bug. I'm bisecting.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/00205474/attachment.html>


[PATCH 30/33] drm/omap: verify that fb plane pitches are the same

2016-02-26 Thread Tomi Valkeinen


On 26/02/16 10:55, Laurent Pinchart wrote:

>> I don't quite understand what you mean. The checks apply to all planes.
> 
> My point is that if you add a check to ensure that the pitch is identical in 
> all planes, the other tests on the pitch don't have to be repeated for every 
> plane.

Hmm... The other tests also depend on the plane's bpp, so I'm not sure
if any of those can be skipped.

But I agree, the loop with the checks does look somewhat complex, and
there's probably room for improvement.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/4176949e/attachment.sig>


[PATCH 11/33] drm/omap: use dma_mapping_error in omap_gem_attach_pages

2016-02-26 Thread Tomi Valkeinen
On 26/02/16 10:52, Laurent Pinchart wrote:

>>>> +
>>>> +  for (i = i - 1; i >= 0; --i) {
>>>
>>> Maybe i-- instead of i = i - 1 ?
>>
>> Hmm I don't know... I do like assignment in the initializer more than
>> i--. And why i--? Why not --i? =)
> 
> --i is fine with me too ;-) Or maybe
> 
>   while (i--)
>   dma_unmap_page(dev->dev, addrs[i],
>PAGE_SIZE, DMA_BIDIRECTIONAL);

Maybe it's just me, but I find it a bit difficult to decipher what
exactly goes on there.

I think the original 'if' is the most clear one: start from i-1, do
while i>=0, decrement by one. It's obvious with a quick glance, whereas
with the 'while' I need to stop and think.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/784d0d84/attachment.sig>


[PATCH 30/33] drm/omap: verify that fb plane pitches are the same

2016-02-26 Thread Laurent Pinchart
Hi Tomi,

On Thursday 25 February 2016 17:56:57 Tomi Valkeinen wrote:
> On 24/02/16 01:02, Laurent Pinchart wrote:
> > On Friday 19 February 2016 11:48:05 Tomi Valkeinen wrote:
> >> The DSS hardware uses the same ROW_INC value for both Y and UV planes
> >> for NV12 format. This means that the pitches of the Y and UV planes have
> >> to match. omapdrm doesn't check this at the moment, and this can lead
> >> into a broken NV12 fb on the screen.
> >> 
> >> This patch adds the check.
> >> 
> >> Signed-off-by: Tomi Valkeinen 
> > 
> > Reviewed-by: Laurent Pinchart 
> > 
> > We can probably simplify the implementation further as most of the checks
> > in the loop apply to the first place only. Would you like me to give it a
> > go ?
>
> "place" is plane?

Yes, sorry.

> I don't quite understand what you mean. The checks apply to all planes.

My point is that if you add a check to ensure that the pitch is identical in 
all planes, the other tests on the pitch don't have to be repeated for every 
plane.

-- 
Regards,

Laurent Pinchart



[PATCH 12/33] drm/omap: use dma_mapping_error in omap_gem_dma_sync

2016-02-26 Thread Laurent Pinchart
Hi Tomi,

On Thursday 25 February 2016 17:45:48 Tomi Valkeinen wrote:
> On 24/02/16 00:14, Laurent Pinchart wrote:
> > On Friday 19 February 2016 11:47:47 Tomi Valkeinen wrote:
> >> omap_gem_dma_sync() calls dma_map_page() but does not check the possible
> >> error with dma_mapping_error(). If DMA-API debugging is enabled, the
> >> debug layer will give a warning if dma_mapping_error() has not been
> >> used.
> >> 
> >> This patch adds proper error handling to omap_gem_dma_sync().
> >> 
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >> 
> >>  drivers/gpu/drm/omapdrm/omap_gem.c | 11 ++-
> >>  1 file changed, 10 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> >> b/drivers/gpu/drm/omapdrm/omap_gem.c index 7098190815f1..a60c30a59f7e
> >> 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> >> @@ -775,9 +775,18 @@ void omap_gem_dma_sync(struct drm_gem_object *obj,
> >> 
> >>for (i = 0; i < npages; i++) {
> >>if (!omap_obj->addrs[i]) {
> >> -  omap_obj->addrs[i] = dma_map_page(dev->dev, 
> >> pages[i], 0,
> >> +  dma_addr_t addr;
> >> +
> >> +  addr = dma_map_page(dev->dev, pages[i], 0,
> >>PAGE_SIZE, DMA_BIDIRECTIONAL);
> >> +
> >> +  if (dma_mapping_error(dev->dev, addr)) {
> >> +  dev_warn(dev->dev, "omap_gem_dma_sync: 
> >> dma_map_page
> > failed\n");
> > 
> > Same comment as for the previous patch.
> > 
> > No need to unmap ?
> 
> I don't know... Maybe, maybe not.
> 
> The function doesn't return any error, and the mapped pages are stored
> in omap_obj->addrs[]. So, if the failure was temporary, next time we
> have already mapped the pages that did succeed. If the failure was not
> temporary, well, we don't pass any error anyway, so the pages have to be
> unmapped somewhere in any case.
> 
> So possibly we could unmap, but I don't see us leaking anything even if
> the dma_map_page fails.

OK. It's not a new issue anyway, so I'm fine with the patch (after fixing the 
dev_warn()).

-- 
Regards,

Laurent Pinchart



[PATCH 11/33] drm/omap: use dma_mapping_error in omap_gem_attach_pages

2016-02-26 Thread Laurent Pinchart
Hi Tomi,

On Thursday 25 February 2016 17:39:35 Tomi Valkeinen wrote:
> On 24/02/16 00:10, Laurent Pinchart wrote:
> > On Friday 19 February 2016 11:47:46 Tomi Valkeinen wrote:
> >> omap_gem_attach_pages() calls dma_map_page() but does not check the
> >> possible error with dma_mapping_error(). If DMA-API debugging is
> >> enabled, the debug layer will give a warning if dma_mapping_error() has
> >> not been used.
> >> 
> >> This patch adds proper error handling to omap_gem_attach_pages().
> >> 
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >> 
> >>  drivers/gpu/drm/omapdrm/omap_gem.c | 14 ++
> >>  1 file changed, 14 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> >> b/drivers/gpu/drm/omapdrm/omap_gem.c index 8495a1a4b617..7098190815f1
> >> 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> >> @@ -264,6 +264,18 @@ static int omap_gem_attach_pages(struct
> >> drm_gem_object *obj)
> >>for (i = 0; i < npages; i++) {
> >>addrs[i] = dma_map_page(dev->dev, pages[i],
> >>0, PAGE_SIZE, DMA_BIDIRECTIONAL);
> >> +
> >> +  if (dma_mapping_error(dev->dev, addrs[i])) {
> >> +  dev_warn(dev->dev, "omap_gem_attach_pages: 
> >> dma_map_page
> > failed\n");
> > 
> > Using dev_warn(dev->dev, "%s: failed to map page\n", __func__); and proper
> > line breaks you'll have no trouble complying with the 80 characters per
> > line limit :-)
> 
> Ok.
> 
> >> +
> >> +  for (i = i - 1; i >= 0; --i) {
> > 
> > Maybe i-- instead of i = i - 1 ?
> 
> Hmm I don't know... I do like assignment in the initializer more than
> i--. And why i--? Why not --i? =)

--i is fine with me too ;-) Or maybe

while (i--)
dma_unmap_page(dev->dev, addrs[i],
 PAGE_SIZE, DMA_BIDIRECTIONAL);

> >> +  dma_unmap_page(dev->dev, addrs[i],
> >> +  PAGE_SIZE, DMA_BIDIRECTIONAL);
> >> +  }
> >> +
> >> +  ret = -ENOMEM;
> >> +  goto free_addrs;
> >> +  }
> >> 
> >>}
> >>
> >>} else {
> >>
> >>addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
> >> 
> >> @@ -277,6 +289,8 @@ static int omap_gem_attach_pages(struct
> >> drm_gem_object
> >> *obj) omap_obj->pages = pages;
> >> 
> >>return 0;
> >> 
> >> +free_addrs:
> >> +  kfree(addrs);
> > 
> > I'd move this blank line before free_addrs.
> 
> Yes, that makes it cleaner.

-- 
Regards,

Laurent Pinchart



[Bug 93594] Flickering Shadows in The Talos Principle

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93594

Marek Olšák  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #27 from Marek Olšák  ---
(In reply to EoD from comment #26)
> (In reply to Marek Olšák from comment #25)
> > (In reply to Christoph Haag from comment #24)
> > > Well, not sure what exactly we are talking about. The quick flickering 
> > > that
> > > made it completely unplaybable is gone.
> > > 
> > > I'm not sure how the shadows are supposed to look like. I tried
> > > https://cgit.freedesktop.org/~nh/llvm/log/?h=images and that's what it 
> > > looks
> > > like
> > > https://www.youtube.com/watch?v=DzkV_BHXzuU
> > > (damn, gstreamer recording + vaapi encoding is stuttering a lot again)
> > 
> > Looks good. What fixed it? The LLVM patch or game update?
> 
> The video shows from Christoph Haag shows those "minor flickerings" we were
> talking about. Those flickers also are in the D3D11 and Vulkan version of
> the game, so it's not an issue on mesa's side.

It's not an issue. It's normal behavior. It's a trait of the shadow mapping
technique and it happens when the shadow map isn't large enough. AFAIK, shadow
mapping is the best way to do soft shadows, but the technique alone can create
a lot of artifacts and what you've seen there aren't even the worst ones. Game
developers usually spend as much time implementing shadow mapping as they spend
on attempts to hide its flaws. See the images here for some extreme examples of
what is "normal" with the technique:
https://takinginitiative.wordpress.com/2011/05/25/directx10-tutorial-10-shadow-mapping-part-2/

> 
> For me, the flickering disappeared after updating the game, not llvm. Do you
> want us to test the old game version with those llvm changes?

No, we can close this as fixed by the game developer. Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/4e541c9a/attachment-0001.html>


[PATCH v5 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem

2016-02-26 Thread Xinliang Liu
On 25 February 2016 at 10:21, Xinliang Liu  wrote:
> On 24 February 2016 at 02:37, Mark Rutland  wrote:
> Hi Mark, thanks for review.
>
>> On Tue, Feb 23, 2016 at 11:00:21AM +0800, Xinliang Liu wrote:
>>> Add ADE display controller binding doc.
>>> Add DesignWare DSI Host Controller v1.20a binding doc.
>>>
>>> v5:
>>> - Remove endpoint unit address of dsi output port.
>>> - Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
>>> - Add "resets" property for ADE reset.
>>> v4:
>>> - Describe more specific of clocks and ports.
>>> - Fix indentation.
>>> v3:
>>> - Make ade as the drm master node.
>>> - Use assigned-clocks to set clock rate.
>>> - Use ports to connect display relavant nodes.
>>> v2:
>>> - Move dt binding docs to bindings/display/hisilicon directory.
>>>
>>> Signed-off-by: Xinwei Kong 
>>> Signed-off-by: Xinliang Liu 
>>> ---
>>>  .../bindings/display/hisilicon/dw-dsi.txt  | 72 
>>> ++
>>>  .../bindings/display/hisilicon/hisi-ade.txt| 64 +++
>>>  2 files changed, 136 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt 
>>> b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>> new file mode 100644
>>> index ..0d234b5e19af
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>> @@ -0,0 +1,72 @@
>>> +Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
>>> +
>>> +A DSI Host Controller resides in the middle of display controller and 
>>> external
>>> +HDMI converter or panel.
>>> +
>>> +Required properties:
>>> +- compatible: value should be "hisilicon,hi6220-dsi".
>>> +- reg: physical base address and length of dsi controller's registers.
>>> +- clocks: the clocks needed.
>>> +- clock-names: the name of the clocks.
>>
>> You _must_ specify the precise set of clock names you expect here.
>>
>> Per the example, you seem to expect "pclk_dsi".
>>
>> Is that the name given in the DSI controller manual? Or is it just
>> "pclk"? It's already specific to the DSI controller...
>>

Yet, while reading the DSI controller manual. It is called "pclk".
Yes, you are right this is already specific to the DSI controller.
will use "pclk" instead in next version.

>
> I have read the SoC manual again, and it is the configuration clock.
> Maybe we can call it "cfg_clk".



>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt 
>>> b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>> new file mode 100644
>>> index ..c1844b3ff878
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>> @@ -0,0 +1,64 @@
>>> +Device-Tree bindings for hisilicon ADE display controller driver
>>> +
>>> +ADE (Advanced Display Engine) is the display controller which grab image
>>> +data from memory, do composition, do post image processing, generate RGB
>>> +timing stream and transfer to DSI.
>>> +
>>> +Required properties:
>>> +- compatible: value should be "hisilicon,hi6220-ade".
>>> +- reg: physical base address and length of the ADE controller's registers.
>>> +  Value should be "<0x0 0xf410 0x0 0x7800>".
>>
>> Get rid of the "Value should be ... " part. It is nonsensical to
>> describe this in the binding. Just describe what this is with relation
>> to _this_ IP block.
>
> OK, will fix all these parts in next version.
>
>>
>>> +- reg-names: name of physical base. Value should be "ade_base".
>>
>> That obviously doesn't apply to *-names propertiesm which must all be
>> specified in the binding (they're local to the device rather than
>> remote).
>>
>>> +- hisilicon,noc-syscon: ADE NOC QoS syscon. Value should be 
>>> "<_ade>"
>>> +- resets: The ADE reset controller node. Value should be "<_ctrl
>>> +  MEDIA_ADE>".
>>
>> Likewise.
>>
>>> +- interrupt: the ldi vblank interrupt number used.
>>> +- clocks: the clocks needed. Three clocks are used in ADE driver:
>>> +  ADE core clock, value should be "<_ctrl HI6220_ADE_CORE>";
>>> +  ADE pixel clok, value should be "<_ctrl HI6220_ADE_PIX_SRC>";
>>> +  media NOC QoS clock, value should be "<_ctrl HI6220_CODEC_JPEG>".
>>> +- clock-names: the name of the clocks. Values should be "clk_ade_core",
>>> +  "clk_codec_jpeg" and "clk_ade_pix".
>>
>> Likewise, don't specify the value.
>>
>> Jsut define clocks in terms of clock-names, e.g.
>>
>> - clocks: a list of phandle + clock-specifier pairs, one for each entry
>>   in clock-names.
>> - clock-names: should contain:
>>   * "clk_ade_core" for the ADE ciore clock
>>   * ...
>>   * ...
>
> All right, got it. Thanks for teaching me how to to.
>
>>
>>> +- assigned-clocks: clocks to be assigned rate.
>>> +- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
>>> 

[Bug 94272] machinectl shell causes screen to get scrambled

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94272

Michel D�nzer  changed:

   What|Removed |Added

Product|Mesa|xorg
Version|11.1|unspecified
  Component|Drivers/Gallium/r600|Server/DDX/Xorg
 QA Contact|dri-devel at lists.freedesktop |xorg-team at lists.x.org
   |.org|
   Assignee|dri-devel at lists.freedesktop |xorg-team at lists.x.org
   |.org|

--- Comment #1 from Michel D�nzer  ---
Looks like machinectl / polkitd is doing something funky wrt VTs: The first
time I run it, it switches away from X to an empty VT with just a blinking
cursor. However, the line

 (II) AIGLX: Suspending AIGLX clients for VT switch

only appears in the Xorg log when I switch to *another* VT, so apparently the
Xorg server/driver doesn't get notified about the first VT switch. As such, it
can't really be a graphics driver issue. Reassigning to Xorg for now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/0a71bf14/attachment.html>


[PATCH] drm: sti: remove sti_gem_prime_export hack

2016-02-26 Thread Benjamin Gaignard
Thanks to "drm: prime: Honour O_RDWR during prime-handle-to-fd"
commit we don't need to hack flags anymore.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_drv.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 506b562..32a3eec 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -181,15 +181,6 @@ static const struct file_operations sti_driver_fops = {
.release = drm_release,
 };

-static struct dma_buf *sti_gem_prime_export(struct drm_device *dev,
-   struct drm_gem_object *obj,
-   int flags)
-{
-   /* we want to be able to write in mmapped buffer */
-   flags |= O_RDWR;
-   return drm_gem_prime_export(dev, obj, flags);
-}
-
 static struct drm_driver sti_driver = {
.driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
DRIVER_GEM | DRIVER_PRIME,
@@ -207,7 +198,7 @@ static struct drm_driver sti_driver = {

.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = sti_gem_prime_export,
+   .gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
-- 
1.9.1



[v4] drm/panel: add s6e3ha2 AMOLED panel driver

2016-02-26 Thread Marek Szyprowski
Hello,

Hyungwon Hwang  samsung.com> writes:

> Dear Theirry,
> 
> Gentle ping. I modified as you reviewed before. Also I wrote the
> reason for using passing variable by reference for error checking. Can
> you share your opinion for that, and review this driver?
> 
> Best regards,
> Hyungwon Hwang
> 
> On Fri, 29 May 2015 18:47:02 +0900
> Hyungwon Hwang  gmail.com> wrote:
> > 
> > This patch adds MIPI-DSI based S6E3HA2 panel driver. This panel has
> > 1440x2560 resolution in 5.7-inch physical panel.
> > 
> > Signed-off-by: Donghwa Lee  samsung.com>
> > Signed-off-by: Hyungwon Hwang  samsung.com>
> > Cc: Inki Dae  samsung.com>

Theirry, do you want a resend of this driver for another review? We would
really like to have it merged.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland 



[Bug 94284] [radeonsi] outlast segfault on start

2016-02-26 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=94284

--- Comment #3 from Michel D�nzer  ---
Created attachment 121980
  --> https://bugs.freedesktop.org/attachment.cgi?id=121980=edit
Invalid reads flagged by valgrind

I got these when replaying the apitrace from bug 94242. Looks like there may be
some sampler view / resource referencing imbalance somewhere, resulting in the
radeonsi driver accessing memory of a resource which was already destroyed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160226/828dcb98/attachment.html>


[PATCH, RESEND] drm/sti: use u32 to store DMA addresses

2016-02-26 Thread Vincent ABRIOU
Hi Arnd,


Your patch will be part of the next pull request for the STI driver that 
will be done by the end of next week.

Reviewed-by: Vincent Abriou 

On 02/25/2016 10:11 PM, Arnd Bergmann wrote:
> The STi drm driver correctly warns about invalid format strings
> when built with 64-bit dma_addr_t:
>
> sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
> sti_hqvdp.c:605:119: warning: format '%x' expects argument of type 'unsigned 
> int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' 
> [-Wformat=]
> sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
> sti_hqvdp.c:931:118: warning: format '%x' expects argument of type 'unsigned 
> int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' 
> [-Wformat=]
>
> This could be changed to using the %pad format string, but that
> does not work when printing an rvalue, so instead I'm changing
> the type in the sti_hqvdp structure to u32, which is what gets
> written into the registers anyway.
>
> Signed-off-by: Arnd Bergmann 
> ---
>   drivers/gpu/drm/sti/sti_hqvdp.c | 14 --
>   1 file changed, 8 insertions(+), 6 deletions(-)
>
> I originally submitted this on Tue, 08 Dec 2015, but got no reply,
> so resending the same patch now.
>
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index 1d3c3d029603..7818d47bea43 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -349,7 +349,7 @@ struct sti_hqvdp {
>   unsigned int curr_field_count;
>   unsigned int last_field_count;
>   void *hqvdp_cmd;
> - dma_addr_t hqvdp_cmd_paddr;
> + u32 hqvdp_cmd_paddr;
>   struct sti_vtg *vtg;
>   bool xp70_initialized;
>   };
> @@ -372,8 +372,8 @@ static const uint32_t hqvdp_supported_formats[] = {
>*/
>   static int sti_hqvdp_get_free_cmd(struct sti_hqvdp *hqvdp)
>   {
> - int curr_cmd, next_cmd;
> - dma_addr_t cmd = hqvdp->hqvdp_cmd_paddr;
> + u32 curr_cmd, next_cmd;
> + u32 cmd = hqvdp->hqvdp_cmd_paddr;
>   int i;
>
>   curr_cmd = readl(hqvdp->regs + HQVDP_MBX_CURRENT_CMD);
> @@ -400,8 +400,8 @@ static int sti_hqvdp_get_free_cmd(struct sti_hqvdp *hqvdp)
>*/
>   static int sti_hqvdp_get_curr_cmd(struct sti_hqvdp *hqvdp)
>   {
> - int curr_cmd;
> - dma_addr_t cmd = hqvdp->hqvdp_cmd_paddr;
> + u32 curr_cmd;
> + u32 cmd = hqvdp->hqvdp_cmd_paddr;
>   unsigned int i;
>
>   curr_cmd = readl(hqvdp->regs + HQVDP_MBX_CURRENT_CMD);
> @@ -612,19 +612,21 @@ int sti_hqvdp_vtg_cb(struct notifier_block *nb, 
> unsigned long evt, void *data)
>   static void sti_hqvdp_init(struct sti_hqvdp *hqvdp)
>   {
>   int size;
> + dma_addr_t dma_addr;
>
>   hqvdp->vtg_nb.notifier_call = sti_hqvdp_vtg_cb;
>
>   /* Allocate memory for the VDP commands */
>   size = NB_VDP_CMD * sizeof(struct sti_hqvdp_cmd);
>   hqvdp->hqvdp_cmd = dma_alloc_wc(hqvdp->dev, size,
> - >hqvdp_cmd_paddr,
> + _addr,
>   GFP_KERNEL | GFP_DMA);
>   if (!hqvdp->hqvdp_cmd) {
>   DRM_ERROR("Failed to allocate memory for VDP cmd\n");
>   return;
>   }
>
> + hqvdp->hqvdp_cmd_paddr = (u32)dma_addr;
>   memset(hqvdp->hqvdp_cmd, 0, size);
>   }
>
>


  1   2   >