[PATCH] exynos-drm: Fix error messages to print flags and size

[Inki Dae]

2016-10-06 22:09 GMT+09:00 Tobias Jakobi :
> Hello,
>
> I think this patch was never picked up. So just a short 'ping' from my side.
>

Oops. one I missed. Will pick it up soon.

Thanks,
Inki Dae

> With best wishes,
> Tobias
>
>
> Shuah Khan wrote:
>> Fix exynos_drm_gem_create() error messages to include flags and size when
>> flags and size are invalid.
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index cdf9f1a..4c4cb0e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -231,12 +231,12 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
>> drm_device *dev,
>>   int ret;
>>
>>   if (flags & ~(EXYNOS_BO_MASK)) {
>> - DRM_ERROR("invalid flags.\n");
>> + DRM_ERROR("invalid GEM buffer flags: %u\n", flags);
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>>   if (!size) {
>> - DRM_ERROR("invalid size.\n");
>> + DRM_ERROR("invalid GEM buffer size: %lu\n", size);
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

[Michael Ellerman]

Lorenzo Stoakes  writes:

> diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
> index f52b7db3..010b7b3 100644
> --- a/arch/powerpc/kernel/ptrace32.c
> +++ b/arch/powerpc/kernel/ptrace32.c
> @@ -74,7 +74,7 @@ long compat_arch_ptrace(struct task_struct *child, 
> compat_long_t request,
>   break;
>  
>   copied = access_process_vm(child, (u64)addrOthers, ,
> - sizeof(tmp), 0);
> + sizeof(tmp), FOLL_FORCE);
>   if (copied != sizeof(tmp))
>   break;
>   ret = put_user(tmp, (u32 __user *)data);

LGTM.

> @@ -179,7 +179,8 @@ long compat_arch_ptrace(struct task_struct *child, 
> compat_long_t request,
>   break;
>   ret = 0;
>   if (access_process_vm(child, (u64)addrOthers, ,
> - sizeof(tmp), 1) == sizeof(tmp))
> + sizeof(tmp),
> + FOLL_FORCE | FOLL_WRITE) == sizeof(tmp))
>   break;
>   ret = -EIO;
>   break;

If you're respinning this anyway, can you format that as:

if (access_process_vm(child, (u64)addrOthers, , sizeof(tmp),
  FOLL_FORCE | FOLL_WRITE) == sizeof(tmp))
break;

I realise you probably deliberately didn't do that to make the diff clearer.

Either way:

Acked-by: Michael Ellerman  (powerpc)


cheers

the dp helper would try to enable the i2c channel for rockchip-edp

[Randy Li]

Hello,

   Recently, I want to use a eDP panel in my RK3288 platform, but I got 
the following message:

[8.935918] i2c i2c-6: of_i2c: modalias failure on /dp at ff97/ports
[8.936018] rockchip-drm display-subsystem: bound ff97.dp (ops 
rockchip_dp_component_ops [analogix_dp_rockchip])
It try to enable the eDP aux channel and add a new I2C controller, but 
it failed then the whole display subsystem is broken, the panel doesn't 
power on either.

   I hope somebody could figure out what is wrong with it.

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #37 from Jan Niklas Hasse  ---
> Sorry, but I don't know what you mean by "using bitsect".

Changes to the source code of the driver are controlled via Git as commits.
Assuming it once worked 144 Hz it's possible to use Git to find out which
commit caused the flickering. This is done by identifying any commit which
worked (good, in your case 4.4) and a commit which doesn't work (bad, 4.8).
Bisecting will then help you find the first bad commit faster (by sectioning
the pool of possible first bad commits in two sections repeatedly).

I'm not sure though that this good commit exists though. Flickering also
happens with 4.4 for me.

-- 
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/20161019/911a6e74/attachment.html>

[Bug 98333] 4K @ 60Hz over HDMI 2.0 not working with AMDGPU-DAL

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98333

Bug ID: 98333
   Summary: 4K @ 60Hz over HDMI 2.0 not working with AMDGPU-DAL
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: dillondixon at gmail.com

So this is regarding AMDGPU DAL as it currently exists in
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7, which from my
understanding contains the most up-to-date public-facing iteration of the DAL
patch.

So I have an HDMI 2.0 4K 60 Hz monitor (Vizio D40u-D1) as my main display
connected to an XFX RX 480. I'm using a kernel compiled from the branch listed
above.

Now the issue I'm having is that I'm stuck at 30 Hz. The RX 480 is capable of
driving this monitor at 60 Hz @ 4K, which works under Windows. Trying to switch
to 60 Hz either results in no signal, or just 30 Hz again.

I had the same issue in the past with the proprietary Linux Nvidia drivers on a
960 GTX I used to own, and after several months, the devs there were able to
figure out what the issue is, describe it in a forum post, and get a fix in.
See here:
https://devtalk.nvidia.com/default/topic/939971/linux/4k-60hz-works-in-windows-not-in-linux/

So what I'm hoping is that a similar fix would work in DAL.

I can provide logs on request (not sure to log right now).

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/20161019/e2623bed/attachment.html>

[PATCH 2/2] dma-buf/fence-array: hold fences reference when creating an array

[Christian König]

Am 19.10.2016 um 19:48 schrieb Gustavo Padovan:
> From: Gustavo Padovan 
>
> When creating fence arrays we were not holding references to the fences
> in the array, however when destroy the array we were putting away a
> reference to these fences.
>
> This patch hold the ref for all fences in the array when creating the
> array.
>
> It then removes the code that was holding the fences on both amdgpu_vm and
> sync_file. For sync_file, specially, we worked on small referencing
> refactor for sync_file_merge().
>
> Signed-off-by: Gustavo Padovan 

I would prefer it to keep it like it is, cause this is a bit inconsistent.

With this change the fence array takes the ownership of the array, but 
not of the fences inside it.

> ---
>   drivers/dma-buf/fence-array.c  |  8 
>   drivers/dma-buf/sync_file.c| 14 +++---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  3 ---
>   3 files changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
> index f1989fc..598737f 100644
> --- a/drivers/dma-buf/fence-array.c
> +++ b/drivers/dma-buf/fence-array.c
> @@ -112,10 +112,6 @@ EXPORT_SYMBOL(fence_array_ops);
>* Allocate a fence_array object and initialize the base fence with 
> fence_init().
>* In case of error it returns NULL.
>*
> - * The caller should allocate the fences array with num_fences size
> - * and fill it with the fences it wants to add to the object. Ownership of 
> this
> - * array is taken and fence_put() is used on each fence on release.
> - *

At bare minimum you should keep this comment, cause ownership of the 
array is still taken and so it is released in the destructor.

Christian.

>* If @signal_on_any is true the fence array signals if any fence in the 
> array
>* signals, otherwise it signals when all fences in the array signal.
>*/
> @@ -125,6 +121,7 @@ struct fence_array *fence_array_create(int num_fences, 
> struct fence **fences,
>   {
>   struct fence_array *array;
>   size_t size = sizeof(*array);
> + int i;
>   
>   /* Allocate the callback structures behind the array. */
>   size += num_fences * sizeof(struct fence_array_cb);
> @@ -140,6 +137,9 @@ struct fence_array *fence_array_create(int num_fences, 
> struct fence **fences,
>   atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
>   array->fences = fences;
>   
> + for (i = 0; i < array->num_fences; ++i)
> + fence_get(array->fences[i]);
> +
>   return array;
>   }
>   EXPORT_SYMBOL(fence_array_create);
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 235f8ac..678baaf 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -142,14 +142,8 @@ static int sync_file_set_fence(struct sync_file 
> *sync_file,
>   {
>   struct fence_array *array;
>   
> - /*
> -  * The reference for the fences in the new sync_file and held
> -  * in add_fence() during the merge procedure, so for num_fences == 1
> -  * we already own a new reference to the fence. For num_fence > 1
> -  * we own the reference of the fence_array creation.
> -  */
>   if (num_fences == 1) {
> - sync_file->fence = fences[0];
> + sync_file->fence = fence_get(fences[0]);
>   kfree(fences);
>   } else {
>   array = fence_array_create(num_fences, fences,
> @@ -180,10 +174,8 @@ static void add_fence(struct fence **fences, int *i, 
> struct fence *fence)
>   {
>   fences[*i] = fence;
>   
> - if (!fence_is_signaled(fence)) {
> - fence_get(fence);
> + if (!fence_is_signaled(fence))
>   (*i)++;
> - }
>   }
>   
>   /**
> @@ -255,7 +247,7 @@ static struct sync_file *sync_file_merge(const char 
> *name, struct sync_file *a,
>   add_fence(fences, , b_fences[i_b]);
>   
>   if (i == 0)
> - fences[i++] = fence_get(a_fences[0]);
> + fences[i++] = a_fences[0];
>   
>   if (num_fences > i) {
>   nfences = krealloc(fences, i * sizeof(*fences),
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index bc4b22c..4ee7988 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -228,9 +228,6 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
> amdgpu_ring *ring,
>   struct fence_array *array;
>   unsigned j;
>   
> - for (j = 0; j < i; ++j)
> - fence_get(fences[j]);
> -
>   array = fence_array_create(i, fences, fence_context,
>  seqno, true);
>   if (!array) {

[PATCH] reservation: fix reservation_object_wait_timeout_rcu result

[Christian König]

From: Christian König 

Return one when the timeout is zero and we don't got any fences.

Fixes "reservation: revert "wait only with non-zero timeout specified (v3)"".

Signed-off-by: Christian König 
---
 drivers/dma-buf/reservation.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index bb97b04..debb91d 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -379,7 +379,7 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
 {
struct fence *fence;
unsigned seq, shared_count, i = 0;
-   long ret = timeout;
+   long ret = timeout ? timeout : 1;

 retry:
fence = NULL;
-- 
2.5.0

[RESEND][GIT PULL] TDA998x I2C driver development updates

[Russell King]

Sorry, my mistake - it was merged, and it's just that I seem to have
accidentally rebased the branch, which is why the commits were still
showing up in my tree.

Sorry for the noise, please ignore.

On Wed, Oct 19, 2016 at 05:37:18PM +0100, Russell King wrote:
> David,
> 
> Please incorporate the latest TDA998x I2C driver development updates,
> which can be found at:
> 
>   git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
> 
> with SHA1 df0bd1e8f3c508bf4c3445f94b12e38289b65f13.
> 
> This was sent on the 9th September, and I was hoping that it was going
> to make 4.9-rc1 as TI want it in, but it appears that it was never
> picked up.  What's going on?  Should I queue this (and my other DRM
> changes) for Linus myself?
> 
> This will update the following files:
> 
>  .../devicetree/bindings/display/bridge/tda998x.txt |  18 ++
>  arch/arm/boot/dts/am335x-boneblack.dts |  71 -
>  drivers/gpu/drm/i2c/Kconfig|   1 +
>  drivers/gpu/drm/i2c/tda998x_drv.c  | 297 
> ++---
>  include/drm/i2c/tda998x.h  |  29 +-
>  include/dt-bindings/display/tda998x.h  |   7 +
>  6 files changed, 368 insertions(+), 55 deletions(-)
>  create mode 100644 include/dt-bindings/display/tda998x.h
> 
> through these changes:
> 
> Jyri Sarha (3):
>   drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata
>   drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding
>   ARM: dts: am335x-boneblack: Add HDMI audio support
> 
> Russell King (1):
>   Merge commit 'efc9194bcff84' ("ASoC: hdmi-codec: callback function will 
> be called with private data") into drm-tda998x-devel
> 
> Many thanks.

[PATCH v2] drm/bridge: adv7511: Remove unused code blocks

[Sharma, Jitendra]

Hi Laurent,


On 10/19/2016 7:03 PM, Laurent Pinchart wrote:
> Hi Jitendra,
>
> On Wednesday 19 Oct 2016 18:37:38 Sharma, Jitendra wrote:
>> On 10/19/2016 5:21 PM, Laurent Pinchart wrote:
>>> On Wednesday 19 Oct 2016 17:12:48 Jitendra Sharma wrote:
 Remove redundant condition check
 Remove not necessary if-else block for checking DT entry because else
 part will never be picked as in absence of device node, probe will
 fail in initial stage only.

 Remove unused id->driver_data entries
 As id->driver_data is not used in driver source. So no need in
 Keeping these entries in id_table

 Signed-off-by: Jitendra Sharma 
 ---
 Probe was not happening in Patch v1 due to removal of .id_table.As the
 intention of this patch is not to change any functionality, also
 changes looks simple enough.So, didn't verified Patch v1 over hardware
>>> You should *ALWAYS* verify patches before sending them out.
>> Will keep in mind
>>
>>> I assume you've now properly tested this one ?
>>>
 Hence fixing the issues in Patch v1 and posting patch v2

 Changes for v2:
- Keep the id_table entries
- Keep the id->driver_data to 0

 ---

drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)

 diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
 b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 8ed3906..3279059
 100644
 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
 +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
 @@ -942,10 +942,7 @@ static int adv7511_probe(struct i2c_client *i2c,
 const
 struct i2c_device_id *id) adv7511->powered = false;

adv7511->status = connector_status_disconnected;

 -  if (dev->of_node)
 -  adv7511->type = (enum
>>> adv7511_type)of_device_get_match_data(dev);
>>>
 -  else
 -  adv7511->type = id->driver_data;
 +  adv7511->type = (enum adv7511_type)of_device_get_match_data(dev);

memset(_config, 0, sizeof(link_config));

 @@ -1066,11 +1063,11 @@ static int adv7511_remove(struct i2c_client *i2c)

}

static const struct i2c_device_id adv7511_i2c_ids[] = {

 -  { "adv7511", ADV7511 },
 -  { "adv7511w", ADV7511 },
 -  { "adv7513", ADV7511 },
 +  { "adv7511", 0 },
 +  { "adv7511w", 0 },
 +  { "adv7513", 0 },

#ifdef CONFIG_DRM_I2C_ADV7533

 -  { "adv7533", ADV7533 },
 +  { "adv7533", 0 },

#endif
>>> What's the purpose of this ? It doesn't save any memory or CPU cycle.
>> Idea is to remove unnecessary code, variables and if possible to reduce
>> lines of code for example here by eliminating obvious branching.
>> Regarding memory or cpu cyles, no difference could be because of
>> compiler optimization
> For the code block in the probe function I understand, but for the
> initializers here I don't see the point.
>
> And one might argue that using id->driver_data unconditionally would be better
> as it would save a call to of_device_get_match_data()...
Agreed.
So, there could be two ways round either use id->driver_data 
unconditionally or use of_device_get_match_data().
IMO it would be better to use id->driver_data unconditionally and save a 
call to of_device_get_match_data()
What would you suggest to move ahead?
{ }

};

[PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

[Michal Hocko]

On Wed 19-10-16 09:49:43, Dave Hansen wrote:
> On 10/19/2016 02:07 AM, Michal Hocko wrote:
> > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> >>> I am wondering whether we can go further. E.g. it is not really clear to
> >>> me whether we need an explicit FOLL_REMOTE when we can in fact check
> >>> mm != current->mm and imply that. Maybe there are some contexts which
> >>> wouldn't work, I haven't checked.
> >>
> >> This flag is set even when /proc/self/mem is used. I've not looked deeply 
> >> into
> >> this flag but perhaps accessing your own memory this way can be considered
> >> 'remote' since you're not accessing it directly. On the other hand, 
> >> perhaps this
> >> is just mistaken in this case?
> > 
> > My understanding of the flag is quite limited as well. All I know it is
> > related to protection keys and it is needed to bypass protection check.
> > See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> > enforce PKEY permissions on remote mm access").
> 
> Yeah, we need the flag to tell us when PKEYs should be applied or not.
> The current task's PKRU (pkey rights register) should really only be
> used to impact access to the task's memory, but has no bearing on how a
> given task should access remote memory.

The question I had earlier was whether this has to be an explicit FOLL
flag used by g-u-p users or we can just use it internally when mm !=
current->mm

-- 
Michal Hocko
SUSE Labs

[PATCH v2] drm/bridge: adv7511: Remove unused code blocks

[Archit Taneja]

Hi.,

On 10/19/2016 6:37 PM, Sharma, Jitendra wrote:
> Hi Laurent,
>
>
> On 10/19/2016 5:21 PM, Laurent Pinchart wrote:
>> Hi Jitendra,
>>
>> Thank you for the patch.
>>
>> On Wednesday 19 Oct 2016 17:12:48 Jitendra Sharma wrote:
>>> Remove redundant condition check
>>> Remove not necessary if-else block for checking DT entry because else
>>> part will never be picked as in absence of device node, probe will
>>> fail in initial stage only.
>>>
>>> Remove unused id->driver_data entries
>>> As id->driver_data is not used in driver source. So no need in
>>> Keeping these entries in id_table
>>>
>>> Signed-off-by: Jitendra Sharma 
>>> ---
>>> Probe was not happening in Patch v1 due to removal of .id_table.As the
>>> intention of this patch is not to change any functionality, also
>>> changes looks simple enough.So, didn't verified Patch v1 over hardware
>> You should *ALWAYS* verify patches before sending them out.
> Will keep in mind
>>
>> I assume you've now properly tested this one ?

Tested v2 on Jitendra's behalf.

Thanks,
Archit

>>
>>> Hence fixing the issues in Patch v1 and posting patch v2
>>>
>>> Changes for v2:
>>>   - Keep the id_table entries
>>>   - Keep the id->driver_data to 0
>>> ---
>>>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 +
>>>   1 file changed, 5 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 8ed3906..3279059
>>> 100644
>>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>>> @@ -942,10 +942,7 @@ static int adv7511_probe(struct i2c_client *i2c,
>>> const
>>> struct i2c_device_id *id) adv7511->powered = false;
>>>   adv7511->status = connector_status_disconnected;
>>>
>>> -if (dev->of_node)
>>> -adv7511->type = (enum
>> adv7511_type)of_device_get_match_data(dev);
>>> -else
>>> -adv7511->type = id->driver_data;
>>> +adv7511->type = (enum adv7511_type)of_device_get_match_data(dev);
>>>
>>>   memset(_config, 0, sizeof(link_config));
>>>
>>> @@ -1066,11 +1063,11 @@ static int adv7511_remove(struct i2c_client
>>> *i2c)
>>>   }
>>>
>>>   static const struct i2c_device_id adv7511_i2c_ids[] = {
>>> -{ "adv7511", ADV7511 },
>>> -{ "adv7511w", ADV7511 },
>>> -{ "adv7513", ADV7511 },
>>> +{ "adv7511", 0 },
>>> +{ "adv7511w", 0 },
>>> +{ "adv7513", 0 },
>>>   #ifdef CONFIG_DRM_I2C_ADV7533
>>> -{ "adv7533", ADV7533 },
>>> +{ "adv7533", 0 },
>>>   #endif
>> What's the purpose of this ? It doesn't save any memory or CPU cycle.
> Idea is to remove unnecessary code, variables and if possible to reduce
> lines of code for example here by eliminating obvious branching.
> Regarding memory or cpu cyles, no difference could be because of
> compiler optimization
>>
>>>   { }
>>>   };
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Unix Device Memory Allocation project

[Marek Olšák]

On Wed, Oct 19, 2016 at 4:10 PM, Daniel Vetter  wrote:
> On Wed, Oct 19, 2016 at 03:15:08PM +0200, Marek Olšák wrote:
>> On Oct 19, 2016 8:24 AM, "Daniel Vetter"  wrote:
>> > On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák  wrote:
>> > > - The producer-consumer interop API doesn't know about the metadata.
>> > > All you need to pass around is a buffer handle. (KMS, DMABUF, etc.)
>> > >   * There was a note during the talk that DMABUF doesn't have any
>> > > metadata. Well, I just told you that it has, but it's private to
>> > > amdgpu and possibly accessible to other kernel drivers too.
>> > >   * We can build upon this idea. I think the worst thing to do would
>> > > be to add metadata handling to driver-agnostic userspace APIs. Really,
>> > > driver-agnostic APIs shouldn't know about that, because they can't
>> > > understand all the hw-specific information encoded in the metadata.
>> > > Also, when you want to change the metadata format, you only have to
>> > > update the affected drivers, not userspace APIs.
>> >
>> > That's a bit a surprise to hear, since "can't we just add a bit of
>> > opaque metadata to dma-buf" came up all the time over the past years,
>> > and died all the time again. dma-buf shouldn't imo be just yet another
>> > linux IPC mechanism and protocol, which is pretty much what you end up
>> > doing when you add this stuff. DRM runs all kinds of compositors with
>> > all kinds of existing userspace proto, and with reasonable ones like
>> > Wayland vendors can add whatever extensions they want. Plus there's
>> > all the interop with v4l and every other kernel subsytem. Trying to
>> > standardize that into some blob that works for everyone is imo nigh
>> > impossible.
>> >
>> > On top of that dma-buf is the wrong thing - you don't want this on
>> > buffers, but on surfaces. At least when it's time to reallocate. And
>> > oh dear I have seen what happens when soc vendors extend this design
>> > to cover that use-case, plus dynamic reallocation and all that. Imo
>> > there should be no way at all this ever comes close to dma-buf itself.
>> >
>> > And tbh I think it's a bit silly that amd snuck this in through
>> > amdgpu. But as long as you don't expect this to spread I guess it'll
>> > be fine.
>>
>> LOL. It's not per DMABUF, it's per buffer, so you need a KMS handle to
>> access it from userspace.
>
> Seems to be on gem buffers, not any KMS object (like framebuffers). For
> cross driver that corresponds to dma-buf, and the discussion here is about
> cross-driver/vendor buffer sharing.
>
>> We've had per buffer metadata in Radeon since KMS, which I believe first
>> appeared in 2009. It's 4 bytes large and is used to communicate tiling
>> flags between Mesa, DDX, and the kernel display code. It was a widely
>> accepted solution back then and Red Hat was the main developer. So yeah,
>> pretty much all people except Intel were collaborating on "sneaking" this
>> in in 2009. I think radeon driver developers deserve an apology for that
>> language.
>>
>> Amdgpu extended that metadata to 8 bytes and it's used in the same way as
>> radeon. Additionally, amdgpu added opaque metadata having 256 bytes for use
>> by userspace drivers only. The kernel driver isn't supposed to read it or
>> parse it. The format is negotiated between userspace driver developers for
>> sharing of more complex allocations than 2D displayable surfaces.
>
> Metadata needed for kms (what Christian also pointed out) is what everyone
> did (intel included) and I think that's perfectly reasonable. And I was
> aware of that radeon is doing that since the dawn of ages since forever.
>
> What I think is not really ok is opaque metadata blobs that the kernel
> never ever inspect, but just carries around. That essentially means you're
> reimplementing some bad form of IPC, and I dont think that's something the
> drm subsystem (or dma-buf) really should be doing. Because you still have
> that real protocol in userspace (dri2/3, wayland, whatever), but now with
> a side channel with no documented ordering and synchronization. It gets
> the job done for single-vendor buffer metadata transport, but as soon as
> there's more than one vendor, or as soon as you need to reallocate buffers
> dynamically because the usage changes it gets bad imo (and I've seen what

The metadata is immutable after allocation, so it's not a
communication channel. There is no synchronization or ordering needed
for immutable metadata. That implies that a shared buffer can't be
reused for an entirely different purpose. It can only be used as-is or
freed.

For suballocated memory, the idea is to reallocate it as a separate
buffer on the first "handle" export, so that shared suballocated
buffers don't exist.

> that looks like on android in various forms). And that consensus (at least
> among folks involved in dma-buf) goes back to the dma-buf kickoff 3-day
> meeting we've had over 5 years ago. Not sure we're gaining anything with a
> "who's older" competition.

[PATCH v2] drm/bridge: adv7511: Remove unused code blocks

[Sharma, Jitendra]

Hi Laurent,


On 10/19/2016 5:21 PM, Laurent Pinchart wrote:
> Hi Jitendra,
>
> Thank you for the patch.
>
> On Wednesday 19 Oct 2016 17:12:48 Jitendra Sharma wrote:
>> Remove redundant condition check
>> Remove not necessary if-else block for checking DT entry because else
>> part will never be picked as in absence of device node, probe will
>> fail in initial stage only.
>>
>> Remove unused id->driver_data entries
>> As id->driver_data is not used in driver source. So no need in
>> Keeping these entries in id_table
>>
>> Signed-off-by: Jitendra Sharma 
>> ---
>> Probe was not happening in Patch v1 due to removal of .id_table.As the
>> intention of this patch is not to change any functionality, also
>> changes looks simple enough.So, didn't verified Patch v1 over hardware
> You should *ALWAYS* verify patches before sending them out.
Will keep in mind
>
> I assume you've now properly tested this one ?
>
>> Hence fixing the issues in Patch v1 and posting patch v2
>>
>> Changes for v2:
>>   - Keep the id_table entries
>>   - Keep the id->driver_data to 0
>> ---
>>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 +
>>   1 file changed, 5 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 8ed3906..3279059
>> 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> @@ -942,10 +942,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
>> struct i2c_device_id *id) adv7511->powered = false;
>>  adv7511->status = connector_status_disconnected;
>>
>> -if (dev->of_node)
>> -adv7511->type = (enum
> adv7511_type)of_device_get_match_data(dev);
>> -else
>> -adv7511->type = id->driver_data;
>> +adv7511->type = (enum adv7511_type)of_device_get_match_data(dev);
>>
>>  memset(_config, 0, sizeof(link_config));
>>
>> @@ -1066,11 +1063,11 @@ static int adv7511_remove(struct i2c_client *i2c)
>>   }
>>
>>   static const struct i2c_device_id adv7511_i2c_ids[] = {
>> -{ "adv7511", ADV7511 },
>> -{ "adv7511w", ADV7511 },
>> -{ "adv7513", ADV7511 },
>> +{ "adv7511", 0 },
>> +{ "adv7511w", 0 },
>> +{ "adv7513", 0 },
>>   #ifdef CONFIG_DRM_I2C_ADV7533
>> -{ "adv7533", ADV7533 },
>> +{ "adv7533", 0 },
>>   #endif
> What's the purpose of this ? It doesn't save any memory or CPU cycle.
Idea is to remove unnecessary code, variables and if possible to reduce 
lines of code for example here by eliminating obvious branching.
Regarding memory or cpu cyles, no difference could be because of 
compiler optimization
>
>>  { }
>>   };

exynos-drm: display manager fails to start without IOMMU problem

[Tobias Jakobi]

Hello Shuah,

just a short note that more misleading comments about default allocation
flags can be found in libdrm.

https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c

See e.g. the comment for exynos_bo_create().

In my opinion, the whole approach to _set_ a bit to get non-contigious
memory is messed up. It would make more sense to me to set a bit to
request an additional property (here "being contiguous") of the memory.

Anyway, clearing up this situation is highly appreciated!

More comments below.

With best wishes,
Tobias



Shuah Khan wrote:
> Restarting the thread with a different subject line:
> 
> I haven't given up on this yet. I am still seeing the following failure:
> 
> Additional debug messages I added:
> [   15.287403] exynos_drm_gem_create_ioctl() 1
> [   15.287419] exynos_drm_gem_create() flags 1
> 
> [   15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM 
> memory is not supported.
> 
> Additional debug message I added:
> [   15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize 
> framebuffer
> 
> This is what happens:
> 
> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>check_fb_gem_memory_type()
> 
> At this point, there is no recovery and lightdm fails
> 
> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
> allocations are not supported in some exynos drm versions: The following
> commit introduced this change:
> 
> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
> 
> excerpts from the diff:-   if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
> -   create_exynos.flags = EXYNOS_BO_CONTIG;
> -   else
> -   create_exynos.flags = EXYNOS_BO_NONCONTIG;
> +
> +   /* Contiguous allocations are not supported in some exynos drm 
> versions.
> +* When they are supported all allocations are effectively contiguous
> +* anyway, so for simplicity we always request non contiguous buffers.
> +*/
> +   create_exynos.flags = EXYNOS_BO_NONCONTIG;
> 
> There might have been logic on exynos_drm that forced Contig when it coudn't
> support NONCONTIG. At least, that is what this comment suggests. This 
> assumption
> doesn't appear to be a good one and not sure if this change was made to fix a 
> bug.
> 
> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
> support, latest kernels have a mismatch with the installed xf86-video-armsoc
> 
> This is what I am running into. This leads to the following question:
> 
> 1. How do we ensure exynos_drm kernel changes don't break user-space
>specifically xf86-video-armsoc
> 2. This seems to have gone undetected for a while. I see a change in
>exynos_drm_gem_dumb_create() that is probably addressing this type
>of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>handling for IOMMU NONCONTIG case.
I don't think that this commit is related to the issue, since it is only
used for the generic dumb buffer ioctl, while armsoc is using an Exynos
specific ioctl.

So in particular you shouldn't see the issue with
xf86-video-modesetting. Might be worth trying that one out?


> 
> Anyway, I am interested in getting the exynos_drm kernel side code
> and xf86-video-armsoc in sync to resolve the issue.
> 
> Could you recommend a going forward plan?
> 
> I can submit a patch to xf86-video-armsoc. I am also looking ahead to
> see if we can avoid such breaks in the future by keeping kernel and
> xf86-video-armsoc in sync.
> 
> thanks,
> -- Shuah
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH] drm: Fix LSPCON kernel-doc

[Jani Nikula]

On Wed, 19 Oct 2016, Ville Syrjälä  wrote:
> On Wed, Oct 19, 2016 at 03:08:04PM +0300, Jani Nikula wrote:
>> Fix warnings on building htmldocs.
>> 
>> v2: whitespace around '/' (Ville)
>> 
>> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
>> Cc: Rodrigo Vivi 
>> Cc: Shashank Sharma 
>> Cc: 
>> Signed-off-by: Jani Nikula 
>
> lgtm
> Reviewed-by: Ville Syrjälä 

Pushed to drm-intel-next-queued, thanks for the review.

BR,
Jani.

>
>> 
>> ---
>> 
>> n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
>> been merged via drm-intel tree
>> ---
>>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
>>  include/drm/drm_dp_dual_mode_helper.h | 15 ---
>>  2 files changed, 15 insertions(+), 14 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
>> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> index 2624e266abbd..488355bdafb9 100644
>> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
>> @@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
>>  
>>  /**
>>   * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
>> - * by reading offset (0x80, 0x41)
>> - * @i2c_adapter: I2C-over-aux adapter
>> - * @current_mode: out vaiable, current lspcon mode of operation
>> + * reading offset (0x80, 0x41)
>> + * @adapter: I2C-over-aux adapter
>> + * @mode: current lspcon mode of operation output variable
>>   *
>>   * Returns:
>>   * 0 on success, sets the current_mode value to appropriate mode
>> @@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>>  EXPORT_SYMBOL(drm_lspcon_get_mode);
>>  
>>  /**
>> - * drm_lspcon_change_mode: Change LSPCON's mode of operation by
>> - * by writing offset (0x80, 0x40)
>> - * @i2c_adapter: I2C-over-aux adapter
>> - * @reqd_mode: required mode of operation
>> + * drm_lspcon_set_mode: Change LSPCON's mode of operation by
>> + * writing offset (0x80, 0x40)
>> + * @adapter: I2C-over-aux adapter
>> + * @mode: required mode of operation
>>   *
>>   * Returns:
>>   * 0 on success, -error on failure/timeout
>> diff --git a/include/drm/drm_dp_dual_mode_helper.h 
>> b/include/drm/drm_dp_dual_mode_helper.h
>> index 55677704add8..4c42db81fcb4 100644
>> --- a/include/drm/drm_dp_dual_mode_helper.h
>> +++ b/include/drm/drm_dp_dual_mode_helper.h
>> @@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter 
>> *adapter,
>> u8 offset, const void *buffer, size_t size);
>>  
>>  /**
>> -* enum drm_lspcon_mode
>> -* @lspcon_mode_ls: Level shifter mode of LSPCON
>> -*   which drives DP++ to HDMI 1.4 conversion.
>> -* @lspcon_mode_pcon: Protocol converter mode of LSPCON
>> -*   which drives DP++ to HDMI 2.0 active conversion.
>> -*/
>> + * enum drm_lspcon_mode
>> + * @DRM_LSPCON_MODE_INVALID: No LSPCON.
>> + * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
>> + *  which drives DP++ to HDMI 1.4 conversion.
>> + * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
>> + *  which drives DP++ to HDMI 2.0 active conversion.
>> + */
>>  enum drm_lspcon_mode {
>>  DRM_LSPCON_MODE_INVALID,
>>  DRM_LSPCON_MODE_LS,
>> @@ -90,7 +91,7 @@ enum drm_lspcon_mode {
>>   * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
>>   * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
>>   * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
>> - * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
>> + * @DRM_DP_DUAL_MODE_LSPCON: Level shifter / protocol converter
>>   */
>>  enum drm_dp_dual_mode_type {
>>  DRM_DP_DUAL_MODE_NONE,
>> -- 
>> 2.1.4

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/msm: update uapi header license

[Rob Clark]

The same file in libdrm is, as is the tradition with the rest of libdrm,
etc, using an MIT license.  To avoid complications in the future with
sync'ing the uapi header to libdrm, lets fix the license mismatch now
before there are any non-trivial commits from someone other than myself.

Cc: Emil Velikov 
Cc: Gabriel Laskar 
Cc: Mikko Rapeli 
Signed-off-by: Rob Clark 
---
 include/uapi/drm/msm_drm.h | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 233ed30..6a1b1d4 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -2,17 +2,24 @@
  * Copyright (C) 2013 Red Hat
  * Author: Rob Clark 
  *
- * 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.
+ * 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:
  *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
  *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
+ * 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.
  */

 #ifndef __MSM_DRM_H__
-- 
2.7.4

[PATCH] drm: Fix LSPCON kernel-doc

[Ville Syrjälä]

On Wed, Oct 19, 2016 at 03:08:04PM +0300, Jani Nikula wrote:
> Fix warnings on building htmldocs.
> 
> v2: whitespace around '/' (Ville)
> 
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Rodrigo Vivi 
> Cc: Shashank Sharma 
> Cc: 
> Signed-off-by: Jani Nikula 

lgtm
Reviewed-by: Ville Syrjälä 

> 
> ---
> 
> n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
> been merged via drm-intel tree
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
>  include/drm/drm_dp_dual_mode_helper.h | 15 ---
>  2 files changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 2624e266abbd..488355bdafb9 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
>  
>  /**
>   * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
> - * by reading offset (0x80, 0x41)
> - * @i2c_adapter: I2C-over-aux adapter
> - * @current_mode: out vaiable, current lspcon mode of operation
> + * reading offset (0x80, 0x41)
> + * @adapter: I2C-over-aux adapter
> + * @mode: current lspcon mode of operation output variable
>   *
>   * Returns:
>   * 0 on success, sets the current_mode value to appropriate mode
> @@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>  EXPORT_SYMBOL(drm_lspcon_get_mode);
>  
>  /**
> - * drm_lspcon_change_mode: Change LSPCON's mode of operation by
> - * by writing offset (0x80, 0x40)
> - * @i2c_adapter: I2C-over-aux adapter
> - * @reqd_mode: required mode of operation
> + * drm_lspcon_set_mode: Change LSPCON's mode of operation by
> + * writing offset (0x80, 0x40)
> + * @adapter: I2C-over-aux adapter
> + * @mode: required mode of operation
>   *
>   * Returns:
>   * 0 on success, -error on failure/timeout
> diff --git a/include/drm/drm_dp_dual_mode_helper.h 
> b/include/drm/drm_dp_dual_mode_helper.h
> index 55677704add8..4c42db81fcb4 100644
> --- a/include/drm/drm_dp_dual_mode_helper.h
> +++ b/include/drm/drm_dp_dual_mode_helper.h
> @@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter 
> *adapter,
>  u8 offset, const void *buffer, size_t size);
>  
>  /**
> -* enum drm_lspcon_mode
> -* @lspcon_mode_ls: Level shifter mode of LSPCON
> -*which drives DP++ to HDMI 1.4 conversion.
> -* @lspcon_mode_pcon: Protocol converter mode of LSPCON
> -*which drives DP++ to HDMI 2.0 active conversion.
> -*/
> + * enum drm_lspcon_mode
> + * @DRM_LSPCON_MODE_INVALID: No LSPCON.
> + * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
> + *   which drives DP++ to HDMI 1.4 conversion.
> + * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
> + *   which drives DP++ to HDMI 2.0 active conversion.
> + */
>  enum drm_lspcon_mode {
>   DRM_LSPCON_MODE_INVALID,
>   DRM_LSPCON_MODE_LS,
> @@ -90,7 +91,7 @@ enum drm_lspcon_mode {
>   * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
>   * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
>   * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
> - * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
> + * @DRM_DP_DUAL_MODE_LSPCON: Level shifter / protocol converter
>   */
>  enum drm_dp_dual_mode_type {
>   DRM_DP_DUAL_MODE_NONE,
> -- 
> 2.1.4

-- 
Ville Syrjälä
Intel OTC

[RESEND][GIT PULL] TDA998x I2C driver development updates

[Russell King]

David,

Please incorporate the latest TDA998x I2C driver development updates,
which can be found at:

  git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel

with SHA1 df0bd1e8f3c508bf4c3445f94b12e38289b65f13.

This was sent on the 9th September, and I was hoping that it was going
to make 4.9-rc1 as TI want it in, but it appears that it was never
picked up.  What's going on?  Should I queue this (and my other DRM
changes) for Linus myself?

This will update the following files:

 .../devicetree/bindings/display/bridge/tda998x.txt |  18 ++
 arch/arm/boot/dts/am335x-boneblack.dts |  71 -
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 297 ++---
 include/drm/i2c/tda998x.h  |  29 +-
 include/dt-bindings/display/tda998x.h  |   7 +
 6 files changed, 368 insertions(+), 55 deletions(-)
 create mode 100644 include/dt-bindings/display/tda998x.h

through these changes:

Jyri Sarha (3):
  drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata
  drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding
  ARM: dts: am335x-boneblack: Add HDMI audio support

Russell King (1):
  Merge commit 'efc9194bcff84' ("ASoC: hdmi-codec: callback function will 
be called with private data") into drm-tda998x-devel

Many thanks.

[Intel-gfx] [PATCH] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

On Wed, Oct 12, 2016 at 12:41 PM, Joonas Lahtinen <
joonas.lahtinen at linux.intel.com> wrote:

> On ti, 2016-10-11 at 12:03 -0700, Robert Bragg wrote:
> > > > +   case DRM_I915_PERF_PROP_MAX:
> > > > +   BUG();
> > >
> > > We already handle this case above, but I guess we still need this in
> > > order to silence gcc...
> >
> > right, and preferable to having a default: case, for the future compiler
> warning to handle any new properties here.
>
> Please, do use MISSING_CASE instead. Daniel is known to get upset for
> far less ;)
>
> Generally consensus is that BUG() is used only when there're no other
> options to back out.
>

thanks for this pointer.

I'll add a default: with MISSING_CASE as that looks like an i915-specific
convention; though it seems like a real shame to defer missing case issues
to runtime errors instead of taking advantage of the compiler complaining
at build time that a case has been forgotten.

Thanks,
- Robert



>
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/9f52acaf/attachment.html>

[Bug 98324] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98324

Darren Salt  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)

-- 
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/20161019/9c1beb3f/attachment-0001.html>

[PATCH 3/3] drm/fsl-dcu: disable outputs before unloading driver

[Stefan Agner]

Make sure that all outputs are disabled before unloading the DRM
driver. Otherwise vblank handling is not shut down properly and
warnings such as this appear:
WARNING: CPU: 0 PID: 540 at drivers/gpu/drm/drm_irq.c:339 
drm_vblank_cleanup+0x5c/0x94

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 66f3d2c..4a31f20 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -108,6 +108,7 @@ static int fsl_dcu_unload(struct drm_device *dev)
 {
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;

+   drm_crtc_force_disable_all(dev);
drm_kms_helper_poll_fini(dev);

if (fsl_dev->fbdev)
-- 
2.10.0

[PATCH 2/3] drm/fsl-dcu: unload driver before disabling clocks

[Stefan Agner]

Use drm_put_dev to unload the driver before disabling clocks.
Otherwise the driver might read a register during unload which
leads to an external abort.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 07969f5..66f3d2c 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -429,9 +429,9 @@ static int fsl_dcu_drm_remove(struct platform_device *pdev)
 {
struct fsl_dcu_drm_device *fsl_dev = platform_get_drvdata(pdev);

+   drm_put_dev(fsl_dev->drm);
clk_disable_unprepare(fsl_dev->clk);
clk_unregister(fsl_dev->pix_clk);
-   drm_put_dev(fsl_dev->drm);

return 0;
 }
-- 
2.10.0

[PATCH 1/3] drm/fb_cma_helper: do not free fbdev if there is none

[Stefan Agner]

If fbdev emulation is not in use (or not built-in), fb_helper.fbdev
is NULL. Don't call calling drm_fbdev_cma_defio_fini in this case.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 1fd6eac..12d654d 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -557,7 +557,8 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_init);
 void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma)
 {
drm_fb_helper_unregister_fbi(_cma->fb_helper);
-   drm_fbdev_cma_defio_fini(fbdev_cma->fb_helper.fbdev);
+   if (fbdev_cma->fb_helper.fbdev)
+   drm_fbdev_cma_defio_fini(fbdev_cma->fb_helper.fbdev);
drm_fb_helper_release_fbi(_cma->fb_helper);

if (fbdev_cma->fb) {
-- 
2.10.0

[PATCH 0/3] drm/fsl-dcu: fix driver remove/DRM unload

[Stefan Agner]

Hi All,

The first patch is a better alternative to the previously posted
patch ("drm/fsl-dcu: only init fbdev if required") as suggested
by Daniel.

The second and third are fix related issue uncovered during tests
with bind/unbind:
echo 40058000.dcu > /sys/bus/platform/drivers/fsl-dcu/unbind
echo 40058000.dcu > /sys/bus/platform/drivers/fsl-dcu/bind

Especially the third patch I am not sure if that is a reasonable
strategy to fix the issue. I did not saw another SoC DRM driver
which is making use of drm_crtc_force_disable_all...

Also, when the X Server is running (with modesetting driver) I
still get a warning:

WARNING: CPU: 0 PID: 452 at drivers/gpu/drm/drm_crtc.c:1154 
drm_mode_config_cleanup+0x210/0x220

The comment says it is the drivers fault, but as far as I can
tell it is user space which does not free up this framebuffers.
Is there something missing in my driver?

Any ideas?

--
Stefan

Stefan Agner (3):
  drm/fb_cma_helper: do not free fbdev if there is none
  drm/fsl-dcu: unload driver before disabling clocks
  drm/fsl-dcu: disable outputs before unloading driver

 drivers/gpu/drm/drm_fb_cma_helper.c   | 3 ++-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.10.0

[GIT PULL] Armada DRM fixes

[Russell King]

David,

Please incorporate the latest Armada DRM fixes fixes, which can be
found at:

  git://git.armlinux.org.uk/~rmk/linux-arm.git drm-armada-fixes

with SHA1 ea908ba8f73446dfbf87ff71f7cadb1994d2c5bb.

One small fix for Armada, where the clock prepare/enable counts were
going awry.

This will update the following files:

 drivers/gpu/drm/armada/armada_crtc.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

through these changes:

Russell King (1):
  drm/armada: fix clock counts

Many thanks.

[PATCH] drm: rcar-du: Simplify and fix probe error handling

[Laurent Pinchart]

It isn't safe to call drm_dev_unregister() without first initializing
mode setting with drm_mode_config_init(). This leads to a crash if
either IO memory can't be remapped or vblank initialization fails.

Fix this by reordering the initialization sequence. Move vblank
initialization after the drm_mode_config_init() call, and move IO
remapping before drm_dev_alloc() to avoid the need to perform clean up
in case of failure.

While at it remove the explicit drm_vblank_cleanup() call from
rcar_du_remove() as the drm_dev_unregister() function already cleans up
vblank.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 30 ++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  7 +++
 2 files changed, 17 insertions(+), 20 deletions(-)

(Resent with the proper dri-devel mailing list address, sorry for the noise)

I wonder whether it's safe to call drm_dev_unregister() without a previous
call to drm_dev_register(), or if it only works at the time being by chance.
The function is convenient to implement error handlers without having to
resort go lots of goto's or manual tests.

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 16ef919f316f..5968c2fa8e33 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -334,7 +334,6 @@ static int rcar_du_remove(struct platform_device *pdev)

drm_kms_helper_poll_fini(ddev);
drm_mode_config_cleanup(ddev);
-   drm_vblank_cleanup(ddev);

drm_dev_unref(ddev);

@@ -348,7 +347,7 @@ static int rcar_du_probe(struct platform_device *pdev)
struct resource *mem;
int ret;

-   /* Allocate and initialize the DRM and R-Car device structures. */
+   /* Allocate and initialize the R-Car device structure. */
rcdu = devm_kzalloc(>dev, sizeof(*rcdu), GFP_KERNEL);
if (rcdu == NULL)
return -ENOMEM;
@@ -358,31 +357,22 @@ static int rcar_du_probe(struct platform_device *pdev)
rcdu->dev = >dev;
rcdu->info = of_match_device(rcar_du_of_table, rcdu->dev)->data;

-   ddev = drm_dev_alloc(_du_driver, >dev);
-   if (IS_ERR(ddev))
-   return PTR_ERR(ddev);
-
-   rcdu->ddev = ddev;
-   ddev->dev_private = rcdu;
-
platform_set_drvdata(pdev, rcdu);

/* I/O resources */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
rcdu->mmio = devm_ioremap_resource(>dev, mem);
-   if (IS_ERR(rcdu->mmio)) {
-   ret = PTR_ERR(rcdu->mmio);
-   goto error;
-   }
-
-   /* Initialize vertical blanking interrupts handling. Start with vblank
-* disabled for all CRTCs.
-*/
-   ret = drm_vblank_init(ddev, (1 << rcdu->info->num_crtcs) - 1);
-   if (ret < 0)
-   goto error;
+   if (IS_ERR(rcdu->mmio))
+   return PTR_ERR(rcdu->mmio);

/* DRM/KMS objects */
+   ddev = drm_dev_alloc(_du_driver, >dev);
+   if (IS_ERR(ddev))
+   return PTR_ERR(ddev);
+
+   rcdu->ddev = ddev;
+   ddev->dev_private = rcdu;
+
ret = rcar_du_modeset_init(rcdu);
if (ret < 0) {
if (ret != -EPROBE_DEFER)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 1f9f13a80f85..57437e3372a6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -526,6 +526,13 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
if (ret < 0)
return ret;

+   /* Initialize vertical blanking interrupts handling. Start with vblank
+* disabled for all CRTCs.
+*/
+   ret = drm_vblank_init(dev, (1 << rcdu->info->num_crtcs) - 1);
+   if (ret < 0)
+   return ret;
+
/* Initialize the groups. */
num_groups = DIV_ROUND_UP(rcdu->num_crtcs, 2);

-- 
Regards,

Laurent Pinchart

[PATCH 8/8] drm: rcar-du: Initialize encoder's type based on the bridge's type

[Laurent Pinchart]

Set the type of the DRM encoder that models the hardware encoders
(bridges) chain based on the type of the last bridge in the chain
instead of hardcoding encoder compatible strings in the display driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 17 ++
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 38 ++-
 3 files changed, 4 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 61aaf746b2d6..f49be3765ed7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -105,7 +105,6 @@ static const struct drm_encoder_funcs encoder_funcs = {
 };

 int rcar_du_encoder_init(struct rcar_du_device *rcdu,
-enum rcar_du_encoder_type type,
 enum rcar_du_output output,
 struct device_node *enc_node,
 struct device_node *con_node)
@@ -143,23 +142,11 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
ret = -EPROBE_DEFER;
goto done;
}
-   }

-   switch (type) {
-   case RCAR_DU_ENCODER_VGA:
-   encoder_type = DRM_MODE_ENCODER_DAC;
-   break;
-   case RCAR_DU_ENCODER_LVDS:
-   encoder_type = DRM_MODE_ENCODER_LVDS;
-   break;
-   case RCAR_DU_ENCODER_HDMI:
-   encoder_type = DRM_MODE_ENCODER_TMDS;
-   break;
-   case RCAR_DU_ENCODER_NONE:
-   default:
+   encoder_type = bridge->encoder_type;
+   } else {
/* No external encoder, use the internal encoder type. */
encoder_type = rcdu->info->routes[output].encoder_type;
-   break;
}

ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index 5609a0b8d7e6..150de76088e1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -47,7 +47,6 @@ struct rcar_du_connector {
container_of(c, struct rcar_du_connector, connector)

 int rcar_du_encoder_init(struct rcar_du_device *rcdu,
-enum rcar_du_encoder_type type,
 enum rcar_du_output output,
 struct device_node *enc_node,
 struct device_node *con_node);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index f03864033cbb..1f9f13a80f85 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -357,17 +357,6 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
 enum rcar_du_output output,
 struct of_endpoint *ep)
 {
-   static const struct {
-   const char *compatible;
-   enum rcar_du_encoder_type type;
-   } encoders[] = {
-   { "adi,adv7123", RCAR_DU_ENCODER_VGA },
-   { "adi,adv7511w", RCAR_DU_ENCODER_HDMI },
-   { "adi,adv7513", RCAR_DU_ENCODER_HDMI },
-   { "thine,thc63lvdm83d", RCAR_DU_ENCODER_LVDS },
-   };
-
-   enum rcar_du_encoder_type enc_type = RCAR_DU_ENCODER_NONE;
struct device_node *connector = NULL;
struct device_node *encoder = NULL;
struct device_node *ep_node = NULL;
@@ -414,30 +403,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,

of_node_put(entity_ep_node);

-   if (encoder) {
-   /*
-* If an encoder has been found, get its type based on its
-* compatible string.
-*/
-   unsigned int i;
-
-   for (i = 0; i < ARRAY_SIZE(encoders); ++i) {
-   if (of_device_is_compatible(encoder,
-   encoders[i].compatible)) {
-   enc_type = encoders[i].type;
-   break;
-   }
-   }
-
-   if (i == ARRAY_SIZE(encoders)) {
-   dev_warn(rcdu->dev,
-"unknown encoder type for %s, skipping\n",
-encoder->full_name);
-   of_node_put(encoder);
-   of_node_put(connector);
-   return -EINVAL;
-   }
-   } else {
+   if (!encoder) {
/*
 * If no encoder has been found the entity must be the
 * connector.
@@ -445,7 +411,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
   

[PATCH 7/8] drm: rcar-du: Replace manual VGA DAC implementation with DRM bridge

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig   |   6 --
 drivers/gpu/drm/rcar-du/Makefile  |   5 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  52 
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   2 -
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 137 --
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h |  35 
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |  82 --
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h  |  23 -
 8 files changed, 35 insertions(+), 307 deletions(-)
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 4c2fd056dd6d..c222dc157494 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -11,12 +11,6 @@ config DRM_RCAR_DU
  Choose this option if you have an R-Car chipset.
  If M is selected the module will be called rcar-du-drm.

-config DRM_RCAR_HDMI
-   bool "R-Car DU HDMI Encoder Support"
-   depends on DRM_RCAR_DU
-   help
- Enable support for external HDMI encoders.
-
 config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index d3b44651061a..a492e6858691 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,10 +4,7 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_group.o \
 rcar_du_kms.o \
 rcar_du_lvdscon.o \
-rcar_du_plane.o \
-rcar_du_vgacon.o
-
-rcar-du-drm-$(CONFIG_DRM_RCAR_HDMI)+= rcar_du_hdmienc.o
+rcar_du_plane.o

 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index ab8645c57e2d..61aaf746b2d6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -19,11 +19,9 @@

 #include "rcar_du_drv.h"
 #include "rcar_du_encoder.h"
-#include "rcar_du_hdmienc.h"
 #include "rcar_du_kms.h"
 #include "rcar_du_lvdscon.h"
 #include "rcar_du_lvdsenc.h"
-#include "rcar_du_vgacon.h"

 /* 
-
  * Encoder
@@ -56,8 +54,12 @@ static int rcar_du_encoder_atomic_check(struct drm_encoder 
*encoder,
struct drm_connector *connector = conn_state->connector;
struct drm_device *dev = encoder->dev;

-   /* DAC encoders have currently no restriction on the mode. */
-   if (encoder->encoder_type == DRM_MODE_ENCODER_DAC)
+   /*
+* Only panel-related encoder types require validation here, everything
+* else is handled by the bridge drivers.
+*/
+   if (encoder->encoder_type != DRM_MODE_ENCODER_NONE &&
+   encoder->encoder_type != DRM_MODE_ENCODER_LVDS)
return 0;

if (list_empty(>modes)) {
@@ -110,6 +112,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 {
struct rcar_du_encoder *renc;
struct drm_encoder *encoder;
+   struct drm_bridge *bridge = NULL;
unsigned int encoder_type;
int ret;

@@ -133,6 +136,15 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
break;
}

+   if (enc_node) {
+   /* Locate the DRM bridge from the encoder DT node. */
+   bridge = of_drm_find_bridge(enc_node);
+   if (!bridge) {
+   ret = -EPROBE_DEFER;
+   goto done;
+   }
+   }
+
switch (type) {
case RCAR_DU_ENCODER_VGA:
encoder_type = DRM_MODE_ENCODER_DAC;
@@ -150,30 +162,34 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
break;
}

-   if (type == RCAR_DU_ENCODER_HDMI) {
-   ret = rcar_du_hdmienc_init(rcdu, renc, enc_node);
-   if (ret < 0)
-   goto done;
-   } else {
-   ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
-  encoder_type, NULL);
-   if (ret < 0)
-   goto done;
+   ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
+  encoder_type, NULL);
+   if (ret < 0)
+   goto done;

-   drm_encoder_helper_add(encoder, _helper_funcs);
+   drm_encoder_helper_add(encoder, _helper_funcs);
+
+   /* Link the bridge to the encoder. */
+   if (bridge) {
+   bridge->encoder = encoder;
+   encoder->bridge = bridge;
+
+   ret = 

[PATCH 6/8] drm: Set on-chip bridges' encoder type

[Laurent Pinchart]

Initialize the new drm_bridge::encoder_type field to the right value for
all bridges that model on-SoC IP cores.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 ++
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
 drivers/gpu/drm/sti/sti_dvo.c   | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0be6d65..7175ecda36e8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -390,6 +390,8 @@ static int exynos_mic_bind(struct device *dev, struct 
device *master,
mic->bridge.funcs = _bridge_funcs;
mic->bridge.of_node = dev->of_node;
mic->bridge.driver_private = mic;
+   mic->bridge.encoder_type = DRM_MODE_ENCODER_DSI;
+
ret = drm_bridge_add(>bridge);
if (ret)
DRM_ERROR("mic: Failed to add MIC to the global bridge list\n");
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 71227deef21b..4fd2e6203266 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1711,6 +1711,8 @@ static int mtk_drm_hdmi_probe(struct platform_device 
*pdev)

hdmi->bridge.funcs = _hdmi_bridge_funcs;
hdmi->bridge.of_node = pdev->dev.of_node;
+   hdmi->bridge.encoder_type = DRM_MODE_ENCODER_TMDS;
+
ret = drm_bridge_add(>bridge);
if (ret) {
dev_err(dev, "failed to add bridge, ret = %d\n", ret);
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index e8c1ed08a9f7..0c00d18028c5 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -472,6 +472,8 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
bridge->driver_private = dvo;
bridge->funcs = _dvo_bridge_funcs;
bridge->of_node = dvo->dev.of_node;
+   bridge->encoder_type = DRM_MODE_ENCODER_LVDS;
+
err = drm_bridge_add(bridge);
if (err) {
DRM_ERROR("Failed to add bridge\n");
-- 
Regards,

Laurent Pinchart

[PATCH 5/8] drm: bridge: Set bridges' encoder type

[Laurent Pinchart]

Initialize the new drm_bridge::encoder_type field to the right value for
all external bridge drivers.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 1 +
 drivers/gpu/drm/bridge/analogix-anx78xx.c  | 1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 drivers/gpu/drm/bridge/dumb-vga-dac.c  | 1 +
 drivers/gpu/drm/bridge/dw-hdmi.c   | 2 ++
 drivers/gpu/drm/bridge/nxp-ptn3460.c   | 2 ++
 drivers/gpu/drm/bridge/parade-ps8622.c | 2 ++
 drivers/gpu/drm/bridge/sii902x.c   | 2 ++
 drivers/gpu/drm/bridge/tc358767.c  | 2 ++
 9 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 8ed3906dd411..66bbd2073529 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1030,6 +1030,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)

adv7511->bridge.funcs = _bridge_funcs;
adv7511->bridge.of_node = dev->of_node;
+   adv7511->bridge.encoder_type = DRM_MODE_ENCODER_TMDS;

ret = drm_bridge_add(>bridge);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a82366a771..62be93f7ffaa 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1437,6 +1437,7 @@ static int anx78xx_i2c_probe(struct i2c_client *client,
}

anx78xx->bridge.funcs = _bridge_funcs;
+   anx78xx->bridge.encoder_type = DRM_MODE_ENCODER_TMDS;

err = drm_bridge_add(>bridge);
if (err < 0) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6e0447f329a2..d7eda99e5b8a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1231,6 +1231,7 @@ static int analogix_dp_create_bridge(struct drm_device 
*drm_dev,
bridge->driver_private = dp;
bridge->encoder = dp->encoder;
bridge->funcs = _dp_bridge_funcs;
+   bridge->encoder_type = DRM_MODE_ENCODER_TMDS;

ret = drm_bridge_attach(drm_dev, bridge);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index b33e3f829e4f..036c54c849e6 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -182,6 +182,7 @@ static int dumb_vga_probe(struct platform_device *pdev)

vga->bridge.funcs = _vga_bridge_funcs;
vga->bridge.of_node = pdev->dev.of_node;
+   vga->bridge.encoder_type = DRM_MODE_ENCODER_DAC;

ret = drm_bridge_add(>bridge);
if (ret && !IS_ERR(vga->ddc))
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ab7023e5dfde..f6485885c4ff 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1609,6 +1609,8 @@ static int dw_hdmi_register(struct drm_device *drm, 
struct dw_hdmi *hdmi)
hdmi->bridge = bridge;
bridge->driver_private = hdmi;
bridge->funcs = _hdmi_bridge_funcs;
+   bridge->encoder_type = DRM_MODE_ENCODER_TMDS;
+
ret = drm_bridge_attach(drm, bridge);
if (ret) {
DRM_ERROR("Failed to initialize bridge with drm\n");
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c 
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index f1a99938e924..8be117cc024f 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -349,6 +349,8 @@ static int ptn3460_probe(struct i2c_client *client,

ptn_bridge->bridge.funcs = _bridge_funcs;
ptn_bridge->bridge.of_node = dev->of_node;
+   ptn_bridge->bridge.encoder_type = DRM_MODE_ENCODER_LVDS;
+
ret = drm_bridge_add(_bridge->bridge);
if (ret) {
DRM_ERROR("Failed to add bridge\n");
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c 
b/drivers/gpu/drm/bridge/parade-ps8622.c
index 6f7c2f9860d2..37ac7211139a 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -615,6 +615,8 @@ static int ps8622_probe(struct i2c_client *client,

ps8622->bridge.funcs = _bridge_funcs;
ps8622->bridge.of_node = dev->of_node;
+   ps8622->bridge.encoder_type = DRM_MODE_ENCODER_LVDS;
+
ret = drm_bridge_add(>bridge);
if (ret) {
DRM_ERROR("Failed to add bridge\n");
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 9126d0306ab5..ad4663dea333 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -418,6 +418,8 @@ static int sii902x_probe(struct i2c_client *client,

sii902x->bridge.funcs = 

[PATCH 4/8] drm: Add encoder_type field to the drm_bridge structure

[Laurent Pinchart]

The drm_bridge object models on- or off-chip hardware encoders and
provide an abstract control API to display drivers. In order to help
display drivers creating the right kind of drm_encoder object, expose
the type of the hardware encoder associated with each bridge.

Signed-off-by: Laurent Pinchart 
---
 include/drm/drm_bridge.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 530a1d6e8cde..e93105bffc3c 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -194,6 +194,14 @@ struct drm_bridge {
 #endif
struct list_head list;

+   /**
+* @encoder_type:
+*
+* Type of the hardware encoder modeled by the bridge as one of the
+* DRM_MODE_ENCODER_* types. This will usually be identical to the
+* ->encoder.encoder_type for the last bridge in the chain only.
+*/
+   int encoder_type;
const struct drm_bridge_funcs *funcs;
void *driver_private;
 };
-- 
Regards,

Laurent Pinchart

[PATCH 3/8] drm: bridge: lvds-encoder: Add thine, thc63lvdm83d compatible string

[Laurent Pinchart]

The THC63LVDM83D is a transparent LVDS encoder. Unlike dumb LVDS
encoders it can be controlled through a few pins (power down, LVDS
swing, clock edge selection) and requires power supplies. However, on
several boards where the device is used neither the control pins nor the
power supply are controllable.

To avoid developing a separate device-specific driver add a
"thine,thc63lvdm83d" compatible entry to the lvds-encoder driver. This
will allow supporting many THC63LVDM83D-based boards easily, while
allowing future development of an thc63lvdm83d driver when needed
without breaking backward compatibility.

Cc: devicetree at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/lvds-encoder.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 33e8025c8a6d..f3026ad82fe1 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -184,6 +184,7 @@ static int lvds_encoder_remove(struct platform_device *pdev)

 static const struct of_device_id lvds_encoder_match[] = {
{ .compatible = "lvds-encoder" },
+   { .compatible = "thine,thc63lvdm83d" },
{},
 };
 MODULE_DEVICE_TABLE(of, lvds_encoder_match);
-- 
Regards,

Laurent Pinchart

[PATCH 2/8] drm: bridge: vga-dac: Add adi,adv7123 compatible string

[Laurent Pinchart]

The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
controlled through a power save pin, and requires a power supply.
However, on most boards where the device is used neither the power save
signal nor the power supply are controllable.

To avoid developing a separate device-specific driver add an
"adi,adv7123" compatible entry to the dumb-vga-dac driver. This will
allow supporting most ADV7123-based boards easily, while allowing future
development of an adv7123 driver when needed without breaking backward
compatibility.

Cc: devicetree at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232185a7..b33e3f829e4f 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device *pdev)

 static const struct of_device_id dumb_vga_match[] = {
{ .compatible = "dumb-vga-dac" },
+   { .compatible = "adi,adv7123" },
{},
 };
 MODULE_DEVICE_TABLE(of, dumb_vga_match);
-- 
Regards,

Laurent Pinchart

[PATCH 1/8] drm: bridge: Add LVDS encoder driver

[Laurent Pinchart]

The LVDS encoder driver is a DRM bridge driver that supports the
parallel to LVDS encoders that don't require any configuration. The
driver thus doesn't interact with the device, but creates an LVDS
connector for the panel and exposes its size and timing based on
information retrieved from DT.

Cc: devicetree at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 .../bindings/display/bridge/lvds-transmitter.txt   |  64 +++
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/lvds-encoder.c  | 203 +
 4 files changed, 276 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
 create mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
new file mode 100644
index ..fd39ad34c383
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -0,0 +1,64 @@
+Parallel to LVDS Encoder
+
+
+This binding supports the parallel to LVDS encoders that don't require any
+configuration.
+
+LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+incompatible data link layers have been used over time to transmit image data
+to LVDS panels. This binding targets devices compatible with the following
+specifications only.
+
+[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+Semiconductor
+[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+Electronics Standards Association (VESA)
+
+Those devices have been marketed under the FPD-Link and FlatLink brand names
+among others.
+
+
+Required properties:
+
+- compatible: Must be "lvds-encoder"
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for parallel input
+- Video port 1 for LVDS output
+
+
+Example
+---
+
+lvds-encoder {
+   compatible = "lvds-encoder";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+
+   lvds_enc_in: endpoint {
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   lvds_enc_out: endpoint {
+   remote-endpoint = <_panel_in>;
+   };
+   };
+   };
+};
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 10e12e74fc9f..5dafad7817ad 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -24,6 +24,14 @@ config DRM_DUMB_VGA_DAC
help
  Support for RGB to VGA DAC based bridges

+config DRM_LVDS_ENCODER
+   tristate "Transparent parallel to LVDS encoder support"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Support for transparent parallel to LVDS encoders that don't require
+ any configuration.
+
 config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cdf3a3cf765d..bbaf583581ac 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@ ccflags-y := -Iinclude/drm

 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
+obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
new file mode 100644
index ..33e8025c8a6d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (C) 2016 Laurent Pinchart 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+struct lvds_encoder {
+   struct device *dev;
+
+   struct drm_bridge bridge;
+   struct drm_connector connector;
+
+  

[PATCH 0/8] R-Car DU: Use drm bridge API

[Laurent Pinchart]

Hello,

(This time with the proper dri-devel mailing list address, sorry for the
noise)

This patch series replaces the custom external encoders support implementation
in the R-Car DU driver with code based on the DRM bridge API.

While the overall diffstat isn't impressive, the rcar-du-drm driver gets
notably thinner in the process:

9 files changed, 38 insertions(+), 358 deletions(-)

This is offset by a reusable driver for LVDS encoders along with the
corresponding DT bindings (+ 277 lines).

Patch 1/8 adds the new LVDS encoder driver. It supports "dumb" LVDS encoders
only, similarly to the dumb-vga-dac driver. One notable difference, though, is
that LVDS encoders can't be purely passive, and thus require at least one
power supply (and usually multiple of them) and have a few control GPIOs (most
notably to control reset, power down, clock polarity and/or LVDS slew rate).
However, on many systems those encoders are integrated in such a way that the
control pins are pulled up or down appropriately and the power supplies are
either always on or shared with other display components that make them
operate as if they were always on. For that reason a common drivers for those
systems is useful, with simple DT bindings that don't try to cover any device-
specific control pin or power supply.

To ensure backward compatibility most LVDS encoders should *not* use the
common simple "lvds-encoder" compatible string, but should instead define a
device-specific compatible string that can then be added to the lvds-encoder
driver (patch 3/8). This way, when the need to control pins or supplies will
arise, a new driver can be developed matching on the device-specific
compatible string, which will then be removed from the simple driver. Existing
systems will migrate transparently without requiring a change to their device
tree.

A similar reasoning applies to VGA DACs, leading to the addition of the
"adi,adv7123" compatible string to the dumb-vga-dac driver's OF match table in
patch 2/8.

Patch 4/8 adds a new type field to the drm_bridge structure to inform bridge
users of the bridge type. This is useful for display driver to create a DRM
encoder of the appropriate type without having to resort to heuristics.
Patches 5/8 and 6/8 update all bridge drivers to initialize the new field to
the appropriate value.

Patches 7/8 and 8/8 finally migrate the rcar-du-drm driver to the DRM bridge
API, removing the custom VGA DAC implementation in patch 7/8 and the table of
bridge compatible strings used to find the encoder type in patch 8/8.

Cc: devicetree at vger.kernel.org

Laurent Pinchart (8):
  drm: bridge: Add LVDS encoder driver
  drm: bridge: vga-dac: Add adi,adv7123 compatible string
  drm: bridge: lvds-encoder: Add thine,thc63lvdm83d compatible string
  drm: Add encoder_type field to the drm_bridge structure
  drm: bridge: Set bridges' encoder type
  drm: Set on-chip bridges' encoder type
  drm: rcar-du: Replace manual VGA DAC implementation with DRM bridge
  drm: rcar-du: Initialize encoder's type based on the bridge's type

 .../bindings/display/bridge/lvds-transmitter.txt   |  64 +++
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   1 +
 drivers/gpu/drm/bridge/analogix-anx78xx.c  |   1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |   1 +
 drivers/gpu/drm/bridge/dumb-vga-dac.c  |   2 +
 drivers/gpu/drm/bridge/dw-hdmi.c   |   2 +
 drivers/gpu/drm/bridge/lvds-encoder.c  | 204 +
 drivers/gpu/drm/bridge/nxp-ptn3460.c   |   2 +
 drivers/gpu/drm/bridge/parade-ps8622.c |   2 +
 drivers/gpu/drm/bridge/sii902x.c   |   2 +
 drivers/gpu/drm/bridge/tc358767.c  |   2 +
 drivers/gpu/drm/exynos/exynos_drm_mic.c|   2 +
 drivers/gpu/drm/mediatek/mtk_hdmi.c|   2 +
 drivers/gpu/drm/rcar-du/Kconfig|   6 -
 drivers/gpu/drm/rcar-du/Makefile   |   5 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |  67 +++
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |   3 -
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c  | 137 --
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h  |  35 
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  38 +---
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c   |  82 -
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h   |  23 ---
 drivers/gpu/drm/sti/sti_dvo.c  |   2 +
 include/drm/drm_bridge.h   |   8 +
 26 files changed, 344 insertions(+), 358 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
 create mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
 delete mode 100644 

[Bug 98324] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98324

Bug ID: 98324
   Summary: amd-staging-4.7: problems with unblanking displays
when monitors are switched off
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: bugspam at moreofthesa.me.uk

Created attachment 127405
  --> https://bugs.freedesktop.org/attachment.cgi?id=127405=edit
Kernel log extract, showing the unblanking failure.

Setup: RX 470 with two monitors attached – one via DVI-and one via HDMI. (Both
are AOC monitors.)

* Ensure that outputs are blanked (via xset, time-out or similar).
* Switch off the monitors.
* Unblank the outputs.
* Switch on the monitors.

Invariably, in this situation, the DVI-connected monitor is unblanked and
displaying what it should be, but the HDMI-connected monitor is receiving no
signal (or at least nothing to display) and is therefore displaying nothing.

The HDMI-connected monitor can be restored by using xrandr to change mode or by
blanking and unblanking – so long as it's switched on while doing so.

-- 
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/20161019/88773a3e/attachment.html>

[PATCH v2] drm/bridge: adv7511: Remove unused code blocks

[Jitendra Sharma]

Remove redundant condition check
Remove not necessary if-else block for checking DT entry because else
part will never be picked as in absence of device node, probe will
fail in initial stage only.

Remove unused id->driver_data entries
As id->driver_data is not used in driver source. So no need in
Keeping these entries in id_table

Signed-off-by: Jitendra Sharma 
---
Probe was not happening in Patch v1 due to removal of .id_table.As the
intention of this patch is not to change any functionality, also 
changes looks simple enough.So, didn't verified Patch v1 over hardware
Hence fixing the issues in Patch v1 and posting patch v2

Changes for v2:
 - Keep the id_table entries
 - Keep the id->driver_data to 0
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 8ed3906..3279059 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -942,10 +942,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
adv7511->powered = false;
adv7511->status = connector_status_disconnected;

-   if (dev->of_node)
-   adv7511->type = (enum 
adv7511_type)of_device_get_match_data(dev);
-   else
-   adv7511->type = id->driver_data;
+   adv7511->type = (enum adv7511_type)of_device_get_match_data(dev);

memset(_config, 0, sizeof(link_config));

@@ -1066,11 +1063,11 @@ static int adv7511_remove(struct i2c_client *i2c)
 }

 static const struct i2c_device_id adv7511_i2c_ids[] = {
-   { "adv7511", ADV7511 },
-   { "adv7511w", ADV7511 },
-   { "adv7513", ADV7511 },
+   { "adv7511", 0 },
+   { "adv7511w", 0 },
+   { "adv7513", 0 },
 #ifdef CONFIG_DRM_I2C_ADV7533
-   { "adv7533", ADV7533 },
+   { "adv7533", 0 },
 #endif
{ }
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[GIT PULL] drm/fsl-dcu: fixes for v4.9-rc2

[Stefan Agner]

Hi Dave,

This are some fixes which I hoped to still get into v4.9. I used to
test them here since about 2 weeks and Meng came around to test it
on the second platform making use of this IP too, so they are well
tested now.

--
Stefan

The following changes since commit fa860a1751e388385a7f249dd3f24a6c76db0ba9:

  drm: Print device information again in debugfs (2016-10-17 16:20:53 +1000)

are available in the git repository at:

  http://git.agner.ch/git/linux-drm-fsl-dcu.git fixes-for-v4.9-rc2

for you to fetch changes up to 0a70c998d0c571c66d0ba8ffd9f803392a53193d:

  drm/fsl-dcu: enable pixel clock when enabling CRTC (2016-10-19 17:03:02 -0700)


Stefan Agner (4):
  drm/fsl-dcu: enable TCON bypass mode by default
  drm/fsl-dcu: do not transfer registers on plane init
  drm/fsl-dcu: do not transfer registers in mode_set_nofb
  drm/fsl-dcu: enable pixel clock when enabling CRTC

 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  |  4 +--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   | 23 +++--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  5 
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c   | 39 -
 4 files changed, 10 insertions(+), 61 deletions(-)

[PATCH v3 1/5] drm/fsl-dcu: enable TCON bypass mode by default

[Stefan Agner]

On 2016-10-19 02:35, Meng Yi wrote:
>>
>> Do not use encoder disable/enable callbacks to control bypass mode as this
>> seems to mess with the signals not liked by displays. This also makes more
>> sense since the encoder is already defined to be parallel RGB/LVDS at 
>> creation
>> time.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |  2 ++  drivers/gpu/drm/fsl-
>> dcu/fsl_dcu_drm_rgb.c | 39 ---
>>  2 files changed, 7 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-
>> dcu/fsl_dcu_drm_drv.c
>> index 0884c45..3897f56 100644
>> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>> @@ -273,6 +273,8 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
>>  goto disable_dcu_clk;
>>  }
>>
>> +if (fsl_dev->tcon)
>> +fsl_tcon_bypass_enable(fsl_dev->tcon);
>>  fsl_dcu_drm_init_planes(fsl_dev->drm);
>>  drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
>>
>> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-
>> dcu/fsl_dcu_drm_rgb.c
>> index 26edcc8..e1dd75b 100644
>> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
>> @@ -20,38 +20,6 @@
>>  #include "fsl_dcu_drm_drv.h"
>>  #include "fsl_tcon.h"
>>
>> -static int
>> -fsl_dcu_drm_encoder_atomic_check(struct drm_encoder *encoder,
>> - struct drm_crtc_state *crtc_state,
>> - struct drm_connector_state *conn_state)
>> -{
>> -return 0;
>> -}
>> -
>> -static void fsl_dcu_drm_encoder_disable(struct drm_encoder *encoder) -{
>> -struct drm_device *dev = encoder->dev;
>> -struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
>> -
>> -if (fsl_dev->tcon)
>> -fsl_tcon_bypass_disable(fsl_dev->tcon);
>> -}
>> -
>> -static void fsl_dcu_drm_encoder_enable(struct drm_encoder *encoder) -{
>> -struct drm_device *dev = encoder->dev;
>> -struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
>> -
>> -if (fsl_dev->tcon)
>> -fsl_tcon_bypass_enable(fsl_dev->tcon);
>> -}
>> -
>> -static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
>> -.atomic_check = fsl_dcu_drm_encoder_atomic_check,
>> -.disable = fsl_dcu_drm_encoder_disable,
>> -.enable = fsl_dcu_drm_encoder_enable,
>> -};
>> -
>>  static void fsl_dcu_drm_encoder_destroy(struct drm_encoder *encoder)  {
>>  drm_encoder_cleanup(encoder);
>> @@ -68,13 +36,16 @@ int fsl_dcu_drm_encoder_create(struct
>> fsl_dcu_drm_device *fsl_dev,
>>  int ret;
>>
>>  encoder->possible_crtcs = 1;
>> +
>> +/* Use bypass mode for parallel RGB/LVDS encoder */
>> +if (fsl_dev->tcon)
>> +fsl_tcon_bypass_enable(fsl_dev->tcon);
>> +
>>  ret = drm_encoder_init(fsl_dev->drm, encoder, _funcs,
>> DRM_MODE_ENCODER_LVDS, NULL);
>>  if (ret < 0)
>>  return ret;
>>
>> -drm_encoder_helper_add(encoder, _helper_funcs);
>> -
>>  return 0;
>>  }
>>
>> --
>> 2.10.0
> 
> Tested-By: Meng Yi 
> 
> Tested those 5 patches on LS1021a-twr, and everything is fine.

Thanks.

Applied 1~4.

--
Stefan

exynos-drm: display manager fails to start without IOMMU problem

[Shuah Khan]

On 10/19/2016 10:23 AM, Tobias Jakobi wrote:
> Hello Shuah,
> 
> just a short note that more misleading comments about default allocation
> flags can be found in libdrm.
> 
> https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c
> 
> See e.g. the comment for exynos_bo_create().
> 
> In my opinion, the whole approach to _set_ a bit to get non-contigious
> memory is messed up. It would make more sense to me to set a bit to
> request an additional property (here "being contiguous") of the memory.
> 
> Anyway, clearing up this situation is highly appreciated!
> 
> More comments below.
> 
> With best wishes,
> Tobias
> 

Hi Tobias,

Thanks for the note. Yes the comments are confusing. It seems like
some old assumptions are persisting. I will fix these as well.

-- Shuah

[PATCH] reservation: fix reservation_object_wait_timeout_rcu result

[Alex Deucher]

On Wed, Oct 19, 2016 at 1:59 PM, Christian König
 wrote:
> From: Christian König 
>
> Return one when the timeout is zero and we don't got any fences.
>
> Fixes "reservation: revert "wait only with non-zero timeout specified (v3)"".
>
> Signed-off-by: Christian König 

Reviewed-by: Alex Deucher 

You should make sure you cc Sumit on these patches as I think they
would need to go upstream via the dma-buf tree.   Also respin a v2
with this fix integrated.

Alex

> ---
>  drivers/dma-buf/reservation.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index bb97b04..debb91d 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -379,7 +379,7 @@ long reservation_object_wait_timeout_rcu(struct 
> reservation_object *obj,
>  {
> struct fence *fence;
> unsigned seq, shared_count, i = 0;
> -   long ret = timeout;
> +   long ret = timeout ? timeout : 1;
>
>  retry:
> fence = NULL;
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Dave Airlie]

On 18 October 2016 at 23:53, Dan Williams  wrote:
> On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie  wrote:
> [..]
 Aren't there only 2 possibilities for this regression?

 1/ a memtype entry was never made so track_pfn_insert() returns an
 uncached mapping

 2/ a conflicting memtype entry exists and undefined behavior due to
 mixed mapping types is avoided with the change.
>>>
>>> 3/ The CPU usage through this path goes up, and slows things down,
>>> though I suspect you it's more an uncached mapping showing up
>>> when we don't expect it.
>>
>> It's looking line number 1, there is no mapping, now we get uncached
>> where we used to get write through.
>>
>> difference in page prot 7f7bbc0e, pfn 200e71e4,
>> 8037, 802f
>>
>> 0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned
>> pgprot which lacks that bit.
>>
>> not sure where to go from here, suggestions?
>
> If the driver established an ioremap_wt() across the range, or just
> called reserve_memtype() directly that should restore WT mappings.
>
> Although Daniel's suggestion to use the i915 mapping helpers sounds
> like it avoids problem 3/ as well.

Well we shouldn't be doing that many VRAM mappings on the CPU so
I doubt we'll hit the overheads here that often.

Ideally we'd always use DMA to move stuff in/out of VRAM, but there
are some places where we still do WC VRAM writes for uploads.

So I've sent the patches, any major opinions on them, we can't just
ioremap_wc the whole BAR, as on 32-bit that just messes things up
and it's unnecessary anyways.

Dave.

[PATCH 2/2] dma-buf/fence-array: hold fences reference when creating an array

[Gustavo Padovan]

2016-10-19 Christian König :

> Am 19.10.2016 um 19:48 schrieb Gustavo Padovan:
> > From: Gustavo Padovan 
> > 
> > When creating fence arrays we were not holding references to the fences
> > in the array, however when destroy the array we were putting away a
> > reference to these fences.
> > 
> > This patch hold the ref for all fences in the array when creating the
> > array.
> > 
> > It then removes the code that was holding the fences on both amdgpu_vm and
> > sync_file. For sync_file, specially, we worked on small referencing
> > refactor for sync_file_merge().
> > 
> > Signed-off-by: Gustavo Padovan 
> 
> I would prefer it to keep it like it is, cause this is a bit inconsistent.
> 
> With this change the fence array takes the ownership of the array, but not
> of the fences inside it.

I was thinking more in to keep consistency between all fence users. Every
user should hold a ref to the fence assigned to it. That is what patch
1 is doing for sync_file and think it is a good idea do the same here.

The array itself is not refcounted and the users calling
fence_array_create() doesn't store the allocated array anywhere. The
comment I errouneously removed already states that.

Gustavo

[Bug 178421] [regression] Radeon Oops on shutdown

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=178421

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Already fixed:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9305ee6fe52035f63d70d023235b792ba22107f0

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2] drm/bridge: adv7511: Remove unused code blocks

[Laurent Pinchart]

Hi Jitendra,

On Wednesday 19 Oct 2016 18:37:38 Sharma, Jitendra wrote:
> On 10/19/2016 5:21 PM, Laurent Pinchart wrote:
> > On Wednesday 19 Oct 2016 17:12:48 Jitendra Sharma wrote:
> >> Remove redundant condition check
> >> Remove not necessary if-else block for checking DT entry because else
> >> part will never be picked as in absence of device node, probe will
> >> fail in initial stage only.
> >> 
> >> Remove unused id->driver_data entries
> >> As id->driver_data is not used in driver source. So no need in
> >> Keeping these entries in id_table
> >> 
> >> Signed-off-by: Jitendra Sharma 
> >> ---
> >> Probe was not happening in Patch v1 due to removal of .id_table.As the
> >> intention of this patch is not to change any functionality, also
> >> changes looks simple enough.So, didn't verified Patch v1 over hardware
> > 
> > You should *ALWAYS* verify patches before sending them out.
> 
> Will keep in mind
> 
> > I assume you've now properly tested this one ?
> > 
> >> Hence fixing the issues in Patch v1 and posting patch v2
> >> 
> >> Changes for v2:
> >>   - Keep the id_table entries
> >>   - Keep the id->driver_data to 0
> >> 
> >> ---
> >> 
> >>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 +
> >>   1 file changed, 5 insertions(+), 8 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 8ed3906..3279059
> >> 100644
> >> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> @@ -942,10 +942,7 @@ static int adv7511_probe(struct i2c_client *i2c,
> >> const
> >> struct i2c_device_id *id) adv7511->powered = false;
> >> 
> >>adv7511->status = connector_status_disconnected;
> >> 
> >> -  if (dev->of_node)
> >> -  adv7511->type = (enum
> > 
> > adv7511_type)of_device_get_match_data(dev);
> > 
> >> -  else
> >> -  adv7511->type = id->driver_data;
> >> +  adv7511->type = (enum adv7511_type)of_device_get_match_data(dev);
> >> 
> >>memset(_config, 0, sizeof(link_config));
> >> 
> >> @@ -1066,11 +1063,11 @@ static int adv7511_remove(struct i2c_client *i2c)
> >> 
> >>   }
> >>   
> >>   static const struct i2c_device_id adv7511_i2c_ids[] = {
> >> 
> >> -  { "adv7511", ADV7511 },
> >> -  { "adv7511w", ADV7511 },
> >> -  { "adv7513", ADV7511 },
> >> +  { "adv7511", 0 },
> >> +  { "adv7511w", 0 },
> >> +  { "adv7513", 0 },
> >> 
> >>   #ifdef CONFIG_DRM_I2C_ADV7533
> >> 
> >> -  { "adv7533", ADV7533 },
> >> +  { "adv7533", 0 },
> >> 
> >>   #endif
> > 
> > What's the purpose of this ? It doesn't save any memory or CPU cycle.
> 
> Idea is to remove unnecessary code, variables and if possible to reduce
> lines of code for example here by eliminating obvious branching.
> Regarding memory or cpu cyles, no difference could be because of
> compiler optimization

For the code block in the probe function I understand, but for the 
initializers here I don't see the point.

And one might argue that using id->driver_data unconditionally would be better 
as it would save a call to of_device_get_match_data()...

> >>{ }
> >>   
> >>   };

-- 
Regards,

Laurent Pinchart

[Bug 178421] New: [regression] Radeon Oops on shutdown

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=178421

Bug ID: 178421
   Summary: [regression] Radeon Oops on shutdown
   Product: Drivers
   Version: 2.5
Kernel Version: 4.9-rc1
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: jtmettala at gmail.com
Regression: No

Created attachment 241971
  --> https://bugzilla.kernel.org/attachment.cgi?id=241971=edit
picture of panic

Between 4.8 and 4.9-rc1 shutdown stopped working without power button. There
was blinking caps- and scroll lock leds on custom kernel. There was no blinking
leds on 4.9.0-040900rc1-generic from ubuntu kernel ppa. But it didn't power off
either. Suspend worked at least with custom kernel.

I tried to bisect. There was some uncertainity. Still bisect said
c0d5fb4d0d9224ccaad0475c9b58740873970e7e is the first bad commit. I tried git
revert -n -m 1 c0d5fb4d0d9224ccaad0475c9b58740873970e7e which gave Oops on
screen after shutdown attemp. Picture is attached.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

[Shuah Khan]

On 10/19/2016 08:16 AM, Inki Dae wrote:
> Hi Shuah,
> 
> 2016-10-13 8:11 GMT+09:00 Shuah Khan :
>> Hi Inki,
>>
>> On 08/15/2016 10:40 PM, Inki Dae wrote:
>>

 okay the very first commit that added IOMMU support
 introduced the code that rejects non-contig gem memory
 type without IOMMU.

 commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
 Author: Inki Dae 
 Date:   Sat Oct 20 07:53:42 2012 -0700

 drm/exynos: add iommu support for exynos drm framework

>>
>> I haven't given up on this yet. I am still seeing the following failure:
>>
>> Additional debug messages I added:
>> [   15.287403] exynos_drm_gem_create_ioctl() 1
>> [   15.287419] exynos_drm_gem_create() flags 1
>>
>> [   15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM 
>> memory is not supported.
>>
>> Additional debug message I added:
>> [   15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize 
>> framebuffer
>>
>> This is what happens:
>>
>> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
>> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
>> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>>check_fb_gem_memory_type()
>>
>> At this point, there is no recovery and lightdm fails
>>
>> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
>> allocations are not supported in some exynos drm versions: The following
>> commit introduced this change:
>>
>> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>>
>> excerpts from the diff:-   if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
>> -   create_exynos.flags = EXYNOS_BO_CONTIG;
>> -   else
>> -   create_exynos.flags = EXYNOS_BO_NONCONTIG;
>> +
>> +   /* Contiguous allocations are not supported in some exynos drm 
>> versions.
>> +* When they are supported all allocations are effectively contiguous
>> +* anyway, so for simplicity we always request non contiguous 
>> buffers.
>> +*/
>> +   create_exynos.flags = EXYNOS_BO_NONCONTIG;
>>
> 
> Above comment, "Contiguous allocations are not supported in some
> exynos drm versions.", seems wrong assumption.
> The root cause, contiguous allocation is not supported, would be that
> they used Linux kernel which didn't have CMA region enough - as
> default 16MB, or didn't declare CMA region enough for the DMA device.
> So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
> should manage the error case if the allocation failed.

This assumption doesn't sound correct and forcing NONCONTIG isn't right
either. 

> 
>> There might have been logic on exynos_drm that forced Contig when it coudn't
>> support NONCONTIG. At least, that is what this comment suggests. This 
>> assumption
>> doesn't appear to be a good one and not sure if this change was made to fix 
>> a bug.
>>
>> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
>> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>>
>> This is what I am running into. This leads to the following question:
>>
>> 1. How do we ensure exynos_drm kernel changes don't break user-space
>>specifically xf86-video-armsoc
>> 2. This seems to have gone undetected for a while. I see a change in
>>exynos_drm_gem_dumb_create() that is probably addressing this type
>>of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>>handling for IOMMU NONCONTIG case.
> 
> Seems this patch has a problem. This patch forces to flag NONCONTIG if
> iommu is enabled. The flag should be depend on the argument from
> user-space.
> I.e., if user-space requested a gem allocation with CONTIG flag, then
> Exynos drm driver should allocate contiguous memory even though iommu
> is enabled.
> 
>>
>> Anyway, I am interested in getting the exynos_drm kernel side code
>> and xf86-video-armsoc in sync to resolve the issue.
>>
>> Could you recommend a going forward plan?
> 
> My opinion are,
> 
> 1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
> 2. Do not force to flag NONCONTIG at Exynos drm driver even though
> iommu is enabled and flag allocation type with the argument from
> user-space.
> 
> I think you could try to post above patches.
> 

Sounds good. I will work on the above two patches.

thanks,
-- Shuah

[PATCH -next] drm/i915/gvt: fix return value check

[Wei Yongjun]

From: Wei Yongjun 

In case of error, the function i915_gem_object_create() returns
ERR_PTR() not NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7..6abb2a6 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1640,8 +1640,8 @@ static int perform_bb_shadow(struct parser_exec_state *s)

entry_obj->obj = i915_gem_object_create(&(s->vgpu->gvt->dev_priv->drm),
round_up(bb_size, PAGE_SIZE));
-   if (entry_obj->obj == NULL)
-   return -ENOMEM;
+   if (IS_ERR(entry_obj->obj))
+   return PTR_ERR(entry_obj->obj);
entry_obj->len = bb_size;
INIT_LIST_HEAD(_obj->list);

@@ -2712,8 +2712,8 @@ static int shadow_indirect_ctx(struct intel_shadow_wa_ctx 
*wa_ctx)

wa_ctx->indirect_ctx.obj = i915_gem_object_create(dev,
round_up(ctx_size + CACHELINE_BYTES, PAGE_SIZE));
-   if (wa_ctx->indirect_ctx.obj == NULL)
-   return -ENOMEM;
+   if (IS_ERR(wa_ctx->indirect_ctx.obj))
+   return PTR_ERR(wa_ctx->indirect_ctx.obj);

ret = i915_gem_object_get_pages(wa_ctx->indirect_ctx.obj);
if (ret)

Unix Device Memory Allocation project

[Daniel Vetter]

On Wed, Oct 19, 2016 at 03:15:08PM +0200, Marek Olšák wrote:
> On Oct 19, 2016 8:24 AM, "Daniel Vetter"  wrote:
> > On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák  wrote:
> > > - The producer-consumer interop API doesn't know about the metadata.
> > > All you need to pass around is a buffer handle. (KMS, DMABUF, etc.)
> > >   * There was a note during the talk that DMABUF doesn't have any
> > > metadata. Well, I just told you that it has, but it's private to
> > > amdgpu and possibly accessible to other kernel drivers too.
> > >   * We can build upon this idea. I think the worst thing to do would
> > > be to add metadata handling to driver-agnostic userspace APIs. Really,
> > > driver-agnostic APIs shouldn't know about that, because they can't
> > > understand all the hw-specific information encoded in the metadata.
> > > Also, when you want to change the metadata format, you only have to
> > > update the affected drivers, not userspace APIs.
> >
> > That's a bit a surprise to hear, since "can't we just add a bit of
> > opaque metadata to dma-buf" came up all the time over the past years,
> > and died all the time again. dma-buf shouldn't imo be just yet another
> > linux IPC mechanism and protocol, which is pretty much what you end up
> > doing when you add this stuff. DRM runs all kinds of compositors with
> > all kinds of existing userspace proto, and with reasonable ones like
> > Wayland vendors can add whatever extensions they want. Plus there's
> > all the interop with v4l and every other kernel subsytem. Trying to
> > standardize that into some blob that works for everyone is imo nigh
> > impossible.
> >
> > On top of that dma-buf is the wrong thing - you don't want this on
> > buffers, but on surfaces. At least when it's time to reallocate. And
> > oh dear I have seen what happens when soc vendors extend this design
> > to cover that use-case, plus dynamic reallocation and all that. Imo
> > there should be no way at all this ever comes close to dma-buf itself.
> >
> > And tbh I think it's a bit silly that amd snuck this in through
> > amdgpu. But as long as you don't expect this to spread I guess it'll
> > be fine.
> 
> LOL. It's not per DMABUF, it's per buffer, so you need a KMS handle to
> access it from userspace.

Seems to be on gem buffers, not any KMS object (like framebuffers). For
cross driver that corresponds to dma-buf, and the discussion here is about
cross-driver/vendor buffer sharing.

> We've had per buffer metadata in Radeon since KMS, which I believe first
> appeared in 2009. It's 4 bytes large and is used to communicate tiling
> flags between Mesa, DDX, and the kernel display code. It was a widely
> accepted solution back then and Red Hat was the main developer. So yeah,
> pretty much all people except Intel were collaborating on "sneaking" this
> in in 2009. I think radeon driver developers deserve an apology for that
> language.
> 
> Amdgpu extended that metadata to 8 bytes and it's used in the same way as
> radeon. Additionally, amdgpu added opaque metadata having 256 bytes for use
> by userspace drivers only. The kernel driver isn't supposed to read it or
> parse it. The format is negotiated between userspace driver developers for
> sharing of more complex allocations than 2D displayable surfaces.

Metadata needed for kms (what Christian also pointed out) is what everyone
did (intel included) and I think that's perfectly reasonable. And I was
aware of that radeon is doing that since the dawn of ages since forever.

What I think is not really ok is opaque metadata blobs that the kernel
never ever inspect, but just carries around. That essentially means you're
reimplementing some bad form of IPC, and I dont think that's something the
drm subsystem (or dma-buf) really should be doing. Because you still have
that real protocol in userspace (dri2/3, wayland, whatever), but now with
a side channel with no documented ordering and synchronization. It gets
the job done for single-vendor buffer metadata transport, but as soon as
there's more than one vendor, or as soon as you need to reallocate buffers
dynamically because the usage changes it gets bad imo (and I've seen what
that looks like on android in various forms). And that consensus (at least
among folks involved in dma-buf) goes back to the dma-buf kickoff 3-day
meeting we've had over 5 years ago. Not sure we're gaining anything with a
"who's older" competition.

Anyways it's there and it's uabi so will never disappear. Just wanted to
make sure it's clear that for dma-buf we've discussed this years ago, and
decided it wasn't a great idea. And I think that's still correct.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 98322] QXL drm driver regression in 4.7

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98322

Bug ID: 98322
   Summary: QXL drm driver regression in 4.7
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: tiwai at suse.de

Since 4.7 kernel, qxl drm driver spews the errors when using VT:

 kernel: [TTM] Buffer eviction failed
 kernel: qxl :00:02.0: object_init failed for (4026540032, 0x0001)
 kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO

In my test case, just install a QEMU/KVM VM with QXL interface, login GUI, and
then switch to VT1.  At login there, the error appears repeatedly.

4.6 kernel works fine.

The git bisection spotted that it was introduced by
6819c3c2517604f979da3de773f2420e07dd4f4b
drm/qxl: Use drm_fb_helper deferred_io support

This was originally reported for opensuse TW:
  https://bugzilla.suse.com/show_bug.cgi?id=1003298

-- 
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/20161019/504107ae/attachment.html>

[PATCH 9/9] gpu: ipu-v3: initially clear all interrupts

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> If we want to stop resetting the IPU in the future, masking all
> interrupts before registering the irq handlers will not be enough to
> avoid spurious interrupts. We also have to clear them.
>
> Signed-off-by: Philipp Zabel 

Acked-by: Liu Ying 

> ---
>  drivers/gpu/ipu-v3/ipu-common.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index b7d7bd6..97218af 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -1286,8 +1286,11 @@ static int ipu_irq_init(struct ipu_soc *ipu)
> return ret;
> }
>
> -   for (i = 0; i < IPU_NUM_IRQS; i += 32)
> +   /* Mask and clear all interrupts */
> +   for (i = 0; i < IPU_NUM_IRQS; i += 32) {
> ipu_cm_write(ipu, 0, IPU_INT_CTRL(i / 32));
> +   ipu_cm_write(ipu, ~unused[i / 32], IPU_INT_STAT(i / 32));
> +   }
>
> for (i = 0; i < IPU_NUM_IRQS; i += 32) {
> gc = irq_get_domain_generic_chip(ipu->domain, i);
> --
> 2.9.3
>

[PATCH 8/9] drm/imx: ipuv3-plane: add support for YUV 4:2:2 and 4:4:4, NV12, and NV16 formats

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> Hook up support for DRM_FORMAT_YUV422, DRM_FORMAT_YVU422,
> DRM_FORMAT_YUV444, DRM_FORMAT_YVU444, DRM_FORMAT_NV12,
> and DRM_FORMAT_NV16.
>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 52 
> +--
>  1 file changed, 44 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 88829b9..991b3f1 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -50,6 +50,12 @@ static const uint32_t ipu_plane_formats[] = {
> DRM_FORMAT_YVYU,
> DRM_FORMAT_YUV420,
> DRM_FORMAT_YVU420,
> +   DRM_FORMAT_YUV422,
> +   DRM_FORMAT_YVU422,
> +   DRM_FORMAT_YUV444,
> +   DRM_FORMAT_YVU444,
> +   DRM_FORMAT_NV12,
> +   DRM_FORMAT_NV16,
> DRM_FORMAT_RGB565,
>  };
>
> @@ -292,6 +298,10 @@ static int ipu_plane_atomic_check(struct drm_plane 
> *plane,
> switch (fb->pixel_format) {
> case DRM_FORMAT_YUV420:
> case DRM_FORMAT_YVU420:
> +   case DRM_FORMAT_YUV422:
> +   case DRM_FORMAT_YVU422:
> +   case DRM_FORMAT_YUV444:
> +   case DRM_FORMAT_YVU444:
> /*
>  * Multiplanar formats have to meet the following 
> restrictions:
>  * - The (up to) three plane addresses are EBA, EBA+UBO, 
> EBA+VBO
> @@ -300,25 +310,34 @@ static int ipu_plane_atomic_check(struct drm_plane 
> *plane,
>  * - Only EBA may be changed while scanout is active
>  * - The strides of U and V planes must be identical.
>  */
> -   ubo = drm_plane_state_to_ubo(state);
> vbo = drm_plane_state_to_vbo(state);
>
> -   if ((ubo & 0x7) || (vbo & 0x7))
> -   return -EINVAL;
> -
> -   if ((ubo > 0xf8) || (vbo > 0xf8))
> +   if (vbo & 0x7 || vbo > 0xf8)
> return -EINVAL;
>
> if (old_fb && (fb->pixel_format == old_fb->pixel_format)) {
> -   old_ubo = drm_plane_state_to_ubo(old_state);
> old_vbo = drm_plane_state_to_vbo(old_state);
> -   if (ubo != old_ubo || vbo != old_vbo)
> +   if (vbo != old_vbo)
> crtc_state->mode_changed = true;
> }
>
> if (fb->pitches[1] != fb->pitches[2])
> return -EINVAL;
>
> +   /* fall-through */
> +   case DRM_FORMAT_NV12:
> +   case DRM_FORMAT_NV16:
> +   ubo = drm_plane_state_to_ubo(state);
> +
> +   if (ubo & 0x7 || ubo > 0xf8)
> +   return -EINVAL;
> +
> +   if (old_fb && (fb->pixel_format == old_fb->pixel_format)) {
> +   old_ubo = drm_plane_state_to_ubo(old_state);
> +   if (ubo != old_ubo)
> +   crtc_state->mode_changed = true;
> +   }
> +
> if (fb->pitches[1] < 1 || fb->pitches[1] > 16384)
> return -EINVAL;
>
> @@ -406,10 +425,16 @@ static void ipu_plane_atomic_update(struct drm_plane 
> *plane,
> switch (fb->pixel_format) {
> case DRM_FORMAT_YUV420:
> case DRM_FORMAT_YVU420:
> +   case DRM_FORMAT_YUV422:
> +   case DRM_FORMAT_YVU422:
> +   case DRM_FORMAT_YUV444:
> +   case DRM_FORMAT_YVU444:
> ubo = drm_plane_state_to_ubo(state);
> vbo = drm_plane_state_to_vbo(state);
>
> -   if (fb->pixel_format == DRM_FORMAT_YUV420)
> +   if (fb->pixel_format != DRM_FORMAT_YVU420 &&
> +   fb->pixel_format != DRM_FORMAT_YVU422 &&
> +   fb->pixel_format != DRM_FORMAT_YVU444)

Nit:
This looks more straightforward, perhaps.

+   if (fb->pixel_format == DRM_FORMAT_YUV420 ||
+   fb->pixel_format == DRM_FORMAT_YUV422 ||
+   fb->pixel_format == DRM_FORMAT_YUV444)

Regards,
Liu Ying


> ipu_cpmem_set_yuv_planar_full(ipu_plane->ipu_ch,
>   fb->pitches[1], ubo, 
> vbo);
> else
> @@ -420,6 +445,17 @@ static void ipu_plane_atomic_update(struct drm_plane 
> *plane,
> "phy = %lu %lu %lu, x = %d, y = %d", eba, ubo, vbo,
> state->src_x >> 16, state->src_y >> 16);
> break;
> +   case DRM_FORMAT_NV12:
> +   case DRM_FORMAT_NV16:
> +   ubo = drm_plane_state_to_ubo(state);
> +
> +   ipu_cpmem_set_yuv_planar_full(ipu_plane->ipu_ch,
> + fb->pitches[1], ubo, ubo);
> +
> +   dev_dbg(ipu_plane->base.dev->dev,
> +   "phy = %lu %lu, x = %d, 

Unix Device Memory Allocation project

[Michel Dänzer]

On 19/10/16 08:40 AM, Marek Olšák wrote:
> 
> 1) DRI (producer: application; consumer: X server)
> - The producer receives these flags: READ, EXPLICIT_FLUSH. The X
> server will treat the shared "texture" as read-only.

FWIW, no, the X server doesn't treat buffers shared with clients via DRI
as read-only.

In particular, pixmaps created from client-side buffers via DRI3 are
normal pixmaps which can be used for all X11 functionality where any
other pixmap can be used. At least the Plasma (KDE) desktop is already
making use of that, as I discovered when looking into
https://bugs.freedesktop.org/show_bug.cgi?id=95475 .

Similarly, with DRI2, shared buffers can be written to by the X server
as well as the client, in particular the (fake) front buffers used for
backing GLX window front buffers and GLX pixmaps.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 2/2] dma-buf/fence-array: hold fences reference when creating an array

[Gustavo Padovan]

From: Gustavo Padovan 

When creating fence arrays we were not holding references to the fences
in the array, however when destroy the array we were putting away a
reference to these fences.

This patch hold the ref for all fences in the array when creating the
array.

It then removes the code that was holding the fences on both amdgpu_vm and
sync_file. For sync_file, specially, we worked on small referencing
refactor for sync_file_merge().

Signed-off-by: Gustavo Padovan 
---
 drivers/dma-buf/fence-array.c  |  8 
 drivers/dma-buf/sync_file.c| 14 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  3 ---
 3 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
index f1989fc..598737f 100644
--- a/drivers/dma-buf/fence-array.c
+++ b/drivers/dma-buf/fence-array.c
@@ -112,10 +112,6 @@ EXPORT_SYMBOL(fence_array_ops);
  * Allocate a fence_array object and initialize the base fence with 
fence_init().
  * In case of error it returns NULL.
  *
- * The caller should allocate the fences array with num_fences size
- * and fill it with the fences it wants to add to the object. Ownership of this
- * array is taken and fence_put() is used on each fence on release.
- *
  * If @signal_on_any is true the fence array signals if any fence in the array
  * signals, otherwise it signals when all fences in the array signal.
  */
@@ -125,6 +121,7 @@ struct fence_array *fence_array_create(int num_fences, 
struct fence **fences,
 {
struct fence_array *array;
size_t size = sizeof(*array);
+   int i;

/* Allocate the callback structures behind the array. */
size += num_fences * sizeof(struct fence_array_cb);
@@ -140,6 +137,9 @@ struct fence_array *fence_array_create(int num_fences, 
struct fence **fences,
atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;

+   for (i = 0; i < array->num_fences; ++i)
+   fence_get(array->fences[i]);
+
return array;
 }
 EXPORT_SYMBOL(fence_array_create);
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 235f8ac..678baaf 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -142,14 +142,8 @@ static int sync_file_set_fence(struct sync_file *sync_file,
 {
struct fence_array *array;

-   /*
-* The reference for the fences in the new sync_file and held
-* in add_fence() during the merge procedure, so for num_fences == 1
-* we already own a new reference to the fence. For num_fence > 1
-* we own the reference of the fence_array creation.
-*/
if (num_fences == 1) {
-   sync_file->fence = fences[0];
+   sync_file->fence = fence_get(fences[0]);
kfree(fences);
} else {
array = fence_array_create(num_fences, fences,
@@ -180,10 +174,8 @@ static void add_fence(struct fence **fences, int *i, 
struct fence *fence)
 {
fences[*i] = fence;

-   if (!fence_is_signaled(fence)) {
-   fence_get(fence);
+   if (!fence_is_signaled(fence))
(*i)++;
-   }
 }

 /**
@@ -255,7 +247,7 @@ static struct sync_file *sync_file_merge(const char *name, 
struct sync_file *a,
add_fence(fences, , b_fences[i_b]);

if (i == 0)
-   fences[i++] = fence_get(a_fences[0]);
+   fences[i++] = a_fences[0];

if (num_fences > i) {
nfences = krealloc(fences, i * sizeof(*fences),
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index bc4b22c..4ee7988 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -228,9 +228,6 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
amdgpu_ring *ring,
struct fence_array *array;
unsigned j;

-   for (j = 0; j < i; ++j)
-   fence_get(fences[j]);
-
array = fence_array_create(i, fences, fence_context,
   seqno, true);
if (!array) {
-- 
2.5.5

[PATCH 1/2] dma-buf/sync_file: hold reference to fence when creating sync_file

[Gustavo Padovan]

From: Gustavo Padovan 

fence referencing was out of balance. It was not taking any ref to the
fence at creating time, but it was putting a reference when freeing the
sync file.

This patch fixes the balancing issue by getting a reference for the fence
when creating the sync_file.

Signed-off-by: Gustavo Padovan 
---
 drivers/dma-buf/sync_file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index b29a9e8..235f8ac 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -79,7 +79,7 @@ struct sync_file *sync_file_create(struct fence *fence)
if (!sync_file)
return NULL;

-   sync_file->fence = fence;
+   sync_file->fence = fence_get(fence);

snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
 fence->ops->get_driver_name(fence),
-- 
2.5.5

[PATCH 7/9] gpu: ipu-v3: add YUV 4:4:4 support

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> The IDMAC does support reading and writing DRM_FORMAT_YUV444 and
> DRM_FORMAT_YVU444.
>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/ipu-v3/ipu-common.c |  2 ++
>  drivers/gpu/ipu-v3/ipu-cpmem.c  | 17 +
>  2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index b9539f7..b7d7bd6 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -88,6 +88,8 @@ enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 
> drm_fourcc)
> case DRM_FORMAT_YVU420:
> case DRM_FORMAT_YUV422:
> case DRM_FORMAT_YVU422:
> +   case DRM_FORMAT_YUV444:
> +   case DRM_FORMAT_YVU444:
> case DRM_FORMAT_NV12:
> case DRM_FORMAT_NV21:
> case DRM_FORMAT_NV16:
> diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
> index e6b8bae..4db7475 100644
> --- a/drivers/gpu/ipu-v3/ipu-cpmem.c
> +++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
> @@ -445,6 +445,16 @@ void ipu_cpmem_set_yuv_planar(struct ipuv3_channel *ch,
> v_offset = stride * height;
> u_offset = v_offset + (uv_stride * height);
> break;
> +   case DRM_FORMAT_YUV444:
> +   uv_stride = stride;
> +   u_offset = stride * height;
> +   v_offset = u_offset + (uv_stride * height);
> +   break;
> +   case DRM_FORMAT_YVU444:
> +   uv_stride = stride;
> +   v_offset = stride * height;
> +   u_offset = v_offset + (uv_stride * height);
> +   break;

This function can be removed probably as I mentioned in comments
for patch 6/9.

With that addressed:
Acked-by: Liu Ying 

Regards,
Liu Ying


> case DRM_FORMAT_NV12:
> case DRM_FORMAT_NV16:
> uv_stride = stride;
> @@ -595,6 +605,13 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
> drm_fourcc)
> /* burst size */
> ipu_ch_param_write_field(ch, IPU_FIELD_NPB, 31);
> break;
> +   case DRM_FORMAT_YUV444:
> +   case DRM_FORMAT_YVU444:
> +   /* pix format */
> +   ipu_ch_param_write_field(ch, IPU_FIELD_PFS, 0);
> +   /* burst size */
> +   ipu_ch_param_write_field(ch, IPU_FIELD_NPB, 31);
> +   break;
> case DRM_FORMAT_NV12:
> /* pix format */
> ipu_ch_param_write_field(ch, IPU_FIELD_PFS, 4);
> --
> 2.9.3
>

[PATCH 6/9] gpu: ipu-cpmem: Add missing YVU422 case to ipu_cpmem_set_yuv_planar

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> ipu_cpmem_set_fmt is already prepared to handle DRM_FORMAT_YVU422.
>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/ipu-v3/ipu-cpmem.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
> index fcb7dc8..e6b8bae 100644
> --- a/drivers/gpu/ipu-v3/ipu-cpmem.c
> +++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
> @@ -440,6 +440,11 @@ void ipu_cpmem_set_yuv_planar(struct ipuv3_channel *ch,
> u_offset = stride * height;
> v_offset = u_offset + (uv_stride * height);
> break;
> +   case DRM_FORMAT_YVU422:
> +   uv_stride = stride / 2;
> +   v_offset = stride * height;
> +   u_offset = v_offset + (uv_stride * height);
> +   break;

It looks no one is using this function.
How about removing it directly?

Regards,
Liu Ying

> case DRM_FORMAT_NV12:
> case DRM_FORMAT_NV16:
> uv_stride = stride;
> --
> 2.9.3
>

[PATCH 5/9] drm/imx: ipuv3-plane: let drm_plane_state_to_ubo/vbo handle chroma subsampling other than 4:2:0

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> To support 4:2:2 or 4:4:4 chroma subsampling, divide the x/y offsets in
> drm_plane_state_to_ubo/vbo only if necessary for the given pixel format.
>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 27 ++-
>  1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 70fd55d..88829b9 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -64,13 +64,14 @@ drm_plane_state_to_eba(struct drm_plane_state *state)
>  {
> struct drm_framebuffer *fb = state->fb;
> struct drm_gem_cma_object *cma_obj;
> +   int x = state->src_x >> 16;
> +   int y = state->src_y >> 16;
>
> cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
> BUG_ON(!cma_obj);
>
> -   return cma_obj->paddr + fb->offsets[0] +
> -  fb->pitches[0] * (state->src_y >> 16) +
> -  (fb->bits_per_pixel >> 3) * (state->src_x >> 16);
> +   return cma_obj->paddr + fb->offsets[0] + fb->pitches[0] * y +
> +  drm_format_plane_cpp(fb->pixel_format, 0) * x;

I need some time to look into drm_format_plane_cpp().
Will provide comments after that.

Regards,
Liu Ying

>  }
>
>  static inline unsigned long
> @@ -79,13 +80,17 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
> struct drm_framebuffer *fb = state->fb;
> struct drm_gem_cma_object *cma_obj;
> unsigned long eba = drm_plane_state_to_eba(state);
> +   int x = state->src_x >> 16;
> +   int y = state->src_y >> 16;
>
> cma_obj = drm_fb_cma_get_gem_obj(fb, 1);
> BUG_ON(!cma_obj);
>
> -   return cma_obj->paddr + fb->offsets[1] +
> -  fb->pitches[1] * (state->src_y >> 16) / 2 +
> -  (state->src_x >> 16) / 2 - eba;
> +   x /= drm_format_horz_chroma_subsampling(fb->pixel_format);
> +   y /= drm_format_vert_chroma_subsampling(fb->pixel_format);
> +
> +   return cma_obj->paddr + fb->offsets[1] + fb->pitches[1] * y +
> +  drm_format_plane_cpp(fb->pixel_format, 1) * x - eba;
>  }
>
>  static inline unsigned long
> @@ -94,13 +99,17 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
> struct drm_framebuffer *fb = state->fb;
> struct drm_gem_cma_object *cma_obj;
> unsigned long eba = drm_plane_state_to_eba(state);
> +   int x = state->src_x >> 16;
> +   int y = state->src_y >> 16;
>
> cma_obj = drm_fb_cma_get_gem_obj(fb, 2);
> BUG_ON(!cma_obj);
>
> -   return cma_obj->paddr + fb->offsets[2] +
> -  fb->pitches[2] * (state->src_y >> 16) / 2 +
> -  (state->src_x >> 16) / 2 - eba;
> +   x /= drm_format_horz_chroma_subsampling(fb->pixel_format);
> +   y /= drm_format_vert_chroma_subsampling(fb->pixel_format);
> +
> +   return cma_obj->paddr + fb->offsets[2] + fb->pitches[2] * y +
> +  drm_format_plane_cpp(fb->pixel_format, 2) * x - eba;
>  }
>
>  void ipu_plane_put_resources(struct ipu_plane *ipu_plane)
> --
> 2.9.3
>

Unix Device Memory Allocation project

[Marek Olšák]

On Oct 19, 2016 2:33 PM, "Nicolai Hähnle"  wrote:
>
> On 19.10.2016 01:40, Marek Olšák wrote:
>>
>>   * We can build upon this idea. I think the worst thing to do would
>> be to add metadata handling to driver-agnostic userspace APIs. Really,
>> driver-agnostic APIs shouldn't know about that, because they can't
>> understand all the hw-specific information encoded in the metadata.
>> Also, when you want to change the metadata format, you only have to
>> update the affected drivers, not userspace APIs.
>
>
> I don't fully agree with that. In a PRIME setting, where you have a
compositor running on an integrated GPU and an application on a dGPU, there
may well be a benefit to finding a tiling format that the dGPU can produce
and the iGPU can consume. Admittedly I don't know whether that's actually
possible today when they're from different vendors, but resigning ourselves
to linear only for all time seems a bit pessimistic.

Yeah, that's a good point and I even mentioned it near the end of my post.
It could be solved by passing the PCI ID of the other device to the driver
instead of the linear flag. Then the driver can decide whether a linear
layout is necessary or not.

Marek
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/7d9bf461/attachment.html>

[PATCH V2] gpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap

[Arvind Yadav]

Free memory mapping, if hdmi_probe is not successful.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..ba28dec 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
 err_hdmiphy:
if (hdata->hdmiphy_port)
put_device(>hdmiphy_port->dev);
+   if (hdata->regs_hdmiphy)
+   iounmap(hdata->regs_hdmiphy);
 err_ddc:
put_device(>ddc_adpt->dev);

@@ -1923,6 +1925,9 @@ static int hdmi_remove(struct platform_device *pdev)
if (hdata->hdmiphy_port)
put_device(>hdmiphy_port->dev);

+   if (hdata->regs_hdmiphy)
+   iounmap(hdata->regs_hdmiphy);
+
put_device(>ddc_adpt->dev);

return 0;
-- 
1.7.9.5

[PATCH 4/9] drm/imx: ipuv3-plane: merge ipu_plane_atomic_set_base into atomic_update

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> ipu_plane_atomic_set_base is called from ipu_plane_atomic_update in two
> different places, depending on whether drm_atomic_crtc_needs_modeset is
> true. Also depending on the same condition, this function does two
> different things.
> This patch removes the indirection by merging the relevant parts into
> ipu_plane_atomic_update, making the actual code flow more obvious as a
> result. Also remove the duplicate planar format comment, which is
> already found in ipu_plane_atomic_check.
>
> Signed-off-by: Philipp Zabel 

Acked-by: Liu Ying 

> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 97 
> ++-
>  1 file changed, 34 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index f217444..70fd55d 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -103,62 +103,6 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
>(state->src_x >> 16) / 2 - eba;
>  }
>
> -static void ipu_plane_atomic_set_base(struct ipu_plane *ipu_plane)
> -{
> -   struct drm_plane *plane = _plane->base;
> -   struct drm_plane_state *state = plane->state;
> -   struct drm_crtc_state *crtc_state = state->crtc->state;
> -   struct drm_framebuffer *fb = state->fb;
> -   unsigned long eba, ubo, vbo;
> -   int active;
> -
> -   eba = drm_plane_state_to_eba(state);
> -
> -   switch (fb->pixel_format) {
> -   case DRM_FORMAT_YUV420:
> -   case DRM_FORMAT_YVU420:
> -   if (!drm_atomic_crtc_needs_modeset(crtc_state))
> -   break;
> -
> -   /*
> -* Multiplanar formats have to meet the following 
> restrictions:
> -* - The (up to) three plane addresses are EBA, EBA+UBO, 
> EBA+VBO
> -* - EBA, UBO and VBO are a multiple of 8
> -* - UBO and VBO are unsigned and not larger than 0xf8
> -* - Only EBA may be changed while scanout is active
> -* - The strides of U and V planes must be identical.
> -*/
> -   ubo = drm_plane_state_to_ubo(state);
> -   vbo = drm_plane_state_to_vbo(state);
> -
> -   if (fb->pixel_format == DRM_FORMAT_YUV420)
> -   ipu_cpmem_set_yuv_planar_full(ipu_plane->ipu_ch,
> - fb->pitches[1], ubo, 
> vbo);
> -   else
> -   ipu_cpmem_set_yuv_planar_full(ipu_plane->ipu_ch,
> - fb->pitches[1], vbo, 
> ubo);
> -
> -   dev_dbg(ipu_plane->base.dev->dev,
> -   "phy = %lu %lu %lu, x = %d, y = %d", eba, ubo, vbo,
> -   state->src_x >> 16, state->src_y >> 16);
> -   break;
> -   default:
> -   dev_dbg(ipu_plane->base.dev->dev, "phys = %lu, x = %d, y = 
> %d",
> -   eba, state->src_x >> 16, state->src_y >> 16);
> -
> -   break;
> -   }
> -
> -   if (!drm_atomic_crtc_needs_modeset(crtc_state)) {
> -   active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
> -   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
> -   ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
> -   } else {
> -   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 0, eba);
> -   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 1, eba);
> -   }
> -}
> -
>  void ipu_plane_put_resources(struct ipu_plane *ipu_plane)
>  {
> if (!IS_ERR_OR_NULL(ipu_plane->dp))
> @@ -394,15 +338,19 @@ static void ipu_plane_atomic_update(struct drm_plane 
> *plane,
>  {
> struct ipu_plane *ipu_plane = to_ipu_plane(plane);
> struct drm_plane_state *state = plane->state;
> +   struct drm_crtc_state *crtc_state = state->crtc->state;
> +   struct drm_framebuffer *fb = state->fb;
> +   unsigned long eba, ubo, vbo;
> enum ipu_color_space ics;
> +   int active;
>
> -   if (old_state->fb) {
> -   struct drm_crtc_state *crtc_state = state->crtc->state;
> +   eba = drm_plane_state_to_eba(state);
>
> -   if (!drm_atomic_crtc_needs_modeset(crtc_state)) {
> -   ipu_plane_atomic_set_base(ipu_plane);
> -   return;
> -   }
> +   if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
> +   active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
> +   ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
> +   ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
> +   return;
> }
>
> switch (ipu_plane->dp_flow) {
> @@ -446,7 +394,30 @@ static void ipu_plane_atomic_update(struct drm_plane 
> *plane,
> 

[PATCH 3/9] drm/imx: ipuv3-plane: request modeset if plane offsets changed

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> If the framebuffer pixel format is planar YUV and unchanged, but the U
> or V plane offsets change, do not return an error, but request a modeset
> instead.
>
> Signed-off-by: Philipp Zabel 

Acked-by: Liu Ying 

> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index d4a771c..f217444 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -356,13 +356,11 @@ static int ipu_plane_atomic_check(struct drm_plane 
> *plane,
> if ((ubo > 0xf8) || (vbo > 0xf8))
> return -EINVAL;
>
> -   if (old_fb &&
> -   (old_fb->pixel_format == DRM_FORMAT_YUV420 ||
> -old_fb->pixel_format == DRM_FORMAT_YVU420)) {
> +   if (old_fb && (fb->pixel_format == old_fb->pixel_format)) {
> old_ubo = drm_plane_state_to_ubo(old_state);
> old_vbo = drm_plane_state_to_vbo(old_state);
> if (ubo != old_ubo || vbo != old_vbo)
> -   return -EINVAL;
> +   crtc_state->mode_changed = true;
> }
>
> if (fb->pitches[1] != fb->pitches[2])
> --
> 2.9.3
>

[PATCH 2/9] drm/imx: ipuv3-plane: disable local alpha for planes without alpha channel

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> Without this patch, after enabling the overlay plane with an RGBA
> framebuffer, switching to a framebuffer without alpha channel would
> cause the plane to vanish, since the pixel local alpha is constant
> zero in that case. Disable local alpha again when setting an opaque
> framebuffer.
>
> Signed-off-by: Philipp Zabel 

Looking at the big picture, we've got some hard coding for DP CSC :(
However, looking at this patch itself, it is acceptable to me.

Regards,
Liu Ying

> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 3a03fd8..d4a771c 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -434,6 +434,7 @@ static void ipu_plane_atomic_update(struct drm_plane 
> *plane,
> ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, 
> false);
> break;
> default:
> +   ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
> break;
> }
> }
> --
> 2.9.3
>

Unix Device Memory Allocation project

[Marek Olšák]

On Oct 19, 2016 8:24 AM, "Daniel Vetter"  wrote:
>
> On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák  wrote:
> > - The producer-consumer interop API doesn't know about the metadata.
> > All you need to pass around is a buffer handle. (KMS, DMABUF, etc.)
> >   * There was a note during the talk that DMABUF doesn't have any
> > metadata. Well, I just told you that it has, but it's private to
> > amdgpu and possibly accessible to other kernel drivers too.
> >   * We can build upon this idea. I think the worst thing to do would
> > be to add metadata handling to driver-agnostic userspace APIs. Really,
> > driver-agnostic APIs shouldn't know about that, because they can't
> > understand all the hw-specific information encoded in the metadata.
> > Also, when you want to change the metadata format, you only have to
> > update the affected drivers, not userspace APIs.
>
> That's a bit a surprise to hear, since "can't we just add a bit of
> opaque metadata to dma-buf" came up all the time over the past years,
> and died all the time again. dma-buf shouldn't imo be just yet another
> linux IPC mechanism and protocol, which is pretty much what you end up
> doing when you add this stuff. DRM runs all kinds of compositors with
> all kinds of existing userspace proto, and with reasonable ones like
> Wayland vendors can add whatever extensions they want. Plus there's
> all the interop with v4l and every other kernel subsytem. Trying to
> standardize that into some blob that works for everyone is imo nigh
> impossible.
>
> On top of that dma-buf is the wrong thing - you don't want this on
> buffers, but on surfaces. At least when it's time to reallocate. And
> oh dear I have seen what happens when soc vendors extend this design
> to cover that use-case, plus dynamic reallocation and all that. Imo
> there should be no way at all this ever comes close to dma-buf itself.
>
> And tbh I think it's a bit silly that amd snuck this in through
> amdgpu. But as long as you don't expect this to spread I guess it'll
> be fine.

LOL. It's not per DMABUF, it's per buffer, so you need a KMS handle to
access it from userspace.

We've had per buffer metadata in Radeon since KMS, which I believe first
appeared in 2009. It's 4 bytes large and is used to communicate tiling
flags between Mesa, DDX, and the kernel display code. It was a widely
accepted solution back then and Red Hat was the main developer. So yeah,
pretty much all people except Intel were collaborating on "sneaking" this
in in 2009. I think radeon driver developers deserve an apology for that
language.

Amdgpu extended that metadata to 8 bytes and it's used in the same way as
radeon. Additionally, amdgpu added opaque metadata having 256 bytes for use
by userspace drivers only. The kernel driver isn't supposed to read it or
parse it. The format is negotiated between userspace driver developers for
sharing of more complex allocations than 2D displayable surfaces.

Marek


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/f4e50c12/attachment-0001.html>

[PATCH 1/9] drm/imx: ipuv3-plane: make sure x/y offsets are even in case of chroma subsampling

[Ying Liu]

On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel  
wrote:
> Odd x/y offsets are not allowed for chroma subsampled planar YUV
> formats.
>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 5c34299..3a03fd8 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -259,6 +259,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
> struct drm_framebuffer *fb = state->fb;
> struct drm_framebuffer *old_fb = old_state->fb;
> unsigned long eba, ubo, vbo, old_ubo, old_vbo;
> +   int hsub, vsub;
>
> /* Ok to disable */
> if (!fb)
> @@ -372,6 +373,13 @@ static int ipu_plane_atomic_check(struct drm_plane 
> *plane,
>
> if (old_fb && old_fb->pitches[1] != fb->pitches[1])
> crtc_state->mode_changed = true;
> +
> +   /* x and y offsets must be even in case of chroma subsampling 
> */

True for x offsets, but not for y offsets, e.g., NV16.

Regards,
Liu Ying

> +   hsub = drm_format_horz_chroma_subsampling(fb->pixel_format);
> +   vsub = drm_format_vert_chroma_subsampling(fb->pixel_format);
> +   if (((state->src_x >> 16) & (hsub - 1)) ||
> +   ((state->src_y >> 16) & (vsub - 1)))
> +   return -EINVAL;
> }
>
> return 0;
> --
> 2.9.3
>

[PATCH] drm: Fix LSPCON kernel-doc

[Jani Nikula]

Fix warnings on building htmldocs.

v2: whitespace around '/' (Ville)

Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Rodrigo Vivi 
Cc: Shashank Sharma 
Cc: 
Signed-off-by: Jani Nikula 

---

n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
been merged via drm-intel tree
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
 include/drm/drm_dp_dual_mode_helper.h | 15 ---
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 2624e266abbd..488355bdafb9 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);

 /**
  * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
- * by reading offset (0x80, 0x41)
- * @i2c_adapter: I2C-over-aux adapter
- * @current_mode: out vaiable, current lspcon mode of operation
+ * reading offset (0x80, 0x41)
+ * @adapter: I2C-over-aux adapter
+ * @mode: current lspcon mode of operation output variable
  *
  * Returns:
  * 0 on success, sets the current_mode value to appropriate mode
@@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
 EXPORT_SYMBOL(drm_lspcon_get_mode);

 /**
- * drm_lspcon_change_mode: Change LSPCON's mode of operation by
- * by writing offset (0x80, 0x40)
- * @i2c_adapter: I2C-over-aux adapter
- * @reqd_mode: required mode of operation
+ * drm_lspcon_set_mode: Change LSPCON's mode of operation by
+ * writing offset (0x80, 0x40)
+ * @adapter: I2C-over-aux adapter
+ * @mode: required mode of operation
  *
  * Returns:
  * 0 on success, -error on failure/timeout
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 55677704add8..4c42db81fcb4 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter *adapter,
   u8 offset, const void *buffer, size_t size);

 /**
-* enum drm_lspcon_mode
-* @lspcon_mode_ls: Level shifter mode of LSPCON
-*  which drives DP++ to HDMI 1.4 conversion.
-* @lspcon_mode_pcon: Protocol converter mode of LSPCON
-*  which drives DP++ to HDMI 2.0 active conversion.
-*/
+ * enum drm_lspcon_mode
+ * @DRM_LSPCON_MODE_INVALID: No LSPCON.
+ * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
+ * which drives DP++ to HDMI 1.4 conversion.
+ * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
+ * which drives DP++ to HDMI 2.0 active conversion.
+ */
 enum drm_lspcon_mode {
DRM_LSPCON_MODE_INVALID,
DRM_LSPCON_MODE_LS,
@@ -90,7 +91,7 @@ enum drm_lspcon_mode {
  * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
  * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
  * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
- * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
+ * @DRM_DP_DUAL_MODE_LSPCON: Level shifter / protocol converter
  */
 enum drm_dp_dual_mode_type {
DRM_DP_DUAL_MODE_NONE,
-- 
2.1.4

[Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

[Ville Syrjälä]

On Wed, Oct 19, 2016 at 02:43:24PM +0300, Jani Nikula wrote:
> Fix warnings on building htmldocs.
> 
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Rodrigo Vivi 
> Cc: Shashank Sharma 
> Cc: 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
> been merged via drm-intel tree
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
>  include/drm/drm_dp_dual_mode_helper.h | 15 ---
>  2 files changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 2624e266abbd..488355bdafb9 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
>  
>  /**
>   * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
> - * by reading offset (0x80, 0x41)
> - * @i2c_adapter: I2C-over-aux adapter
> - * @current_mode: out vaiable, current lspcon mode of operation
> + * reading offset (0x80, 0x41)
> + * @adapter: I2C-over-aux adapter
> + * @mode: current lspcon mode of operation output variable
>   *
>   * Returns:
>   * 0 on success, sets the current_mode value to appropriate mode
> @@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
>  EXPORT_SYMBOL(drm_lspcon_get_mode);
>  
>  /**
> - * drm_lspcon_change_mode: Change LSPCON's mode of operation by
> - * by writing offset (0x80, 0x40)
> - * @i2c_adapter: I2C-over-aux adapter
> - * @reqd_mode: required mode of operation
> + * drm_lspcon_set_mode: Change LSPCON's mode of operation by
> + * writing offset (0x80, 0x40)
> + * @adapter: I2C-over-aux adapter
> + * @mode: required mode of operation
>   *
>   * Returns:
>   * 0 on success, -error on failure/timeout
> diff --git a/include/drm/drm_dp_dual_mode_helper.h 
> b/include/drm/drm_dp_dual_mode_helper.h
> index 55677704add8..1f04c5cfd402 100644
> --- a/include/drm/drm_dp_dual_mode_helper.h
> +++ b/include/drm/drm_dp_dual_mode_helper.h
> @@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter 
> *adapter,
>  u8 offset, const void *buffer, size_t size);
>  
>  /**
> -* enum drm_lspcon_mode
> -* @lspcon_mode_ls: Level shifter mode of LSPCON
> -*which drives DP++ to HDMI 1.4 conversion.
> -* @lspcon_mode_pcon: Protocol converter mode of LSPCON
> -*which drives DP++ to HDMI 2.0 active conversion.
> -*/
> + * enum drm_lspcon_mode
> + * @DRM_LSPCON_MODE_INVALID: No LSPCON.
> + * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
> + *   which drives DP++ to HDMI 1.4 conversion.
> + * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
> + *   which drives DP++ to HDMI 2.0 active conversion.
> + */
>  enum drm_lspcon_mode {
>   DRM_LSPCON_MODE_INVALID,
>   DRM_LSPCON_MODE_LS,
> @@ -90,7 +91,7 @@ enum drm_lspcon_mode {
>   * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
>   * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
>   * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
> - * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
> + * @DRM_DP_DUAL_MODE_LSPCON: Level shifter /protocol converter

May want to fix up the whitespace around '/' a bit too. Looks weird now.

>   */
>  enum drm_dp_dual_mode_type {
>   DRM_DP_DUAL_MODE_NONE,
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[PATCH v2] drm/bridge: adv7511: Remove unused code blocks

[Laurent Pinchart]

Hi Jitendra,

Thank you for the patch.

On Wednesday 19 Oct 2016 17:12:48 Jitendra Sharma wrote:
> Remove redundant condition check
> Remove not necessary if-else block for checking DT entry because else
> part will never be picked as in absence of device node, probe will
> fail in initial stage only.
> 
> Remove unused id->driver_data entries
> As id->driver_data is not used in driver source. So no need in
> Keeping these entries in id_table
> 
> Signed-off-by: Jitendra Sharma 
> ---
> Probe was not happening in Patch v1 due to removal of .id_table.As the
> intention of this patch is not to change any functionality, also
> changes looks simple enough.So, didn't verified Patch v1 over hardware

You should *ALWAYS* verify patches before sending them out.

I assume you've now properly tested this one ?

> Hence fixing the issues in Patch v1 and posting patch v2
> 
> Changes for v2:
>  - Keep the id_table entries
>  - Keep the id->driver_data to 0
> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index 8ed3906..3279059
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -942,10 +942,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) adv7511->powered = false;
>   adv7511->status = connector_status_disconnected;
> 
> - if (dev->of_node)
> - adv7511->type = (enum 
adv7511_type)of_device_get_match_data(dev);
> - else
> - adv7511->type = id->driver_data;
> + adv7511->type = (enum adv7511_type)of_device_get_match_data(dev);
> 
>   memset(_config, 0, sizeof(link_config));
> 
> @@ -1066,11 +1063,11 @@ static int adv7511_remove(struct i2c_client *i2c)
>  }
> 
>  static const struct i2c_device_id adv7511_i2c_ids[] = {
> - { "adv7511", ADV7511 },
> - { "adv7511w", ADV7511 },
> - { "adv7513", ADV7511 },
> + { "adv7511", 0 },
> + { "adv7511w", 0 },
> + { "adv7513", 0 },
>  #ifdef CONFIG_DRM_I2C_ADV7533
> - { "adv7533", ADV7533 },
> + { "adv7533", 0 },
>  #endif

What's the purpose of this ? It doesn't save any memory or CPU cycle.

>   { }
>  };

-- 
Regards,

Laurent Pinchart

[PATCH RFC 8/8] drm/i915: Add support for DP link training compliance

[Manasi Navare]

This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is sent in order
to trigger another modeset during which the pipe is configured
and link is enabled for link parameters requested by the test.

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
---
 drivers/gpu/drm/i915/intel_dp.c  | 72 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 78246ba..cd7a59e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1588,6 +1588,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
/* Conveniently, the link BW constants become indices with a shift...*/
int min_clock = 0;
int max_clock;
+   int link_rate_index;
int bpp, mode_rate;
int link_avail, link_clock;
int common_rates[DP_MAX_SUPPORTED_RATES] = {};
@@ -1636,6 +1637,19 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
intel_dp->link_train_failed_link_rate = 0;
intel_dp->link_rate_index = -1;
}
+   /* Use values requested by Compliance Test Request */
+   if (intel_dp->compliance_test_link_rate &&
+   intel_dp->compliance_test_lane_count) {
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  
drm_dp_bw_code_to_link_rate(intel_dp->compliance_test_link_rate));
+   if (link_rate_index >= 0)
+   min_clock = max_clock = link_rate_index;
+   min_lane_count = max_lane_count = 
intel_dp->compliance_test_lane_count;
+
+   intel_dp->compliance_test_link_rate = 0;
+   intel_dp->compliance_test_lane_count = 0;
+   }

DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %d pixel clock %iKHz\n",
@@ -1684,6 +1698,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
}
}
}
+
}

return false;
@@ -3865,6 +3880,29 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
 static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
 {
uint8_t test_result = DP_TEST_ACK;
+   int status = 0;
+   /* (DP CTS 1.2)
+* 4.3.1.11
+*/
+   /* Read the TEST_LANE_COUNT and TEST_LINK_RTAE fields (DP CTS 3.1.4) */
+   status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LANE_COUNT,
+ _dp->compliance_test_lane_count);
+
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Could not read test lane count from "
+ "reference sink\n");
+   return 0;
+   }
+   intel_dp->compliance_test_lane_count &= DP_MAX_LANE_COUNT_MASK;
+
+   status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LINK_RATE,
+  _dp->compliance_test_link_rate);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Could not read test link rate from "
+ "refernce sink\n");
+   return 0;
+   }
+
return test_result;
 }

@@ -3965,11 +4003,14 @@ static void intel_dp_handle_test_request(struct 
intel_dp *intel_dp)
}

 update_status:
-   status = drm_dp_dpcd_write(_dp->aux,
-  DP_TEST_RESPONSE,
-  , 1);
-   if (status <= 0)
-   DRM_DEBUG_KMS("Could not write test response to sink\n");
+   if (intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) {
+   status = drm_dp_dpcd_write(_dp->aux,
+  DP_TEST_RESPONSE,
+  , 1);
+   if (status <= 0)
+   DRM_DEBUG_KMS("Could not write test response "
+ "to sink\n");
+   }
 }

 static int
@@ -4074,9 +4115,7 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
if (!to_intel_crtc(intel_encoder->base.crtc)->active)
return;

-   /* if link training is requested we should perform it always */
-   if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
-   (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
+   if ((!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
DRM_DEBUG_KMS("%s: channel EQ not ok, 

[PATCH RFC 7/8] drm/i915: Link Rate fallback on Link training failure

[Manasi Navare]

If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed and use a lower link rate
to prune the modes during the next modeset, configure the pipe at
lower link rate and retrian at lower link rate.

This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 14 ++-
 drivers/gpu/drm/i915/intel_dp.c   | 35 +--
 drivers/gpu/drm/i915/intel_dp_link_training.c | 12 ++---
 drivers/gpu/drm/i915/intel_drv.h  |  6 -
 4 files changed, 60 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7f7741c..cccb301 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1642,6 +1642,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;

intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
@@ -1652,7 +1654,17 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
+   if (!intel_dp_start_link_train(intel_dp)) {
+   DRM_ERROR("Link Training failed at link rate = %d, lane count = 
%d",
+ link_rate, lane_count);
+   intel_dp->link_train_failed = true;
+   intel_dp->link_train_failed_link_rate = link_rate;
+   intel_dp->link_train_failed_lane_count = lane_count;
+   /* Schedule a Hotplug Uevent to userspace to start modeset */
+   schedule_work(>i915_modeset_retry_work);
+   } else
+   connector->link_train_retry = false;
+
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index aae7f82..78246ba 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -313,6 +313,7 @@ static int intel_dp_link_rate_index(struct intel_dp 
*intel_dp, int *common_rates
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk;
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};

max_dotclk = intel_dp_downstream_max_dotclock(intel_dp);

@@ -326,8 +327,26 @@ static int intel_dp_link_rate_index(struct intel_dp 
*intel_dp, int *common_rates
target_clock = fixed_mode->clock;
}

-   max_link_clock = intel_dp_max_link_rate(intel_dp);
-   max_lanes = intel_dp_max_lane_count(intel_dp);
+   /* Prune the modes based on the link rate that failed */
+   if (intel_dp->link_train_failed_link_rate) {
+   intel_dp->link_rate_index = intel_dp_link_rate_index(intel_dp,
+
common_rates,
+
intel_dp->link_train_failed_link_rate);
+   if (intel_dp->link_rate_index > 0) {
+   max_link_clock = common_rates[intel_dp->link_rate_index 
- 1];
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   } else {
+   /* Here we can lower the lane count, but that is DP 1.3 
not 1.2 */
+   DRM_ERROR(" No Valid Mode Supported for this Link");
+   connector->link_train_retry = false;
+   intel_dp->link_train_failed_link_rate = 0;
+   intel_dp->link_rate_index = -1;
+   }
+   }
+   else {
+   max_link_clock = intel_dp_max_link_rate(intel_dp);
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   }

max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1610,6 +1629,14 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;

+   /* Fall back to lower link rate in case of failure in previous modeset 
*/
+   if (intel_dp->link_train_failed_link_rate) {
+   min_lane_count = max_lane_count;
+  

[PATCH RFC 6/8] drm/i915: Define the modeset retry work function

[Manasi Navare]

This work function gets scheduled on link training failure
during the atomic commit of modeset. It should get executed
after the current modeset is completed and send a hotplug uevent
to notify the usersapce about change in the connector link property
requesting link_train_retry

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a60bef8..aae7f82 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5675,6 +5675,22 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
return false;
 }

+static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
+{
+   struct drm_connector *connector;
+
+   connector = container_of(work, typeof(*connector),
+i915_modeset_retry_work);
+
+   /* Grab the locks before changing connector property*/
+   mutex_lock(>dev->mode_config.mutex);
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
+ connector->name);
+   connector->link_train_retry = true;
+   mutex_unlock(>dev->mode_config.mutex);
+   drm_kms_helper_hotplug_event(connector->dev);
+}
+
 bool
 intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector)
@@ -5687,6 +5703,10 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
enum port port = intel_dig_port->port;
int type;

+   /* Initialize the work for modeset in case of link train failure */
+   INIT_WORK(>i915_modeset_retry_work,
+ intel_dp_modeset_retry_work_fn);
+
if (WARN(intel_dig_port->max_lanes < 1,
 "Not enough lanes (%d) for DP on port %c\n",
 intel_dig_port->max_lanes, port_name(port)))
-- 
1.9.1

[PATCH RFC 5/8] drm/i915; Add a function to return index of link rate

[Manasi Navare]

This is required to return the index of link rate into
common_rates array. This gets used to retry the link
training at lower link rate.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6b54b0e..a60bef8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,21 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
   common_rates);
 }

+static int intel_dp_link_rate_index(struct intel_dp *intel_dp, int 
*common_rates,
+   int link_rate)
+{
+   int common_len;
+   int index;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   for (index = 0; index < common_len; index++) {
+   if (link_rate == common_rates[common_len - index - 1])
+   return common_len - index - 1;
+   }
+
+   return -1;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
-- 
1.9.1

[PATCH RFC 4/8] drm/i915: Change the placement of some static functions in intel_dp.c

[Manasi Navare]

From: "Navare, Manasi D" 

These static helper functions are required to be used during
fallback link rate implemnetation so they need to be placed at the top
of the file.

v3:
* Add cleanup to other patch (Mika Kahola)
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
Reviewed-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 150 
 1 file changed, 75 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 88f3b74..6b54b0e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -213,6 +213,81 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
*intel_dp)
return max_dotclk;
 }

+static int
+intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates)
+{
+   if (intel_dp->num_sink_rates) {
+   *sink_rates = intel_dp->sink_rates;
+   return intel_dp->num_sink_rates;
+   }
+
+   *sink_rates = default_rates;
+
+   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
+}
+
+static int
+intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   int size;
+
+   if (IS_BROXTON(dev_priv)) {
+   *source_rates = bxt_rates;
+   size = ARRAY_SIZE(bxt_rates);
+   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
+   *source_rates = skl_rates;
+   size = ARRAY_SIZE(skl_rates);
+   } else {
+   *source_rates = default_rates;
+   size = ARRAY_SIZE(default_rates);
+   }
+
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (!intel_dp_source_supports_hbr2(intel_dp))
+   size--;
+
+   return size;
+}
+
+static int intersect_rates(const int *source_rates, int source_len,
+  const int *sink_rates, int sink_len,
+  int *common_rates)
+{
+   int i = 0, j = 0, k = 0;
+
+   while (i < source_len && j < sink_len) {
+   if (source_rates[i] == sink_rates[j]) {
+   if (WARN_ON(k >= DP_MAX_SUPPORTED_RATES))
+   return k;
+   common_rates[k] = source_rates[i];
+   ++k;
+   ++i;
+   ++j;
+   } else if (source_rates[i] < sink_rates[j]) {
+   ++i;
+   } else {
+   ++j;
+   }
+   }
+   return k;
+}
+
+static int intel_dp_common_rates(struct intel_dp *intel_dp,
+int *common_rates)
+{
+   const int *source_rates, *sink_rates;
+   int source_len, sink_len;
+
+   sink_len = intel_dp_sink_rates(intel_dp, _rates);
+   source_len = intel_dp_source_rates(intel_dp, _rates);
+
+   return intersect_rates(source_rates, source_len,
+  sink_rates, sink_len,
+  common_rates);
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1282,19 +1357,6 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
intel_dp->aux.transfer = intel_dp_aux_transfer;
 }

-static int
-intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates)
-{
-   if (intel_dp->num_sink_rates) {
-   *sink_rates = intel_dp->sink_rates;
-   return intel_dp->num_sink_rates;
-   }
-
-   *sink_rates = default_rates;
-
-   return (intel_dp_max_link_bw(intel_dp) >> 3) + 1;
-}
-
 bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -1307,31 +1369,6 @@ bool intel_dp_source_supports_hbr2(struct intel_dp 
*intel_dp)
return false;
 }

-static int
-intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates)
-{
-   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
-   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-   int size;
-
-   if (IS_BROXTON(dev_priv)) {
-   *source_rates = bxt_rates;
-   size = ARRAY_SIZE(bxt_rates);
-   } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
-   *source_rates = skl_rates;
-   size = ARRAY_SIZE(skl_rates);
-   } else {
-   *source_rates = default_rates;
-   size = ARRAY_SIZE(default_rates);
-   }
-
-   /* This depends on the fact that 5.4 is last value in the array */
-   if (!intel_dp_source_supports_hbr2(intel_dp))
-  

[PATCH RFC 3/8] drm: Trigger a complete modeset if link_train_retry is set

[Manasi Navare]

The link_train_retry property of the connector needs to be checked
to see if a full modeset is required. If this is set, then link train
retry is requested possibly due to linktrain failure in the previous
modeset. Hence we need to indicate connector status changed in order to
trigger a full modeset.

Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_atomic_helper.c | 9 +
 drivers/gpu/drm/drm_fb_helper.c | 3 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 07b432f..aeb2215 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -517,6 +517,15 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 */
ret = update_connector_routing(state, connector,
   connector_state);
+   /* Set crtc->mode_changed and crtc->connectors_changed if
+* link_train_retry flag is set in the connector.
+*/
+   if (connector->link_train_retry) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
connector->state->crtc);
+   crtc_state->connectors_changed = true;
+   crtc_state->mode_changed = true;
+   }
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8fffac8..b408e62 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2152,7 +2152,8 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper)
fb_crtc->desired_mode = mode;
fb_crtc->x = offset->x;
fb_crtc->y = offset->y;
-   if (modeset->mode)
+   if (modeset->mode &&
+   
!(fb_helper->connector_info[i]->connector->link_train_retry))
drm_mode_destroy(dev, modeset->mode);
modeset->mode = drm_mode_duplicate(dev,
   
fb_crtc->desired_mode);
-- 
1.9.1

[PATCH RFC 2/8] drm: Define a work struct for scheduling a uevent for modeset retry

[Manasi Navare]

This work struct will be used to schedule a uevent on a separate
thread. This will be scheduled after a link train failure during modeset
to indicate a modeset retry request. It will get executed after the
current modeset is complete and all locks are released. This was
required to avoid deadlock.

Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 

Signed-off-by: Manasi Navare 
---
 include/drm/drm_connector.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index d499466..9218a24 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -687,6 +687,11 @@ struct drm_connector {
 * in case of link train failure during current modeset
 */
bool link_train_retry;
+
+   /* Work struct to schedule a uevent on link train failure for
+* DisplayPort.
+*/
+   struct work_struct i915_modeset_retry_work;
 };

 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
-- 
1.9.1

[PATCH RFC 1/8] drm: Add a link_train_retry field to drm_connector

[Manasi Navare]

This is a boolean that is set to true if link training fails
during modeset in the atomic commit.
This will be used to detect a change in the connector properties
and to retrigger a full modeset so that the link can be retrained
at lower link rate value.

Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 

Signed-off-by: Manasi Navare 
---
 include/drm/drm_connector.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ac9d7d8..d499466 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -682,6 +682,11 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+   /* Flag to indicate if link train retry is required for DisplayPort
+* in case of link train failure during current modeset
+*/
+   bool link_train_retry;
 };

 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
-- 
1.9.1

[PATCH RFC 0/8] Hotplug Uevent on Link training failure on DP

[Manasi Navare]

These patches handle the DP link training failure during atomic modeset.
A new connector property is defined to indicate if link training retry
is requested on failure. If link training fails, we set this connector
property and send a hotplug uevent that gets exceuted after the current modeset
is completed an dlocks are released. The userspace is expected to monitor this
connector property to detect a change in connector and trigger a full modeset.
Here changes are made in fb_dev to monitor this property as well as the
atomic check modeset to use this new property to detect a change.
In the modeset retry, the modes are validated based on link rate lower than
the failed link rate and link is retrained at lower link rate.

Manasi Navare (7):
  drm: Add a link_train_retry field to drm_connector
  drm: Define a work struct for scheduling a uevent for modeset retry
  drm: Trigger a complete modeset if link_train_retry is set
  drm/i915; Add a function to return index of link rate
  drm/i915: Define the modeset retry work function
  drm/i915: Link Rate fallback on Link training failure
  drm/i915: Add support for DP link training compliance

Navare, Manasi D (1):
  drm/i915: Change the placement of some static functions in intel_dp.c

 drivers/gpu/drm/drm_atomic_helper.c   |   9 +
 drivers/gpu/drm/drm_fb_helper.c   |   3 +-
 drivers/gpu/drm/i915/intel_ddi.c  |  14 +-
 drivers/gpu/drm/i915/intel_dp.c   | 286 ++
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 +-
 drivers/gpu/drm/i915/intel_drv.h  |   8 +-
 include/drm/drm_connector.h   |  10 +
 7 files changed, 249 insertions(+), 93 deletions(-)

-- 
1.9.1

[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

[Archit Taneja]

On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> ARC PGU driver starts crashing on initialization after
> 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
> of "drm_i2c_encoder_driver" structure, which doesn't exist after
> adv7511 hdmi encoder interface changed from slave encoder to drm bridge.
> So, when we call "encoder_init" function from this structure driver
> crashes.
>
> Bootlog:
> ->8
> [drm] Initialized drm 1.1.0 20060810
> arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab
> arcpgu e0017000.pgu: assigned reserved memory node frame_buffer at 9e00
> Path: (null)
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.8.0-1-gb5642252fa01-dirty #8
> task: 9a058000 task.stack: 9a032000
>
> [ECR   ]: 0x00220100 => Invalid Read @ 0x0004 by insn @ 0x803934e8
> [EFA   ]: 0x0004
> [BLINK ]: drm_atomic_helper_connector_dpms+0xa6/0x230
> [ERET  ]: drm_atomic_helper_connector_dpms+0xa4/0x230
> [STAT32]: 0x0846 : K DE   E2 E1
> BTA: 0x8016d949  SP: 0x9a033e34  FP: 0x
> LPS: 0x8036f6fc LPE: 0x8036f700 LPC: 0x
> r00: 0x8063c118 r01: 0x805b98ac r02: 0x0b11
> r03: 0x r04: 0x9a010f54 r05: 0x
> r06: 0x0001 r07: 0x r08: 0x0028
> r09: 0x0001 r10: 0x0007 r11: 0x0054
> r12: 0x720a3033
>
> Stack Trace:
>   drm_atomic_helper_connector_dpms+0xa4/0x230
>   arcpgu_drm_hdmi_init+0xbc/0x228
>   arcpgu_probe+0x168/0x244
>   platform_drv_probe+0x26/0x64
>   really_probe+0x1f0/0x32c
>   __driver_attach+0xa8/0xd0
>   bus_for_each_dev+0x3c/0x74
>   bus_add_driver+0xc2/0x184
>   driver_register+0x50/0xec
>   do_one_initcall+0x3a/0x120
>   kernel_init_freeable+0x108/0x1a0
> ->8
>
> Fix ARC PGU driver to be able work with drm bridge hdmi encoder
> interface. The hdmi connector code isn't needed anymore as we expect
> the adv7511 bridge driver to create/manage the connector.

Looks good now.

Reviewed-by: Archit Taneja 

>
> Signed-off-by: Eugeniy Paltsev 
> ---
> Changes for v2:
>- remove bridge functions call from kms driver
>- get rid of drm_encoder_slave interface
>- coding style cleanup
>
>  drivers/gpu/drm/arc/arcpgu_hdmi.c | 159 
> --
>  1 file changed, 17 insertions(+), 142 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c 
> b/drivers/gpu/drm/arc/arcpgu_hdmi.c
> index b7a8b2a..b69c66b 100644
> --- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
> +++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
> @@ -14,170 +14,45 @@
>   *
>   */
>
> -#include 
> +#include 
>  #include 
> -#include 
>
>  #include "arcpgu.h"
>
> -struct arcpgu_drm_connector {
> - struct drm_connector connector;
> - struct drm_encoder_slave *encoder_slave;
> -};
> -
> -static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
> -{
> - const struct drm_encoder_slave_funcs *sfuncs;
> - struct drm_encoder_slave *slave;
> - struct arcpgu_drm_connector *con =
> - container_of(connector, struct arcpgu_drm_connector, connector);
> -
> - slave = con->encoder_slave;
> - if (slave == NULL) {
> - dev_err(connector->dev->dev,
> - "connector_get_modes: cannot find slave encoder for 
> connector\n");
> - return 0;
> - }
> -
> - sfuncs = slave->slave_funcs;
> - if (sfuncs->get_modes == NULL)
> - return 0;
> -
> - return sfuncs->get_modes(>base, connector);
> -}
> -
> -static enum drm_connector_status
> -arcpgu_drm_connector_detect(struct drm_connector *connector, bool force)
> -{
> - enum drm_connector_status status = connector_status_unknown;
> - const struct drm_encoder_slave_funcs *sfuncs;
> - struct drm_encoder_slave *slave;
> -
> - struct arcpgu_drm_connector *con =
> - container_of(connector, struct arcpgu_drm_connector, connector);
> -
> - slave = con->encoder_slave;
> - if (slave == NULL) {
> - dev_err(connector->dev->dev,
> - "connector_detect: cannot find slave encoder for 
> connector\n");
> - return status;
> - }
> -
> - sfuncs = slave->slave_funcs;
> - if (sfuncs && sfuncs->detect)
> - return sfuncs->detect(>base, connector);
> -
> - dev_err(connector->dev->dev, "connector_detect: could not detect slave 
> funcs\n");
> - return status;
> -}
> -
> -static void arcpgu_drm_connector_destroy(struct drm_connector *connector)
> -{
> - drm_connector_unregister(connector);
> - drm_connector_cleanup(connector);
> -}
> -
> -static const struct drm_connector_helper_funcs
> -arcpgu_drm_connector_helper_funcs = {
> - .get_modes = arcpgu_drm_connector_get_modes,
> -};
> -
> -static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
> - 

[PATCH] drm: Fix LSPCON kernel-doc

[Jani Nikula]

Fix warnings on building htmldocs.

Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Rodrigo Vivi 
Cc: Shashank Sharma 
Cc: 
Signed-off-by: Jani Nikula 

---

n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
been merged via drm-intel tree
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 14 +++---
 include/drm/drm_dp_dual_mode_helper.h | 15 ---
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index 2624e266abbd..488355bdafb9 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -377,9 +377,9 @@ EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);

 /**
  * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
- * by reading offset (0x80, 0x41)
- * @i2c_adapter: I2C-over-aux adapter
- * @current_mode: out vaiable, current lspcon mode of operation
+ * reading offset (0x80, 0x41)
+ * @adapter: I2C-over-aux adapter
+ * @mode: current lspcon mode of operation output variable
  *
  * Returns:
  * 0 on success, sets the current_mode value to appropriate mode
@@ -413,10 +413,10 @@ int drm_lspcon_get_mode(struct i2c_adapter *adapter,
 EXPORT_SYMBOL(drm_lspcon_get_mode);

 /**
- * drm_lspcon_change_mode: Change LSPCON's mode of operation by
- * by writing offset (0x80, 0x40)
- * @i2c_adapter: I2C-over-aux adapter
- * @reqd_mode: required mode of operation
+ * drm_lspcon_set_mode: Change LSPCON's mode of operation by
+ * writing offset (0x80, 0x40)
+ * @adapter: I2C-over-aux adapter
+ * @mode: required mode of operation
  *
  * Returns:
  * 0 on success, -error on failure/timeout
diff --git a/include/drm/drm_dp_dual_mode_helper.h 
b/include/drm/drm_dp_dual_mode_helper.h
index 55677704add8..1f04c5cfd402 100644
--- a/include/drm/drm_dp_dual_mode_helper.h
+++ b/include/drm/drm_dp_dual_mode_helper.h
@@ -70,12 +70,13 @@ ssize_t drm_dp_dual_mode_write(struct i2c_adapter *adapter,
   u8 offset, const void *buffer, size_t size);

 /**
-* enum drm_lspcon_mode
-* @lspcon_mode_ls: Level shifter mode of LSPCON
-*  which drives DP++ to HDMI 1.4 conversion.
-* @lspcon_mode_pcon: Protocol converter mode of LSPCON
-*  which drives DP++ to HDMI 2.0 active conversion.
-*/
+ * enum drm_lspcon_mode
+ * @DRM_LSPCON_MODE_INVALID: No LSPCON.
+ * @DRM_LSPCON_MODE_LS: Level shifter mode of LSPCON
+ * which drives DP++ to HDMI 1.4 conversion.
+ * @DRM_LSPCON_MODE_PCON: Protocol converter mode of LSPCON
+ * which drives DP++ to HDMI 2.0 active conversion.
+ */
 enum drm_lspcon_mode {
DRM_LSPCON_MODE_INVALID,
DRM_LSPCON_MODE_LS,
@@ -90,7 +91,7 @@ enum drm_lspcon_mode {
  * @DRM_DP_DUAL_MODE_TYPE1_HDMI: Type 1 HDMI adaptor
  * @DRM_DP_DUAL_MODE_TYPE2_DVI: Type 2 DVI adaptor
  * @DRM_DP_DUAL_MODE_TYPE2_HDMI: Type 2 HDMI adaptor
- * @DRM_DP_DUAL_MODE_TYPE2_LSPCON: Level shifter /protocol converter
+ * @DRM_DP_DUAL_MODE_LSPCON: Level shifter /protocol converter
  */
 enum drm_dp_dual_mode_type {
DRM_DP_DUAL_MODE_NONE,
-- 
2.1.4

[PATCH v2 5/9] of: Add vendor prefix for Netron DY

[Thierry Reding]

On Tue, Sep 06, 2016 at 04:46:16PM +0200, Maxime Ripard wrote:
> Netron DY is a brand of LCD panels found on SBCs and tablets.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Hi Rob,

care to give this your Acked-by?

Thanks,
Thierry

> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 1992aa97d45a..9c1ab3c1132b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -176,6 +176,7 @@ nec   NEC LCD Technologies, Ltd.
>  neonode  Neonode Inc.
>  netgear  NETGEAR
>  netlogic Broadcom Corporation (formerly NetLogic Microsystems)
> +netron-dyNetron DY
>  netxeon  Shenzhen Netxeon Technology CO., LTD
>  newhaven Newhaven Display International
>  nintendo Nintendo
> -- 
> 2.9.3
> 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/8e2680c2/attachment.sig>

[PATCH v4 1/1] drm/panel: simple: Add nvd9128 as a simple panel

[Thierry Reding]

On Mon, Oct 17, 2016 at 11:38:01AM +0200, Fabien Lahoudere wrote:
> Add New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
> 
> Signed-off-by: Fabien Lahoudere 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/display/panel/nvd,9128.txt |  7 ++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  3 files changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/nvd,9128.txt

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/1f6d7174/attachment.sig>

[PATCH v4] drm/panel: simple: Add support for AUO t215hvn01

[Thierry Reding]

On Tue, Oct 11, 2016 at 02:59:16PM -0700, Haixia Shi wrote:
> The AUO t215hvn01 is a 21.5" FHD (1920x1080) color TFT LCD panel.
> 
> This panel is used on the Acer Chromebase 21.5-inch All-in-One (DC221HQ).
> 
> Link to spec: http://www.udmgroup.com/ftp/T215HVN01.0.pdf
> 
> v2: fix alphabetical order
> v3: remove minor revision suffix ".0" and add link to spec
> v4: add dt-binding documentation
> 
> Signed-off-by: Haixia Shi 
> Tested-by: Haixia Shi 
> Reviewed-by: Stéphane Marchesin 
> Cc: Emil Velikov 
> Cc: Thierry Reding 
> Cc: David Airlie 
> Cc: Rob Herring <robh+dt at kernel.org>
> Cc: Mark Rutland 
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  .../bindings/display/panel/auo,t215hvn01.txt   |  7 +
>  drivers/gpu/drm/panel/panel-simple.c   | 30 
> ++
>  2 files changed, 37 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/auo,t215hvn01.txt

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/2255e529/attachment-0001.sig>

Unix Device Memory Allocation project

[Nicolai Hähnle]

On 19.10.2016 01:40, Marek Olšák wrote:
>   * We can build upon this idea. I think the worst thing to do would
> be to add metadata handling to driver-agnostic userspace APIs. Really,
> driver-agnostic APIs shouldn't know about that, because they can't
> understand all the hw-specific information encoded in the metadata.
> Also, when you want to change the metadata format, you only have to
> update the affected drivers, not userspace APIs.

I don't fully agree with that. In a PRIME setting, where you have a 
compositor running on an integrated GPU and an application on a dGPU, 
there may well be a benefit to finding a tiling format that the dGPU can 
produce and the iGPU can consume. Admittedly I don't know whether that's 
actually possible today when they're from different vendors, but 
resigning ourselves to linear only for all time seems a bit pessimistic.

Nicolai

[PATCH v4 2/2] drm/panel: simple: add support for Sharp LQ150X1LG11 panels

[Thierry Reding]

On Wed, Oct 19, 2016 at 02:27:50PM +0200, Thierry Reding wrote:
> On Tue, Oct 04, 2016 at 05:29:21PM +0200, Peter Rosin wrote:
> > From: Gustaf Lindström 
> > 
> > The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
> > 
> > The simple-panel driver is used to get support for essential
> > functionality of the panel.
> > 
> > Signed-off-by: Gustaf Lindström 
> > Signed-off-by: Peter Rosin 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 27 +++
> >  1 file changed, 27 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 85143d1b9b31..58cfe0a7a9d6 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1386,6 +1386,30 @@ static const struct panel_desc sharp_lq123p1jx31 = {
> > },
> >  };
> >  
> > +static const struct drm_display_mode sharp_lq150x1lg11_mode = {
> > +   .clock = 71100,
> > +   .hdisplay = 1024,
> > +   .hsync_start = 1024 + 168,
> > +   .hsync_end = 1024 + 168 + 64,
> > +   .htotal = 1024 + 168 + 64 + 88,
> > +   .vdisplay = 768,
> > +   .vsync_start = 768 + 37,
> > +   .vsync_end = 768 + 37 + 2,
> > +   .vtotal = 768 + 37 + 2 + 8,
> > +   .vrefresh = 60,
> > +};
> > +
> > +static const struct panel_desc sharp_lq150x1lg11 = {
> > +   .modes = _lq150x1lg11_mode,
> > +   .num_modes = 1,
> > +   .bpc = 8,
> > +   .size = {
> > +   .width = 304,
> > +   .height = 228,
> > +   },
> > +   .bus_format = MEDIA_BUS_FMT_RGB565_1X16,
> 
> This doesn't match the .bpc = 8 above. You'd usually use a .bpc = 6 for
> RGB565 panels.

Are you actually using the .bpc field in your driver? If yes, can you
please test if things work correctly if you set it to 6? If it's unused
I'm leaning towards just applying this with .bpc set to 6 and hope for
the best (and fix it if somebody finds that it's broken).

So no need to resend, just let me know what you think.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/59630dac/attachment.sig>

[PATCH v4 2/2] drm/panel: simple: add support for Sharp LQ150X1LG11 panels

[Thierry Reding]

On Tue, Oct 04, 2016 at 05:29:21PM +0200, Peter Rosin wrote:
> From: Gustaf Lindström 
> 
> The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
> 
> The simple-panel driver is used to get support for essential
> functionality of the panel.
> 
> Signed-off-by: Gustaf Lindström 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 85143d1b9b31..58cfe0a7a9d6 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1386,6 +1386,30 @@ static const struct panel_desc sharp_lq123p1jx31 = {
>   },
>  };
>  
> +static const struct drm_display_mode sharp_lq150x1lg11_mode = {
> + .clock = 71100,
> + .hdisplay = 1024,
> + .hsync_start = 1024 + 168,
> + .hsync_end = 1024 + 168 + 64,
> + .htotal = 1024 + 168 + 64 + 88,
> + .vdisplay = 768,
> + .vsync_start = 768 + 37,
> + .vsync_end = 768 + 37 + 2,
> + .vtotal = 768 + 37 + 2 + 8,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc sharp_lq150x1lg11 = {
> + .modes = _lq150x1lg11_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 304,
> + .height = 228,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB565_1X16,

This doesn't match the .bpc = 8 above. You'd usually use a .bpc = 6 for
RGB565 panels.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161019/d7f6d758/attachment.sig>

[Bug 178281] wine-staging apps freezes the machine with RX460

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=178281

--- Comment #8 from fin4478 at hotmail.com ---
I made my kernel slower by enabling debug and setting cpu timer from 300Hz to
250Hz. Now my desktop does not hang with TR 2013 and Heaven benchmarks although
Heaven hangs when using 8x antialising but I can kill that.

Amd should put their .config to public and highlight the following kernel
settings:
IRQ Quirks, Amdgpu PowerPlay, KVM, use a debug kernel and 250MHz timer.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Unix Device Memory Allocation project

[Christian König]

Am 19.10.2016 um 08:23 schrieb Daniel Vetter:
> On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák  wrote:
>> - The producer-consumer interop API doesn't know about the metadata.
>> All you need to pass around is a buffer handle. (KMS, DMABUF, etc.)
>>* There was a note during the talk that DMABUF doesn't have any
>> metadata. Well, I just told you that it has, but it's private to
>> amdgpu and possibly accessible to other kernel drivers too.
>>* We can build upon this idea. I think the worst thing to do would
>> be to add metadata handling to driver-agnostic userspace APIs. Really,
>> driver-agnostic APIs shouldn't know about that, because they can't
>> understand all the hw-specific information encoded in the metadata.
>> Also, when you want to change the metadata format, you only have to
>> update the affected drivers, not userspace APIs.
> That's a bit a surprise to hear, since "can't we just add a bit of
> opaque metadata to dma-buf" came up all the time over the past years,
> and died all the time again. dma-buf shouldn't imo be just yet another
> linux IPC mechanism and protocol, which is pretty much what you end up
> doing when you add this stuff. DRM runs all kinds of compositors with
> all kinds of existing userspace proto, and with reasonable ones like
> Wayland vendors can add whatever extensions they want. Plus there's
> all the interop with v4l and every other kernel subsytem. Trying to
> standardize that into some blob that works for everyone is imo nigh
> impossible.
>
> On top of that dma-buf is the wrong thing - you don't want this on
> buffers, but on surfaces. At least when it's time to reallocate. And
> oh dear I have seen what happens when soc vendors extend this design
> to cover that use-case, plus dynamic reallocation and all that. Imo
> there should be no way at all this ever comes close to dma-buf itself.
>
> And tbh I think it's a bit silly that amd snuck this in through
> amdgpu. But as long as you don't expect this to spread I guess it'll
> be fine.

Actually we didn't started to do it like this with amdgpu. Radeon works 
exactly the same way.

Additional to that there is a really good reason to do it like this: The 
kernel needs this information to program the CRTC for scanning out 
tilled surfaces as well.

So you either end up with additions to the mode setting call to 
transport all the device specific information about the data layout in 
the buffer or you attach this information directly to your buffer handle.

We choose the later and I think that this is a rather nice solution 
compared to all the headache you run into pushing this information 
through all the different protocols and APIs (DRI2,DRI3,Wayland,Modeset).

Regards,
Christian.

> -Daniel

[PATCH 1/2] drm: make is_lspcon_adaptor static

[Jani Nikula]

On Tue, 18 Oct 2016, "Sharma, Shashank"  wrote:
> Reviewed-by: Shashank Sharma

Both pushed to drm-intel-next-queued, thanks for the review.

RB,
Jani.

>
> Regards
> Shashank
> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, October 18, 2016 4:52 PM
> To: intel-gfx at lists.freedesktop.org
> Cc: Nikula, Jani ; Vivi, Rodrigo  intel.com>; Sharma, Shashank ; dri-devel at 
> lists.freedesktop.org
> Subject: [PATCH 1/2] drm: make is_lspcon_adaptor static
>
> Fixes sparse warning:
>
> drivers/gpu/drm/drm_dp_dual_mode_helper.c:151:6: warning: symbol 
> 'is_lspcon_adaptor' was not declared. Should it be static?
>
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Rodrigo Vivi 
> Cc: Shashank Sharma 
> Cc: 
> Signed-off-by: Jani Nikula 
>
> ---
>
> n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has been 
> merged via drm-intel tree
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index a7aeb1ec852c..2624e266abbd 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -148,8 +148,8 @@ static bool is_type2_adaptor(uint8_t adaptor_id)
> DP_DUAL_MODE_REV_TYPE2);
>  }
>  
> -bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
> - const uint8_t adaptor_id)
> +static bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
> +   const uint8_t adaptor_id)
>  {
>   return is_hdmi_adaptor(hdmi_id) &&
>   (adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
> --
> 2.1.4
>

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm: fix sparse warnings on undeclared symbols in crc debugfs

[Jani Nikula]

On Tue, 18 Oct 2016, Chris Wilson  wrote:
> On Tue, Oct 18, 2016 at 02:28:35PM +0300, Jani Nikula wrote:
>> Fixes sparse warnings:
>> 
>> drivers/gpu/drm/drm_debugfs_crc.c:118:30: warning: symbol
>> 'drm_crtc_crc_control_fops' was not declared. Should it be static?
>> 
>> drivers/gpu/drm/drm_debugfs_crc.c:264:30: warning: symbol
>> 'drm_crtc_crc_data_fops' was not declared. Should it be static?
>> 
>> drivers/gpu/drm/drm_debugfs_crc.c:281:5: warning: symbol
>> 'drm_debugfs_crtc_crc_add' was not declared. Should it be static?
>> 
>> Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs")
>> Cc: Benjamin Gaignard 
>> Cc: Daniel Vetter 
>> Cc: Emil Velikov 
>> Cc: Tomeu Vizoso 
>> Signed-off-by: Jani Nikula 
> Reviewed-by: Chris Wilson 

Pushed to drm-misc, thanks for the review.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/amd/powerplay: don't give up if DPM is already running

[Zhu, Rex]

Hi Gražvydas,

Sorry for so late response.

I can reproduce this issue in gpu passthrough case.

When we forced power off the VM or forced reset the VM without shutting down 
the Os, the rmmod will not be called. So dpm was still running.

If we skipped the enable dpm tasks, some clock tables were not be initialized, 
so kernel panic when we visited those tables in set power state.

I will send the fix patch for review tomorrow.

Thanks.

Best Regards
Rex

-Original Message-
From: Grazvydas Ignotas [mailto:nota...@gmail.com] 
Sent: Sunday, October 16, 2016 2:55 AM
To: Zhu, Rex
Cc: Alex Deucher; amd-gfx list; Maling list - DRI developers
Subject: Re: [PATCH] drm/amd/powerplay: don't give up if DPM is already running

Hi,

On Thu, Oct 13, 2016 at 10:45 AM, Zhu, Rex  wrote:
>
> The attached patches were also for this issue.
> Disable dpm when rmmod amdgpu.

It works for modprobe-rmmod-modprobe test, thanks.

However with GPU passthrough (giving control of the GPU to a Windows virtual 
machine using iommu, then shutting down the VM and loading
amdgpu) the problem is still there, same backtrace as in my commit message. It 
seems the Windows driver leaves DPM enabled on shutdown.
With my patch the crash goes away.

It would be nice to have GPU passthrough working, this is the only issue that 
breaks it. Windows can drive the GPU after amdgpu fine already, only amdgpu has 
problems to run after Windows.

Gražvydas

[PATCH 10/10] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates

[Ville Syrjälä]

On Wed, Oct 19, 2016 at 12:21:17PM +0200, Philipp Zabel wrote:
> Use drm_plane_helper_check_state to clip raw user coordinates to crtc
> bounds. This checks for full plane coverage and scaling already, so
> we can drop some custom checks. Use the clipped coordinates everywhere.
> 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 78 
> ++-
>  1 file changed, 36 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 6a97e396..f0ce899 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -70,8 +70,8 @@ drm_plane_state_to_eba(struct drm_plane_state *state)
>  {
>   struct drm_framebuffer *fb = state->fb;
>   struct drm_gem_cma_object *cma_obj;
> - int x = state->src_x >> 16;
> - int y = state->src_y >> 16;
> + int x = state->src.x1 >> 16;
> + int y = state->src.y1 >> 16;
>  
>   cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
>   BUG_ON(!cma_obj);
> @@ -86,8 +86,8 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
>   struct drm_framebuffer *fb = state->fb;
>   struct drm_gem_cma_object *cma_obj;
>   unsigned long eba = drm_plane_state_to_eba(state);
> - int x = state->src_x >> 16;
> - int y = state->src_y >> 16;
> + int x = state->src.x1 >> 16;
> + int y = state->src.y1 >> 16;
>  
>   cma_obj = drm_fb_cma_get_gem_obj(fb, 1);
>   BUG_ON(!cma_obj);
> @@ -105,8 +105,8 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
>   struct drm_framebuffer *fb = state->fb;
>   struct drm_gem_cma_object *cma_obj;
>   unsigned long eba = drm_plane_state_to_eba(state);
> - int x = state->src_x >> 16;
> - int y = state->src_y >> 16;
> + int x = state->src.x1 >> 16;
> + int y = state->src.y1 >> 16;
>  
>   cma_obj = drm_fb_cma_get_gem_obj(fb, 2);
>   BUG_ON(!cma_obj);
> @@ -218,7 +218,10 @@ static int ipu_plane_atomic_check(struct drm_plane 
> *plane,
>   struct drm_framebuffer *fb = state->fb;
>   struct drm_framebuffer *old_fb = old_state->fb;
>   unsigned long eba, ubo, vbo, old_ubo, old_vbo;
> + bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
> + struct drm_rect clip;
>   int hsub, vsub;
> + int ret;
>  
>   /* Ok to disable */
>   if (!fb)
> @@ -232,44 +235,35 @@ static int ipu_plane_atomic_check(struct drm_plane 
> *plane,
>   if (WARN_ON(!crtc_state))
>   return -EINVAL;
>  
> + clip.x1 = 0;
> + clip.y1 = 0;
> + clip.x2 = crtc_state->adjusted_mode.hdisplay;
> + clip.y2 = crtc_state->adjusted_mode.vdisplay;
> + ret = drm_plane_helper_check_state(state, ,
> +DRM_PLANE_HELPER_NO_SCALING,
> +DRM_PLANE_HELPER_NO_SCALING,
> +can_position, true);
> + if (ret)
> + return ret;
> +
>   /* CRTC should be enabled */
>   if (!crtc_state->enable)
>   return -EINVAL;
>  
> - /* no scaling */
> - if (state->src_w >> 16 != state->crtc_w ||
> - state->src_h >> 16 != state->crtc_h)
> - return -EINVAL;
> -
>   switch (plane->type) {
>   case DRM_PLANE_TYPE_PRIMARY:
> - /* full plane doesn't support partial off screen */
> - if (state->crtc_x || state->crtc_y ||
> - state->crtc_w != crtc_state->adjusted_mode.hdisplay ||
> - state->crtc_h != crtc_state->adjusted_mode.vdisplay)
> - return -EINVAL;
> -
>   /* full plane minimum width is 13 pixels */
> - if (state->crtc_w < 13)
> + if (drm_rect_width(>dst) < 13)
>   return -EINVAL;
>   break;
>   case DRM_PLANE_TYPE_OVERLAY:
> - if (state->crtc_x < 0 || state->crtc_y < 0)
> - return -EINVAL;
> -
> - if (state->crtc_x + state->crtc_w >
> - crtc_state->adjusted_mode.hdisplay)
> - return -EINVAL;
> - if (state->crtc_y + state->crtc_h >
> - crtc_state->adjusted_mode.vdisplay)
> - return -EINVAL;
>   break;
>   default:
> - dev_warn(dev, "Unsupported plane type\n");
> + dev_warn(dev, "Unsupported plane type %d\n", plane->type);
>   return -EINVAL;
>   }
>  
> - if (state->crtc_h < 2)
> + if (drm_rect_height(>dst) < 2)
>   return -EINVAL;
>  
>   /*
> @@ -279,9 +273,8 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
>* callback.  The planes will be reenabled in plane's ->atomic_update
>* callback.
>*/
> - if (old_fb && (state->src_w != old_state->src_w ||
> -   state->src_h != old_state->src_h ||
> - 

[Bug 178281] wine-staging apps freezes the machine with RX460

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=178281

--- Comment #7 from fin4478 at hotmail.com ---
There is just boot traces in dmesg, journalctl and Xorg.0.log when my computer
desktop hangs and checking with ssh.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 10/10] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates

[Philipp Zabel]

Am Mittwoch, den 19.10.2016, 13:31 +0300 schrieb Ville Syrjälä:
> On Wed, Oct 19, 2016 at 12:21:17PM +0200, Philipp Zabel wrote:
> > Use drm_plane_helper_check_state to clip raw user coordinates to crtc
> > bounds. This checks for full plane coverage and scaling already, so
> > we can drop some custom checks. Use the clipped coordinates everywhere.
> > 
> > Suggested-by: Ville Syrjälä 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/gpu/drm/imx/ipuv3-plane.c | 78 
> > ++-
> >  1 file changed, 36 insertions(+), 42 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> > b/drivers/gpu/drm/imx/ipuv3-plane.c
> > index 6a97e396..f0ce899 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> > @@ -70,8 +70,8 @@ drm_plane_state_to_eba(struct drm_plane_state *state)
> >  {
> > struct drm_framebuffer *fb = state->fb;
> > struct drm_gem_cma_object *cma_obj;
> > -   int x = state->src_x >> 16;
> > -   int y = state->src_y >> 16;
> > +   int x = state->src.x1 >> 16;
> > +   int y = state->src.y1 >> 16;
> >  
> > cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
> > BUG_ON(!cma_obj);
> > @@ -86,8 +86,8 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
> > struct drm_framebuffer *fb = state->fb;
> > struct drm_gem_cma_object *cma_obj;
> > unsigned long eba = drm_plane_state_to_eba(state);
> > -   int x = state->src_x >> 16;
> > -   int y = state->src_y >> 16;
> > +   int x = state->src.x1 >> 16;
> > +   int y = state->src.y1 >> 16;
> >  
> > cma_obj = drm_fb_cma_get_gem_obj(fb, 1);
> > BUG_ON(!cma_obj);
> > @@ -105,8 +105,8 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
> > struct drm_framebuffer *fb = state->fb;
> > struct drm_gem_cma_object *cma_obj;
> > unsigned long eba = drm_plane_state_to_eba(state);
> > -   int x = state->src_x >> 16;
> > -   int y = state->src_y >> 16;
> > +   int x = state->src.x1 >> 16;
> > +   int y = state->src.y1 >> 16;
> >  
> > cma_obj = drm_fb_cma_get_gem_obj(fb, 2);
> > BUG_ON(!cma_obj);
> > @@ -218,7 +218,10 @@ static int ipu_plane_atomic_check(struct drm_plane 
> > *plane,
> > struct drm_framebuffer *fb = state->fb;
> > struct drm_framebuffer *old_fb = old_state->fb;
> > unsigned long eba, ubo, vbo, old_ubo, old_vbo;
> > +   bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
> > +   struct drm_rect clip;
> > int hsub, vsub;
> > +   int ret;
> >  
> > /* Ok to disable */
> > if (!fb)
> > @@ -232,44 +235,35 @@ static int ipu_plane_atomic_check(struct drm_plane 
> > *plane,
> > if (WARN_ON(!crtc_state))
> > return -EINVAL;
> >  
> > +   clip.x1 = 0;
> > +   clip.y1 = 0;
> > +   clip.x2 = crtc_state->adjusted_mode.hdisplay;
> > +   clip.y2 = crtc_state->adjusted_mode.vdisplay;
> > +   ret = drm_plane_helper_check_state(state, ,
> > +  DRM_PLANE_HELPER_NO_SCALING,
> > +  DRM_PLANE_HELPER_NO_SCALING,
> > +  can_position, true);
> > +   if (ret)
> > +   return ret;
> > +
> > /* CRTC should be enabled */
> > if (!crtc_state->enable)
> > return -EINVAL;
> >  
> > -   /* no scaling */
> > -   if (state->src_w >> 16 != state->crtc_w ||
> > -   state->src_h >> 16 != state->crtc_h)
> > -   return -EINVAL;
> > -
> > switch (plane->type) {
> > case DRM_PLANE_TYPE_PRIMARY:
> > -   /* full plane doesn't support partial off screen */
> > -   if (state->crtc_x || state->crtc_y ||
> > -   state->crtc_w != crtc_state->adjusted_mode.hdisplay ||
> > -   state->crtc_h != crtc_state->adjusted_mode.vdisplay)
> > -   return -EINVAL;
> > -
> > /* full plane minimum width is 13 pixels */
> > -   if (state->crtc_w < 13)
> > +   if (drm_rect_width(>dst) < 13)
> > return -EINVAL;
> > break;
> > case DRM_PLANE_TYPE_OVERLAY:
> > -   if (state->crtc_x < 0 || state->crtc_y < 0)
> > -   return -EINVAL;
> > -
> > -   if (state->crtc_x + state->crtc_w >
> > -   crtc_state->adjusted_mode.hdisplay)
> > -   return -EINVAL;
> > -   if (state->crtc_y + state->crtc_h >
> > -   crtc_state->adjusted_mode.vdisplay)
> > -   return -EINVAL;
> > break;
> > default:
> > -   dev_warn(dev, "Unsupported plane type\n");
> > +   dev_warn(dev, "Unsupported plane type %d\n", plane->type);
> > return -EINVAL;
> > }
> >  
> > -   if (state->crtc_h < 2)
> > +   if (drm_rect_height(>dst) < 2)
> > return -EINVAL;
> >  
> > /*
> > @@ -279,9 +273,8 @@ static int ipu_plane_atomic_check(struct drm_plane 
> > *plane,
> >  * callback.  The planes will be reenabled in plane's ->atomic_update
> >  * 

mm: fix cache mode tracking in vm_insert_mixed() breaks AMDGPU [was: Re: Latest testing with drm-next-4.9-wip and latest LLVM/mesa stack - Regression in PowerPlay/DPM on CIK?]

[Marek Olšák]

On Wed, Oct 19, 2016 at 8:42 AM, Dave Airlie  wrote:
> On 18 October 2016 at 23:53, Dan Williams  wrote:
>> On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie  wrote:
>> [..]
> Aren't there only 2 possibilities for this regression?
>
> 1/ a memtype entry was never made so track_pfn_insert() returns an
> uncached mapping
>
> 2/ a conflicting memtype entry exists and undefined behavior due to
> mixed mapping types is avoided with the change.

 3/ The CPU usage through this path goes up, and slows things down,
 though I suspect you it's more an uncached mapping showing up
 when we don't expect it.
>>>
>>> It's looking line number 1, there is no mapping, now we get uncached
>>> where we used to get write through.
>>>
>>> difference in page prot 7f7bbc0e, pfn 200e71e4,
>>> 8037, 802f
>>>
>>> 0x2f is the vma pg prot which has PWT set in it, 0x37 is the returned
>>> pgprot which lacks that bit.
>>>
>>> not sure where to go from here, suggestions?
>>
>> If the driver established an ioremap_wt() across the range, or just
>> called reserve_memtype() directly that should restore WT mappings.
>>
>> Although Daniel's suggestion to use the i915 mapping helpers sounds
>> like it avoids problem 3/ as well.
>
> Well we shouldn't be doing that many VRAM mappings on the CPU so
> I doubt we'll hit the overheads here that often.
>
> Ideally we'd always use DMA to move stuff in/out of VRAM, but there
> are some places where we still do WC VRAM writes for uploads.

WC VRAM for uploads is better than WC GART IMO.

Marek

[PATCH 10/10] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates

[Philipp Zabel]

Use drm_plane_helper_check_state to clip raw user coordinates to crtc
bounds. This checks for full plane coverage and scaling already, so
we can drop some custom checks. Use the clipped coordinates everywhere.

Suggested-by: Ville Syrjälä 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 78 ++-
 1 file changed, 36 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 6a97e396..f0ce899 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -70,8 +70,8 @@ drm_plane_state_to_eba(struct drm_plane_state *state)
 {
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
-   int x = state->src_x >> 16;
-   int y = state->src_y >> 16;
+   int x = state->src.x1 >> 16;
+   int y = state->src.y1 >> 16;

cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
BUG_ON(!cma_obj);
@@ -86,8 +86,8 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
unsigned long eba = drm_plane_state_to_eba(state);
-   int x = state->src_x >> 16;
-   int y = state->src_y >> 16;
+   int x = state->src.x1 >> 16;
+   int y = state->src.y1 >> 16;

cma_obj = drm_fb_cma_get_gem_obj(fb, 1);
BUG_ON(!cma_obj);
@@ -105,8 +105,8 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
unsigned long eba = drm_plane_state_to_eba(state);
-   int x = state->src_x >> 16;
-   int y = state->src_y >> 16;
+   int x = state->src.x1 >> 16;
+   int y = state->src.y1 >> 16;

cma_obj = drm_fb_cma_get_gem_obj(fb, 2);
BUG_ON(!cma_obj);
@@ -218,7 +218,10 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
struct drm_framebuffer *fb = state->fb;
struct drm_framebuffer *old_fb = old_state->fb;
unsigned long eba, ubo, vbo, old_ubo, old_vbo;
+   bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
+   struct drm_rect clip;
int hsub, vsub;
+   int ret;

/* Ok to disable */
if (!fb)
@@ -232,44 +235,35 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (WARN_ON(!crtc_state))
return -EINVAL;

+   clip.x1 = 0;
+   clip.y1 = 0;
+   clip.x2 = crtc_state->adjusted_mode.hdisplay;
+   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   ret = drm_plane_helper_check_state(state, ,
+  DRM_PLANE_HELPER_NO_SCALING,
+  DRM_PLANE_HELPER_NO_SCALING,
+  can_position, true);
+   if (ret)
+   return ret;
+
/* CRTC should be enabled */
if (!crtc_state->enable)
return -EINVAL;

-   /* no scaling */
-   if (state->src_w >> 16 != state->crtc_w ||
-   state->src_h >> 16 != state->crtc_h)
-   return -EINVAL;
-
switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
-   /* full plane doesn't support partial off screen */
-   if (state->crtc_x || state->crtc_y ||
-   state->crtc_w != crtc_state->adjusted_mode.hdisplay ||
-   state->crtc_h != crtc_state->adjusted_mode.vdisplay)
-   return -EINVAL;
-
/* full plane minimum width is 13 pixels */
-   if (state->crtc_w < 13)
+   if (drm_rect_width(>dst) < 13)
return -EINVAL;
break;
case DRM_PLANE_TYPE_OVERLAY:
-   if (state->crtc_x < 0 || state->crtc_y < 0)
-   return -EINVAL;
-
-   if (state->crtc_x + state->crtc_w >
-   crtc_state->adjusted_mode.hdisplay)
-   return -EINVAL;
-   if (state->crtc_y + state->crtc_h >
-   crtc_state->adjusted_mode.vdisplay)
-   return -EINVAL;
break;
default:
-   dev_warn(dev, "Unsupported plane type\n");
+   dev_warn(dev, "Unsupported plane type %d\n", plane->type);
return -EINVAL;
}

-   if (state->crtc_h < 2)
+   if (drm_rect_height(>dst) < 2)
return -EINVAL;

/*
@@ -279,9 +273,8 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
 * callback.  The planes will be reenabled in plane's ->atomic_update
 * callback.
 */
-   if (old_fb && (state->src_w != old_state->src_w ||
- state->src_h != old_state->src_h ||
- fb->pixel_format != old_fb->pixel_format))
+   if (old_fb && (!drm_rect_equals(>dst, _state->dst) ||
+

[PATCH 09/10] gpu: ipu-v3: initially clear all interrupts

[Philipp Zabel]

If we want to stop resetting the IPU in the future, masking all
interrupts before registering the irq handlers will not be enough to
avoid spurious interrupts. We also have to clear them.

Signed-off-by: Philipp Zabel 
Acked-by: Liu Ying 
---
 drivers/gpu/ipu-v3/ipu-common.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index b7d7bd6..97218af 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1286,8 +1286,11 @@ static int ipu_irq_init(struct ipu_soc *ipu)
return ret;
}

-   for (i = 0; i < IPU_NUM_IRQS; i += 32)
+   /* Mask and clear all interrupts */
+   for (i = 0; i < IPU_NUM_IRQS; i += 32) {
ipu_cm_write(ipu, 0, IPU_INT_CTRL(i / 32));
+   ipu_cm_write(ipu, ~unused[i / 32], IPU_INT_STAT(i / 32));
+   }

for (i = 0; i < IPU_NUM_IRQS; i += 32) {
gc = irq_get_domain_generic_chip(ipu->domain, i);
-- 
2.9.3

[PATCH 08/10] drm/imx: ipuv3-plane: add support for YUV 4:2:2 and 4:4:4, NV12, and NV16 formats

[Philipp Zabel]

Hook up support for DRM_FORMAT_YUV422, DRM_FORMAT_YVU422,
DRM_FORMAT_YUV444, DRM_FORMAT_YVU444, DRM_FORMAT_NV12,
and DRM_FORMAT_NV16.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Make UBO/VBO swap for YVU formats more obvious in ipu_plane_atomic_update
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 60 ++-
 1 file changed, 47 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 52784cb..6a97e396 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -50,6 +50,12 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_YUV420,
DRM_FORMAT_YVU420,
+   DRM_FORMAT_YUV422,
+   DRM_FORMAT_YVU422,
+   DRM_FORMAT_YUV444,
+   DRM_FORMAT_YVU444,
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_NV16,
DRM_FORMAT_RGB565,
 };

@@ -292,6 +298,10 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
switch (fb->pixel_format) {
case DRM_FORMAT_YUV420:
case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV422:
+   case DRM_FORMAT_YVU422:
+   case DRM_FORMAT_YUV444:
+   case DRM_FORMAT_YVU444:
/*
 * Multiplanar formats have to meet the following restrictions:
 * - The (up to) three plane addresses are EBA, EBA+UBO, EBA+VBO
@@ -300,25 +310,34 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
 * - Only EBA may be changed while scanout is active
 * - The strides of U and V planes must be identical.
 */
-   ubo = drm_plane_state_to_ubo(state);
vbo = drm_plane_state_to_vbo(state);

-   if ((ubo & 0x7) || (vbo & 0x7))
-   return -EINVAL;
-
-   if ((ubo > 0xf8) || (vbo > 0xf8))
+   if (vbo & 0x7 || vbo > 0xf8)
return -EINVAL;

if (old_fb && (fb->pixel_format == old_fb->pixel_format)) {
-   old_ubo = drm_plane_state_to_ubo(old_state);
old_vbo = drm_plane_state_to_vbo(old_state);
-   if (ubo != old_ubo || vbo != old_vbo)
+   if (vbo != old_vbo)
crtc_state->mode_changed = true;
}

if (fb->pitches[1] != fb->pitches[2])
return -EINVAL;

+   /* fall-through */
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV16:
+   ubo = drm_plane_state_to_ubo(state);
+
+   if (ubo & 0x7 || ubo > 0xf8)
+   return -EINVAL;
+
+   if (old_fb && (fb->pixel_format == old_fb->pixel_format)) {
+   old_ubo = drm_plane_state_to_ubo(old_state);
+   if (ubo != old_ubo)
+   crtc_state->mode_changed = true;
+   }
+
if (fb->pitches[1] < 1 || fb->pitches[1] > 16384)
return -EINVAL;

@@ -409,20 +428,35 @@ static void ipu_plane_atomic_update(struct drm_plane 
*plane,
switch (fb->pixel_format) {
case DRM_FORMAT_YUV420:
case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV422:
+   case DRM_FORMAT_YVU422:
+   case DRM_FORMAT_YUV444:
+   case DRM_FORMAT_YVU444:
ubo = drm_plane_state_to_ubo(state);
vbo = drm_plane_state_to_vbo(state);
+   if (fb->pixel_format == DRM_FORMAT_YVU420 ||
+   fb->pixel_format == DRM_FORMAT_YVU422 ||
+   fb->pixel_format == DRM_FORMAT_YVU444)
+   swap(ubo, vbo);

-   if (fb->pixel_format == DRM_FORMAT_YUV420)
-   ipu_cpmem_set_yuv_planar_full(ipu_plane->ipu_ch,
- fb->pitches[1], ubo, vbo);
-   else
-   ipu_cpmem_set_yuv_planar_full(ipu_plane->ipu_ch,
- fb->pitches[1], vbo, ubo);
+   ipu_cpmem_set_yuv_planar_full(ipu_plane->ipu_ch,
+ fb->pitches[1], ubo, vbo);

dev_dbg(ipu_plane->base.dev->dev,
"phy = %lu %lu %lu, x = %d, y = %d", eba, ubo, vbo,
state->src_x >> 16, state->src_y >> 16);
break;
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV16:
+   ubo = drm_plane_state_to_ubo(state);
+
+   ipu_cpmem_set_yuv_planar_full(ipu_plane->ipu_ch,
+ fb->pitches[1], ubo, ubo);
+
+   dev_dbg(ipu_plane->base.dev->dev,
+   "phy = %lu %lu, x = %d, y = %d", eba, ubo,
+   state->src_x >> 16, state->src_y >> 16);
+   break;
default:

[PATCH 07/10] gpu: ipu-v3: add YUV 4:4:4 support

[Philipp Zabel]

The IDMAC does support reading and writing DRM_FORMAT_YUV444 and
DRM_FORMAT_YVU444.

Signed-off-by: Philipp Zabel 
Acked-by: Liu Ying 
---
Changes since v1:
 - Drop change to ipu_cpmem_set_yuv_planar, which has been removed
---
 drivers/gpu/ipu-v3/ipu-common.c | 2 ++
 drivers/gpu/ipu-v3/ipu-cpmem.c  | 7 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index b9539f7..b7d7bd6 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -88,6 +88,8 @@ enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 
drm_fourcc)
case DRM_FORMAT_YVU420:
case DRM_FORMAT_YUV422:
case DRM_FORMAT_YVU422:
+   case DRM_FORMAT_YUV444:
+   case DRM_FORMAT_YVU444:
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV21:
case DRM_FORMAT_NV16:
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index f3ca1d6..4b2b671 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -554,6 +554,13 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
drm_fourcc)
/* burst size */
ipu_ch_param_write_field(ch, IPU_FIELD_NPB, 31);
break;
+   case DRM_FORMAT_YUV444:
+   case DRM_FORMAT_YVU444:
+   /* pix format */
+   ipu_ch_param_write_field(ch, IPU_FIELD_PFS, 0);
+   /* burst size */
+   ipu_ch_param_write_field(ch, IPU_FIELD_NPB, 31);
+   break;
case DRM_FORMAT_NV12:
/* pix format */
ipu_ch_param_write_field(ch, IPU_FIELD_PFS, 4);
-- 
2.9.3

[PATCH 06/10] gpu: ipu-cpmem: remove unused ipu_cpmem_set_yuv_planar function

[Philipp Zabel]

ipu_cpmem_set_yuv_planar_full is only used directly, remove the wrapper.

Suggested-by: Liu Ying 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-cpmem.c | 36 
 include/video/imx-ipu-v3.h |  2 --
 2 files changed, 38 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index fcb7dc8..f3ca1d6 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -417,42 +417,6 @@ void ipu_cpmem_set_yuv_planar_full(struct ipuv3_channel 
*ch,
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_yuv_planar_full);

-void ipu_cpmem_set_yuv_planar(struct ipuv3_channel *ch,
- u32 pixel_format, int stride, int height)
-{
-   int fourcc, u_offset, v_offset;
-   int uv_stride = 0;
-
-   fourcc = v4l2_pix_fmt_to_drm_fourcc(pixel_format);
-   switch (fourcc) {
-   case DRM_FORMAT_YUV420:
-   uv_stride = stride / 2;
-   u_offset = stride * height;
-   v_offset = u_offset + (uv_stride * height / 2);
-   break;
-   case DRM_FORMAT_YVU420:
-   uv_stride = stride / 2;
-   v_offset = stride * height;
-   u_offset = v_offset + (uv_stride * height / 2);
-   break;
-   case DRM_FORMAT_YUV422:
-   uv_stride = stride / 2;
-   u_offset = stride * height;
-   v_offset = u_offset + (uv_stride * height);
-   break;
-   case DRM_FORMAT_NV12:
-   case DRM_FORMAT_NV16:
-   uv_stride = stride;
-   u_offset = stride * height;
-   v_offset = 0;
-   break;
-   default:
-   return;
-   }
-   ipu_cpmem_set_yuv_planar_full(ch, uv_stride, u_offset, v_offset);
-}
-EXPORT_SYMBOL_GPL(ipu_cpmem_set_yuv_planar);
-
 static const struct ipu_rgb def_xrgb_32 = {
.red= { .offset = 16, .length = 8, },
.green  = { .offset =  8, .length = 8, },
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 173073e..cc8174c 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -247,8 +247,6 @@ void ipu_cpmem_set_yuv_planar_full(struct ipuv3_channel *ch,
   unsigned int uv_stride,
   unsigned int u_offset,
   unsigned int v_offset);
-void ipu_cpmem_set_yuv_planar(struct ipuv3_channel *ch,
- u32 pixel_format, int stride, int height);
 int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 drm_fourcc);
 int ipu_cpmem_set_image(struct ipuv3_channel *ch, struct ipu_image *image);
 void ipu_cpmem_dump(struct ipuv3_channel *ch);
-- 
2.9.3

[PATCH 05/10] drm/imx: ipuv3-plane: let drm_plane_state_to_ubo/vbo handle chroma subsampling other than 4:2:0

[Philipp Zabel]

To support 4:2:2 or 4:4:4 chroma subsampling, divide the x/y offsets in
drm_plane_state_to_ubo/vbo only if necessary for the given pixel format.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 32871be..52784cb 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -64,13 +64,14 @@ drm_plane_state_to_eba(struct drm_plane_state *state)
 {
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
+   int x = state->src_x >> 16;
+   int y = state->src_y >> 16;

cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
BUG_ON(!cma_obj);

-   return cma_obj->paddr + fb->offsets[0] +
-  fb->pitches[0] * (state->src_y >> 16) +
-  (fb->bits_per_pixel >> 3) * (state->src_x >> 16);
+   return cma_obj->paddr + fb->offsets[0] + fb->pitches[0] * y +
+  drm_format_plane_cpp(fb->pixel_format, 0) * x;
 }

 static inline unsigned long
@@ -79,13 +80,17 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
unsigned long eba = drm_plane_state_to_eba(state);
+   int x = state->src_x >> 16;
+   int y = state->src_y >> 16;

cma_obj = drm_fb_cma_get_gem_obj(fb, 1);
BUG_ON(!cma_obj);

-   return cma_obj->paddr + fb->offsets[1] +
-  fb->pitches[1] * (state->src_y >> 16) / 2 +
-  (state->src_x >> 16) / 2 - eba;
+   x /= drm_format_horz_chroma_subsampling(fb->pixel_format);
+   y /= drm_format_vert_chroma_subsampling(fb->pixel_format);
+
+   return cma_obj->paddr + fb->offsets[1] + fb->pitches[1] * y +
+  drm_format_plane_cpp(fb->pixel_format, 1) * x - eba;
 }

 static inline unsigned long
@@ -94,13 +99,17 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
unsigned long eba = drm_plane_state_to_eba(state);
+   int x = state->src_x >> 16;
+   int y = state->src_y >> 16;

cma_obj = drm_fb_cma_get_gem_obj(fb, 2);
BUG_ON(!cma_obj);

-   return cma_obj->paddr + fb->offsets[2] +
-  fb->pitches[2] * (state->src_y >> 16) / 2 +
-  (state->src_x >> 16) / 2 - eba;
+   x /= drm_format_horz_chroma_subsampling(fb->pixel_format);
+   y /= drm_format_vert_chroma_subsampling(fb->pixel_format);
+
+   return cma_obj->paddr + fb->offsets[2] + fb->pitches[2] * y +
+  drm_format_plane_cpp(fb->pixel_format, 2) * x - eba;
 }

 void ipu_plane_put_resources(struct ipu_plane *ipu_plane)
-- 
2.9.3