[PATCH] tty: vt: Fix soft lockup in fbcon cursor blink timer.

[Pavel Machek]

On Tue 2016-05-17 11:41:04, David Daney wrote:
> From: David Daney 
> 
> We are getting somewhat random soft lockups with this signature:
> 
> [   86.992215] [] el1_irq+0xa0/0x10c
> [   86.997082] [] cursor_timer_handler+0x30/0x54
> [   87.002991] [] call_timer_fn+0x54/0x1a8
> [   87.008378] [] run_timer_softirq+0x1c4/0x2bc
> [   87.014200] [] __do_softirq+0x114/0x344
> [   87.019590] [] irq_exit+0x74/0x98
> [   87.024458] [] __handle_domain_irq+0x98/0xfc
> [   87.030278] [] gic_handle_irq+0x94/0x190
> 
> This is caused by the vt visual_init() function calling into
> fbcon_init() with a vc_cur_blink_ms value of zero.  This is a
> transient condition, as it is later set to a non-zero value.  But, if
> the timer happens to expire while the blink rate is zero, it goes into
> an endless loop, and we get soft lockup.
> 
> The fix is to initialize vc_cur_blink_ms before calling the con_init()
> function.
> 
> Signed-off-by: David Daney 
> Cc: stable at vger.kernel.org

Acked-by: Pavel Machek 

(And it is amazing how many problems configurable blink speed caused).

Thanks!
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH v7 1/3] create SMAF module

[Emil Velikov]

On 17 May 2016 at 22:29, Daniel Vetter  wrote:

> Please don't use __kernel_size_t, it's only for backwards compat if you
> already botched an ioctl definition ;-)
>
That explains why I've not seen it in (m)any other UAPI headers but
our legacy ones.

Thank you !
Emil

[PATCH v7 1/3] create SMAF module

[Emil Velikov]

On 17 May 2016 at 14:50, Benjamin Gaignard  
wrote:
> Hello Emil,
>
> thanks for your review.
> I have understand most of your remarks and I'm fixing them
> but some points aren't obvious for me...
>
Sure thing. Thanks for being honest.

>
> No because a device could attach itself on the buffer and the
> allocator will only
> be selected at the first map_attach call.
> The goal is to delay the allocation until all devices are attached to
> select the best allocator.
>
I see. Makes sense.


>>> +static long smaf_ioctl(struct file *file, unsigned int cmd, unsigned long 
>>> arg)
>>> +{
>>> +   switch (cmd) {
>>> +   case SMAF_IOC_CREATE:
>>> +   {
>>> +   struct smaf_create_data data;
>>> +   struct smaf_handle *handle;
>>> +
>>> +   if (copy_from_user(, (void __user *)arg, 
>>> _IOC_SIZE(cmd)))
>>> +   return -EFAULT;
>>> +
>>> +   handle = smaf_create_handle(data.length, data.flags);
>> We want to sanitise the input data.{length,flags} before sending it
>> deeper in the kernel.
>
> Sorry but can you elaborate little more here ?
> I don't understand your expectations.
>
You want to determine which flags are 'considered useful' at this
stage, and reject anything else. As-is you inject any flags that the
user gives you directly into the 'guts' of the kernel. This is not
good from security and future expandability POV.

About the length you want a similar thing. size_t is unsigned (great),
although ideally you'll want to check/determine if one cannot exploit
it, integer overflow being the more common suspect. This may be quite
hard to track, so I'd stick with the flags checking at least.


> It is useless the add this function in this .h file I will remove it
> and fix the comment in structure defintion

I've seen both approaches - description next to the declaration or
definition. I'd rather not pick sides, as people might throw rotten
fruit at me ;-)


>>> +/**
>>> + * struct smaf_create_data - allocation parameters
>>> + * @length:size of the allocation
>>> + * @flags: flags passed to allocator
>>> + * @name:  name of the allocator to be selected, could be NULL
Just occurred to - you might want to comment what the user should
expect if NULL. Any at random one will be used or otherwise. Very
quick description on the heuristics used might be good as well.

>> Is it guaranteed to be null terminated ? If so one should mentioned it
>> otherwise your userspace should be fixed.
>> Same comments apply for smaf_info::name.
>
> I have used strncpy everywhere to avoid this problem but maybe it is not 
> enough
>
According to the man page

"The strncpy() function is similar, except that at most n bytes of src
are copied.  Warning: If there is no null byte among the first n bytes
of src, the string placed in dest will _not_ be null-terminated."

Annotation is mine obviously. I believe that after the strncpy 'name'
is/was assumed (used as) a NULL terminated string.

>>
>>
>>> + * @fd:returned file descriptor
>>> + */
>>> +struct smaf_create_data {
>>> +   size_t length;
>>> +   unsigned int flags;
>>> +   char name[ALLOCATOR_NAME_LENGTH];
>>> +   int fd;
>> The structs here feels quite fragile. Please read up on Daniel
>> Vetter's "Botching up ioctls" [1]. Personally I find pahole quite
>> useful is such process.
>>
> if I describe the structures like this:
> /**
>  * struct smaf_create_data - allocation parameters
>  * @length: size of the allocation
>  * @flags: flags passed to allocator
>  * @name_len: length of name
>  * @name: name of the allocator to be selected, could be NULL
>  * @fd: returned file descriptor
>  */
> struct smaf_create_data {
> size_t length;
> unsigned int flags;
> size_t name_len;
> char __user *name;
> int fd;
> char padding[44];
> };
>
> does it sound more robust for you ?
>
Seems like you changed 'name' from fixed size array to char *. Which
actually gets us slightly further away from robust.

As Daniel said, please read through the hole file.

Here is a (slightly incomplete) gist of it all:
- you want to to use __[us]{8,16,32,64} and __kernel_size_t types everywhere
- each member of the struct must be the same offset for both 32bit and
64bit builds. ^^ helps with that
- double check for gaps in the struct - I think you have a few
- each struct should have it's old 'flags' which you'll use to
indicate the capability of the ioctl and thus the size of struct used.
i.e. it's for future use.

Obviously the other two structs need similar polish.

Here is how you can check things with pahole:
 - Create a simple C file that includes the header and has an instance
of each struct - it doesn't have to be use any of them.
 - Compile for 32 and 64 bit with -g -O0. Compare the struct layout -
it should be identical in both cases.

Hope that makes things a bit clearer.

Emil

[PATCH] drm/tegra: Fix crash caused by reference count imbalance

[Daniel Vetter]

On Tue, May 17, 2016 at 7:29 PM, Jon Hunter  wrote:
>>> @@ -764,6 +769,9 @@ tegra_dsi_connector_duplicate_state(struct 
>>> drm_connector *connector)
>>>  if (!copy)
>>>  return NULL;
>>>
>>> +if (copy->base.crtc)
>>> +drm_connector_reference(connector);
>>> +
>>
>> Please use __drm_atomic_helper_connector_duplicate_state instead of
>> open-coding it.
>
> Unfortunately, tegra is allocating and duplicating memory for the entire
> tegra_dsi_state structure (of which drm_connector_state is a member) in
> this function and so I was not able to do that. However, may be Thierry
> can comment on whether that is completely necessary and if we can move
> to using __drm_atomic_helper_connector_duplicate_state() instead.

Check out how other drivers are using this helper - it is explicitly
for the case where you duplicate the entire struct, and it just
initializes the core part from drm. You can then add your own fixup
code afterwards. It also doesn't matter whether you do kmalloc or
kcalloc or kmemdup - it does a memcpy of its own to make sure state
gets copied.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

Ok as promised heres the patches to do some function interface refactoring
across the tree. I've double check and run gcc on x86 and arm, but please
also check that nothing crept in meanwhile before pushing out the merge.

Otherwise a few more misc patches, plus the 2 duct-tape patches for dp mst
backporting from Lyude.

Note that I spotted one tegra patch in-flight which will conflict, I asked
for that to be rebased already.

Cheers, Daniel


The following changes since commit 99ee87295017e36abb6925e6139ca303cb55aee7:

  Merge tag 'topic/drm-misc-2016-05-13' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-05-17 07:06:14 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-05-17

for you to fetch changes up to 255f0e7c418ad95a4baeda017ae6182ba9b3c423:

  drm/fb_helper: Fix references to dev->mode_config.num_connector (2016-05-17 
15:44:41 +0200)


Chris Wilson (1):
  drm: Remove unused drm_device from drm_gem_object_lookup()

Dan Carpenter (1):
  drm/exynos/hdmi: add a missing tab

Daniel Vetter (3):
  drm: Drop crtc argument from __drm_atomic_helper_crtc_destroy_state
  drm: Drop plane argument from __drm_atomic_helper_plane_destroy_state
  drm: Drop connector argument from 
__drm_atomic_helper_connector_destroy_state

Gerd Hoffmann (1):
  qxl: catch qxlfb_create_pinned_object failures

Lyude (2):
  drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()
  drm/fb_helper: Fix references to dev->mode_config.num_connector

Noralf Trønnes (2):
  drm/fb-cma-helper: Use const for drm_framebuffer_funcs argument
  drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  3 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 10 +++
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  2 +-
 drivers/gpu/drm/armada/armada_crtc.c   |  2 +-
 drivers/gpu/drm/armada/armada_fb.c |  2 +-
 drivers/gpu/drm/armada/armada_gem.c|  6 ++---
 drivers/gpu/drm/armada/armada_gem.h|  4 +--
 drivers/gpu/drm/ast/ast_main.c |  4 +--
 drivers/gpu/drm/ast/ast_mode.c |  2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c   |  4 +--
 drivers/gpu/drm/cirrus/cirrus_main.c   |  4 +--
 drivers/gpu/drm/drm_atomic_helper.c| 25 +++--
 drivers/gpu/drm/drm_fb_cma_helper.c| 37 +++---
 drivers/gpu/drm/drm_fb_helper.c|  5 ++--
 drivers/gpu/drm/drm_gem.c  | 14 +++---
 drivers/gpu/drm/drm_gem_cma_helper.c   |  2 +-
 drivers/gpu/drm/drm_prime.c|  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  8 +++---
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  3 +--
 drivers/gpu/drm/exynos/exynos_drm_gem.c| 10 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |  2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  2 +-
 drivers/gpu/drm/gma500/framebuffer.c   |  2 +-
 drivers/gpu/drm/gma500/gem.c   |  2 +-
 drivers/gpu/drm/gma500/gma_display.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem.c| 22 +++
 drivers/gpu/drm/i915/i915_gem_tiling.c |  4 +--
 drivers/gpu/drm/i915/intel_display.c   |  7 +++--
 drivers/gpu/drm/i915/intel_fbdev.c |  6 ++---
 drivers/gpu/drm/i915/intel_overlay.c   |  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c   |  2 +-
 drivers/gpu/drm/mgag200/mgag200_cursor.c   |  2 +-
 drivers/gpu/drm/mgag200/mgag200_main.c |  4 +--
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c   |  2 +-
 drivers/gpu/drm/msm/msm_drv.c  |  6 ++---
 drivers/gpu/drm/msm/msm_fb.c   |  3 +--
 drivers/gpu/drm/msm/msm_gem.c  |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_display.c  |  4 +--
 drivers/gpu/drm/nouveau/nouveau_gem.c  |  8 +++---
 drivers/gpu/drm/nouveau/nv50_display.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c |  6 ++---
 drivers/gpu/drm/omapdrm/omap_drv.h |  4 +--
 drivers/gpu/drm/omapdrm/omap_fb.c  |  2 +-
 drivers/gpu/drm/omapdrm/omap_gem.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c   |  2 +-
 drivers/gpu/drm/qxl/qxl_display.c  |  6 +++--
 drivers/gpu/drm/qxl/qxl_dumb.c |  2 +-

[PATCH] drm/tegra: Fix crash caused by reference count imbalance

[Daniel Vetter]

On Tue, May 17, 2016 at 05:27:15PM +0100, Jon Hunter wrote:
> Commit d2307dea14a4 ("drm/atomic: use connector references (v3)") added
> reference counting for DRM connectors and this caused a crash when
> exercising system suspend on Tegra114 Dalmore.
> 
> The Tegra DSI driver implements a Tegra specific function,
> tegra_dsi_connector_duplicate_state(), to duplicate the connector state
> and destroys the state using the generic helper function,
> drm_atomic_helper_connector_destroy_state(). Following commit
> d2307dea14a4 ("drm/atomic: use connector references (v3)") there is
> now an imbalance in the connector reference count because the Tegra
> function to duplicate state does not take a reference when duplicating
> the state information. However, the generic helper function to destroy
> the state information assumes a reference has been taken and during
> system suspend, when the connector state is destroyed, this leads to a
> crash because we attempt to put the reference for an object that has
> already been freed.
> 
> Fix this by aligning tegra_dsi_connector_duplicate_state() with commit
> d2307dea14a4 ("drm/atomic: use connector references (v3)"), so that we
> take a reference on a connector if crtc is set.
> 
> By fixing tegra_dsi_connector_duplicate_state() to take a reference,
> although a crash was no longer seen, it was then observed that after
> each system suspend-resume cycle, the reference would be one greater
> than before the suspend-resume cycle. Following commit d2307dea14a4
> ("drm/atomic: use connector references (v3)"), it was found that we
> also need to put the reference when calling the function
> tegra_dsi_connector_reset() before freeing the state. Fix this by
> updating tegra_dsi_connector_reset() to call the function
> __drm_atomic_helper_connector_destroy_state() in order to put the
> reference for the connector.
> 
> Finally, add a warning if allocating memory for the state information
> fails in tegra_dsi_connector_reset().
> 
> Fixes: d2307dea14a4 ("drm/atomic: use connector references (v3)")
> 
> Signed-off-by: Jon Hunter 
> ---
>  drivers/gpu/drm/tegra/dsi.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
> index 44e102799195..68aaa4c33cd8 100644
> --- a/drivers/gpu/drm/tegra/dsi.c
> +++ b/drivers/gpu/drm/tegra/dsi.c
> @@ -745,13 +745,18 @@ static void tegra_dsi_soft_reset(struct tegra_dsi *dsi)
>  
>  static void tegra_dsi_connector_reset(struct drm_connector *connector)
>  {
> - struct tegra_dsi_state *state =
> - kzalloc(sizeof(*state), GFP_KERNEL);
> + struct tegra_dsi_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
>  
> - if (state) {
> + if (WARN_ON(!state))
> + return;
> +
> + if (connector->state) {
> + __drm_atomic_helper_connector_destroy_state(connector,
> + connector->state);
>   kfree(connector->state);
> - __drm_atomic_helper_connector_reset(connector, >base);
>   }
> +
> + __drm_atomic_helper_connector_reset(connector, >base);

Please rebase onto drm-misc or linux-next, I've removed the connector
argument from __drm_atomic_helper_connector_destroy_state(). I'll send the
pull request for that later today to Dave.

>  }
>  
>  static struct drm_connector_state *
> @@ -764,6 +769,9 @@ tegra_dsi_connector_duplicate_state(struct drm_connector 
> *connector)
>   if (!copy)
>   return NULL;
>  
> + if (copy->base.crtc)
> + drm_connector_reference(connector);
> +

Please use __drm_atomic_helper_connector_duplicate_state instead of
open-coding it.

Cheers, Daniel

>   return >base;
>  }
>  
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/tegra: Fix crash caused by reference count imbalance

[Jon Hunter]

On 17/05/16 17:46, Daniel Vetter wrote:
> On Tue, May 17, 2016 at 05:27:15PM +0100, Jon Hunter wrote:
>> Commit d2307dea14a4 ("drm/atomic: use connector references (v3)") added
>> reference counting for DRM connectors and this caused a crash when
>> exercising system suspend on Tegra114 Dalmore.
>>
>> The Tegra DSI driver implements a Tegra specific function,
>> tegra_dsi_connector_duplicate_state(), to duplicate the connector state
>> and destroys the state using the generic helper function,
>> drm_atomic_helper_connector_destroy_state(). Following commit
>> d2307dea14a4 ("drm/atomic: use connector references (v3)") there is
>> now an imbalance in the connector reference count because the Tegra
>> function to duplicate state does not take a reference when duplicating
>> the state information. However, the generic helper function to destroy
>> the state information assumes a reference has been taken and during
>> system suspend, when the connector state is destroyed, this leads to a
>> crash because we attempt to put the reference for an object that has
>> already been freed.
>>
>> Fix this by aligning tegra_dsi_connector_duplicate_state() with commit
>> d2307dea14a4 ("drm/atomic: use connector references (v3)"), so that we
>> take a reference on a connector if crtc is set.
>>
>> By fixing tegra_dsi_connector_duplicate_state() to take a reference,
>> although a crash was no longer seen, it was then observed that after
>> each system suspend-resume cycle, the reference would be one greater
>> than before the suspend-resume cycle. Following commit d2307dea14a4
>> ("drm/atomic: use connector references (v3)"), it was found that we
>> also need to put the reference when calling the function
>> tegra_dsi_connector_reset() before freeing the state. Fix this by
>> updating tegra_dsi_connector_reset() to call the function
>> __drm_atomic_helper_connector_destroy_state() in order to put the
>> reference for the connector.
>>
>> Finally, add a warning if allocating memory for the state information
>> fails in tegra_dsi_connector_reset().
>>
>> Fixes: d2307dea14a4 ("drm/atomic: use connector references (v3)")
>>
>> Signed-off-by: Jon Hunter 
>> ---
>>  drivers/gpu/drm/tegra/dsi.c | 16 
>>  1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
>> index 44e102799195..68aaa4c33cd8 100644
>> --- a/drivers/gpu/drm/tegra/dsi.c
>> +++ b/drivers/gpu/drm/tegra/dsi.c
>> @@ -745,13 +745,18 @@ static void tegra_dsi_soft_reset(struct tegra_dsi *dsi)
>>  
>>  static void tegra_dsi_connector_reset(struct drm_connector *connector)
>>  {
>> -struct tegra_dsi_state *state =
>> -kzalloc(sizeof(*state), GFP_KERNEL);
>> +struct tegra_dsi_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
>>  
>> -if (state) {
>> +if (WARN_ON(!state))
>> +return;
>> +
>> +if (connector->state) {
>> +__drm_atomic_helper_connector_destroy_state(connector,
>> +connector->state);
>>  kfree(connector->state);
>> -__drm_atomic_helper_connector_reset(connector, >base);
>>  }
>> +
>> +__drm_atomic_helper_connector_reset(connector, >base);
> 
> Please rebase onto drm-misc or linux-next, I've removed the connector
> argument from __drm_atomic_helper_connector_destroy_state(). I'll send the
> pull request for that later today to Dave.

OK. This is based upon next-20160516 and so I will update to today's.

>>  }
>>  
>>  static struct drm_connector_state *
>> @@ -764,6 +769,9 @@ tegra_dsi_connector_duplicate_state(struct drm_connector 
>> *connector)
>>  if (!copy)
>>  return NULL;
>>  
>> +if (copy->base.crtc)
>> +drm_connector_reference(connector);
>> +
> 
> Please use __drm_atomic_helper_connector_duplicate_state instead of
> open-coding it.

Unfortunately, tegra is allocating and duplicating memory for the entire
tegra_dsi_state structure (of which drm_connector_state is a member) in
this function and so I was not able to do that. However, may be Thierry
can comment on whether that is completely necessary and if we can move
to using __drm_atomic_helper_connector_duplicate_state() instead.

Cheers
Jon

-- 
nvpublic

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Ville Syrjälä]

On Tue, May 17, 2016 at 03:19:20PM +0200, Daniel Vetter wrote:
> On Tue, May 17, 2016 at 3:14 PM, Ville Syrjälä
>  wrote:
> > On Tue, May 17, 2016 at 03:04:52PM +0200, Daniel Vetter wrote:
> >> On Tue, May 17, 2016 at 02:22:26PM +0200, Noralf Trønnes wrote:
> >> >
> >> >
> >> > Den 17.05.2016 14:12, skrev Ville Syrjälä:
> >> > >On Tue, May 17, 2016 at 02:00:45PM +0200, Noralf Trønnes wrote:
> >> > >>Den 17.05.2016 09:59, skrev Daniel Vetter:
> >> > >>>On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
> >> > On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
> >> > >On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
> >> > >>On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> >> > >>>Provides helper functions for drivers that have a simple display
> >> > >>>pipeline. Plane, crtc and encoder are collapsed into one entity.
> >> > >>>
> >> > >>>Cc: jsarha at ti.com
> >> > >>>Signed-off-by: Noralf Trønnes 
> >> > >>>---
> >> > >>>
> >> > >>>Changes since v3:
> >> > >>>- (struct drm_simple_display_pipe *)->funcs should be const
> >> > >>>
> >> > >>>Changes since v2:
> >> > >>>- Drop Kconfig knob DRM_KMS_HELPER
> >> > >>>- Expand documentation
> >> > >>>
> >> > >>>Changes since v1:
> >> > >>>- Add DOC header and add to gpu.tmpl
> >> > >>>- Fix docs: @funcs is optional, "negative error code",
> >> > >>>"This hook is optional."
> >> > >>>- Add checks to drm_simple_kms_plane_atomic_check()
> >> > >>>
> >> > >>>   Documentation/DocBook/gpu.tmpl  |   6 +
> >> > >>>   drivers/gpu/drm/Makefile|   2 +-
> >> > >>>   drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> >> > >>> 
> >> > >>>   include/drm/drm_simple_kms_helper.h |  94 +++
> >> > >>>   4 files changed, 309 insertions(+), 1 deletion(-)
> >> > >>>   create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
> >> > >>>   create mode 100644 include/drm/drm_simple_kms_helper.h
> >> > >>>
> >> > >>>diff --git a/Documentation/DocBook/gpu.tmpl 
> >> > >>>b/Documentation/DocBook/gpu.tmpl
> >> > >>>index 4a0c599..cf3f5a8 100644
> >> > >>>--- a/Documentation/DocBook/gpu.tmpl
> >> > >>>+++ b/Documentation/DocBook/gpu.tmpl
> >> > >>>@@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
> >> > >>>   !Edrivers/gpu/drm/drm_panel.c
> >> > >>>   !Pdrivers/gpu/drm/drm_panel.c drm panel
> >> > >>>   
> >> > >>>+
> >> > >>>+  Simple KMS Helper Reference
> >> > >>>+!Iinclude/drm/drm_simple_kms_helper.h
> >> > >>>+!Edrivers/gpu/drm/drm_simple_kms_helper.c
> >> > >>>+!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> >> > >>>+
> >> > >>> 
> >> > >>>
> >> > >>> 
> >> > >>>diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> >> > >>>index 2bd3e5a..31b85df5 100644
> >> > >>>--- a/drivers/gpu/drm/Makefile
> >> > >>>+++ b/drivers/gpu/drm/Makefile
> >> > >>>@@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> >> > >>>
> >> > >>>   drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> >> > >>> drm_probe_helper.o \
> >> > >>> drm_plane_helper.o drm_dp_mst_topology.o 
> >> > >>> drm_atomic_helper.o \
> >> > >>>-drm_kms_helper_common.o
> >> > >>>+drm_kms_helper_common.o drm_simple_kms_helper.o
> >> > >>>
> >> > >>>   drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
> >> > >>> drm_edid_load.o
> >> > >>>   drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> >> > >>>diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> >> > >>>b/drivers/gpu/drm/drm_simple_kms_helper.c
> >> > >>>new file mode 100644
> >> > >>>index 000..d45417a
> >> > >>>--- /dev/null
> >> > >>>+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> >> > >>>@@ -0,0 +1,208 @@
> >> > >>>+/*
> >> > >>>+ * Copyright (C) 2016 Noralf Trønnes
> >> > >>>+ *
> >> > >>>+ * 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 
> >> > >>>+
> >> > >>>+/**
> >> > >>>+ * DOC: overview
> >> > >>>+ *
> >> > >>>+ * This helper library provides helpers for drivers for simple 
> >> > >>>display
> >> > >>>+ * hardware.
> >> > >>>+ *
> >> > >>>+ * drm_simple_display_pipe_init() 

[PATCH v7 1/3] create SMAF module

[Daniel Vetter]

On Tue, May 17, 2016 at 03:50:41PM +0200, Benjamin Gaignard wrote:
> 2016-05-17 0:58 GMT+02:00 Emil Velikov :
> > On 9 May 2016 at 16:07, Benjamin Gaignard  
> > wrote:
> >> + * @fd:returned file descriptor
> >> + */
> >> +struct smaf_create_data {
> >> +   size_t length;
> >> +   unsigned int flags;
> >> +   char name[ALLOCATOR_NAME_LENGTH];
> >> +   int fd;
> > The structs here feels quite fragile. Please read up on Daniel
> > Vetter's "Botching up ioctls" [1]. Personally I find pahole quite
> > useful is such process.
> >
> if I describe the structures like this:
> /**
>  * struct smaf_create_data - allocation parameters
>  * @length: size of the allocation
>  * @flags: flags passed to allocator
>  * @name_len: length of name
>  * @name: name of the allocator to be selected, could be NULL
>  * @fd: returned file descriptor
>  */
> struct smaf_create_data {
> size_t length;
> unsigned int flags;
> size_t name_len;
> char __user *name;
> int fd;
> char padding[44];
> };
> 
> does it sound more robust for you ?
> 
> > Hopefully I haven't lost the plot with the above, if I had don't be
> > shy to point out.
> >
> > Thanks,
> > Emil
> >
> > [1] 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt

Please read this doc in it's entirety, ask on irc if you don't get certain
parts. Then come back an rework your patch.

Super short summary: _All_ the types you've used are absolute no-go in
ioctl structs.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/tegra: Fix crash caused by reference count imbalance

[Jon Hunter]

Commit d2307dea14a4 ("drm/atomic: use connector references (v3)") added
reference counting for DRM connectors and this caused a crash when
exercising system suspend on Tegra114 Dalmore.

The Tegra DSI driver implements a Tegra specific function,
tegra_dsi_connector_duplicate_state(), to duplicate the connector state
and destroys the state using the generic helper function,
drm_atomic_helper_connector_destroy_state(). Following commit
d2307dea14a4 ("drm/atomic: use connector references (v3)") there is
now an imbalance in the connector reference count because the Tegra
function to duplicate state does not take a reference when duplicating
the state information. However, the generic helper function to destroy
the state information assumes a reference has been taken and during
system suspend, when the connector state is destroyed, this leads to a
crash because we attempt to put the reference for an object that has
already been freed.

Fix this by aligning tegra_dsi_connector_duplicate_state() with commit
d2307dea14a4 ("drm/atomic: use connector references (v3)"), so that we
take a reference on a connector if crtc is set.

By fixing tegra_dsi_connector_duplicate_state() to take a reference,
although a crash was no longer seen, it was then observed that after
each system suspend-resume cycle, the reference would be one greater
than before the suspend-resume cycle. Following commit d2307dea14a4
("drm/atomic: use connector references (v3)"), it was found that we
also need to put the reference when calling the function
tegra_dsi_connector_reset() before freeing the state. Fix this by
updating tegra_dsi_connector_reset() to call the function
__drm_atomic_helper_connector_destroy_state() in order to put the
reference for the connector.

Finally, add a warning if allocating memory for the state information
fails in tegra_dsi_connector_reset().

Fixes: d2307dea14a4 ("drm/atomic: use connector references (v3)")

Signed-off-by: Jon Hunter 
---
 drivers/gpu/drm/tegra/dsi.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 44e102799195..68aaa4c33cd8 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -745,13 +745,18 @@ static void tegra_dsi_soft_reset(struct tegra_dsi *dsi)

 static void tegra_dsi_connector_reset(struct drm_connector *connector)
 {
-   struct tegra_dsi_state *state =
-   kzalloc(sizeof(*state), GFP_KERNEL);
+   struct tegra_dsi_state *state = kzalloc(sizeof(*state), GFP_KERNEL);

-   if (state) {
+   if (WARN_ON(!state))
+   return;
+
+   if (connector->state) {
+   __drm_atomic_helper_connector_destroy_state(connector,
+   connector->state);
kfree(connector->state);
-   __drm_atomic_helper_connector_reset(connector, >base);
}
+
+   __drm_atomic_helper_connector_reset(connector, >base);
 }

 static struct drm_connector_state *
@@ -764,6 +769,9 @@ tegra_dsi_connector_duplicate_state(struct drm_connector 
*connector)
if (!copy)
return NULL;

+   if (copy->base.crtc)
+   drm_connector_reference(connector);
+
return >base;
 }

-- 
2.1.4

[PATCH v2] drm/imx: use bus_flags for pixel clock polarity

[Philipp Zabel]

This patch allows panels to set pixel clock and data enable pin polarity
other than the default of driving data at the falling pixel clock edge
and active high display enable.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Invert polarity - driving pixel data on the falling edge and sampling
   it at the rising edge is the default.
 - Rename imx_drm_set_bus_format_pins to imx_drm_set_bus_config as now,
   additionally to bus format and pins, it also sets polarities.
---
 drivers/gpu/drm/imx/imx-drm-core.c | 13 -
 drivers/gpu/drm/imx/imx-drm.h  |  7 ---
 drivers/gpu/drm/imx/imx-tve.c  |  6 --
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 10 +++---
 drivers/gpu/drm/imx/parallel-display.c |  4 ++--
 5 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index e26dcde..1da77fd 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -96,8 +96,8 @@ static struct imx_drm_crtc *imx_drm_find_crtc(struct drm_crtc 
*crtc)
return NULL;
 }

-int imx_drm_set_bus_format_pins(struct drm_encoder *encoder, u32 bus_format,
-   int hsync_pin, int vsync_pin)
+int imx_drm_set_bus_config(struct drm_encoder *encoder, u32 bus_format,
+   int hsync_pin, int vsync_pin, u32 bus_flags)
 {
struct imx_drm_crtc_helper_funcs *helper;
struct imx_drm_crtc *imx_crtc;
@@ -109,14 +109,17 @@ int imx_drm_set_bus_format_pins(struct drm_encoder 
*encoder, u32 bus_format,
helper = _crtc->imx_drm_helper_funcs;
if (helper->set_interface_pix_fmt)
return helper->set_interface_pix_fmt(encoder->crtc,
-   bus_format, hsync_pin, vsync_pin);
+   bus_format, hsync_pin, vsync_pin,
+   bus_flags);
return 0;
 }
-EXPORT_SYMBOL_GPL(imx_drm_set_bus_format_pins);
+EXPORT_SYMBOL_GPL(imx_drm_set_bus_config);

 int imx_drm_set_bus_format(struct drm_encoder *encoder, u32 bus_format)
 {
-   return imx_drm_set_bus_format_pins(encoder, bus_format, 2, 3);
+   return imx_drm_set_bus_config(encoder, bus_format, 2, 3,
+ DRM_BUS_FLAG_DE_HIGH |
+ DRM_BUS_FLAG_PIXDATA_NEGEDGE);
 }
 EXPORT_SYMBOL_GPL(imx_drm_set_bus_format);

diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index b0241b9..74320a1 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -19,7 +19,8 @@ struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
int (*set_interface_pix_fmt)(struct drm_crtc *crtc,
-   u32 bus_format, int hsync_pin, int vsync_pin);
+   u32 bus_format, int hsync_pin, int vsync_pin,
+   u32 bus_flags);
const struct drm_crtc_helper_funcs *crtc_helper_funcs;
const struct drm_crtc_funcs *crtc_funcs;
 };
@@ -41,8 +42,8 @@ void imx_drm_mode_config_init(struct drm_device *drm);

 struct drm_gem_cma_object *imx_drm_fb_get_obj(struct drm_framebuffer *fb);

-int imx_drm_set_bus_format_pins(struct drm_encoder *encoder,
-   u32 bus_format, int hsync_pin, int vsync_pin);
+int imx_drm_set_bus_config(struct drm_encoder *encoder, u32 bus_format,
+   int hsync_pin, int vsync_pin, u32 bus_flags);
 int imx_drm_set_bus_format(struct drm_encoder *encoder,
u32 bus_format);

diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index ae7a9fb..baf7881 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -294,8 +294,10 @@ static void imx_tve_encoder_prepare(struct drm_encoder 
*encoder)

switch (tve->mode) {
case TVE_MODE_VGA:
-   imx_drm_set_bus_format_pins(encoder, MEDIA_BUS_FMT_GBR888_1X24,
-   tve->hsync_pin, tve->vsync_pin);
+   imx_drm_set_bus_config(encoder, MEDIA_BUS_FMT_GBR888_1X24,
+  tve->hsync_pin, tve->vsync_pin,
+  DRM_BUS_FLAG_DE_HIGH |
+  DRM_BUS_FLAG_PIXDATA_NEGEDGE);
break;
case TVE_MODE_TVOUT:
imx_drm_set_bus_format(encoder, MEDIA_BUS_FMT_YUV8_1X24);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index dee8e8b..438e6c4 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -66,6 +66,7 @@ struct ipu_crtc {
struct ipu_flip_work*flip_work;
int irq;
u32 bus_format;
+   u32 bus_flags;
int di_hsync_pin;
int di_vsync_pin;
 };

[PATCH v7 3/3] SMAF: add fake secure module

[Benjamin Gaignard]

2016-05-17 1:10 GMT+02:00 Emil Velikov :
> Hi Benjamin,
>
> On 9 May 2016 at 16:07, Benjamin Gaignard  
> wrote:
>> This module is allow testing secure calls of SMAF.
>>
> "Add fake secure module" does sound like something not (m)any people
> want to hear ;-)
> Have you considered calling it 'dummy', 'test' or similar ?

"test" is better name, I will change to that

>
>
>> --- /dev/null
>> +++ b/drivers/smaf/smaf-fakesecure.c
>> @@ -0,0 +1,85 @@
>> +/*
>> + * smaf-fakesecure.c
>> + *
>> + * Copyright (C) Linaro SA 2015
>> + * Author: Benjamin Gaignard  for Linaro.
>> + * License terms:  GNU General Public License (GPL), version 2
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MAGIC 0xDEADBEEF
>> +
>> +struct fake_private {
>> +   int magic;
>> +};
>> +
>> +static void *smaf_fakesecure_create(void)
>> +{
>> +   struct fake_private *priv;
>> +
>> +   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> Missing ENOMEM handling ?
>
>> +   priv->magic = MAGIC;
>> +
>> +   return priv;
>> +}
>> +
>> +static int smaf_fakesecure_destroy(void *ctx)
>> +{
>> +   struct fake_private *priv = (struct fake_private *)ctx;
> You might want to flesh this cast into a (inline) helper and use it 
> throughout ?
>
>
> ... and that is all. Hope these were useful, or at the very least not
> utterly wrong, suggestions :-)
>
>
> Regards,
> Emil
>
> P.S. From a quick look userspace has some subtle bugs/odd practises.
> Let me know if you're interested in my input.

Your advices are welcome for userspace too

Thanks
Benjamin



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

ast: cursor flashing softlockups

[Ming Lei]

Hi,

On Tue, May 17, 2016 at 4:07 AM, Dann Frazier
 wrote:
> Hi,
>  I'm observing a soft lockup issue w/ the ASPEED controller on an
> arm64 server platform. This was originally seen on Ubuntu's 4.4
> kernel, but it is reproducible w/ vanilla 4.6-rc7 as well.
>
> [   32.792656] NMI watchdog: BUG: soft lockup - CPU#38 stuck for 22s!
> [swapper/38:0]
>
> I observe this just once each time I boot into debian-installer (I'm
> using a serial console, but the ast module gets loaded during
> startup).

I have figured out that it is caused by 'mod_timer(timer, jiffies)' and
'ops->cur_blink_jiffies' is observed as zero in cursor_timer_handler()
when the issue happened.

Looks it is a real fbcon/vt issue, see following:

fbcon_init()
<-.con_init
  <-visual_init()

reset_terminal()
<-vc_init()

vc->vc_cur_blink_ms is just set in reset_terminal() from vc_init() path,
and ops->cur_blink_jiffies is figured out from vc->vc_cur_blink_ms
in fbcon_init().

And visual_init() is always run before vc_init(), so ops->cur_blink_jiffies
is initialized as zero and cause the soft lockup issue finally.

Thanks,
Ming

>
> perf shows that the CPU caught by the NMI is typically in code
> updating the cursor timer:
>
> -   16.92%  swapper  [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore
>- _raw_spin_unlock_irqrestore
>   + 16.87% mod_timer
>   + 0.05% cursor_timer_handler
> -   12.15%  swapper  [kernel.kallsyms]  [k] queue_work_on
>- queue_work_on
>   + 12.00% cursor_timer_handler
>   + 0.15% call_timer_fn
> +   10.98%  swapper  [kernel.kallsyms]  [k] run_timer_softirq
> -2.23%  swapper  [kernel.kallsyms]  [k] mod_timer
>- mod_timer
>   + 1.97% cursor_timer_handler
>   + 0.26% call_timer_fn
>
> During the same period, I can see that another CPU is actively
> executing the timer function:
>
> -   42.18%  kworker/u96:2  [kernel.kallsyms]  [k] ww_mutex_unlock
>- ww_mutex_unlock
>   - 40.70% ast_dirty_update
>ast_imageblit
>soft_cursor
>bit_cursor
>fb_flashcursor
>process_one_work
>worker_thread
>kthread
>ret_from_fork
>   + 1.48% ast_imageblit
> -   40.15%  kworker/u96:2  [kernel.kallsyms]  [k] __memcpy_toio
>- __memcpy_toio
>   + 31.54% ast_dirty_update
>   + 8.61% ast_imageblit
>
> Using the graph function tracer on fb_flashcursor(), I see that
> ast_dirty_update usually takes around 60 us, in which it makes 16
> calls to __memcpy_toio(). However, there is always one instance on
> every boot of the installer where ast_dirty_update() takes ~98 *ms* to
> complete, during which it makes 743 calls to __memcpy_toio(). While
> that  doesn't directly account for the full 22s, I do wonder if that
> maybe a smoking gun.
>
> fyi, this is being tracked at: https://bugs.launchpad.net/bugs/1574814
>
>   -dann

[PATCH v7 2/3] SMAF: add CMA allocator

[Benjamin Gaignard]

Hi Emil,

2016-05-17 1:05 GMT+02:00 Emil Velikov :
> Hi Benjamin,
>
> On 9 May 2016 at 16:07, Benjamin Gaignard  
> wrote:
>> SMAF CMA allocator implement helpers functions to allow SMAF
>> to allocate contiguous memory.
>>
>> match() each if at least one of the attached devices have coherent_dma_mask
>> set to DMA_BIT_MASK(32).
>>
> What is the idea behind the hardcoded 32. Wouldn't it be better to avoid that 
> ?
>

Device dma_bit_mask field has to be set to DMA_BIT_MASK(32) to target
a CMA area.
I haven't see any other #define for that.

>
>> +static void smaf_cma_release(struct dma_buf *dmabuf)
>> +{
>> +   struct smaf_cma_buffer_info *info = dmabuf->priv;
>> +   DEFINE_DMA_ATTRS(attrs);
>> +
>> +   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
>> +
> Imho it's worth storing the dma_attrs within smaf_cma_buffer_info.
> This way it's less likely for things to go wrong, if one forgets to
> update one of the three in the future.

Here I have duplicate what is done everywhere else but I could try to
add it into
smaf_cma_buffer_info structure.

>
>> +static void smaf_cma_unmap(struct dma_buf_attachment *attachment,
>> +  struct sg_table *sgt,
>> +  enum dma_data_direction direction)
>> +{
>> +   /* do nothing */
> There could/should really be a comment explaining why we "do nothing"
> here, right ?
>

I haven't used DMA_ATTR_NO_KERNEL_MAPPING while allocating the buffer
so kernel mapping is set by default and I don't have to manage map refcounting.

>> +}
>> +
>> +static int smaf_cma_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
>> +{
>> +   struct smaf_cma_buffer_info *info = dmabuf->priv;
>> +   int ret;
>> +   DEFINE_DMA_ATTRS(attrs);
>> +
>> +   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
>> +
>> +   if (info->size < vma->vm_end - vma->vm_start)
>> +   return -EINVAL;
>> +
>> +   vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
>> +   ret = dma_mmap_attrs(info->dev, vma, info->vaddr, info->paddr,
>> +info->size, );
>> +
>> +   return ret;
> Kill the temporary variable 'ret' ?

sure
>
>
>> +static struct dma_buf_ops smaf_cma_ops = {
> const ? Afaict the compiler would/should warn you about discarding it
> as the ops are defined const.
>
>
>> +static struct dma_buf *smaf_cma_allocate(struct dma_buf *dmabuf,
>> +size_t length, unsigned int flags)
>> +{
>> +   struct dma_buf_attachment *attach_obj;
>> +   struct smaf_cma_buffer_info *info;
>> +   struct dma_buf *cma_dmabuf;
>> +   int ret;
>> +
>> +   DEFINE_DMA_BUF_EXPORT_INFO(export);
>> +   DEFINE_DMA_ATTRS(attrs);
>> +
>> +   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
>> +
>> +   info = kzalloc(sizeof(*info), GFP_KERNEL);
>> +   if (!info)
>> +   return NULL;
>> +
>> +   info->dev = find_matching_device(dmabuf);
> find_matching_device() can return NULL. We should handle that imho.
>

If the returned device have an associated CMA area then it will use it else
if dev have not CMA area or if find_matching_device() return NULL
the default CMA area will be used

>> +   info->size = length;
>> +   info->vaddr = dma_alloc_attrs(info->dev, info->size, >paddr,
>> + GFP_KERNEL | __GFP_NOWARN, );
>> +   if (!info->vaddr) {
>> +   ret = -ENOMEM;
> set-but-unused-variable 'ret' ?
>
I will remove it

>> +   goto error;
>> +   }
>> +
>> +   export.ops = _cma_ops;
>> +   export.size = info->size;
>> +   export.flags = flags;
>> +   export.priv = info;
>> +
>> +   cma_dmabuf = dma_buf_export();
>> +   if (IS_ERR(cma_dmabuf))
> Missing dma_free_attrs() ? I'd add another label in the error path and
> handle it there.
>
OK

>> +   goto error;
>> +
>> +   list_for_each_entry(attach_obj, >attachments, node) {
>> +   dma_buf_attach(cma_dmabuf, attach_obj->dev);
> Imho one should error out if attach fails. Or warn at the very least ?
>
>
>> +static int __init smaf_cma_init(void)
>> +{
>> +   INIT_LIST_HEAD(_cma.list_node);
> Isn't this something that smaf_register_allocator() should be doing ?
>

Yes for sure

>
> Regards,
> Emil



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Bug 95452] System freeze radeon 5770

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

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

--- Comment #5 from F. Prage  ---
Created attachment 123837
  --> https://bugs.freedesktop.org/attachment.cgi?id=123837=edit
Xorg.0.log Ubuntu 16.04

crashed while playing youtube fullscreen video in firefox

-- 
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/20160517/00d44430/attachment.html>

[Bug 95452] System freeze radeon 5770

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

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

--- Comment #4 from F. Prage  ---
Created attachment 123836
  --> https://bugs.freedesktop.org/attachment.cgi?id=123836=edit
kern.log ubuntu 16.06

freeze not logged, happened about 1 hour after log ends

-- 
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/20160517/db5a533a/attachment.html>

[PATCH 4/4] drm/amdgpu: update Polaris11 golden setting

[Alex Deucher]

From: Flora Cui 

Signed-off-by: Flora Cui 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 5 +++--
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 ++
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 4862073..cd2ec81 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -137,7 +137,7 @@ static const u32 polaris11_golden_settings_a11[] =
mmDCI_CLK_CNTL, 0x0080, 0x,
mmFBC_DEBUG_COMP, 0x00f0, 0x0070,
mmFBC_DEBUG1, 0x, 0x0008,
-   mmFBC_MISC, 0x9f313fff, 0x1438,
+   mmFBC_MISC, 0x9f313fff, 0x14302008,
mmHDMI_CONTROL, 0x313f031f, 0x0011,
 };

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 3e97e1e..f19bab6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -267,10 +267,13 @@ static const u32 tonga_mgcg_cgcg_init[] =

 static const u32 golden_settings_polaris11_a11[] =
 {
+   mmCB_HW_CONTROL, 0xfffdf3cf, 0x6208,
mmCB_HW_CONTROL_3, 0x01ff, 0x0040,
mmDB_DEBUG2, 0xf00f, 0x0400,
mmPA_SC_ENHANCE, 0x, 0x2001,
mmPA_SC_LINE_STIPPLE_STATE, 0xff0f, 0x,
+   mmPA_SC_RASTER_CONFIG, 0x3f3f, 0x1612,
+   mmPA_SC_RASTER_CONFIG_1, 0x003f, 0x,
mmRLC_CGCG_CGLS_CTRL, 0x0003, 0x0001003c,
mmRLC_CGCG_CGLS_CTRL_3D, 0x, 0x0001003c,
mmSQ_CONFIG, 0x07f8, 0x0718,
@@ -284,8 +287,6 @@ static const u32 golden_settings_polaris11_a11[] =
 static const u32 polaris11_golden_common_all[] =
 {
mmGRBM_GFX_INDEX, 0x, 0xe000,
-   mmPA_SC_RASTER_CONFIG, 0x, 0x1612,
-   mmPA_SC_RASTER_CONFIG_1, 0x, 0x,
mmGB_ADDR_CONFIG, 0x, 0x22011002,
mmSPI_RESOURCE_RESERVE_CU_0, 0x, 0x0800,
mmSPI_RESOURCE_RESERVE_CU_1, 0x, 0x0800,
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
index 063f08a..31d99b00 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
@@ -109,10 +109,12 @@ static const u32 fiji_mgcg_cgcg_init[] =
 static const u32 golden_settings_polaris11_a11[] =
 {
mmSDMA0_CHICKEN_BITS, 0xfc910007, 0x00810007,
+   mmSDMA0_CLK_CTRL, 0xff000fff, 0x,
mmSDMA0_GFX_IB_CNTL, 0x800f0111, 0x0100,
mmSDMA0_RLC0_IB_CNTL, 0x800f0111, 0x0100,
mmSDMA0_RLC1_IB_CNTL, 0x800f0111, 0x0100,
mmSDMA1_CHICKEN_BITS, 0xfc910007, 0x00810007,
+   mmSDMA1_CLK_CTRL, 0xff000fff, 0x,
mmSDMA1_GFX_IB_CNTL, 0x800f0111, 0x0100,
mmSDMA1_RLC0_IB_CNTL, 0x800f0111, 0x0100,
mmSDMA1_RLC1_IB_CNTL, 0x800f0111, 0x0100,
-- 
2.5.5

[PATCH 3/4] drm/amdgpu: Add more Polaris 11 PCI IDs

[Alex Deucher]

From: Flora Cui 

Signed-off-by: Flora Cui 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index f108d6d..f888c01 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -281,11 +281,14 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x98E4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_STONEY|AMD_IS_APU},
/* Polaris11 */
{0x1002, 0x67E0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
-   {0x1002, 0x67E1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
+   {0x1002, 0x67E3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
{0x1002, 0x67E8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
-   {0x1002, 0x67E9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
{0x1002, 0x67EB, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
+   {0x1002, 0x67EF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
{0x1002, 0x67FF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
+   {0x1002, 0x67E1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
+   {0x1002, 0x67E7, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
+   {0x1002, 0x67E9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
/* Polaris10 */
{0x1002, 0x67C0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
{0x1002, 0x67C1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
-- 
2.5.5

[PATCH 2/4] drm/amdgpu: update Polaris10 golden setting

[Alex Deucher]

From: Flora Cui 

Signed-off-by: Flora Cui 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 1e09885..4862073 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -145,7 +145,7 @@ static const u32 polaris10_golden_settings_a11[] =
 {
mmDCI_CLK_CNTL, 0x0080, 0x,
mmFBC_DEBUG_COMP, 0x00f0, 0x0070,
-   mmFBC_MISC, 0x9f313fff, 0x1438,
+   mmFBC_MISC, 0x9f313fff, 0x14302008,
mmHDMI_CONTROL, 0x313f031f, 0x0011,
 };

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index ef192aa..3e97e1e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -296,6 +296,7 @@ static const u32 polaris11_golden_common_all[] =
 static const u32 golden_settings_polaris10_a11[] =
 {
mmATC_MISC_CG, 0x000c0fc0, 0x000c0200,
+   mmCB_HW_CONTROL, 0xfffdf3cf, 0x6208,
mmCB_HW_CONTROL_3, 0x01ff, 0x0040,
mmDB_DEBUG2, 0xf00f, 0x0400,
mmPA_SC_ENHANCE, 0x, 0x2001,
-- 
2.5.5

[PATCH 1/4] drm/amdgpu: add more Polaris10 DID

[Alex Deucher]

From: Flora Cui 

Signed-off-by: Flora Cui 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6ff5879..f108d6d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -288,7 +288,16 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x67FF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS11},
/* Polaris10 */
{0x1002, 0x67C0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67C1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67C2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67C4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67C7, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
{0x1002, 0x67DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67C8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67C9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67CA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67CC, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},
+   {0x1002, 0x67CF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10},

{0, 0, 0}
 };
-- 
2.5.5

[drm:drm-next 992/1014] ./usr/include/drm/drm.h:63: userspace cannot reference function or variable defined in the kernel

[kbuild test robot]

tree:   git://people.freedesktop.org/~airlied/linux.git drm-next
head:   7c10ddf87472c07eabc206e273dc59f77c700858
commit: ebbb0e5cfd2ceb1150b1af7f9fcf7aeebfb1b69f [992/1014] drm: add extern C 
guard for the UAPI headers
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout ebbb0e5cfd2ceb1150b1af7f9fcf7aeebfb1b69f
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference function or 
variable defined in the kernel
>> ./usr/include/drm/drm.h:63: userspace cannot reference function or variable 
>> defined in the kernel
   ./usr/include/drm/drm.h:699: userspace cannot reference function or variable 
defined in the kernel
>> ./usr/include/drm/drm_fourcc.h:30: userspace cannot reference function or 
>> variable defined in the kernel
>> ./usr/include/drm/drm_mode.h:33: userspace cannot reference function or 
>> variable defined in the kernel
>> ./usr/include/drm/drm_sarea.h:38: userspace cannot reference function or 
>> variable defined in the kernel

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6275 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160517/d599db21/attachment.obj>

[PATCH 1/5] drm/amd/amdgpu : Remove unused variable

[Alex Deucher]

On Tue, May 17, 2016 at 5:42 AM, Muhammad Falak R Wani
 wrote:
> Remove unused variable 'ret', and directly return 0.
>
> Signed-off-by: Muhammad Falak R Wani 

Applied the series.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/cik_ih.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/cik_ih.c 
> b/drivers/gpu/drm/amd/amdgpu/cik_ih.c
> index f2f14fe..e78c9bd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/cik_ih.c
> +++ b/drivers/gpu/drm/amd/amdgpu/cik_ih.c
> @@ -103,7 +103,6 @@ static void cik_ih_disable_interrupts(struct 
> amdgpu_device *adev)
>   */
>  static int cik_ih_irq_init(struct amdgpu_device *adev)
>  {
> -   int ret = 0;
> int rb_bufsz;
> u32 interrupt_cntl, ih_cntl, ih_rb_cntl;
> u64 wptr_off;
> @@ -156,7 +155,7 @@ static int cik_ih_irq_init(struct amdgpu_device *adev)
> /* enable irqs */
> cik_ih_enable_interrupts(adev);
>
> -   return ret;
> +   return 0;
>  }
>
>  /**
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 95451] UVD errors after unsuspending

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

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

Michel Dänzer  changed:

   What|Removed |Added

Summary|Hardware acceleration   |UVD errors after
   |errors after unsuspending   |unsuspending

-- 
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/20160517/870a1297/attachment.html>

[Bug 95451] Hardware acceleration errors after unsuspending

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

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

Michel Dänzer  changed:

   What|Removed |Added

Product|xorg|DRI
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
  Component|Driver/AMDgpu   |DRM/AMDgpu
 QA Contact|xorg-team at lists.x.org   |

-- 
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/20160517/594c23f0/attachment.html>

[drm:drm-next 990/1014] ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference function or variable defined in the kernel

[kbuild test robot]

tree:   git://people.freedesktop.org/~airlied/linux.git drm-next
head:   7c10ddf87472c07eabc206e273dc59f77c700858
commit: cfa7152f1cfeedba7c4ab3abcb4accee94cc2c0f [990/1014] drm/amdgpu: add 
extern C guard for the UAPI header
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout cfa7152f1cfeedba7c4ab3abcb4accee94cc2c0f
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

>> ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference function or 
>> variable defined in the kernel

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6275 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160517/13dcc995/attachment-0001.obj>

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Ville Syrjälä]

On Tue, May 17, 2016 at 03:04:52PM +0200, Daniel Vetter wrote:
> On Tue, May 17, 2016 at 02:22:26PM +0200, Noralf Trønnes wrote:
> > 
> > 
> > Den 17.05.2016 14:12, skrev Ville Syrjälä:
> > >On Tue, May 17, 2016 at 02:00:45PM +0200, Noralf Trønnes wrote:
> > >>Den 17.05.2016 09:59, skrev Daniel Vetter:
> > >>>On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
> > On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
> > >On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
> > >>On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> > >>>Provides helper functions for drivers that have a simple display
> > >>>pipeline. Plane, crtc and encoder are collapsed into one entity.
> > >>>
> > >>>Cc: jsarha at ti.com
> > >>>Signed-off-by: Noralf Trønnes 
> > >>>---
> > >>>
> > >>>Changes since v3:
> > >>>- (struct drm_simple_display_pipe *)->funcs should be const
> > >>>
> > >>>Changes since v2:
> > >>>- Drop Kconfig knob DRM_KMS_HELPER
> > >>>- Expand documentation
> > >>>
> > >>>Changes since v1:
> > >>>- Add DOC header and add to gpu.tmpl
> > >>>- Fix docs: @funcs is optional, "negative error code",
> > >>>"This hook is optional."
> > >>>- Add checks to drm_simple_kms_plane_atomic_check()
> > >>>
> > >>>   Documentation/DocBook/gpu.tmpl  |   6 +
> > >>>   drivers/gpu/drm/Makefile|   2 +-
> > >>>   drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> > >>> 
> > >>>   include/drm/drm_simple_kms_helper.h |  94 +++
> > >>>   4 files changed, 309 insertions(+), 1 deletion(-)
> > >>>   create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
> > >>>   create mode 100644 include/drm/drm_simple_kms_helper.h
> > >>>
> > >>>diff --git a/Documentation/DocBook/gpu.tmpl 
> > >>>b/Documentation/DocBook/gpu.tmpl
> > >>>index 4a0c599..cf3f5a8 100644
> > >>>--- a/Documentation/DocBook/gpu.tmpl
> > >>>+++ b/Documentation/DocBook/gpu.tmpl
> > >>>@@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
> > >>>   !Edrivers/gpu/drm/drm_panel.c
> > >>>   !Pdrivers/gpu/drm/drm_panel.c drm panel
> > >>>   
> > >>>+
> > >>>+  Simple KMS Helper Reference
> > >>>+!Iinclude/drm/drm_simple_kms_helper.h
> > >>>+!Edrivers/gpu/drm/drm_simple_kms_helper.c
> > >>>+!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> > >>>+
> > >>> 
> > >>>
> > >>> 
> > >>>diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > >>>index 2bd3e5a..31b85df5 100644
> > >>>--- a/drivers/gpu/drm/Makefile
> > >>>+++ b/drivers/gpu/drm/Makefile
> > >>>@@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> > >>>
> > >>>   drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> > >>> drm_probe_helper.o \
> > >>> drm_plane_helper.o drm_dp_mst_topology.o 
> > >>> drm_atomic_helper.o \
> > >>>-drm_kms_helper_common.o
> > >>>+drm_kms_helper_common.o drm_simple_kms_helper.o
> > >>>
> > >>>   drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > >>>   drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > >>>diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > >>>b/drivers/gpu/drm/drm_simple_kms_helper.c
> > >>>new file mode 100644
> > >>>index 000..d45417a
> > >>>--- /dev/null
> > >>>+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > >>>@@ -0,0 +1,208 @@
> > >>>+/*
> > >>>+ * Copyright (C) 2016 Noralf Trønnes
> > >>>+ *
> > >>>+ * 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 
> > >>>+
> > >>>+/**
> > >>>+ * DOC: overview
> > >>>+ *
> > >>>+ * This helper library provides helpers for drivers for simple 
> > >>>display
> > >>>+ * hardware.
> > >>>+ *
> > >>>+ * drm_simple_display_pipe_init() initializes a simple display 
> > >>>pipeline
> > >>>+ * which has only one full-screen scanout buffer feeding one 
> > >>>output. The
> > >>>+ * pipeline is represented by struct _simple_display_pipe and 
> > >>>binds
> > >>>+ * together _plane, _crtc and _encoder structures into 
> > >>>one fixed
> > >>>+ * entity. Some flexibility for code reuse is provided through a 
> > >>>separately
> > >>>+ * allocated _connector object and 

[PATCH v7 1/3] create SMAF module

[Benjamin Gaignard]

Hello Emil,

thanks for your review.
I have understand most of your remarks and I'm fixing them
but some points aren't obvious for me...

2016-05-17 0:58 GMT+02:00 Emil Velikov :
>  Hi Benjamin,
>
> I'd suspect you're interested in some feedback on these, so here is a few :-)
> Sadly (ideally?) nothing serious, but a bunch minor suggestions, plus
> the odd bug.
>
> On 9 May 2016 at 16:07, Benjamin Gaignard  
> wrote:
>
>> --- /dev/null
>> +++ b/drivers/smaf/smaf-core.c
>> @@ -0,0 +1,794 @@
>> +/*
>> + * smaf.c
> The comment does not match the actual file name.
>
> You could give a brief summary of the file(s), if you're feeling gracious ;-)
>
>
>> +
>> +/**
>> + * smaf_grant_access - return true if the specified device can get access
>> + * to the memory area
>> + *
> Reading this makes me wonder if {request,allow}_access won't be better name ?
>

grant and revoke sound more secure oriented for me but that could change

>
>> +static int smaf_secure_handle(struct smaf_handle *handle)
>> +{
>> +   if (atomic_read(>is_secure))
>> +   return 0;
>> +
>> +   if (!have_secure_module())
>> +   return -EINVAL;
>> +
>> +   handle->secure_ctx = smaf_dev.secure->create_ctx();
>> +
> Should one use a temporary variable so that the caller provided
> storage is unchanged in case of an error ?
>
>> +   if (!handle->secure_ctx)
>> +   return -EINVAL;
>> +
>> +   atomic_set(>is_secure, 1);
>> +   return 0;
>> +}
>> +
>
>
>> +int smaf_register_secure(struct smaf_secure *s)
>> +{
>> +   /* make sure that secure module have all required functions
>> +* to avoid test them each time later
>> +*/
>> +   WARN_ON(!s || !s->create_ctx || !s->destroy_ctx ||
>> +   !s->grant_access || !s->revoke_access);
>> +
> Is something like below reasonable thing to do in the kernel ?
> Same question goes for smaf_register_allocator() further down.
>
> if (!s || )
>   return -ESHOULDNEVERHAPPEN;
>
>
>
>> +static struct vm_operations_struct smaf_vma_ops = {
> Ops/vfucs normally are const data. Is there something preventing us here ?
>
>> +   .close = smaf_vm_close,
>> +};
>> +
>> +static int smaf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
>> +{
>> +   struct smaf_handle *handle = dmabuf->priv;
>> +   bool ret;
>> +   enum dma_data_direction dir;
>> +
>> +   /* if no allocator attached, get the first allocator */
>> +   if (!handle->allocator) {
>> +   struct smaf_allocator *alloc;
>> +
>> +   mutex_lock(_dev.lock);
>> +   alloc = smaf_get_first_allocator(dmabuf);
>> +   mutex_unlock(_dev.lock);
>> +
>> +   /* still no allocator ? */
>> +   if (!alloc)
>> +   return -EINVAL;
>> +
>> +   handle->allocator = alloc;
>> +   }
>> +
>> +   if (!handle->db_alloc) {
>> +   struct dma_buf *db_alloc;
>> +
>> +   db_alloc = handle->allocator->allocate(dmabuf,
>> +  handle->length,
>> +  handle->flags);
>> +   if (!db_alloc)
>> +   return -EINVAL;
>> +
>> +   handle->db_alloc = db_alloc;
>> +   }
>> +
> The above half of the function looks identical to smaf_map_dma_buf().
> Worth factoring it out to a helper function ?
>
>
>> +static int smaf_attach(struct dma_buf *dmabuf, struct device *dev,
>> +  struct dma_buf_attachment *attach)
>> +{
>> +   struct smaf_handle *handle = dmabuf->priv;
>> +   struct dma_buf_attachment *db_attach;
>> +
>> +   if (!handle->db_alloc)
>> +   return 0;
>> +
> Shouldn't one return an error (-EINVAL or similar) here ?

No because a device could attach itself on the buffer and the
allocator will only
be selected at the first map_attach call.
The goal is to delay the allocation until all devices are attached to
select the best allocator.

>
>
>> +static struct dma_buf_ops smaf_dma_buf_ops = {
> const ? From a very quick look the compiler should warn us about it -
> "smaf_dma_buf_ops discards const qualifier" or similar.
>
>
>> +struct smaf_handle *smaf_create_handle(size_t length, unsigned int flags)
>> +{
>> +   struct smaf_handle *handle;
>> +
>> +   DEFINE_DMA_BUF_EXPORT_INFO(info);
>> +
>> +   handle = kzalloc(sizeof(*handle), GFP_KERNEL);
>> +   if (!handle)
>> +   return ERR_PTR(-ENOMEM);
>> +
> Err this should be return NULL; correct ?
>
>> +   info.ops = _dma_buf_ops;
>> +   info.size = round_up(length, PAGE_SIZE);
>> +   info.flags = flags;
>> +   info.priv = handle;
>> +
>> +   handle->dmabuf = dma_buf_export();
>> +   if (IS_ERR(handle->dmabuf)) {
>> +   kfree(handle);
>> +   return NULL;
>> +   }
>> +
>> +   handle->length = info.size;
>> +   handle->flags = flags;
>> +
>> 

[Bug 117411] [radeon][HD5650][REDWOOD] radeon.dpm causing one minute boot delay

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

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

no.spam.to.me at ish.de changed:

   What|Removed |Added

 Kernel Version|4.5.0   |since 4.3-rc4

--- Comment #3 from no.spam.to.me at ish.de ---
After Bisecting the Kernel I got the commit that introduces the extra 40s Xorg
delay:

8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 is the first bad commit
commit 8c70e1cda04b966b50ddfefafbd0ea376ed8edd5
Author: Alex Deucher 
Date:   Fri Oct 2 16:52:58 2015 -0400

drm/radeon: restore the fbdev mode in lastclose

restore the fbdev state if a drm app like X is killed.

Tested-by: Michel Dänzer 
Reviewed-by: Michel Dänzer 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 

:04 04 d67406e169b8003fc72edf4d26f206ff2e164bf0
5e053c1de5f504e876daffef19a59850a8b6015e Mdrivers

But I don't know how to identify the delay at boot.

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

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Daniel Vetter]

On Tue, May 17, 2016 at 3:14 PM, Ville Syrjälä
 wrote:
> On Tue, May 17, 2016 at 03:04:52PM +0200, Daniel Vetter wrote:
>> On Tue, May 17, 2016 at 02:22:26PM +0200, Noralf Trønnes wrote:
>> >
>> >
>> > Den 17.05.2016 14:12, skrev Ville Syrjälä:
>> > >On Tue, May 17, 2016 at 02:00:45PM +0200, Noralf Trønnes wrote:
>> > >>Den 17.05.2016 09:59, skrev Daniel Vetter:
>> > >>>On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
>> > On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
>> > >On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
>> > >>On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
>> > >>>Provides helper functions for drivers that have a simple display
>> > >>>pipeline. Plane, crtc and encoder are collapsed into one entity.
>> > >>>
>> > >>>Cc: jsarha at ti.com
>> > >>>Signed-off-by: Noralf Trønnes 
>> > >>>---
>> > >>>
>> > >>>Changes since v3:
>> > >>>- (struct drm_simple_display_pipe *)->funcs should be const
>> > >>>
>> > >>>Changes since v2:
>> > >>>- Drop Kconfig knob DRM_KMS_HELPER
>> > >>>- Expand documentation
>> > >>>
>> > >>>Changes since v1:
>> > >>>- Add DOC header and add to gpu.tmpl
>> > >>>- Fix docs: @funcs is optional, "negative error code",
>> > >>>"This hook is optional."
>> > >>>- Add checks to drm_simple_kms_plane_atomic_check()
>> > >>>
>> > >>>   Documentation/DocBook/gpu.tmpl  |   6 +
>> > >>>   drivers/gpu/drm/Makefile|   2 +-
>> > >>>   drivers/gpu/drm/drm_simple_kms_helper.c | 208 
>> > >>> 
>> > >>>   include/drm/drm_simple_kms_helper.h |  94 +++
>> > >>>   4 files changed, 309 insertions(+), 1 deletion(-)
>> > >>>   create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
>> > >>>   create mode 100644 include/drm/drm_simple_kms_helper.h
>> > >>>
>> > >>>diff --git a/Documentation/DocBook/gpu.tmpl 
>> > >>>b/Documentation/DocBook/gpu.tmpl
>> > >>>index 4a0c599..cf3f5a8 100644
>> > >>>--- a/Documentation/DocBook/gpu.tmpl
>> > >>>+++ b/Documentation/DocBook/gpu.tmpl
>> > >>>@@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
>> > >>>   !Edrivers/gpu/drm/drm_panel.c
>> > >>>   !Pdrivers/gpu/drm/drm_panel.c drm panel
>> > >>>   
>> > >>>+
>> > >>>+  Simple KMS Helper Reference
>> > >>>+!Iinclude/drm/drm_simple_kms_helper.h
>> > >>>+!Edrivers/gpu/drm/drm_simple_kms_helper.c
>> > >>>+!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
>> > >>>+
>> > >>> 
>> > >>>
>> > >>> 
>> > >>>diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> > >>>index 2bd3e5a..31b85df5 100644
>> > >>>--- a/drivers/gpu/drm/Makefile
>> > >>>+++ b/drivers/gpu/drm/Makefile
>> > >>>@@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
>> > >>>
>> > >>>   drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
>> > >>> drm_probe_helper.o \
>> > >>> drm_plane_helper.o drm_dp_mst_topology.o 
>> > >>> drm_atomic_helper.o \
>> > >>>-drm_kms_helper_common.o
>> > >>>+drm_kms_helper_common.o drm_simple_kms_helper.o
>> > >>>
>> > >>>   drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
>> > >>> drm_edid_load.o
>> > >>>   drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>> > >>>diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
>> > >>>b/drivers/gpu/drm/drm_simple_kms_helper.c
>> > >>>new file mode 100644
>> > >>>index 000..d45417a
>> > >>>--- /dev/null
>> > >>>+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
>> > >>>@@ -0,0 +1,208 @@
>> > >>>+/*
>> > >>>+ * Copyright (C) 2016 Noralf Trønnes
>> > >>>+ *
>> > >>>+ * 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 
>> > >>>+
>> > >>>+/**
>> > >>>+ * DOC: overview
>> > >>>+ *
>> > >>>+ * This helper library provides helpers for drivers for simple 
>> > >>>display
>> > >>>+ * hardware.
>> > >>>+ *
>> > >>>+ * drm_simple_display_pipe_init() initializes a simple display 
>> > >>>pipeline
>> > >>>+ * which has only one full-screen scanout buffer feeding one 
>> > >>>output. The
>> > >>>+ * pipeline is represented by struct _simple_display_pipe and 
>> > >>>binds
>> > >>>+ * together _plane, _crtc and 

[PATCH 5/5] drm/amd/amdgpu : Remove unused variable

[Muhammad Falak R Wani]

Remove unused variable 'ret', and directly return 0.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c 
b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
index 55cdab8..cba951a 100644
--- a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
@@ -99,7 +99,6 @@ static void tonga_ih_disable_interrupts(struct amdgpu_device 
*adev)
  */
 static int tonga_ih_irq_init(struct amdgpu_device *adev)
 {
-   int ret = 0;
int rb_bufsz;
u32 interrupt_cntl, ih_rb_cntl, ih_doorbell_rtpr;
u64 wptr_off;
@@ -165,7 +164,7 @@ static int tonga_ih_irq_init(struct amdgpu_device *adev)
/* enable interrupts */
tonga_ih_enable_interrupts(adev);

-   return ret;
+   return 0;
 }

 /**
-- 
1.9.1

[PATCH 4/5] drm/amd/amdgpu : Remove unused variable

[Muhammad Falak R Wani]

Remove unused variable 'ret', and directly return 0.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/iceland_ih.c 
b/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
index 5c4001e..e0169bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
@@ -103,7 +103,6 @@ static void iceland_ih_disable_interrupts(struct 
amdgpu_device *adev)
  */
 static int iceland_ih_irq_init(struct amdgpu_device *adev)
 {
-   int ret = 0;
int rb_bufsz;
u32 interrupt_cntl, ih_cntl, ih_rb_cntl;
u64 wptr_off;
@@ -157,7 +156,7 @@ static int iceland_ih_irq_init(struct amdgpu_device *adev)
/* enable interrupts */
iceland_ih_enable_interrupts(adev);

-   return ret;
+   return 0;
 }

 /**
-- 
1.9.1

[PATCH 3/5] drm/amd/amdgpu : Remove unused variable

[Muhammad Falak R Wani]

Remove unused variable 'ret', and directly return 0.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/gpu/drm/amd/amdgpu/cz_ih.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cz_ih.c 
b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
index 23bd912..964956f 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
@@ -103,7 +103,6 @@ static void cz_ih_disable_interrupts(struct amdgpu_device 
*adev)
  */
 static int cz_ih_irq_init(struct amdgpu_device *adev)
 {
-   int ret = 0;
int rb_bufsz;
u32 interrupt_cntl, ih_cntl, ih_rb_cntl;
u64 wptr_off;
@@ -157,7 +156,7 @@ static int cz_ih_irq_init(struct amdgpu_device *adev)
/* enable interrupts */
cz_ih_enable_interrupts(adev);

-   return ret;
+   return 0;
 }

 /**
-- 
1.9.1

[PATCH 2/5] drm/amd/amdgpu/cz_dpm: Remove unused variable

[Muhammad Falak R Wani]

Remove unused variable 'ret' from functions where it
was not used anyway, and directly return 0.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
index bf1847b..2f4ed17 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
@@ -1579,7 +1579,6 @@ static int cz_dpm_update_sclk_limit(struct amdgpu_device 
*adev)

 static int cz_dpm_set_deep_sleep_sclk_threshold(struct amdgpu_device *adev)
 {
-   int ret = 0;
struct cz_power_info *pi = cz_get_pi(adev);

if (pi->caps_sclk_ds) {
@@ -1588,20 +1587,19 @@ static int cz_dpm_set_deep_sleep_sclk_threshold(struct 
amdgpu_device *adev)
CZ_MIN_DEEP_SLEEP_SCLK);
}

-   return ret;
+   return 0;
 }

 /* ?? without dal support, is this still needed in setpowerstate list*/
 static int cz_dpm_set_watermark_threshold(struct amdgpu_device *adev)
 {
-   int ret = 0;
struct cz_power_info *pi = cz_get_pi(adev);

cz_send_msg_to_smc_with_parameter(adev,
PPSMC_MSG_SetWatermarkFrequency,
pi->sclk_dpm.soft_max_clk);

-   return ret;
+   return 0;
 }

 static int cz_dpm_enable_nbdpm(struct amdgpu_device *adev)
@@ -1636,7 +1634,6 @@ static void cz_dpm_nbdpm_lm_pstate_enable(struct 
amdgpu_device *adev,

 static int cz_dpm_update_low_memory_pstate(struct amdgpu_device *adev)
 {
-   int ret = 0;
struct cz_power_info *pi = cz_get_pi(adev);
struct cz_ps *ps = >requested_ps;

@@ -1647,21 +1644,19 @@ static int cz_dpm_update_low_memory_pstate(struct 
amdgpu_device *adev)
cz_dpm_nbdpm_lm_pstate_enable(adev, true);
}

-   return ret;
+   return 0;
 }

 /* with dpm enabled */
 static int cz_dpm_set_power_state(struct amdgpu_device *adev)
 {
-   int ret = 0;
-
cz_dpm_update_sclk_limit(adev);
cz_dpm_set_deep_sleep_sclk_threshold(adev);
cz_dpm_set_watermark_threshold(adev);
cz_dpm_enable_nbdpm(adev);
cz_dpm_update_low_memory_pstate(adev);

-   return ret;
+   return 0;
 }

 static void cz_dpm_post_set_power_state(struct amdgpu_device *adev)
-- 
1.9.1

[PATCH 1/5] drm/amd/amdgpu : Remove unused variable

[Muhammad Falak R Wani]

Remove unused variable 'ret', and directly return 0.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/gpu/drm/amd/amdgpu/cik_ih.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cik_ih.c 
b/drivers/gpu/drm/amd/amdgpu/cik_ih.c
index f2f14fe..e78c9bd 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik_ih.c
@@ -103,7 +103,6 @@ static void cik_ih_disable_interrupts(struct amdgpu_device 
*adev)
  */
 static int cik_ih_irq_init(struct amdgpu_device *adev)
 {
-   int ret = 0;
int rb_bufsz;
u32 interrupt_cntl, ih_cntl, ih_rb_cntl;
u64 wptr_off;
@@ -156,7 +155,7 @@ static int cik_ih_irq_init(struct amdgpu_device *adev)
/* enable irqs */
cik_ih_enable_interrupts(adev);

-   return ret;
+   return 0;
 }

 /**
-- 
1.9.1

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Ville Syrjälä]

On Tue, May 17, 2016 at 02:00:45PM +0200, Noralf Trønnes wrote:
> 
> Den 17.05.2016 09:59, skrev Daniel Vetter:
> > On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
> >> On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
> >>> On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
>  On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> > Provides helper functions for drivers that have a simple display
> > pipeline. Plane, crtc and encoder are collapsed into one entity.
> >
> > Cc: jsarha at ti.com
> > Signed-off-by: Noralf Trønnes 
> > ---
> >
> > Changes since v3:
> > - (struct drm_simple_display_pipe *)->funcs should be const
> >
> > Changes since v2:
> > - Drop Kconfig knob DRM_KMS_HELPER
> > - Expand documentation
> >
> > Changes since v1:
> > - Add DOC header and add to gpu.tmpl
> > - Fix docs: @funcs is optional, "negative error code",
> >"This hook is optional."
> > - Add checks to drm_simple_kms_plane_atomic_check()
> >
> >   Documentation/DocBook/gpu.tmpl  |   6 +
> >   drivers/gpu/drm/Makefile|   2 +-
> >   drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> > 
> >   include/drm/drm_simple_kms_helper.h |  94 +++
> >   4 files changed, 309 insertions(+), 1 deletion(-)
> >   create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
> >   create mode 100644 include/drm/drm_simple_kms_helper.h
> >
> > diff --git a/Documentation/DocBook/gpu.tmpl 
> > b/Documentation/DocBook/gpu.tmpl
> > index 4a0c599..cf3f5a8 100644
> > --- a/Documentation/DocBook/gpu.tmpl
> > +++ b/Documentation/DocBook/gpu.tmpl
> > @@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
> >   !Edrivers/gpu/drm/drm_panel.c
> >   !Pdrivers/gpu/drm/drm_panel.c drm panel
> >   
> > +
> > +  Simple KMS Helper Reference
> > +!Iinclude/drm/drm_simple_kms_helper.h
> > +!Edrivers/gpu/drm/drm_simple_kms_helper.c
> > +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> > +
> > 
> >
> > 
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 2bd3e5a..31b85df5 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> >
> >   drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> > drm_probe_helper.o \
> > drm_plane_helper.o drm_dp_mst_topology.o 
> > drm_atomic_helper.o \
> > -   drm_kms_helper_common.o
> > +   drm_kms_helper_common.o drm_simple_kms_helper.o
> >
> >   drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >   drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > new file mode 100644
> > index 000..d45417a
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -0,0 +1,208 @@
> > +/*
> > + * Copyright (C) 2016 Noralf Trønnes
> > + *
> > + * 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 
> > +
> > +/**
> > + * DOC: overview
> > + *
> > + * This helper library provides helpers for drivers for simple display
> > + * hardware.
> > + *
> > + * drm_simple_display_pipe_init() initializes a simple display pipeline
> > + * which has only one full-screen scanout buffer feeding one output. 
> > The
> > + * pipeline is represented by struct _simple_display_pipe and binds
> > + * together _plane, _crtc and _encoder structures into one 
> > fixed
> > + * entity. Some flexibility for code reuse is provided through a 
> > separately
> > + * allocated _connector object and supporting optional _bridge
> > + * encoder drivers.
> > + */
> > +
> > +static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> > +   .destroy = drm_encoder_cleanup,
> > +};
> > +
> > +static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> > +{
> > +   struct drm_simple_display_pipe *pipe;
> > +
> > +   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> > +   if (!pipe->funcs || !pipe->funcs->enable)
> > +   return;
> > +
> > +   

[PATCH] checkpatch fixes

[Daniel Vetter]

On Tue, May 17, 2016 at 07:45:25AM +1000, Tobin C Harding wrote:
> Fix a couple of checkpatch errors and a bunch of warnings.
> 
> Signed-off-by: Tobin C Harding 

Patch needs a drm/gma500: prefix in the summary. Also please list in the
commit message itself what kinds of warnings exactly you've fixed. Most
maintainers also want that you split the patch up into one addressing each
issue separately (e.g. one for whitespace, one for printk, one for != NULL
removal).
-Daniel

> ---
> 
> Two occurences of (foo != NULL) changed to (!foo) even though not picked up 
> by checkpatch.pl
> 
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c | 39 
> +++--
>  1 file changed, 18 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 813ef23..34f695c 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -229,6 +229,7 @@ static void cdv_intel_lvds_set_power(struct drm_device 
> *dev,
>  static void cdv_intel_lvds_encoder_dpms(struct drm_encoder *encoder, int 
> mode)
>  {
>   struct drm_device *dev = encoder->dev;
> +
>   if (mode == DRM_MODE_DPMS_ON)
>   cdv_intel_lvds_set_power(dev, encoder, true);
>   else
> @@ -284,7 +285,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
> *encoder,
>   head) {
>   if (tmp_encoder != encoder
>   && tmp_encoder->crtc == encoder->crtc) {
> - printk(KERN_ERR "Can't enable LVDS and another "
> + pr_err("Can't enable LVDS and another "
>  "encoder on the same pipe\n");
>   return false;
>   }
> @@ -296,7 +297,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
> *encoder,
>* with the panel scaling set up to source from the H/VDisplay
>* of the original mode.
>*/
> - if (panel_fixed_mode != NULL) {
> + if (panel_fixed_mode) {
>   adjusted_mode->hdisplay = panel_fixed_mode->hdisplay;
>   adjusted_mode->hsync_start = panel_fixed_mode->hsync_start;
>   adjusted_mode->hsync_end = panel_fixed_mode->hsync_end;
> @@ -410,7 +411,8 @@ static int cdv_intel_lvds_get_modes(struct drm_connector 
> *connector)
>   struct psb_intel_mode_device *mode_dev = _priv->mode_dev;
>   int ret;
>  
> - ret = psb_intel_ddc_get_modes(connector, 
> _encoder->i2c_bus->adapter);
> + ret = psb_intel_ddc_get_modes(connector,
> +   _encoder->i2c_bus->adapter);
>  
>   if (ret)
>   return ret;
> @@ -423,7 +425,7 @@ static int cdv_intel_lvds_get_modes(struct drm_connector 
> *connector)
>   connector->display_info.max_vfreq = 200;
>   connector->display_info.min_hfreq = 0;
>   connector->display_info.max_hfreq = 200;
> - if (mode_dev->panel_fixed_mode != NULL) {
> + if (mode_dev->panel_fixed_mode) {
>   struct drm_display_mode *mode =
>   drm_mode_duplicate(dev, mode_dev->panel_fixed_mode);
>   drm_mode_probed_add(connector, mode);
> @@ -503,7 +505,7 @@ static int cdv_intel_lvds_set_property(struct 
> drm_connector *connector,
>   value))
>   return -1;
>   else
> -gma_backlight_set(encoder->dev, value);
> + gma_backlight_set(encoder->dev, value);
>   } else if (!strcmp(property->name, "DPMS") && encoder) {
>   const struct drm_encoder_helper_funcs *helpers =
>   encoder->helper_private;
> @@ -574,7 +576,7 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
>   continue;
>  
>   if (child->i2c_pin)
> - *i2c_pin = child->i2c_pin;
> + *i2c_pin = child->i2c_pin;
>  
>   /* However, we cannot trust the BIOS writers to populate
>* the VBT correctly.  Since LVDS requires additional
> @@ -624,13 +626,11 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>   return;
>   }
>  
> - gma_encoder = kzalloc(sizeof(struct gma_encoder),
> - GFP_KERNEL);
> + gma_encoder = kzalloc(sizeof(struct gma_encoder), GFP_KERNEL);
>   if (!gma_encoder)
>   return;
>  
> - gma_connector = kzalloc(sizeof(struct gma_connector),
> -   GFP_KERNEL);
> + gma_connector = kzalloc(sizeof(struct gma_connector), GFP_KERNEL);
>   if (!gma_connector)
>   goto failed_connector;
>  
> @@ -665,7 +665,7 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>   connector->interlace_allowed = false;
>   connector->doublescan_allowed = false;
>  
> - /*Attach connector properties*/
> + /* Attach connector 

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Daniel Vetter]

On Tue, May 17, 2016 at 02:22:26PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 17.05.2016 14:12, skrev Ville Syrjälä:
> >On Tue, May 17, 2016 at 02:00:45PM +0200, Noralf Trønnes wrote:
> >>Den 17.05.2016 09:59, skrev Daniel Vetter:
> >>>On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
> On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
> >On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
> >>On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> >>>Provides helper functions for drivers that have a simple display
> >>>pipeline. Plane, crtc and encoder are collapsed into one entity.
> >>>
> >>>Cc: jsarha at ti.com
> >>>Signed-off-by: Noralf Trønnes 
> >>>---
> >>>
> >>>Changes since v3:
> >>>- (struct drm_simple_display_pipe *)->funcs should be const
> >>>
> >>>Changes since v2:
> >>>- Drop Kconfig knob DRM_KMS_HELPER
> >>>- Expand documentation
> >>>
> >>>Changes since v1:
> >>>- Add DOC header and add to gpu.tmpl
> >>>- Fix docs: @funcs is optional, "negative error code",
> >>>"This hook is optional."
> >>>- Add checks to drm_simple_kms_plane_atomic_check()
> >>>
> >>>   Documentation/DocBook/gpu.tmpl  |   6 +
> >>>   drivers/gpu/drm/Makefile|   2 +-
> >>>   drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> >>> 
> >>>   include/drm/drm_simple_kms_helper.h |  94 +++
> >>>   4 files changed, 309 insertions(+), 1 deletion(-)
> >>>   create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
> >>>   create mode 100644 include/drm/drm_simple_kms_helper.h
> >>>
> >>>diff --git a/Documentation/DocBook/gpu.tmpl 
> >>>b/Documentation/DocBook/gpu.tmpl
> >>>index 4a0c599..cf3f5a8 100644
> >>>--- a/Documentation/DocBook/gpu.tmpl
> >>>+++ b/Documentation/DocBook/gpu.tmpl
> >>>@@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
> >>>   !Edrivers/gpu/drm/drm_panel.c
> >>>   !Pdrivers/gpu/drm/drm_panel.c drm panel
> >>>   
> >>>+
> >>>+  Simple KMS Helper Reference
> >>>+!Iinclude/drm/drm_simple_kms_helper.h
> >>>+!Edrivers/gpu/drm/drm_simple_kms_helper.c
> >>>+!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> >>>+
> >>> 
> >>>
> >>> 
> >>>diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> >>>index 2bd3e5a..31b85df5 100644
> >>>--- a/drivers/gpu/drm/Makefile
> >>>+++ b/drivers/gpu/drm/Makefile
> >>>@@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> >>>
> >>>   drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> >>> drm_probe_helper.o \
> >>>   drm_plane_helper.o drm_dp_mst_topology.o 
> >>> drm_atomic_helper.o \
> >>>-  drm_kms_helper_common.o
> >>>+  drm_kms_helper_common.o drm_simple_kms_helper.o
> >>>
> >>>   drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >>>   drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> >>>diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> >>>b/drivers/gpu/drm/drm_simple_kms_helper.c
> >>>new file mode 100644
> >>>index 000..d45417a
> >>>--- /dev/null
> >>>+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> >>>@@ -0,0 +1,208 @@
> >>>+/*
> >>>+ * Copyright (C) 2016 Noralf Trønnes
> >>>+ *
> >>>+ * 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 
> >>>+
> >>>+/**
> >>>+ * DOC: overview
> >>>+ *
> >>>+ * This helper library provides helpers for drivers for simple display
> >>>+ * hardware.
> >>>+ *
> >>>+ * drm_simple_display_pipe_init() initializes a simple display 
> >>>pipeline
> >>>+ * which has only one full-screen scanout buffer feeding one output. 
> >>>The
> >>>+ * pipeline is represented by struct _simple_display_pipe and 
> >>>binds
> >>>+ * together _plane, _crtc and _encoder structures into 
> >>>one fixed
> >>>+ * entity. Some flexibility for code reuse is provided through a 
> >>>separately
> >>>+ * allocated _connector object and supporting optional _bridge
> >>>+ * encoder drivers.
> >>>+ */
> >>>+
> >>>+static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> >>>+  .destroy = drm_encoder_cleanup,
> >>>+};
> >>>+
> >>>+static void drm_simple_kms_crtc_enable(struct drm_crtc 

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

[Marcel Ziswiler]

Hi there

On Fri, 2016-05-13 at 12:33 +0200, Lothar Waßmann wrote:
> Hi,
> 
> the commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module
> autoloading")
> indeed fixes the autoloading issue, but completely breaks the driver
> in
> non-modular mode (at least with the parallel-display driver I didn't
> yet check with the imx-ldb driver.
> Can anyone confirm that the imx-drm driver in current linux-next
> (next-20160512) works for them with any i.MX6 or i.MX53 board?

I can confirm that this is actually broken both in v4.6 and next-
20160517. Reverting commit 407c9eba7897 ("drm/imx: Remove of_node
assignment from ipuv3-crtc driver probe") in both cases makes regular
imx_v6_v7_defconfig work again.

> I'm always very suspicious when seeing code moving of_node's from
> one device to another or assigning of_node's to platform devices that
> weren't instantiated via DT.
> 
> 
> Lothar Waßmann

Cheers

Marcel

> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Noralf Trønnes]

Den 17.05.2016 14:12, skrev Ville Syrjälä:
> On Tue, May 17, 2016 at 02:00:45PM +0200, Noralf Trønnes wrote:
>> Den 17.05.2016 09:59, skrev Daniel Vetter:
>>> On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
 On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
> On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
>> On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
>>> Provides helper functions for drivers that have a simple display
>>> pipeline. Plane, crtc and encoder are collapsed into one entity.
>>>
>>> Cc: jsarha at ti.com
>>> Signed-off-by: Noralf Trønnes 
>>> ---
>>>
>>> Changes since v3:
>>> - (struct drm_simple_display_pipe *)->funcs should be const
>>>
>>> Changes since v2:
>>> - Drop Kconfig knob DRM_KMS_HELPER
>>> - Expand documentation
>>>
>>> Changes since v1:
>>> - Add DOC header and add to gpu.tmpl
>>> - Fix docs: @funcs is optional, "negative error code",
>>> "This hook is optional."
>>> - Add checks to drm_simple_kms_plane_atomic_check()
>>>
>>>Documentation/DocBook/gpu.tmpl  |   6 +
>>>drivers/gpu/drm/Makefile|   2 +-
>>>drivers/gpu/drm/drm_simple_kms_helper.c | 208 
>>> 
>>>include/drm/drm_simple_kms_helper.h |  94 +++
>>>4 files changed, 309 insertions(+), 1 deletion(-)
>>>create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
>>>create mode 100644 include/drm/drm_simple_kms_helper.h
>>>
>>> diff --git a/Documentation/DocBook/gpu.tmpl 
>>> b/Documentation/DocBook/gpu.tmpl
>>> index 4a0c599..cf3f5a8 100644
>>> --- a/Documentation/DocBook/gpu.tmpl
>>> +++ b/Documentation/DocBook/gpu.tmpl
>>> @@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
>>>!Edrivers/gpu/drm/drm_panel.c
>>>!Pdrivers/gpu/drm/drm_panel.c drm panel
>>>
>>> +
>>> +  Simple KMS Helper Reference
>>> +!Iinclude/drm/drm_simple_kms_helper.h
>>> +!Edrivers/gpu/drm/drm_simple_kms_helper.c
>>> +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
>>> +
>>>  
>>>
>>>  
>>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>>> index 2bd3e5a..31b85df5 100644
>>> --- a/drivers/gpu/drm/Makefile
>>> +++ b/drivers/gpu/drm/Makefile
>>> @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
>>>
>>>drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
>>> drm_probe_helper.o \
>>> drm_plane_helper.o drm_dp_mst_topology.o 
>>> drm_atomic_helper.o \
>>> -   drm_kms_helper_common.o
>>> +   drm_kms_helper_common.o drm_simple_kms_helper.o
>>>
>>>drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>>>drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>>> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
>>> b/drivers/gpu/drm/drm_simple_kms_helper.c
>>> new file mode 100644
>>> index 000..d45417a
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
>>> @@ -0,0 +1,208 @@
>>> +/*
>>> + * Copyright (C) 2016 Noralf Trønnes
>>> + *
>>> + * 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 
>>> +
>>> +/**
>>> + * DOC: overview
>>> + *
>>> + * This helper library provides helpers for drivers for simple display
>>> + * hardware.
>>> + *
>>> + * drm_simple_display_pipe_init() initializes a simple display pipeline
>>> + * which has only one full-screen scanout buffer feeding one output. 
>>> The
>>> + * pipeline is represented by struct _simple_display_pipe and binds
>>> + * together _plane, _crtc and _encoder structures into one 
>>> fixed
>>> + * entity. Some flexibility for code reuse is provided through a 
>>> separately
>>> + * allocated _connector object and supporting optional _bridge
>>> + * encoder drivers.
>>> + */
>>> +
>>> +static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
>>> +   .destroy = drm_encoder_cleanup,
>>> +};
>>> +
>>> +static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
>>> +{
>>> +   struct drm_simple_display_pipe *pipe;
>>> +
>>> +   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
>>> +   if (!pipe->funcs || !pipe->funcs->enable)
>>> + 

[PATCH] Revert "drm/imx: Remove of_node assignment from ipuv3-crtc driver probe"

[Fabio Estevam]

Commit 407c9eba789767 ("drm/imx: Remove of_node assignment from ipuv3-crtc
driver probe") causes the IPU to be non-functional, so better to 
revert it to avoid such regression.

This reverts commit 407c9eba789767feb68b42eb2d65db68584e06c0.

Cc:  # 4.4.x
Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index dee8e8b..006753d 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -520,6 +520,28 @@ err_put_resources:
return ret;
 }

+static struct device_node *ipu_drm_get_port_by_id(struct device_node *parent,
+ int port_id)
+{
+   struct device_node *port;
+   int id, ret;
+
+   port = of_get_child_by_name(parent, "port");
+   while (port) {
+   ret = of_property_read_u32(port, "reg", );
+   if (!ret && id == port_id)
+   return port;
+
+   do {
+   port = of_get_next_child(parent, port);
+   if (!port)
+   return NULL;
+   } while (of_node_cmp(port->name, "port"));
+   }
+
+   return NULL;
+}
+
 static int ipu_drm_bind(struct device *dev, struct device *master, void *data)
 {
struct ipu_client_platformdata *pdata = dev->platform_data;
@@ -562,11 +584,23 @@ static const struct component_ops ipu_crtc_ops = {
 static int ipu_drm_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
+   struct ipu_client_platformdata *pdata = dev->platform_data;
int ret;

if (!dev->platform_data)
return -EINVAL;

+   if (!dev->of_node) {
+   /* Associate crtc device with the corresponding DI port node */
+   dev->of_node = ipu_drm_get_port_by_id(dev->parent->of_node,
+ pdata->di + 2);
+   if (!dev->of_node) {
+   dev_err(dev, "missing port@%d node in %s\n",
+   pdata->di + 2, dev->parent->of_node->full_name);
+   return -ENODEV;
+   }
+   }
+
ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
-- 
1.9.1

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Noralf Trønnes]

Den 17.05.2016 09:59, skrev Daniel Vetter:
> On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
>> On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
>>> On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
 On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> Provides helper functions for drivers that have a simple display
> pipeline. Plane, crtc and encoder are collapsed into one entity.
>
> Cc: jsarha at ti.com
> Signed-off-by: Noralf Trønnes 
> ---
>
> Changes since v3:
> - (struct drm_simple_display_pipe *)->funcs should be const
>
> Changes since v2:
> - Drop Kconfig knob DRM_KMS_HELPER
> - Expand documentation
>
> Changes since v1:
> - Add DOC header and add to gpu.tmpl
> - Fix docs: @funcs is optional, "negative error code",
>"This hook is optional."
> - Add checks to drm_simple_kms_plane_atomic_check()
>
>   Documentation/DocBook/gpu.tmpl  |   6 +
>   drivers/gpu/drm/Makefile|   2 +-
>   drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> 
>   include/drm/drm_simple_kms_helper.h |  94 +++
>   4 files changed, 309 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
>   create mode 100644 include/drm/drm_simple_kms_helper.h
>
> diff --git a/Documentation/DocBook/gpu.tmpl 
> b/Documentation/DocBook/gpu.tmpl
> index 4a0c599..cf3f5a8 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
>   !Edrivers/gpu/drm/drm_panel.c
>   !Pdrivers/gpu/drm/drm_panel.c drm panel
>   
> +
> +  Simple KMS Helper Reference
> +!Iinclude/drm/drm_simple_kms_helper.h
> +!Edrivers/gpu/drm/drm_simple_kms_helper.c
> +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> +
> 
>
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2bd3e5a..31b85df5 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
>
>   drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o 
> drm_atomic_helper.o \
> - drm_kms_helper_common.o
> + drm_kms_helper_common.o drm_simple_kms_helper.o
>
>   drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>   drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> new file mode 100644
> index 000..d45417a
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -0,0 +1,208 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * 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 
> +
> +/**
> + * DOC: overview
> + *
> + * This helper library provides helpers for drivers for simple display
> + * hardware.
> + *
> + * drm_simple_display_pipe_init() initializes a simple display pipeline
> + * which has only one full-screen scanout buffer feeding one output. The
> + * pipeline is represented by struct _simple_display_pipe and binds
> + * together _plane, _crtc and _encoder structures into one 
> fixed
> + * entity. Some flexibility for code reuse is provided through a 
> separately
> + * allocated _connector object and supporting optional _bridge
> + * encoder drivers.
> + */
> +
> +static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> +static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> + if (!pipe->funcs || !pipe->funcs->enable)
> + return;
> +
> + pipe->funcs->enable(pipe, crtc->state);
> +}
> +
> +static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> + if (!pipe->funcs || !pipe->funcs->disable)
> + return;
> +
> + pipe->funcs->disable(pipe);

[GIT PULL] imx-drm module autoloading fix

[Philipp Zabel]

Am Dienstag, den 17.05.2016, 10:56 +0200 schrieb Philipp Zabel:
> Am Donnerstag, den 05.05.2016, 10:37 +1000 schrieb Dave Airlie:
> > On 3 May 2016 at 18:48, Philipp Zabel  wrote:
> > > Hi Dave,
> > >
> > > here is the imx-ipuv3-crtc autoloading fix so you don't have to revert 
> > > commit
> > > 304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to
> > > corresponding ports").
> > 
> > I didn't pull this, but I cherry-picked the patch out and added stable
> > tags on it
> > since Denis wanted to get it into 4.4 and above.
> 
> It turns out this patch breaks probing for the built-in case [1]. As a
> result, imx-drm probing is broken in v4.6. I have sent a patch [2] to
> fix the issue by matching the crtc components not against dev->of_node
> but against an of_node pointer stored in platform data.
> 
> [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/499839
> Message-ID: <20160513123336.6996dd89 at ipc1.ka-ro>
> [2] https://patchwork.kernel.org/patch/9081661/
> Message-ID: <1463062124-20256-1-git-send-email-p.zabel at pengutronix.de>
> 
> Could we apply that or revert commit 407c9eba7897 ("drm/imx: Remove
> of_node assignment from ipuv3-crtc driver probe") for the time being?
> 
> Either way, applying this patch without doing either of the two will
> break imx-drm probing in v4.4 and v4.5 stable, too.

I stand corrected, v4.4.10 and v4.5.4 are already broken, too.

regards
Philipp

[PATCH v3 7/7] dt-bindings: drm/bridge: Update bindings for ADV7533

[Xinliang Liu]

On 17 May 2016 at 11:43, Archit Taneja  wrote:
>
>
> On 05/16/2016 05:31 PM, Laurent Pinchart wrote:
>>
>> Hi Archit,
>>
>> On Friday 22 Apr 2016 11:10:18 Archit Taneja wrote:
>>>
>>> On 04/22/2016 04:02 AM, Laurent Pinchart wrote:

 On Wednesday 09 Mar 2016 16:27:18 Archit Taneja wrote:
>
> Add description of ADV7533. Add the required and optional properties
> that
> are specific to it.
>
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring 
>
> Signed-off-by: Archit Taneja 
> ---
>
> .../bindings/display/bridge/adi,adv7511.txt| 25
> -
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> index
> 96c25ee..420da5a 100644
> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>>
>>
>> [snip]
>>
> +- adi,disable-timing-generator: Only for ADV7533. Disables the
> internal
> timing
> +  generator. The chip will rely on the sync signals in the DSI data
> lanes,
> +  rather than generate its own timings for HDMI output.


 Isn't that something that should be selectable at runtime ?
>>>
>>>
>>> The timing generator can be enabled/disabled at runtime. Although, we
>>> don't have a way to tell the driver whether we want to keep it enabled
>>> or not.
>>>
>>> It's a hardware feature that works well on most platforms, but not on
>>> all. In particular, it works well on DB410c, but causes issues with
>>> the Hikey 96 board. The DSI host on Hikey has different clock sources
>>> that generate the display controller's pixel clock and DSI byte clock,
>>> whereas the Qualcomm SoC uses the same source. My guess is that the
>>> ADV7533's timing generator doesn't like it when the pixel data and
>>> clock are out of phase or something.
>>>
>>> Since it is a hardware feature which needs tweaking, I thought it
>>> qualified as a DT property.
>>
>>
>> The fact that a hardware generator is present is certainly describes the
>> hardware, but I'm not sure whether to enable it or not also qualifies as a
>> hardware feature.
>>
>> Are there use cases for using the timing generator conditionally on a
>> given
>> board ? As you implement support for disabling it, I assume it's not
>> mandatory. What feature(s) do we lose if we keep it disabled ?
>>
>
> The spec says it's recommended to use the internal timing generator. In
> the case of db410c, I observe an unstable output/flicker for certain
> modes if I don't enable it.
>
> In the case of hikey platform, it's the other way round.
>
> Xinliang, could you describe the problems you face when the timing
> generator is enabled?

Yes,  opening the timing generator of ADV7533 can benefit the HDMI
output signal.
But, for some circumstances, we need to disable timing generator:
To make modes work, the timing parameters (hfp, hbp, etc.) used by
ADV7533 timing generator should match the ones used in DSI.
If the timing parameters changed in DSI and these changing  timing
parameters can't pass to ADV7533, then it need to disable the timing
generator of ADV7533 to make mode work.
Some modes in HiKey is in this case.

Thanks,
-xinliang

>
>
> Thanks,
> Archit
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation

[Bug 95329] Metro 2033 Redux benchmark fails to start

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

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

Jan Ziak <0xe2.0x9a.0x9b at gmail.com> changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #3 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
The cause of the issue is in metro.bin, not in Mesa. Found via running
"valgrind benchmark.sh".

The following code fixes the issue:

$ cat posix_memalign.c
#include 
#include 
#include 
#include 

int posix_memalign(void **memptr, size_t alignment, size_t size) {
if(alignment < 32) {
alignment = 32;  // Optional. Might boost memcpy().
}
size *= 2;   // Required
void *p = memalign(alignment, size);
if(!p && size) {
return ENOMEM;
}
bzero(p, size);  // Optional
*memptr = p;
return 0;
}

$ gcc -m32 -shared -fPIC -O2 -g -Wall -Werror -std=c99 -o posix_memalign32.so
posix_memalign.c
$ gcc -m64 -shared -fPIC -O2 -g -Wall -Werror -std=c99 -o posix_memalign64.so
posix_memalign.c
$ export
LD_PRELOAD="$PWD/posix_memalign32.so:$PWD/posix_memalign64.so:$LD_PRELOAD"
$ .../Metro 2033 Redux/benchmark.sh

-- 
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/20160517/fe1b63a6/attachment.html>

[PATCH v2] drm/amd/powerplay: use ARRAY_SIZE() to calculate array size.

[Muhammad Falak R Wani]

On Mon, May 16, 2016 at 04:53:50PM +0100, Eric Engestrom wrote:
> On Fri, May 13, 2016 at 11:06:40PM +0530, Muhammad Falak R Wani wrote:
> > It is preferred to use ARRAY_SIZE() for size calculation, instead
> > using sizeof(array)/sizeof(*array). It makes the code more readable.
> > 
> > Signed-off-by: Muhammad Falak R Wani 
> 
> Reviewed-by: Eric Engestrom 
> 
> Thanks, and sorry about before, if I made you feel like you made
> a "childish mistake". As Dan said, this is mostly a question of
> style: your code was right, it just had an unnecessary bit.
> 
> I hope I didn't give you a bad impression of the community, most
> people around here have better manners than I :P
> 
> Cheers
Thank you for such a nice gesture. No, I didn't get any bad impression.
Infact people learn like this.

Thank you guys :)

[PATCH 09/20] drm/sun4i: defer only if we didn't find our panel

[Chen-Yu Tsai]

Hi,

On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
 wrote:
> Our code currently defers our probe on any error, even if we were not
> expecting to have one at all.
>
> Make sure we return -EPROBE_DEFER only when we were supposed to have a
> panel, but it's not probed yet.
>
> Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output")
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 9f19b0e08560..eed6a9e8d9a6 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -429,7 +429,7 @@ static struct drm_panel *sun4i_tcon_find_panel(struct 
> device_node *node)
> return ERR_PTR(-EINVAL);
> }
>
> -   return of_drm_find_panel(remote);
> +   return of_drm_find_panel(remote) ?: ERR_PTR(-EPROBE_DEFER);

There's also a typo in the DRM_DEBUG_DRIVER call a few lines up. Could you
fix it as well?

ChenYu

>  }
>
>  static int sun4i_tcon_bind(struct device *dev, struct device *master,
> @@ -522,12 +522,13 @@ static int sun4i_tcon_probe(struct platform_device 
> *pdev)
>  * Defer the probe.
>  */
> panel = sun4i_tcon_find_panel(node);
> -   if (IS_ERR(panel)) {
> -   /*
> -* If we don't have a panel endpoint, just go on
> -*/
> -   if (PTR_ERR(panel) != -ENODEV)
> -   return -EPROBE_DEFER;
> +
> +   /*
> +* If we don't have a panel endpoint, just go on
> +*/
> +   if (PTR_ERR(panel) == -EPROBE_DEFER) {
> +   DRM_DEBUG_DRIVER("Still waiting for our panel. 
> Deferring...\n");
> +   return -EPROBE_DEFER;
> }
>
> return component_add(>dev, _tcon_ops);
> --
> 2.8.2
>

[PATCH 08/20] drm/sun4i: rgb: panel is an error pointer

[Chen-Yu Tsai]

Hi,

On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
 wrote:
> In case of an error, our pointer to the drm_panel structure attached to our
> encoder will hold an error pointer, not a NULL pointer.
>
> Make sure we check the right thing.
>
> Fixes: 29e57fab97fc ("drm: sun4i: Add RGB output")
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index 923f55039cb1..b46d2c15dc95 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -217,7 +217,7 @@ int sun4i_rgb_init(struct drm_device *drm)
> int ret;
>
> /* If we don't have a panel, there's no point in going on */
> -   if (!tcon->panel)
> +   if (IS_ERR(tcon->panel))

Without the next patch, tcon->panel could be the result of of_drm_find_panel(),
which could be NULL.

Use IS_ERR_OR_NULL here, or reorder/squash the patches.

Regards
ChenYu

> return -ENODEV;
>
> rgb = devm_kzalloc(drm->dev, sizeof(*rgb), GFP_KERNEL);
> --
> 2.8.2
>

[PATCH 17/20] ARM: multi_v7: Enable sun4i DRM driver

[Chen-Yu Tsai]

On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
 wrote:
> Enable the new DRM driver in the multi_v7 defconfig
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

[drm:drm-next 990/1014] ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference function or variable defined in the kernel

[Emil Velikov]

On 17 May 2016 at 09:19, kbuild test robot  wrote:
> tree:   git://people.freedesktop.org/~airlied/linux.git drm-next
> head:   7c10ddf87472c07eabc206e273dc59f77c700858
> commit: cfa7152f1cfeedba7c4ab3abcb4accee94cc2c0f [990/1014] drm/amdgpu: add 
> extern C guard for the UAPI header
> config: i386-tinyconfig (attached as .config)
> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> reproduce:
> git checkout cfa7152f1cfeedba7c4ab3abcb4accee94cc2c0f
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All warnings (new ones prefixed by >>):
>
>>> ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference function or 
>>> variable defined in the kernel
>
Interesting that target does not execute on my system. Must have
something different here.

The messages seems bogus, since scripts/headers_check.pl does not
expand/evaluate the macros, but blindly checks line by line looking
for "extern|unsigned|char|short|int|long|void". We actually removed
some of these recently ... yay :-)

Quickest solution would be to skip "extern \"C\"", the long term
solution is to teach the script to honour/evaluate macros. Leaning
towards the latter since my Perl is quite rough.. do we have any Perl
experts around willing to make the script smarter ?

Thanks
Emil

More build fixes for omapdrm in current -next

[Tomi Valkeinen]

On 11/05/16 19:01, Arnd Bergmann wrote:
> A couple more errors showed up in linux-next in the last few
> days, all because of missing header files. I have not seen these
> before, and most configurations appear to be fine. There
> must have been an implicit inclusion somewhere before that
> just got removed, but I couldn't find it and doing the
> explicit #include should always be better here.

Thanks. I picked the first one as is, and third one with some conflict
resolutions. A patch similar to the second one was already queued.

 Tomi

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

ast: cursor flashing softlockups

[David Daney]

On 05/17/2016 10:39 AM, David Daney wrote:
> I can confirm this.

I have a patch that I think is the proper fix.  You should see it soon 
(after I test it a bit more)

Thanks,
David Daney


[...]

>>>
>>> On Tue, May 17, 2016 at 4:07 AM, Dann Frazier
>>>  wrote:
 Hi,
   I'm observing a soft lockup issue w/ the ASPEED controller on an
 arm64 server platform. This was originally seen on Ubuntu's 4.4
 kernel, but it is reproducible w/ vanilla 4.6-rc7 as well.

 [   32.792656] NMI watchdog: BUG: soft lockup - CPU#38 stuck for 22s!
 [swapper/38:0]

 I observe this just once each time I boot into debian-installer (I'm
 using a serial console, but the ast module gets loaded during
 startup).
>>>
>>> I have figured out that it is caused by 'mod_timer(timer, jiffies)' and
>>> 'ops->cur_blink_jiffies' is observed as zero in cursor_timer_handler()
>>> when the issue happened.
>>
>> Thanks for tracking this down.
>>
>> This softlockup looks to be caused by:
>>
>> commit 27a4c827c34ac4256a190cc9d24607f953c1c459
>> Author: Scot Doyle 
>> Date:   Thu Mar 26 13:56:38 2015 +
>>
>> fbcon: use the cursor blink interval provided by vt
>>
>> vt now provides a cursor blink interval via vc_data. Use this
>> interval instead of the currently hardcoded 200 msecs. Store
>> it in
>> fbcon_ops to avoid locking the console in cursor_timer_handler().
>>
>> Signed-off-by: Scot Doyle 
>> Acked-by: Pavel Machek 
>> Signed-off-by: Greg Kroah-Hartman 
>>
>> and
>>
>> commit bd63364caa8df38bad2b25b11b2a1b849475cce5
>> Author: Scot Doyle 
>> Date:   Thu Mar 26 13:54:39 2015 +
>>
>> vt: add cursor blink interval escape sequence
>>
>> Add an escape sequence to specify the current console's cursor
>> blink
>> interval. The interval is specified as a number of
>> milliseconds until
>> the next cursor display state toggle, from 50 to 65535.
>> /proc/loadavg
>> did not show a difference with a one msec interval, but the lower
>> bound is set to 50 msecs since slower hardware wasn't tested.
>>
>> Store the interval in the vc_data structure for later access
>> by fbcon,
>> initializing the value to fbcon's current hardcoded value of
>> 200 msecs.
>>
>> Signed-off-by: Scot Doyle 
>> Acked-by: Pavel Machek 
>> Signed-off-by: Greg Kroah-Hartman 
>>
>>
>>
>>> Looks it is a real fbcon/vt issue, see following:
>>>
>>> fbcon_init()
>>>  <-.con_init
>>><-visual_init()
>>>
>>> reset_terminal()
>>>  <-vc_init()
>>>
>>> vc->vc_cur_blink_ms is just set in reset_terminal() from vc_init() path,
>>> and ops->cur_blink_jiffies is figured out from vc->vc_cur_blink_ms
>>> in fbcon_init().
>>>
>>> And visual_init() is always run before vc_init(), so
>>> ops->cur_blink_jiffies
>>> is initialized as zero and cause the soft lockup issue finally.
>>>
>>> Thanks,
>>> Ming
>>>

 perf shows that the CPU caught by the NMI is typically in code
 updating the cursor timer:

 -   16.92%  swapper  [kernel.kallsyms]  [k]
 _raw_spin_unlock_irqrestore
 - _raw_spin_unlock_irqrestore
+ 16.87% mod_timer
+ 0.05% cursor_timer_handler
 -   12.15%  swapper  [kernel.kallsyms]  [k] queue_work_on
 - queue_work_on
+ 12.00% cursor_timer_handler
+ 0.15% call_timer_fn
 +   10.98%  swapper  [kernel.kallsyms]  [k] run_timer_softirq
 -2.23%  swapper  [kernel.kallsyms]  [k] mod_timer
 - mod_timer
+ 1.97% cursor_timer_handler
+ 0.26% call_timer_fn

 During the same period, I can see that another CPU is actively
 executing the timer function:

 -   42.18%  kworker/u96:2  [kernel.kallsyms]  [k] ww_mutex_unlock
 - ww_mutex_unlock
- 40.70% ast_dirty_update
 ast_imageblit
 soft_cursor
 bit_cursor
 fb_flashcursor
 process_one_work
 worker_thread
 kthread
 ret_from_fork
+ 1.48% ast_imageblit
 -   40.15%  kworker/u96:2  [kernel.kallsyms]  [k] __memcpy_toio
 - __memcpy_toio
+ 31.54% ast_dirty_update
+ 8.61% ast_imageblit

 Using the graph function tracer on fb_flashcursor(), I see that
 ast_dirty_update usually takes around 60 us, in which it makes 16
 calls to __memcpy_toio(). However, there is always one instance on
 every boot of the installer where ast_dirty_update() takes ~98 *ms* to
 complete, during which it makes 743 calls to __memcpy_toio(). While
 that  doesn't directly account for the full 22s, I do wonder if that
 maybe a smoking gun.

 fyi, this is being tracked at: https://bugs.launchpad.net/bugs/1574814

-dann
>>
>

[GIT PULL] imx-drm module autoloading fix

[Philipp Zabel]

Am Donnerstag, den 05.05.2016, 10:37 +1000 schrieb Dave Airlie:
> On 3 May 2016 at 18:48, Philipp Zabel  wrote:
> > Hi Dave,
> >
> > here is the imx-ipuv3-crtc autoloading fix so you don't have to revert 
> > commit
> > 304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to
> > corresponding ports").
> 
> I didn't pull this, but I cherry-picked the patch out and added stable
> tags on it
> since Denis wanted to get it into 4.4 and above.

It turns out this patch breaks probing for the built-in case [1]. As a
result, imx-drm probing is broken in v4.6. I have sent a patch [2] to
fix the issue by matching the crtc components not against dev->of_node
but against an of_node pointer stored in platform data.

[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/499839
Message-ID: <20160513123336.6996dd89 at ipc1.ka-ro>
[2] https://patchwork.kernel.org/patch/9081661/
Message-ID: <1463062124-20256-1-git-send-email-p.zabel at pengutronix.de>

Could we apply that or revert commit 407c9eba7897 ("drm/imx: Remove
of_node assignment from ipuv3-crtc driver probe") for the time being?

Either way, applying this patch without doing either of the two will
break imx-drm probing in v4.4 and v4.5 stable, too.

regards
Philipp

[RFC 2/3] drm/mediatek: add support for Mediatek SoC MT2701

[Emil Velikov]

Hi YT Shen,

On 12 May 2016 at 12:49,   wrote:
> From: YT Shen 
>
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701, and we have shadow
> register support here.
>
> Signed-off-by: YT Shen 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |   49 ++---
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|   36 +--
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   78 +-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |  151 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |2 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   63 +--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   15 +++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   72 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |9 ++
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c  |4 +
>  10 files changed, 373 insertions(+), 106 deletions(-)
>
This patch does a bit too many things at once imho
 - Renames existing macros
 - Factors out helper functions - mtk_crtc_ddp_config and alike.
 - Introduces *driver_data for existing hardware and uses it
 - and adds support for the different hardware.

I'm no expert in the area, but it feels like you want to split things
roughly as per above.
A rather serious mali note and some "this should be const" follow
suggestions inline.


>
> +static struct mtk_ddp_comp_driver_data mt2701_ovl_driver_data = {
> +   .ovl = {0x0040, 1 << 12, 0}
> +};
> +
> +static struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
> +   .ovl = {0x0f40, 0, 1 << 12}
> +};
> +
These two should be const right ?


>
> +static struct mtk_ddp_comp_driver_data mt2701_rdma_driver_data = {
> +   .rdma_fifo_pseudo_size = SZ_4K,
> +};
> +
> +static struct mtk_ddp_comp_driver_data mt8173_rdma_driver_data = {
> +   .rdma_fifo_pseudo_size = SZ_8K,
> +};
> +
Same here.


>
> -#define MUTEX_MOD_DISP_OVL0BIT(11)
> -#define MUTEX_MOD_DISP_OVL1BIT(12)
> -#define MUTEX_MOD_DISP_RDMA0   BIT(13)
> -#define MUTEX_MOD_DISP_RDMA1   BIT(14)
> -#define MUTEX_MOD_DISP_RDMA2   BIT(15)
> -#define MUTEX_MOD_DISP_WDMA0   BIT(16)
> -#define MUTEX_MOD_DISP_WDMA1   BIT(17)
> -#define MUTEX_MOD_DISP_COLOR0  BIT(18)
> -#define MUTEX_MOD_DISP_COLOR1  BIT(19)
> -#define MUTEX_MOD_DISP_AAL BIT(20)
> -#define MUTEX_MOD_DISP_GAMMA   BIT(21)
> -#define MUTEX_MOD_DISP_UFOEBIT(22)
> -#define MUTEX_MOD_DISP_PWM0BIT(23)
> -#define MUTEX_MOD_DISP_PWM1BIT(24)
> -#define MUTEX_MOD_DISP_OD  BIT(25)
> +#define MUTEX_MOD_MT8173_DISP_OVL0 BIT(11)
> +#define MUTEX_MOD_MT8173_DISP_OVL1 BIT(12)
> +#define MUTEX_MOD_MT8173_DISP_RDMA0BIT(13)
> +#define MUTEX_MOD_MT8173_DISP_RDMA1BIT(14)
> +#define MUTEX_MOD_MT8173_DISP_RDMA2BIT(15)
> +#define MUTEX_MOD_MT8173_DISP_WDMA0BIT(16)
> +#define MUTEX_MOD_MT8173_DISP_WDMA1BIT(17)
> +#define MUTEX_MOD_MT8173_DISP_COLOR0   BIT(18)
> +#define MUTEX_MOD_MT8173_DISP_COLOR1   BIT(19)
> +#define MUTEX_MOD_MT8173_DISP_AAL  BIT(20)
> +#define MUTEX_MOD_MT8173_DISP_GAMMABIT(21)
> +#define MUTEX_MOD_MT8173_DISP_UFOE BIT(22)
> +#define MUTEX_MOD_MT8173_DISP_PWM0 BIT(23)
> +#define MUTEX_MOD_MT8173_DISP_PWM1 BIT(24)
> +#define MUTEX_MOD_MT8173_DISP_OD   BIT(25)
> +
> +#define MUTEX_MOD_MT2701_DISP_OVL  BIT(3)
> +#define MUTEX_MOD_MT2701_DISP_WDMA BIT(6)
> +#define MUTEX_MOD_MT2701_DISP_COLORBIT(7)
> +#define MUTEX_MOD_MT2701_DISP_BLS  BIT(9)
> +#define MUTEX_MOD_MT2701_DISP_RDMA0BIT(10)
> +#define MUTEX_MOD_MT2701_DISP_RDMA1BIT(12)
>
Even though the driver not does use a unique prefix/namespace for
these macros (which it should imho), it's better to keep the hardware
name/part first. Ideally the rename will be a separate patch.


> @@ -131,6 +153,32 @@ static const struct mtk_ddp_comp_match 
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA1]   = { MTK_DISP_WDMA,  1, NULL },
>  };
>
> +static struct mtk_ddp_comp_driver_data mt2701_color_driver_data = {
> +   .color_offset = 0x0f00,
> +};
> +
> +static struct mtk_ddp_comp_driver_data mt8173_color_driver_data = {
> +   .color_offset = 0x0c00,
> +};
> +
const again ? You can even tweak the *_get_driver_data helpers, to
return const struct foo*, and resolve the odd warning that the
compiler will give you.


>  struct mtk_ddp_comp {
> struct clk *clk;
> void __iomem *regs;
> @@ -82,6 +96,7 @@ struct mtk_ddp_comp {
> struct device *larb_dev;
> enum mtk_ddp_comp_id id;
> const struct mtk_ddp_comp_funcs *funcs;
> +   struct mtk_ddp_comp_driver_data *data;
const


> +static struct mtk_mmsys_driver_data 

[Bug 95452] System freeze radeon 5770

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

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

--- Comment #3 from Vedran Miletić  ---
Fingers crossed. There will be many revisions to test (apparently), so thanks
in advance for your effort.

-- 
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/20160517/1cda64b6/attachment-0001.html>

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Ville Syrjälä]

On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
> On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
> > On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> > > Provides helper functions for drivers that have a simple display
> > > pipeline. Plane, crtc and encoder are collapsed into one entity.
> > > 
> > > Cc: jsarha at ti.com
> > > Signed-off-by: Noralf Trønnes 
> > > ---
> > > 
> > > Changes since v3:
> > > - (struct drm_simple_display_pipe *)->funcs should be const
> > > 
> > > Changes since v2:
> > > - Drop Kconfig knob DRM_KMS_HELPER
> > > - Expand documentation
> > > 
> > > Changes since v1:
> > > - Add DOC header and add to gpu.tmpl
> > > - Fix docs: @funcs is optional, "negative error code",
> > >   "This hook is optional."
> > > - Add checks to drm_simple_kms_plane_atomic_check()
> > > 
> > >  Documentation/DocBook/gpu.tmpl  |   6 +
> > >  drivers/gpu/drm/Makefile|   2 +-
> > >  drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> > > 
> > >  include/drm/drm_simple_kms_helper.h |  94 +++
> > >  4 files changed, 309 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
> > >  create mode 100644 include/drm/drm_simple_kms_helper.h
> > > 
> > > diff --git a/Documentation/DocBook/gpu.tmpl 
> > > b/Documentation/DocBook/gpu.tmpl
> > > index 4a0c599..cf3f5a8 100644
> > > --- a/Documentation/DocBook/gpu.tmpl
> > > +++ b/Documentation/DocBook/gpu.tmpl
> > > @@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
> > >  !Edrivers/gpu/drm/drm_panel.c
> > >  !Pdrivers/gpu/drm/drm_panel.c drm panel
> > >  
> > > +
> > > +  Simple KMS Helper Reference
> > > +!Iinclude/drm/drm_simple_kms_helper.h
> > > +!Edrivers/gpu/drm/drm_simple_kms_helper.c
> > > +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> > > +
> > >
> > > 
> > >
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 2bd3e5a..31b85df5 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> > > 
> > >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o 
> > > \
> > >   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> > > - drm_kms_helper_common.o
> > > + drm_kms_helper_common.o drm_simple_kms_helper.o
> > > 
> > >  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > >  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > new file mode 100644
> > > index 000..d45417a
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > @@ -0,0 +1,208 @@
> > > +/*
> > > + * Copyright (C) 2016 Noralf Trønnes
> > > + *
> > > + * 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 
> > > +
> > > +/**
> > > + * DOC: overview
> > > + *
> > > + * This helper library provides helpers for drivers for simple display
> > > + * hardware.
> > > + *
> > > + * drm_simple_display_pipe_init() initializes a simple display pipeline
> > > + * which has only one full-screen scanout buffer feeding one output. The
> > > + * pipeline is represented by struct _simple_display_pipe and binds
> > > + * together _plane, _crtc and _encoder structures into one 
> > > fixed
> > > + * entity. Some flexibility for code reuse is provided through a 
> > > separately
> > > + * allocated _connector object and supporting optional _bridge
> > > + * encoder drivers.
> > > + */
> > > +
> > > +static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> > > + .destroy = drm_encoder_cleanup,
> > > +};
> > > +
> > > +static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> > > +{
> > > + struct drm_simple_display_pipe *pipe;
> > > +
> > > + pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> > > + if (!pipe->funcs || !pipe->funcs->enable)
> > > + return;
> > > +
> > > + pipe->funcs->enable(pipe, crtc->state);
> > > +}
> > > +
> > > +static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
> > > +{
> > > + struct drm_simple_display_pipe *pipe;
> > > +
> > > + pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> > > + if (!pipe->funcs || !pipe->funcs->disable)
> > > + return;
> > > +
> > > + pipe->funcs->disable(pipe);
> > > +}
> > > +
> > > +static const struct drm_crtc_helper_funcs 
> > > drm_simple_kms_crtc_helper_funcs = {
> > > + .disable = 

[Bug 92936] Tonga powerplay isssues

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

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

--- Comment #21 from Andy Furniss  ---
Created attachment 123820
  --> https://bugs.freedesktop.org/attachment.cgi?id=123820=edit
uvd hung task

-- 
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/20160517/9fe2f7af/attachment.html>

[Bug 92936] Tonga powerplay isssues

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

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

--- Comment #20 from Andy Furniss  ---
Though UVD seems to work for normal samples upto 2160p now, with an extreme
test I can lock GPU using it with powerplay=1 on low/auto but not (so far) =0.

With this sample there is also a corruption issue even with powerplay=0.

The sample decodes perfectly every time at full speed (player) with powerplay=1
and clocks forced high.

Tested with mpv mainly, but kodi, mplayer, decoding to ram with ffmpeg, gst omx
or gst vaapi all give similar results. Similar = decoding to ram may avoid the
lock (which always happens with players) but will be corrupt on auto. It is
still possible to lock decoding to ram.

Historically with a "normal" 2160p60 I have seen this rarely, but something
seems to have become more efficient so that 2160p60 that needed clocks forced
high will work on auto now.

The issue with this sample exists on older kernels as well as current.

The Sample is rather large and 4080x4096, it is "free" for testing AIUI as the
source images are from vqeg.

I thought I would upload it as I notice Leo Liu works on UVD and has a tonga.

It's 300 meg for 8.6 seconds! made to level 5.2 cbr (but is > 5.2 due to frame
size/num refs)

https://drive.google.com/file/d/0BxP5-S1t9VEEWGREeXlrQkZfaDQ/view?usp=sharing

Testing on a 1920x1080 screen with mpv -fs --hwdec=vdpau it will hang quickly
though GPU is still OK at this point. I could even run a gl Unigine bench  OK
(though mem clock is stuck low).

Trying to switch vt or quit X would hang display.

pkill -9 mpv won't instantly lock display (I use non compositing desktop), but
touching gl even glxinfo will then lock display.

Waiting 2 minutes before sysrq will give attached hung task trace.

-- 
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/20160517/a8714313/attachment.html>

ast: cursor flashing softlockups

[David Daney]

I can confirm this.  The cursor is blinking along nicely with a 200mS 
on/off time then with this patch installed:

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 6e92917..7855446 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -402,6 +402,8 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fbcon_ops *ops = info->fbcon_par;

queue_work(system_power_efficient_wq, >queue);
+   if (WARN_ON(ops->cur_blink_jiffies < 10))
+   ops->cur_blink_jiffies = 200;
mod_timer(>cursor_timer, jiffies + ops->cur_blink_jiffies);
  }

@@ -417,6 +419,8 @@ static void fbcon_add_cursor_timer(struct fb_info *info)

init_timer(>cursor_timer);
ops->cursor_timer.function = cursor_timer_handler;
+   if (WARN_ON(ops->cur_blink_jiffies < 10))
+   ops->cur_blink_jiffies = 200;
ops->cursor_timer.expires = jiffies + ops->cur_blink_jiffies;
ops->cursor_timer.data = (unsigned long ) info;
add_timer(>cursor_timer);
@@ -1096,6 +1100,7 @@ static void fbcon_init(struct vc_data *vc, int init)

ops = info->fbcon_par;
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
+   WARN_ON(ops->cur_blink_jiffies < 10);
p->con_rotate = initial_rotation;
set_blitting_type(vc, info);

@@ -1310,6 +1315,7 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
int c = scr_readw((u16 *) vc->vc_pos);

ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
+   WARN_ON(ops->cur_blink_jiffies < 10);

if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1)
return;

-

I get:


[   29.386066] [ cut here ]
[   29.386080] WARNING: CPU: 0 PID: 1688 at 
drivers/video/console/fbcon.c:1103 fbcon_init+0x47c/0x4b8
[   29.386145] Modules linked in: vfat(E) fat(E) aes_ce_blk(E) 
ablk_helper(E) cryptd(E) aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) 
sha1_ce(E) sg(E) ip_tables(E) xfs(E) libcrc32c(E) nicvf(E) ast(E) 
i2c_algo_bit(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) 
sysimgblt(E) fb_sys_fops(E) ttm(E) drm(E) i2c_core(E) nicpf(E) 
thunder_bgx(E) mdio_thunder(E) mdio_cavium(E) dm_mirror(E) 
dm_region_hash(E) dm_log(E) dm_mod(E)
[   29.386147]
[   29.386153] CPU: 0 PID: 1688 Comm: systemd-logind Tainted: G 
E   4.6.0-rc3-arm64next+ #278
[   29.386155] Hardware name: www.cavium.com ThunderX CRB-2S/ThunderX 
CRB-2S, BIOS 0.3 Apr 25 2016
[   29.386159] task: fe0fd1109d80 ti: fe0fd119c000 task.ti: 
fe0fd119c000
[   29.386163] PC is at fbcon_init+0x47c/0x4b8
[   29.386167] LR is at fbcon_init+0x144/0x4b8
[   29.386170] pc : [] lr : [] 
pstate: 8145
[   29.386172] sp : fe0fd119f900
[   29.386179] x29: fe0fd119f900 x28: fe0fdc059c00
[   29.386186] x27: fe001c7c8800 x26: fe0fd6027910
[   29.386192] x25: fe0fd6027800 x24: fc0009b56f98
[   29.386198] x23: 0001 x22: fc0008d1a000
[   29.386205] x21: fe0ff4062000 x20: fc0009b57018
[   29.386211] x19: fc0009b56000 x18: 02aae7bd51f0
[   29.386222] x17: 03ffb542f9f0 x16: fc0008242b80
[   29.386228] x15: 02aae7bdb328 x14: 0006
[   29.386234] x13: 02aae7bc72c8 x12: 
[   29.386240] x11:  x10: 
[   29.386247] x9 :  x8 : fe001c7c8b18
[   29.386253] x7 :  x6 : 007f
[   29.386259] x5 : fc0008c91640 x4 : 
[   29.386266] x3 : 0800 x2 : fe001c7c8ce8
[   29.386272] x1 : fe0fd4df4e00 x0 : 
[   29.386274]
[   29.386277] ---[ end trace 6c32ddc01008c9ba ]---
[   29.386280] Call trace:
[   29.386284] Exception stack(0xfe0fd119f730 to 0xfe0fd119f850)
[   29.386288] f720:   fc0009b56000 
fc0009b57018
[   29.386292] f740: fe0fd119f900 fc0008468930 8145 
003d
[   29.386296] f760: fc0008c36ce8 fc00081c2a30 fe0fd119f7f0 
fc00080f47d8
[   29.386299] f780: fe0fd119f800 fc00080f47d8 010c 
fe0fd1109d80
[   29.386303] f7a0:  0025810c fe0fd110a5a0 

[   29.386307] f7c0: fc000880d2e8  fe0fd119f850 
fc00080f47d8
[   29.386311] f7e0:  fe0fd4df4e00 fe001c7c8ce8 
0800
[   29.386314] f800:  fc0008c91640 007f 

[   29.386318] f820: fe001c7c8b18   

[   29.386321] f840:  02aae7bc72c8
[   29.386327] [] fbcon_init+0x47c/0x4b8
[   29.386332] [] visual_init+0xbc/0x114
[   29.386336] [] vc_allocate+0x108/0x1e0
[   29.386340] [] con_install+0x34/0x100
[   29.386347] [] 

[Bug 95452] System freeze radeon 5770

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

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

--- Comment #2 from F. Prage  ---
If I could find a way to reproduce the problem fast, without waiting 1-3 days
for each test it would be a lot easier. I'll start looking for a piece of
software that reliably causes the freeze in a short period of time.

-- 
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/20160517/ab93326e/attachment.html>

[PATCH] xf86drm: ensure proper alignment of pointers in drmProcessPciDevice

[Nicolai Hähnle]

Hi Emil,

On 14.05.2016 18:03, Emil Velikov wrote:
> Hi Nicolai,
>
> On 13 May 2016 at 07:14, Nicolai Hähnle  wrote:
>> From: Nicolai Hähnle 
>>
>> Previously, (*device)->businfo.pci would end up misaligned, which results
>> in undefined behavior.
>>
> Can you point me to a source where I can read more on the topic ?
> I'm pretty sure I ran this through valgrind and it gave a clear bill of 
> health.

Valgrind doesn't complain here either, I noticed it with 
-fsanitize=undefined (ubsan) applied to Mesa.

That makes sense, since unaligned loads/stores aren't really a bug as 
far as the x86 ISA is concerned, which is the level at which valgrind 
looks at the code. On the other hand, apparently already an unaligned 
cast (not just the dereference!) is undefined behavior as far as C is 
concerned. I'm not a C language lawyer, but that's what people are 
saying on the interwebs, so it must be true :)

> P.S. Please run the following in your repo $git config --local
> format.subjectPrefix "PATCH libdrm"

Done.

Cheers,
Nicolai

[PATCH v5 02/12] mm: migrate: support non-lru movable page migration

[Minchan Kim]

On Mon, May 16, 2016 at 04:17:51PM +0900, Sergey Senozhatsky wrote:
> On (05/09/16 11:20), Minchan Kim wrote:
> [..]
> > +++ b/include/linux/migrate.h
> > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES];
> >  
> >  #ifdef CONFIG_MIGRATION
> >  
> > +extern int PageMovable(struct page *page);
> > +extern void __SetPageMovable(struct page *page, struct address_space 
> > *mapping);
> > +extern void __ClearPageMovable(struct page *page);
> >  extern void putback_movable_pages(struct list_head *l);
> >  extern int migrate_page(struct address_space *,
> > struct page *, struct page *, enum migrate_mode);
> >  extern int migrate_pages(struct list_head *l, new_page_t new, free_page_t 
> > free,
> > unsigned long private, enum migrate_mode mode, int reason);
> > +extern bool isolate_movable_page(struct page *page, isolate_mode_t mode);
> > +extern void putback_movable_page(struct page *page);
> >  
> >  extern int migrate_prep(void);
> >  extern int migrate_prep_local(void);
> 
> given that some of Movable users can be built as modules, shouldn't
> at least some of those symbols be exported via EXPORT_SYMBOL?

Those functions aim for VM compaction so driver shouldn't use it.
Only driver should be aware of are __SetPageMovable and __CleraPageMovable.
I will export them.

Thanks for the review, Sergey!
> 
>   -ss

[PATCH v5 02/12] mm: migrate: support non-lru movable page migration

[Minchan Kim]

On Mon, May 16, 2016 at 04:04:55PM +0900, Sergey Senozhatsky wrote:
> On (05/09/16 11:20), Minchan Kim wrote:
> > +++ b/include/linux/migrate.h
> > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES];
> >  
> >  #ifdef CONFIG_MIGRATION
> >  
> > +extern int PageMovable(struct page *page);
> > +extern void __SetPageMovable(struct page *page, struct address_space 
> > *mapping);
> > +extern void __ClearPageMovable(struct page *page);
> >  extern void putback_movable_pages(struct list_head *l);
> >  extern int migrate_page(struct address_space *,
> > struct page *, struct page *, enum migrate_mode);
> >  extern int migrate_pages(struct list_head *l, new_page_t new, free_page_t 
> > free,
> > unsigned long private, enum migrate_mode mode, int reason);
> > +extern bool isolate_movable_page(struct page *page, isolate_mode_t mode);
> > +extern void putback_movable_page(struct page *page);
> >  
> >  extern int migrate_prep(void);
> >  extern int migrate_prep_local(void);
> 
> __ClearPageMovable() is under CONFIG_MIGRATION in include/linux/migrate.h,
> but zsmalloc checks for CONFIG_COMPACTION.

Thanks!

PageMovable check function should be in compact.c, I think.
I will fix it.


> 
> can we have stub declarations of movable functions for !CONFIG_MIGRATION 
> builds?
> otherwise the users (zsmalloc, for example) have to do things like
> 
> static void reset_page(struct page *page)
> {
> #ifdef CONFIG_COMPACTION
> __ClearPageMovable(page);
> #endif
> clear_bit(PG_private, >flags);
> clear_bit(PG_private_2, >flags);
> set_page_private(page, 0);
> ClearPageHugeObject(page);
> page->freelist = NULL;
> }
> 
>   -ss

[Bug 92936] Tonga powerplay isssues

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

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

--- Comment #19 from Andy Furniss  ---
Thought I'd already done this one but apparently not.

cat /sys/kernel/debug/dri/64/amdgpu_pm_info

Ever since this option appeared, so before powergating was disabled/clockgating
enabled and currently. VCE is always shown as enabled. UVD behaves and only
says enabled when in use.

-- 
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/20160517/b89daaf8/attachment.html>

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Daniel Vetter]

On Tue, May 17, 2016 at 10:46:51AM +0300, Ville Syrjälä wrote:
> On Tue, May 17, 2016 at 09:05:01AM +0200, Daniel Vetter wrote:
> > On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> > > > Provides helper functions for drivers that have a simple display
> > > > pipeline. Plane, crtc and encoder are collapsed into one entity.
> > > > 
> > > > Cc: jsarha at ti.com
> > > > Signed-off-by: Noralf Trønnes 
> > > > ---
> > > > 
> > > > Changes since v3:
> > > > - (struct drm_simple_display_pipe *)->funcs should be const
> > > > 
> > > > Changes since v2:
> > > > - Drop Kconfig knob DRM_KMS_HELPER
> > > > - Expand documentation
> > > > 
> > > > Changes since v1:
> > > > - Add DOC header and add to gpu.tmpl
> > > > - Fix docs: @funcs is optional, "negative error code",
> > > >   "This hook is optional."
> > > > - Add checks to drm_simple_kms_plane_atomic_check()
> > > > 
> > > >  Documentation/DocBook/gpu.tmpl  |   6 +
> > > >  drivers/gpu/drm/Makefile|   2 +-
> > > >  drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> > > > 
> > > >  include/drm/drm_simple_kms_helper.h |  94 +++
> > > >  4 files changed, 309 insertions(+), 1 deletion(-)
> > > >  create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
> > > >  create mode 100644 include/drm/drm_simple_kms_helper.h
> > > > 
> > > > diff --git a/Documentation/DocBook/gpu.tmpl 
> > > > b/Documentation/DocBook/gpu.tmpl
> > > > index 4a0c599..cf3f5a8 100644
> > > > --- a/Documentation/DocBook/gpu.tmpl
> > > > +++ b/Documentation/DocBook/gpu.tmpl
> > > > @@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
> > > >  !Edrivers/gpu/drm/drm_panel.c
> > > >  !Pdrivers/gpu/drm/drm_panel.c drm panel
> > > >  
> > > > +
> > > > +  Simple KMS Helper Reference
> > > > +!Iinclude/drm/drm_simple_kms_helper.h
> > > > +!Edrivers/gpu/drm/drm_simple_kms_helper.c
> > > > +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> > > > +
> > > >
> > > > 
> > > >
> > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > > index 2bd3e5a..31b85df5 100644
> > > > --- a/drivers/gpu/drm/Makefile
> > > > +++ b/drivers/gpu/drm/Makefile
> > > > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> > > > 
> > > >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> > > > drm_probe_helper.o \
> > > > drm_plane_helper.o drm_dp_mst_topology.o 
> > > > drm_atomic_helper.o \
> > > > -   drm_kms_helper_common.o
> > > > +   drm_kms_helper_common.o drm_simple_kms_helper.o
> > > > 
> > > >  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > > >  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > > > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > > new file mode 100644
> > > > index 000..d45417a
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > > @@ -0,0 +1,208 @@
> > > > +/*
> > > > + * Copyright (C) 2016 Noralf Trønnes
> > > > + *
> > > > + * 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 
> > > > +
> > > > +/**
> > > > + * DOC: overview
> > > > + *
> > > > + * This helper library provides helpers for drivers for simple display
> > > > + * hardware.
> > > > + *
> > > > + * drm_simple_display_pipe_init() initializes a simple display pipeline
> > > > + * which has only one full-screen scanout buffer feeding one output. 
> > > > The
> > > > + * pipeline is represented by struct _simple_display_pipe and binds
> > > > + * together _plane, _crtc and _encoder structures into one 
> > > > fixed
> > > > + * entity. Some flexibility for code reuse is provided through a 
> > > > separately
> > > > + * allocated _connector object and supporting optional _bridge
> > > > + * encoder drivers.
> > > > + */
> > > > +
> > > > +static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> > > > +   .destroy = drm_encoder_cleanup,
> > > > +};
> > > > +
> > > > +static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> > > > +{
> > > > +   struct drm_simple_display_pipe *pipe;
> > > > +
> > > > +   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> > > > +   if (!pipe->funcs || !pipe->funcs->enable)
> > > > +   return;
> > > > +
> > > > +   pipe->funcs->enable(pipe, crtc->state);
> > > > +}
> > > > +
> > > > +static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
> > > > +{
> > > > 

[PATCH] drm.h: Handle DragonFly like Linux

[Ed Maste]

On 17 May 2016 at 01:26, Francois Tigeot  wrote:
>
> FreeBSD and NetBSD even have two different drm.h kernel headers. For some
> reason they think it is a good idea to keep a separate drm implementation
> from ~= 10 years ago or so.

No, we (FreeBSD) don't think it's a good idea. It's an unfortunate
situation that we've ended up in, and is going to take some effort to
clean up, but is not a desired long-term state.

[Bug 95452] System freeze radeon 5770

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

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

--- Comment #1 from Vedran Miletić  ---
So, it used to work years ago... hmm, I know it's a long shot: can you bisect
the kernel?

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

[Bug 95452] System freeze radeon 5770

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

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

Bug ID: 95452
   Summary: System freeze radeon 5770
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: freelancer.pro123 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Freeze happens sometimes when playing video (but it's not necessary), generally
once every day, I never got past 2-3 days, very unpredictable. Does not happen
with fglrx driver, does not happen on windows.

Screen freezes, nothing works, not even the mouse as some other bugs have
reported. If audio was playing, it gets stuck in a last second or so loop. I
need to fully unplug the system to get it to even restart, power/reset buttons
also don't work.

It didn't happen 3 or so years ago (it's an old card). I got hit by this but in
Ubuntu, Gentoo and Arch, distribution doesn't seem to matter. I tried using a
low power profile, didn't do anything.

I'm reporting this since distributions are moving away from fglrx I would need
to replace the card if I can't get it to work, it didn't really bother me while
the proprietary driver was still working.

I'm willing to try out patches, recompile kernels/mesa/whatever if I can get
this to work. Any logs you need, if there's some "enable debug output" or
anything.

lspci using fglrx driver:


01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Juniper XT [Radeon HD 5770] (prog-if 00 [VGA controller])
Subsystem: Hightech Information System Ltd. Device 200b
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [150 v1] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Kernel driver in use: fglrx_pci
Kernel modules: radeon, fglrx

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

[PATCH] drm.h: Handle DragonFly like Linux

[Francois Tigeot]

Hi Randy,

randyf at sibernet.com wrote:
>
>If you are interested in the primary Solaris source, you will really
> want to looking at:
>
> https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel

Thanks. This doesn't look like a git repository though.
How can I clone it ?

>> They are divergent by design :-/
>> Making the Linux headers public and removing the #else path in libdrm's
>> drm.h could be the right thing to do. I'll keep thinking about it...
>
>Removing the #else path will cause Solaris compiles to fail as it
> does consume that side of the conditional (though, as we patch this file
> and don't use it as is, it would be trivial to add it or any other
> Solaris-specific requirements back in).

I was only thinking about patching our libdrm package here, not changing 
the upstream version.

>From a Solaris perspective, I don't see how this file can ever -not-
> have conditional compile statements or be patched to support Solaris, as
> there are sufficient differences requiring at least minor changes.

I'd still like to only use the Linux version by default, both in kernel 
and userland.
I guess at this point the only way to do that without breaking Solaris 
is to either use local patches or change the logic of the #if directives 
to replace the Linux check with a !Solaris one.

>> I'm afraid there won't be many *BSD people around. This year, the XDC and
>> EuroBSDCon conferences fall on the same week-end :-(
>> I'm not sure which one I will be attending to at this point.
>
>Not sure yet if I will be attending either.  But would happily
> provide any input on this either in person (if I am there), or via email.

Dri-devel seems to still be the best place for now :)

Cheers,

-- 
Francois Tigeot

[PATCH v3 7/7] dt-bindings: drm/bridge: Update bindings for ADV7533

[Archit Taneja]

On 05/16/2016 05:31 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Friday 22 Apr 2016 11:10:18 Archit Taneja wrote:
>> On 04/22/2016 04:02 AM, Laurent Pinchart wrote:
>>> On Wednesday 09 Mar 2016 16:27:18 Archit Taneja wrote:
 Add description of ADV7533. Add the required and optional properties that
 are specific to it.

 Cc: devicetree at vger.kernel.org
 Cc: Rob Herring 

 Signed-off-by: Archit Taneja 
 ---

 .../bindings/display/bridge/adi,adv7511.txt| 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

 diff --git
 a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index
 96c25ee..420da5a 100644
 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>
> [snip]
>
 +- adi,disable-timing-generator: Only for ADV7533. Disables the internal
 timing
 +  generator. The chip will rely on the sync signals in the DSI data
 lanes,
 +  rather than generate its own timings for HDMI output.
>>>
>>> Isn't that something that should be selectable at runtime ?
>>
>> The timing generator can be enabled/disabled at runtime. Although, we
>> don't have a way to tell the driver whether we want to keep it enabled
>> or not.
>>
>> It's a hardware feature that works well on most platforms, but not on
>> all. In particular, it works well on DB410c, but causes issues with
>> the Hikey 96 board. The DSI host on Hikey has different clock sources
>> that generate the display controller's pixel clock and DSI byte clock,
>> whereas the Qualcomm SoC uses the same source. My guess is that the
>> ADV7533's timing generator doesn't like it when the pixel data and
>> clock are out of phase or something.
>>
>> Since it is a hardware feature which needs tweaking, I thought it
>> qualified as a DT property.
>
> The fact that a hardware generator is present is certainly describes the
> hardware, but I'm not sure whether to enable it or not also qualifies as a
> hardware feature.
>
> Are there use cases for using the timing generator conditionally on a given
> board ? As you implement support for disabling it, I assume it's not
> mandatory. What feature(s) do we lose if we keep it disabled ?
>

The spec says it's recommended to use the internal timing generator. In
the case of db410c, I observe an unstable output/flicker for certain
modes if I don't enable it.

In the case of hikey platform, it's the other way round.

Xinliang, could you describe the problems you face when the timing
generator is enabled?

Thanks,
Archit

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

[PATCH] qxl: catch qxlfb_create_pinned_object failures

[Daniel Vetter]

On Thu, May 12, 2016 at 07:06:56PM +0200, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/qxl/qxl_fb.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
> index 7136e52..17c1ef0 100644
> --- a/drivers/gpu/drm/qxl/qxl_fb.c
> +++ b/drivers/gpu/drm/qxl/qxl_fb.c
> @@ -360,6 +360,9 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
>   mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth);
>  
>   ret = qxlfb_create_pinned_object(qfbdev, _cmd, );
> + if (ret < 0)
> + return ret;
> +
>   qbo = gem_to_qxl_bo(gobj);
>   QXL_INFO(qdev, "%s: %dx%d %d\n", __func__, mode_cmd.width,
>mode_cmd.height, mode_cmd.pitches[0]);
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[patch] drm/exynos/hdmi: add a missing tab

[Daniel Vetter]

On Thu, May 12, 2016 at 10:54:57PM +0300, Dan Carpenter wrote:
> Smatch warns that the if statement isn't indented.
> 
> Signed-off-by: Dan Carpenter 

Applied to drm-misc, thanks.
-Daniel

> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 0f87acb..748e62f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1612,7 +1612,7 @@ static int hdmi_clk_init(struct hdmi_context *hdata)
>  
>   clks = devm_kzalloc(dev, sizeof(*clks) * count, GFP_KERNEL);
>   if (!clks)
> - return -ENOMEM;
> + return -ENOMEM;
>  
>   hdata->clk_gates = clks;
>   hdata->clk_muxes = clks + drv_data->clk_gates.count;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v4 2/3] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

[Daniel Vetter]

On Thu, May 12, 2016 at 08:25:22PM +0200, Noralf Trønnes wrote:
> Add drm_fb_cma_create_with_funcs() for drivers that need to set the
> dirty() callback.
> 
> Signed-off-by: Noralf Trønnes 
> Acked-by: Laurent Pinchart 

Merged the first 2 patches to drm-misc, thanks.
-Daniel

> ---
> 
> Changes since v3:
> - funcs argument should be const
> 
> Changes since v1:
> - Expand docs
> 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
>  include/drm/drm_fb_cma_helper.h |  3 +++
>  2 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 815c72f..2248c32 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct 
> drm_device *dev,
>  }
> 
>  /**
> - * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create 
> callback function
> + * drm_fb_cma_create_with_funcs() - helper function for the
> + *  _mode_config_funcs ->fb_create
> + *  callback function
>   *
> - * If your hardware has special alignment or pitch requirements these should 
> be
> - * checked before calling this function.
> + * This can be used to set _framebuffer_funcs for drivers that need the
> + * dirty() callback. Use drm_fb_cma_create() if you don't need to change
> + * _framebuffer_funcs.
>   */
> -struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> - struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + const struct drm_framebuffer_funcs *funcs)
>  {
>   struct drm_fb_cma *fb_cma;
>   struct drm_gem_cma_object *objs[4];
> @@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct 
> drm_device *dev,
>   objs[i] = to_drm_gem_cma_obj(obj);
>   }
> 
> - fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
> + fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
>   if (IS_ERR(fb_cma)) {
>   ret = PTR_ERR(fb_cma);
>   goto err_gem_object_unreference;
> @@ -215,6 +219,21 @@ err_gem_object_unreference:
>   drm_gem_object_unreference_unlocked([i]->base);
>   return ERR_PTR(ret);
>  }
> +EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
> +
> +/**
> + * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback function
> + *
> + * If your hardware has special alignment or pitch requirements these should 
> be
> + * checked before calling this function. Use drm_fb_cma_create_with_funcs() 
> if
> + * you need to set _framebuffer_funcs ->dirty.
> + */
> +struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
> + _fb_cma_funcs);
> +}
>  EXPORT_SYMBOL_GPL(drm_fb_cma_create);
> 
>  /**
> diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
> index ac38a05..fd0dde9 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
>  int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
>   struct drm_file *file_priv, unsigned int *handle);
> 
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + const struct drm_framebuffer_funcs *funcs);
>  struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
>   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);
> 
> --
> 2.8.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v4 3/3] drm: Add helper for simple display pipeline

[Daniel Vetter]

On Thu, May 12, 2016 at 09:36:14PM +0300, Ville Syrjälä wrote:
> On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> > Provides helper functions for drivers that have a simple display
> > pipeline. Plane, crtc and encoder are collapsed into one entity.
> > 
> > Cc: jsarha at ti.com
> > Signed-off-by: Noralf Trønnes 
> > ---
> > 
> > Changes since v3:
> > - (struct drm_simple_display_pipe *)->funcs should be const
> > 
> > Changes since v2:
> > - Drop Kconfig knob DRM_KMS_HELPER
> > - Expand documentation
> > 
> > Changes since v1:
> > - Add DOC header and add to gpu.tmpl
> > - Fix docs: @funcs is optional, "negative error code",
> >   "This hook is optional."
> > - Add checks to drm_simple_kms_plane_atomic_check()
> > 
> >  Documentation/DocBook/gpu.tmpl  |   6 +
> >  drivers/gpu/drm/Makefile|   2 +-
> >  drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> > 
> >  include/drm/drm_simple_kms_helper.h |  94 +++
> >  4 files changed, 309 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
> >  create mode 100644 include/drm/drm_simple_kms_helper.h
> > 
> > diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> > index 4a0c599..cf3f5a8 100644
> > --- a/Documentation/DocBook/gpu.tmpl
> > +++ b/Documentation/DocBook/gpu.tmpl
> > @@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
> >  !Edrivers/gpu/drm/drm_panel.c
> >  !Pdrivers/gpu/drm/drm_panel.c drm panel
> >  
> > +
> > +  Simple KMS Helper Reference
> > +!Iinclude/drm/drm_simple_kms_helper.h
> > +!Edrivers/gpu/drm/drm_simple_kms_helper.c
> > +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> > +
> >
> > 
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 2bd3e5a..31b85df5 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> > 
> >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> > -   drm_kms_helper_common.o
> > +   drm_kms_helper_common.o drm_simple_kms_helper.o
> > 
> >  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > new file mode 100644
> > index 000..d45417a
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -0,0 +1,208 @@
> > +/*
> > + * Copyright (C) 2016 Noralf Trønnes
> > + *
> > + * 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 
> > +
> > +/**
> > + * DOC: overview
> > + *
> > + * This helper library provides helpers for drivers for simple display
> > + * hardware.
> > + *
> > + * drm_simple_display_pipe_init() initializes a simple display pipeline
> > + * which has only one full-screen scanout buffer feeding one output. The
> > + * pipeline is represented by struct _simple_display_pipe and binds
> > + * together _plane, _crtc and _encoder structures into one 
> > fixed
> > + * entity. Some flexibility for code reuse is provided through a separately
> > + * allocated _connector object and supporting optional _bridge
> > + * encoder drivers.
> > + */
> > +
> > +static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> > +   .destroy = drm_encoder_cleanup,
> > +};
> > +
> > +static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> > +{
> > +   struct drm_simple_display_pipe *pipe;
> > +
> > +   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> > +   if (!pipe->funcs || !pipe->funcs->enable)
> > +   return;
> > +
> > +   pipe->funcs->enable(pipe, crtc->state);
> > +}
> > +
> > +static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
> > +{
> > +   struct drm_simple_display_pipe *pipe;
> > +
> > +   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> > +   if (!pipe->funcs || !pipe->funcs->disable)
> > +   return;
> > +
> > +   pipe->funcs->disable(pipe);
> > +}
> > +
> > +static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs 
> > = {
> > +   .disable = drm_simple_kms_crtc_disable,
> > +   .enable = drm_simple_kms_crtc_enable,
> > +};
> > +
> > +static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs = {
> > +   .reset = drm_atomic_helper_crtc_reset,
> > +   .destroy = drm_crtc_cleanup,
> > +   .set_config = drm_atomic_helper_set_config,
> > +   .page_flip = 

[PATCH 00/17] SI support for amdgpu

[Daniel Vetter]

On Sat, May 14, 2016 at 03:26:12PM -0400, Alex Deucher wrote:
> This is an initial port of SI support from radeon to amdgpu. This
> should be considered developer level code.  It's not ready for users.
> GFX and DMA are mostly working.  DPM (power management) is implemented,
> but not working yet.  UVD and VCE support have not yet been ported.
> It uses the same ucode as radeon, just like CIK.
> 
> What works:
> - FB console
> - Unaccelerated X
> - Basic OGL tests (e.g. piglit) using gbm
> 
> The code can also be found on the drm-next-4.8-wip-si branch of my fdo tree:
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.8-wip-si

I understand that sometimes with early hw enabling a lot of development
needs to happen behind closed doors because not yet approved for
publishing. SI isn't such a case, still some of these patches are at v6/7
already when they show. Also, you're not the author of any of these. And
they all have r-b tags already.

Everyone else here in the drm subsystem seems to have no problem at all
with developing in the open, why can't AMD?
-Daniel

> 
> Alex
> 
> 
> Ken Wang (13):
>   drm/amdgpu: add SI asics types v2
>   drm/amdgpu: add si header files v3
>   drm/amdgpu: add graphic memory controller implementation for si v5
>   drm/amdgpu: add interupt handler implementation for si v3
>   drm/amdgpu: add display controller implementation for si v7
>   drm/amdgpu: atombios change for dce6 to work v3
>   drm/amdgpu: add graphic pipeline implementation for si v6
>   drm/amdgpu: add DMA implementation for si v6
>   drm/amdgpu: add si implementation v7
>   drm/amdgpu: add all the components for si into Makefile/kconfig v3
>   drm/amdgpu: add si ip blocks setup v3
>   drm/amdgpu: add si specific logic into the device initialize function
> v2
>   drm/amdgpu: add si pciids v2
> 
> Maruthi Srinivas Bayyavarapu (4):
>   drm/amdgpu: add si dpm support in amdgpu_atombios
>   drm/amdgpu: add SI SMC support
>   drm/amdgpu: add SI DPM support (v3)
>   drm/amdgpu: enable SI DPM
> 
>  drivers/gpu/drm/amd/amdgpu/Kconfig |7 +
>  drivers/gpu/drm/amd/amdgpu/Makefile|2 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|9 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c   |  158 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h   |   16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   34 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   74 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |   10 +
>  drivers/gpu/drm/amd/amdgpu/atombios_crtc.c |8 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 3204 
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.h  |   29 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  | 3280 
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.h  |   36 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  | 1077 +++
>  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.h  |   36 +
>  drivers/gpu/drm/amd/amdgpu/r600_dpm.h  |  127 +
>  drivers/gpu/drm/amd/amdgpu/si.c| 1914 +
>  drivers/gpu/drm/amd/amdgpu/si.h|   33 +
>  drivers/gpu/drm/amd/amdgpu/si_dma.c|  963 +++
>  drivers/gpu/drm/amd/amdgpu/si_dma.h|   29 +
>  drivers/gpu/drm/amd/amdgpu/si_dpm.c| 7982 
> 
>  drivers/gpu/drm/amd/amdgpu/si_dpm.h| 1015 +++
>  drivers/gpu/drm/amd/amdgpu/si_ih.c |  313 +
>  drivers/gpu/drm/amd/amdgpu/si_ih.h |   29 +
>  drivers/gpu/drm/amd/amdgpu/si_smc.c|  280 +
>  drivers/gpu/drm/amd/amdgpu/sislands_smc.h  |  423 ++
>  drivers/gpu/drm/amd/include/amd_shared.h   |7 +-
>  .../drm/amd/include/asic_reg/si/clearstate_si.h|  941 +++
>  drivers/gpu/drm/amd/include/asic_reg/si/si_reg.h   |  105 +
>  drivers/gpu/drm/amd/include/asic_reg/si/sid.h  | 2442 ++
>  drivers/gpu/drm/amd/include/atombios.h |2 +
>  31 files changed, 24578 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/dce_v6_0.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/r600_dpm.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/si.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/si.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/si_dma.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/si_dma.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/si_dpm.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/si_dpm.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/si_ih.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/si_ih.h
>  create mode 100644 

[PATCH] drm/i915/dp: Try to find proper bpc for DP->legacy converters. (v2)

[Daniel Vetter]

On Thu, May 12, 2016 at 06:43:58PM +0200, Mario Kleiner wrote:
> This fixes a regression in output precision for DVI and VGA
> video sinks connected to Intel hw via active DisplayPort->DVI/VGA
> converters.
> 
> The regression was indirectly introduced by commit 013dd9e03872
> ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").
> 
> Our current drm edid 1.3 handling can't reliably assign a proper
> minimum supported display depth of 8 bpc to all DVI sinks, as
> mandated by DVI 1.0 spec, section 2.2.11.2 "Monitor data format
> support", but returns 0 bpc = "Don't know" instead. For analog VGA
> sinks it also returns 0 bpc, although those sinks themselves have
> infinite color depth, only restricted by the DAC resolution of
> the encoder.
> 
> If a VGA or dual-link DVI display is connected via DisplayPort
> connector then due to above commit the driver would fall back to
> only 6 bpc, which would cause degradation for DVI and VGA displays,
> annoying in general, but especially harmful for application of display
> devices used in neuroscience research and for medical diagnosic
> which absolutely need native non-dithered 8 bpc at a minimum to
> operate correctly.
> 
> For DP connectors with bpc == 0 according to EDID, fix this problem
> by checking the dpcd data to find out if a DP->legacy converter
> is connected. If the converter is DP->DVI/HDMI assume 8 bpc
> depth. If the converter is DP->VGA assume at least 8 bpc, but
> try to get a more accurate value (8, 10, 12 or 16 bpc) if the
> converter exposes this info.
> 
> Only for a DP sink without downstream ports we assume it is a native DP
> sink and apply the 6 bpc / 18 bpp fallback as required by the DP spec.
> 
> As the "fall back to 18 bpp" patch was backported to stable we should
> include this one also into stable to fix the regression in color
> precision.
> 
> Tested with MiniDP->DP adapter, MiniDP->HDMI adapter,
> MiniDP->single-link DVI adapter, MiniDP->dual-link DVI active adapter,
> and Apple MiniDP->VGA active adapter.
> 
> v2: Take Ville's feedback into account: Fold the 18 bpp fallback into
> the detection function, so it only applies to native DP sinks.
> Rename intel_dp_legacy_bpc() to intel_dp_sink_bpc().
> 
> Signed-off-by: Mario Kleiner 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/i915/intel_display.c | 12 ++--
>  drivers/gpu/drm/i915/intel_dp.c  | 59 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  3 files changed, 69 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a297e1f..7ef52db 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12072,10 +12072,16 @@ connected_sink_compute_bpp(struct intel_connector 
> *connector,
>   int type = connector->base.connector_type;
>   int clamp_bpp = 24;
>  
> - /* Fall back to 18 bpp when DP sink capability is unknown. */
> + /* On DisplayPort try harder to find sink bpc */
>   if (type == DRM_MODE_CONNECTOR_DisplayPort ||
> - type == DRM_MODE_CONNECTOR_eDP)
> - clamp_bpp = 18;
> + type == DRM_MODE_CONNECTOR_eDP) {
> + int sink_bpc = intel_dp_sink_bpc(>base);
> +
> + if (sink_bpc) {
> + DRM_DEBUG_KMS("DP sink with bpc %d\n", 
> sink_bpc);
> + clamp_bpp = 3 * sink_bpc;
> + }
> + }
>  
>   if (bpp > clamp_bpp) {
>   DRM_DEBUG_KMS("clamping display bpp (was %d) to default 
> limit of %d\n",
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f192f58..4dbb55b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6046,3 +6046,62 @@ void intel_dp_mst_resume(struct drm_device *dev)
>   }
>   }
>  }
> +
> +/* XXX Needs work for more than 1 downstream port */
> +int intel_dp_sink_bpc(struct drm_connector *connector)

I think these kind of functions are pretty much why we have a dp helepr.
Can you pls move it there (and add kerneldoc and all the usual
bits). There's also other patches in-flight to add more downstream
port handling ...
-Daniel

> +{
> + struct intel_dp *intel_dp = intel_attached_dp(connector);
> + uint8_t *dpcd = intel_dp->dpcd;
> + uint8_t type;
> + int bpc = 0;
> +
> + /*
> +  * If there isn't any downstream port then this is a native DP sink.
> +  * The standard requires to fall back to 6 bpc / 18 bpp for native DP
> +  * sinks which don't provide bit depth via EDID.
> +  */
> + if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> + return 6;
> +
> + /* Basic type of downstream ports */
> + type = 

[PATCH] drm: Remove unused drm_device from drm_gem_object_lookup()

[Daniel Vetter]

On Mon, May 16, 2016 at 11:15:09PM +0100, Emil Velikov wrote:
> Hi Chris,
> 
> On 9 May 2016 at 11:04, Chris Wilson  wrote:
> 
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> 
> > @@ -607,12 +606,8 @@ drm_gem_object_lookup(struct drm_device *dev, struct 
> > drm_file *filp,
> >
> > /* Check if we currently have a reference on the object */
> > obj = idr_find(>object_idr, handle);
> > -   if (obj == NULL) {
> > -   spin_unlock(>table_lock);
> > -   return NULL;
> > -   }
> > -
> > -   drm_gem_object_reference(obj);
> > +   if (obj)
> > +   drm_gem_object_reference(obj);
> >
> This hunk looks unrelated to the goal of the patch. Still a nice
> cleanup though. Worth splitting out ?

Imo too trivial too require it's own patch, so applied to drm-misc. But
with the kerneldoc updated - 0day should have caught this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

PCI on PowerPC

[Mathieu Malaterre]

Dear all,

I've tested a patch against radeon_drc.c so that the default mode is
now PCI on PowerPC arch.

This is the result of the discussion on the following bug report:

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

Thanks for your comments,

-- 
Mathieu

[PATCH v4 1/2] drm: bridge: Add sii902x driver

[Daniel Vetter]

On Mon, May 16, 2016 at 04:04:28PM +0200, Boris Brezillon wrote:
> Add basic support for the sii902x RGB -> HDMI bridge.
> This driver does not support audio output yet.
> 
> Signed-off-by: Boris Brezillon 
> Tested-by: Nicolas Ferre 
> ---
> Hello,
> 
> This patch is only adding basic support for the sii9022 chip.
> As stated in the commit log, there's no audio support, but the
> driver also hardcodes a lot of things (like the RGB input format to
> use).
> 
> Best Regards,
> 
> Boris
> 
> Changes in v4:
> - make reset GPIO optional
> - only support attaching to DRM devices supporting atomic updates
> 
> Changes in v3:
> - fix get_modes() implementation to avoid turning the screen in power
>   save mode
> - rename the driver (sil902x -> sii902x)
> 
> Changes in v2:
> - fix errors reported by the kbuild robot
> ---
>  drivers/gpu/drm/bridge/Kconfig   |   8 +
>  drivers/gpu/drm/bridge/Makefile  |   1 +
>  drivers/gpu/drm/bridge/sii902x.c | 477 
> +++
>  3 files changed, 486 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/sii902x.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index efd94e0..a692c5b 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -40,6 +40,14 @@ config DRM_PARADE_PS8622
>   ---help---
> Parade eDP-LVDS bridge chip driver.
>  
> +config DRM_SII902X
> + tristate "Silicon Image sii902x RGB/HDMI bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + ---help---
> +   Silicon Image sii902x bridge chip driver.
> +
>  source "drivers/gpu/drm/bridge/analogix/Kconfig"
>  
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index ff821f4..b2a37e8 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,4 +4,5 @@ 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
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> new file mode 100644
> index 000..76ad73a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -0,0 +1,477 @@
> +/*
> + * Copyright (C) 2014 Atmel
> + * Bo Shen 
> + *
> + * Authors:Bo Shen 
> + * Boris Brezillon 
> + * Wu, Songjun 
> + *
> + *
> + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * 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.
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SIL902X_TPI_VIDEO_DATA   0x0
> +
> +#define SIL902X_TPI_PIXEL_REPETITION 0x8
> +#define SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5)
> +#define SIL902X_TPI_AVI_PIXEL_REP_RISING_EDGE   BIT(4)
> +#define SIL902X_TPI_AVI_PIXEL_REP_4X 3
> +#define SIL902X_TPI_AVI_PIXEL_REP_2X 1
> +#define SIL902X_TPI_AVI_PIXEL_REP_NONE   0
> +#define SIL902X_TPI_CLK_RATIO_HALF   (0 << 6)
> +#define SIL902X_TPI_CLK_RATIO_1X (1 << 6)
> +#define SIL902X_TPI_CLK_RATIO_2X (2 << 6)
> +#define SIL902X_TPI_CLK_RATIO_4X (3 << 6)
> +
> +#define SIL902X_TPI_AVI_IN_FORMAT0x9
> +#define SIL902X_TPI_AVI_INPUT_BITMODE_12BIT  BIT(7)
> +#define SIL902X_TPI_AVI_INPUT_DITHER BIT(6)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_LIMITED  (2 << 2)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_FULL (1 << 2)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_AUTO (0 << 2)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_BLACK   (3 << 0)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV422  (2 << 0)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV444  (1 << 0)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_RGB (0 << 0)
> +
> +#define SIL902X_TPI_AVI_INFOFRAME0x0c
> +
> +#define SIL902X_SYS_CTRL_DATA0x1a
> +#define SIL902X_SYS_CTRL_PWR_DWN BIT(4)
> +#define SIL902X_SYS_CTRL_AV_MUTE BIT(3)
> +#define SIL902X_SYS_CTRL_DDC_BUS_REQ BIT(2)
> +#define SIL902X_SYS_CTRL_DDC_BUS_GRTDBIT(1)
> +#define 

[Intel-gfx] [PATCH v2 7/7] drm/i915: Check pixel rate for DP to VGA dongle

[Daniel Vetter]

On Mon, May 16, 2016 at 04:19:33PM +0300, Mika Kahola wrote:
> Prep work to improve DP branch device handling.
> 
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
> 
> The register defines the pixel rate divided by 8 in MP/s.
> 
> v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3633002..5ec6287 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -201,6 +201,12 @@ intel_dp_mode_valid(struct drm_connector *connector,
>   int max_rate, mode_rate, max_lanes, max_link_clock;
>   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>  
> + /* DP to VGA dongle may define max pixel rate in DPCD */
> + if (intel_dp->bd.present &&
> + (intel_dp->bd.type & DP_DS_PORT_TYPE_VGA) &&
> + (intel_dp->bd.dfp.vga.dot_clk > 0))
> + max_dotclk = min(max_dotclk, intel_dp->bd.dfp.vga.dot_clk);

I think this is rendering the helpers a bit pointless if you have to dig
around so much in internals. drm_dp_helper_max_sink_dotclock(), and then
we have a place to put more of that stuff?
-Daniel


> +
>   if (is_edp(intel_dp) && fixed_mode) {
>   if (mode->hdisplay > fixed_mode->hdisplay)
>   return MODE_PANEL;
> @@ -4575,6 +4581,7 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   enum intel_display_power_domain power_domain;
>   enum irqreturn ret = IRQ_NONE;
> + int err;
>  
>   if (intel_dig_port->base.type != INTEL_OUTPUT_EDP &&
>   intel_dig_port->base.type != INTEL_OUTPUT_HDMI)
> @@ -4599,6 +4606,10 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>   power_domain = intel_display_port_aux_power_domain(intel_encoder);
>   intel_display_power_get(dev_priv, power_domain);
>  
> + err = drm_dp_bd(_dp->aux, _dp->bd);
> + if (err < 0)
> + DRM_DEBUG_KMS("error reading DPCD[0x80] for DP branch 
> device\n");
> +
>   if (long_hpd) {
>   /* indicate that we need to restart link training */
>   intel_dp->train_set_valid = false;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] checkpatch fixes

[Tobin C Harding]

Fix a couple of checkpatch errors and a bunch of warnings.

Signed-off-by: Tobin C Harding 
---

Two occurences of (foo != NULL) changed to (!foo) even though not picked up by 
checkpatch.pl

 drivers/gpu/drm/gma500/cdv_intel_lvds.c | 39 +++--
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 813ef23..34f695c 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -229,6 +229,7 @@ static void cdv_intel_lvds_set_power(struct drm_device *dev,
 static void cdv_intel_lvds_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
struct drm_device *dev = encoder->dev;
+
if (mode == DRM_MODE_DPMS_ON)
cdv_intel_lvds_set_power(dev, encoder, true);
else
@@ -284,7 +285,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
head) {
if (tmp_encoder != encoder
&& tmp_encoder->crtc == encoder->crtc) {
-   printk(KERN_ERR "Can't enable LVDS and another "
+   pr_err("Can't enable LVDS and another "
   "encoder on the same pipe\n");
return false;
}
@@ -296,7 +297,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
*encoder,
 * with the panel scaling set up to source from the H/VDisplay
 * of the original mode.
 */
-   if (panel_fixed_mode != NULL) {
+   if (panel_fixed_mode) {
adjusted_mode->hdisplay = panel_fixed_mode->hdisplay;
adjusted_mode->hsync_start = panel_fixed_mode->hsync_start;
adjusted_mode->hsync_end = panel_fixed_mode->hsync_end;
@@ -410,7 +411,8 @@ static int cdv_intel_lvds_get_modes(struct drm_connector 
*connector)
struct psb_intel_mode_device *mode_dev = _priv->mode_dev;
int ret;

-   ret = psb_intel_ddc_get_modes(connector, 
_encoder->i2c_bus->adapter);
+   ret = psb_intel_ddc_get_modes(connector,
+ _encoder->i2c_bus->adapter);

if (ret)
return ret;
@@ -423,7 +425,7 @@ static int cdv_intel_lvds_get_modes(struct drm_connector 
*connector)
connector->display_info.max_vfreq = 200;
connector->display_info.min_hfreq = 0;
connector->display_info.max_hfreq = 200;
-   if (mode_dev->panel_fixed_mode != NULL) {
+   if (mode_dev->panel_fixed_mode) {
struct drm_display_mode *mode =
drm_mode_duplicate(dev, mode_dev->panel_fixed_mode);
drm_mode_probed_add(connector, mode);
@@ -503,7 +505,7 @@ static int cdv_intel_lvds_set_property(struct drm_connector 
*connector,
value))
return -1;
else
-gma_backlight_set(encoder->dev, value);
+   gma_backlight_set(encoder->dev, value);
} else if (!strcmp(property->name, "DPMS") && encoder) {
const struct drm_encoder_helper_funcs *helpers =
encoder->helper_private;
@@ -574,7 +576,7 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
continue;

if (child->i2c_pin)
-   *i2c_pin = child->i2c_pin;
+   *i2c_pin = child->i2c_pin;

/* However, we cannot trust the BIOS writers to populate
 * the VBT correctly.  Since LVDS requires additional
@@ -624,13 +626,11 @@ void cdv_intel_lvds_init(struct drm_device *dev,
return;
}

-   gma_encoder = kzalloc(sizeof(struct gma_encoder),
-   GFP_KERNEL);
+   gma_encoder = kzalloc(sizeof(struct gma_encoder), GFP_KERNEL);
if (!gma_encoder)
return;

-   gma_connector = kzalloc(sizeof(struct gma_connector),
- GFP_KERNEL);
+   gma_connector = kzalloc(sizeof(struct gma_connector), GFP_KERNEL);
if (!gma_connector)
goto failed_connector;

@@ -665,7 +665,7 @@ void cdv_intel_lvds_init(struct drm_device *dev,
connector->interlace_allowed = false;
connector->doublescan_allowed = false;

-   /*Attach connector properties*/
+   /* Attach connector properties */
drm_object_attach_property(>base,
  dev->mode_config.scaling_mode_property,
  DRM_MODE_SCALE_FULLSCREEN);
@@ -677,12 +677,10 @@ void cdv_intel_lvds_init(struct drm_device *dev,
 * Set up I2C bus
 * FIXME: distroy i2c_bus when exit
 */
-   gma_encoder->i2c_bus = psb_intel_i2c_create(dev,
-GPIOB,
-   

ast: cursor flashing softlockups

[Peter Hurley]

[ +to Scot Doyle ]

Scot, please take a look at this soft lockup.

Regards,
Peter Hurley


Hi Ming,

On 05/17/2016 02:12 AM, Ming Lei wrote:
> Hi,
> 
> On Tue, May 17, 2016 at 4:07 AM, Dann Frazier
>  wrote:
>> Hi,
>>  I'm observing a soft lockup issue w/ the ASPEED controller on an
>> arm64 server platform. This was originally seen on Ubuntu's 4.4
>> kernel, but it is reproducible w/ vanilla 4.6-rc7 as well.
>>
>> [   32.792656] NMI watchdog: BUG: soft lockup - CPU#38 stuck for 22s!
>> [swapper/38:0]
>>
>> I observe this just once each time I boot into debian-installer (I'm
>> using a serial console, but the ast module gets loaded during
>> startup).
> 
> I have figured out that it is caused by 'mod_timer(timer, jiffies)' and
> 'ops->cur_blink_jiffies' is observed as zero in cursor_timer_handler()
> when the issue happened.

Thanks for tracking this down.

This softlockup looks to be caused by:

commit 27a4c827c34ac4256a190cc9d24607f953c1c459
Author: Scot Doyle 
Date:   Thu Mar 26 13:56:38 2015 +

fbcon: use the cursor blink interval provided by vt

vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().

Signed-off-by: Scot Doyle 
Acked-by: Pavel Machek 
Signed-off-by: Greg Kroah-Hartman 

and

commit bd63364caa8df38bad2b25b11b2a1b849475cce5
Author: Scot Doyle 
Date:   Thu Mar 26 13:54:39 2015 +

vt: add cursor blink interval escape sequence

Add an escape sequence to specify the current console's cursor blink
interval. The interval is specified as a number of milliseconds 
until
the next cursor display state toggle, from 50 to 65535. 
/proc/loadavg
did not show a difference with a one msec interval, but the lower
bound is set to 50 msecs since slower hardware wasn't tested.

Store the interval in the vc_data structure for later access by 
fbcon,
initializing the value to fbcon's current hardcoded value of 200 
msecs.

Signed-off-by: Scot Doyle 
Acked-by: Pavel Machek 
Signed-off-by: Greg Kroah-Hartman 



> Looks it is a real fbcon/vt issue, see following:
> 
> fbcon_init()
> <-.con_init
>   <-visual_init()
> 
> reset_terminal()
> <-vc_init()
> 
> vc->vc_cur_blink_ms is just set in reset_terminal() from vc_init() path,
> and ops->cur_blink_jiffies is figured out from vc->vc_cur_blink_ms
> in fbcon_init().
> 
> And visual_init() is always run before vc_init(), so ops->cur_blink_jiffies
> is initialized as zero and cause the soft lockup issue finally.
> 
> Thanks,
> Ming
> 
>>
>> perf shows that the CPU caught by the NMI is typically in code
>> updating the cursor timer:
>>
>> -   16.92%  swapper  [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore
>>- _raw_spin_unlock_irqrestore
>>   + 16.87% mod_timer
>>   + 0.05% cursor_timer_handler
>> -   12.15%  swapper  [kernel.kallsyms]  [k] queue_work_on
>>- queue_work_on
>>   + 12.00% cursor_timer_handler
>>   + 0.15% call_timer_fn
>> +   10.98%  swapper  [kernel.kallsyms]  [k] run_timer_softirq
>> -2.23%  swapper  [kernel.kallsyms]  [k] mod_timer
>>- mod_timer
>>   + 1.97% cursor_timer_handler
>>   + 0.26% call_timer_fn
>>
>> During the same period, I can see that another CPU is actively
>> executing the timer function:
>>
>> -   42.18%  kworker/u96:2  [kernel.kallsyms]  [k] ww_mutex_unlock
>>- ww_mutex_unlock
>>   - 40.70% ast_dirty_update
>>ast_imageblit
>>soft_cursor
>>bit_cursor
>>fb_flashcursor
>>process_one_work
>>worker_thread
>>kthread
>>ret_from_fork
>>   + 1.48% ast_imageblit
>> -   40.15%  kworker/u96:2  [kernel.kallsyms]  [k] __memcpy_toio
>>- __memcpy_toio
>>   + 31.54% ast_dirty_update
>>   + 8.61% ast_imageblit
>>
>> Using the graph function tracer on fb_flashcursor(), I see that
>> ast_dirty_update usually takes around 60 us, in which it makes 16
>> calls to __memcpy_toio(). However, there is always one instance on
>> every boot of the installer where ast_dirty_update() takes ~98 *ms* to
>> complete, during which it makes 743 calls to __memcpy_toio(). While
>> that  doesn't directly account for the full 22s, I do wonder if that
>> maybe a smoking gun.
>>
>> fyi, this is being tracked at: https://bugs.launchpad.net/bugs/1574814
>>
>>   -dann

[PATCH] drm.h: Handle DragonFly like Linux

[Francois Tigeot]

On Mon, May 16, 2016 at 11:02:33PM +0100, Emil Velikov wrote:
> On 16 May 2016 at 17:24, Francois Tigeot  wrote:
> >
> > The #else code path is not being used on DragonFly and actually breaks
> > kernel compilation.
> >
> I guess what I'm wondering here is where they working at some point in
> the past ? What was wrong with scheme in the first place ? Surely
> things weren't that bad.

For DragonFly, this did work a long time ago when the drm kernel drivers
were very different from the Linux ones.

> Hmm are you sure about this ... looking at OpenBSD and DragonFly repos
> there seems to be no changes to drm.h. Yet again I'm looking at the
> libdrm which is should be identical to the kernel one with the former
> user space 'version'. Do you define __linux__ for user space or you
> fall back to the 'else' ?

Hrmm. I didn't think about libdrm at all, I only looked at the various
kernel headers.

> [Please tell me that you're not having two different definitions, drm
> header, of the interface on each side - kernel vs userspace]

I'm afraid we have. Kernel headers are not available to userland and
libdrm ones are provided by the libdrm package.

FreeBSD and NetBSD even have two different drm.h kernel headers. For some
reason they think it is a good idea to keep a separate drm implementation
from ~= 10 years ago or so.

> >> Alternatively if one insists on using the __linux__ route here, imho
> >> it's better to just set the define it in your build.
> >
> > It's not really possible for me to patch gcc here since some software
> > depends on the operating system not advertising itself as Linux.
> >
> That sounds quite nasty. Wouldn't it be easier and quicker to beat the
> "else" back into shape, as opposed to trying to force things ?

I guess I'll have to keep patching it out locally.
Drm drivers are developed for Linux first and foremost and I'd like to
reduce differences with upstream as much as possible.

> > On the other hand, the non-Linux code path really is unused. I didn't want
> > to be too intrusive in my patch but it's probably best to just remove it.
> >
> There is more to this world than Linux and BSD, there's Solaris as
> well. Even though they tend to be very quiet ;-)

Right. I forgot about it since the Solaris-derived source code I have easy
access to is illumos-gate and its drm.h hasn't been updated since 2009.

> TL;DR: Please don't diverge userspace vs kernel drm headers. Just beat
> it in shape so that it works in both cases (most likely the 'else'
> one).
> 
> Hopefully ^^ does not sound to hard to achieve and/or demanding ?

They are divergent by design :-/
Making the Linux headers public and removing the #else path in libdrm's
drm.h could be the right thing to do. I'll keep thinking about it...

> P.S. Perhaps we should spend an hour or so over the next XDC trying to
> flush any remaining differences/patches in the graphics stack ? Not
> sure how many BSD/Solaris people will be around though.

I'm afraid there won't be many *BSD people around. This year, the XDC and
EuroBSDCon conferences fall on the same week-end :-(
I'm not sure which one I will be attending to at this point.

Thanks Emil,

-- 
Francois Tigeot

[Bug 93658] Distortions on the right of the monitor

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

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

--- Comment #3 from jody.frankowski at gmail.com ---
As of xf86-video-amdgpu 1.1.0-1 and linux 4.5.2-1 the bug is still present.

-- 
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/20160517/08beefc5/attachment.html>

[Bug 95438] Elemental demo compute shader takes ages to compile

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

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

--- Comment #3 from Dave Airlie  ---
with your patch any my two on llvm master and mesa master I'm running
elementaldemo in 4.3 mode now.

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

[Bug 95438] Elemental demo compute shader takes ages to compile

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

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

--- Comment #2 from Dave Airlie  ---
https://patchwork.freedesktop.org/patch/82260/

Looks like Bas's patch herre actually fixes this. sorry for the noise.

-- 
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/20160517/a242/attachment.html>

[Bug 95438] Elemental demo compute shader takes ages to compile

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

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

--- Comment #1 from Bas Nieuwenhuizen  ---
Last I looked at the elemental demo, we have multiple issues:

- The shared array (1024 elements) get wrongly promoted to a private array.
There is a fix for that at
https://lists.freedesktop.org/archives/mesa-dev/2016-April/113832.html

- in radeonsi we compile arrays to vectors with insert/extract element. This
pretty much results in the array being SSA version, which results in a very
large program.

- a 1024 element vector does not fit in 256 VGPR's so LLVM tries to load and
spill around every operation and therefore every versioned array element takes
scratch space.

- As a result I needed 7 MiB of scratch space per wave, or 6,7 GiB in total. 
This overflows the 32-bit buffer size and we only allocate a smaller buffer.

-  This resulted in hangs (or maybe long long shader execution times, not
really sure...).

So not sure how long a long long time is, last I tried (which admittedly is
some weeks ago) I certainly could get past the compilation stage. If you did
get past that and did not get hangs, I'm not sure why.

Fixing the first problem also circumvents problems 2 & 3, although it would be
nice to get those fixed as well.

-- 
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/20160517/d1b01f24/attachment.html>

[Bug 95438] Elemental demo compute shader takes ages to compile

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

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

Bug ID: 95438
   Summary: Elemental demo compute shader takes ages to compile
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: airlied at freedesktop.org
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 123804
  --> https://bugs.freedesktop.org/attachment.cgi?id=123804=edit
compute shader and GLSL/TGSI/llvm IR.

After fixing the two GLSL bugs, I hit a case where one of the compute shaders
in 
ElementalDemo takes a long long time to compile and consumes a lot of memory
doing so.


#0  llvm::SUnit::addPred (this=this at entry=0x7fa8da02fae0, D=...,
Required=Required at entry=true)
at /home/airlied/devel/llvm/lib/CodeGen/ScheduleDAG.cpp:67
#1  0x7fa92c946d2d in llvm::ScheduleDAGInstrs::addPhysRegDataDeps
(this=this at entry=0x7fa9248d3840, SU=SU at entry=0x7fa8d9833c40, 
OperIdx=OperIdx at entry=8) at
/home/airlied/devel/llvm/lib/CodeGen/ScheduleDAGInstrs.cpp:318
#2  0x7fa92c947198 in llvm::ScheduleDAGInstrs::addPhysRegDeps
(this=this at entry=0x7fa9248d3840, SU=SU at entry=0x7fa8d9833c40, 
OperIdx=OperIdx at entry=8) at
/home/airlied/devel/llvm/lib/CodeGen/ScheduleDAGInstrs.cpp:370
#3  0x7fa92c94fd1e in llvm::ScheduleDAGInstrs::buildSchedGraph
(this=this at entry=0x7fa9248d3840, AA=0x7fa8e2e55b10, 
RPTracker=RPTracker at entry=0x0, PDiffs=PDiffs at entry=0x0, LIS=LIS at 
entry=0x0,
TrackLaneMasks=TrackLaneMasks at entry=false)
at /home/airlied/devel/llvm/lib/CodeGen/ScheduleDAGInstrs.cpp:959
#4  0x7fa92c8ff02b in (anonymous namespace)::SchedulePostRATDList::schedule
(this=this at entry=0x7fa9248d3840)
at /home/airlied/devel/llvm/lib/CodeGen/PostRASchedulerList.cpp:391
#5  0x7fa92c8ffbbe in (anonymous
namespace)::PostRAScheduler::runOnMachineFunction (this=0x7fa8e284a500, Fn=...)
at /home/airlied/devel/llvm/lib/CodeGen/PostRASchedulerList.cpp:360
#6  0x7fa92c880721 in llvm::MachineFunctionPass::runOnFunction
(this=0x7fa8e284a500, F=...)
at /home/airlied/devel/llvm/lib/CodeGen/MachineFunctionPass.cpp:60

-- 
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/20160517/f69f8596/attachment.html>

[PATCH 06/20] drm/sun4i: allow dclk to modify its parent rate

[Chen-Yu Tsai]

Hi,

On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
 wrote:
> The pixel clock being only a divider of its parent clock, depending on the
> resolution, it's expected to change its parent rate. Add that flag so that
> the clock framework knows it.

This should be squashed into the previous patch. Otherwise, the previous one
doesn't really fix things, and probably makes things worse as it assumes the
parent clock would be changed.

ChenYu

> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_dotclock.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c 
> b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> index 1ddf6d7a7107..5b3463197c48 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> @@ -170,6 +170,7 @@ int sun4i_dclk_create(struct device *dev, struct 
> sun4i_tcon *tcon)
> init.ops = _dclk_ops;
> init.parent_names = _name;
> init.num_parents = 1;
> +   init.flags = CLK_SET_RATE_PARENT;
>
> dclk->regmap = tcon->regs;
> dclk->hw.init = 
> --
> 2.8.2
>

[PATCH 14/20] ARM: sun5i: a13: Add LCD pins

[Chen-Yu Tsai]

On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
 wrote:
> The RGB bus can be used in several configurations, one of which being the
> RGB666.
>
> Add a pinctrl group for that case.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

> ---
>  arch/arm/boot/dts/sun5i-a13.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi 
> b/arch/arm/boot/dts/sun5i-a13.dtsi
> index 263d46dbc7e6..79b5d513c142 100644
> --- a/arch/arm/boot/dts/sun5i-a13.dtsi
> +++ b/arch/arm/boot/dts/sun5i-a13.dtsi
> @@ -237,6 +237,16 @@
>   {
> compatible = "allwinner,sun5i-a13-pinctrl";
>
> +   lcd_rgb666_pins: lcd_rgb666 at 0 {
> +   allwinner,pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
> +"PD10", "PD11", "PD12", "PD13", "PD14", 
> "PD15",
> +"PD18", "PD19", "PD20", "PD21", "PD22", 
> "PD23",
> +"PD24", "PD25", "PD26", "PD27";
> +   allwinner,function = "lcd0";
> +   allwinner,drive = ;

Just a thought: would we ever need to increase the drive strength for very high
resolutions?

> +   allwinner,pull = ;
> +   };
> +
> uart1_pins_a: uart1 at 0 {
> allwinner,pins = "PE10", "PE11";
> allwinner,function = "uart1";
> --
> 2.8.2
>

[PATCH] drm.h: Handle DragonFly like Linux

[ran...@sibernet.com]

On Tue, 17 May 2016, Francois Tigeot wrote:

> Hi Randy,
>
> randyf at sibernet.com wrote:
>>
>>If you are interested in the primary Solaris source, you will really
>> want to looking at:
>> 
>> https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel
>
> Thanks. This doesn't look like a git repository though.
> How can I clone it ?
>

   Yea, it's a mercurial repository.  However, it is also browsable in that 
link, if you were interested in specific files (drm.h - at least for now - 
is in sys/drm).

>>> They are divergent by design :-/
>>> Making the Linux headers public and removing the #else path in libdrm's
>>> drm.h could be the right thing to do. I'll keep thinking about it...
>>
>>Removing the #else path will cause Solaris compiles to fail as it
>> does consume that side of the conditional (though, as we patch this file
>> and don't use it as is, it would be trivial to add it or any other
>> Solaris-specific requirements back in).
>
> I was only thinking about patching our libdrm package here, not changing the 
> upstream version.

   It is likely we will continue patching, but do want to limit how much we 
actually have to do (will likely be mostly limited to type conversions). 
At some time, though, I may look into suggesting some of the changes 
upstream (since there already is blocking for __linux__, it shouldn't be 
that bad to add __sun).

>
>>From a Solaris perspective, I don't see how this file can ever -not-
>> have conditional compile statements or be patched to support Solaris, as
>> there are sufficient differences requiring at least minor changes.
>
> I'd still like to only use the Linux version by default, both in kernel and 
> userland.
> I guess at this point the only way to do that without breaking Solaris is to 
> either use local patches or change the logic of the #if directives to replace 
> the Linux check with a !Solaris one.

   For Solaris __linux__ implies !Solaris, so there is no difference.  At 
that specific point in the file, there are header inclusions which don't 
(and probably never will) have a Solaris equivilent.  So I either have to 
patch or add a Solaris conditional anyway (even with the Solaris wrapper, 
it won't be 100% compile compatible).

>>> I'm afraid there won't be many *BSD people around. This year, the XDC and
>>> EuroBSDCon conferences fall on the same week-end :-(
>>> I'm not sure which one I will be attending to at this point.
>>
>>Not sure yet if I will be attending either.  But would happily
>> provide any input on this either in person (if I am there), or via email.
>
> Dri-devel seems to still be the best place for now :)
>

   Indeed (though as I mentioned previously, I'm pretty sparse here, mostly 
just trying to keep up).

> Cheers,

   Same!

 Randy

[PATCH v7 3/3] SMAF: add fake secure module

[Emil Velikov]

Hi Benjamin,

On 9 May 2016 at 16:07, Benjamin Gaignard  
wrote:
> This module is allow testing secure calls of SMAF.
>
"Add fake secure module" does sound like something not (m)any people
want to hear ;-)
Have you considered calling it 'dummy', 'test' or similar ?


> --- /dev/null
> +++ b/drivers/smaf/smaf-fakesecure.c
> @@ -0,0 +1,85 @@
> +/*
> + * smaf-fakesecure.c
> + *
> + * Copyright (C) Linaro SA 2015
> + * Author: Benjamin Gaignard  for Linaro.
> + * License terms:  GNU General Public License (GPL), version 2
> + */
> +#include 
> +#include 
> +#include 
> +
> +#define MAGIC 0xDEADBEEF
> +
> +struct fake_private {
> +   int magic;
> +};
> +
> +static void *smaf_fakesecure_create(void)
> +{
> +   struct fake_private *priv;
> +
> +   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
Missing ENOMEM handling ?

> +   priv->magic = MAGIC;
> +
> +   return priv;
> +}
> +
> +static int smaf_fakesecure_destroy(void *ctx)
> +{
> +   struct fake_private *priv = (struct fake_private *)ctx;
You might want to flesh this cast into a (inline) helper and use it throughout ?


... and that is all. Hope these were useful, or at the very least not
utterly wrong, suggestions :-)


Regards,
Emil

P.S. From a quick look userspace has some subtle bugs/odd practises.
Let me know if you're interested in my input.

[PATCH 03/20] clk: sunxi: tcon-ch1: Do not return a negative error in get_parent

[Chen-Yu Tsai]

On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
 wrote:
> get_parent is supposed to return an unsigned 8 bit integer, so returning
> -EINVAL is a bad idea.
>
> Remove it.
>
> Reported-by: Dan Carpenter 
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

[PATCH v7 2/3] SMAF: add CMA allocator

[Emil Velikov]

Hi Benjamin,

On 9 May 2016 at 16:07, Benjamin Gaignard  
wrote:
> SMAF CMA allocator implement helpers functions to allow SMAF
> to allocate contiguous memory.
>
> match() each if at least one of the attached devices have coherent_dma_mask
> set to DMA_BIT_MASK(32).
>
What is the idea behind the hardcoded 32. Wouldn't it be better to avoid that ?


> +static void smaf_cma_release(struct dma_buf *dmabuf)
> +{
> +   struct smaf_cma_buffer_info *info = dmabuf->priv;
> +   DEFINE_DMA_ATTRS(attrs);
> +
> +   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
> +
Imho it's worth storing the dma_attrs within smaf_cma_buffer_info.
This way it's less likely for things to go wrong, if one forgets to
update one of the three in the future.


> +static void smaf_cma_unmap(struct dma_buf_attachment *attachment,
> +  struct sg_table *sgt,
> +  enum dma_data_direction direction)
> +{
> +   /* do nothing */
There could/should really be a comment explaining why we "do nothing"
here, right ?

> +}
> +
> +static int smaf_cma_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> +{
> +   struct smaf_cma_buffer_info *info = dmabuf->priv;
> +   int ret;
> +   DEFINE_DMA_ATTRS(attrs);
> +
> +   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
> +
> +   if (info->size < vma->vm_end - vma->vm_start)
> +   return -EINVAL;
> +
> +   vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> +   ret = dma_mmap_attrs(info->dev, vma, info->vaddr, info->paddr,
> +info->size, );
> +
> +   return ret;
Kill the temporary variable 'ret' ?


> +static struct dma_buf_ops smaf_cma_ops = {
const ? Afaict the compiler would/should warn you about discarding it
as the ops are defined const.


> +static struct dma_buf *smaf_cma_allocate(struct dma_buf *dmabuf,
> +size_t length, unsigned int flags)
> +{
> +   struct dma_buf_attachment *attach_obj;
> +   struct smaf_cma_buffer_info *info;
> +   struct dma_buf *cma_dmabuf;
> +   int ret;
> +
> +   DEFINE_DMA_BUF_EXPORT_INFO(export);
> +   DEFINE_DMA_ATTRS(attrs);
> +
> +   dma_set_attr(DMA_ATTR_WRITE_COMBINE, );
> +
> +   info = kzalloc(sizeof(*info), GFP_KERNEL);
> +   if (!info)
> +   return NULL;
> +
> +   info->dev = find_matching_device(dmabuf);
find_matching_device() can return NULL. We should handle that imho.

> +   info->size = length;
> +   info->vaddr = dma_alloc_attrs(info->dev, info->size, >paddr,
> + GFP_KERNEL | __GFP_NOWARN, );
> +   if (!info->vaddr) {
> +   ret = -ENOMEM;
set-but-unused-variable 'ret' ?

> +   goto error;
> +   }
> +
> +   export.ops = _cma_ops;
> +   export.size = info->size;
> +   export.flags = flags;
> +   export.priv = info;
> +
> +   cma_dmabuf = dma_buf_export();
> +   if (IS_ERR(cma_dmabuf))
Missing dma_free_attrs() ? I'd add another label in the error path and
handle it there.

> +   goto error;
> +
> +   list_for_each_entry(attach_obj, >attachments, node) {
> +   dma_buf_attach(cma_dmabuf, attach_obj->dev);
Imho one should error out if attach fails. Or warn at the very least ?


> +static int __init smaf_cma_init(void)
> +{
> +   INIT_LIST_HEAD(_cma.list_node);
Isn't this something that smaf_register_allocator() should be doing ?


Regards,
Emil

[PATCH v7 1/3] create SMAF module

[Emil Velikov]

 Hi Benjamin,

I'd suspect you're interested in some feedback on these, so here is a few :-)
Sadly (ideally?) nothing serious, but a bunch minor suggestions, plus
the odd bug.

On 9 May 2016 at 16:07, Benjamin Gaignard  
wrote:

> --- /dev/null
> +++ b/drivers/smaf/smaf-core.c
> @@ -0,0 +1,794 @@
> +/*
> + * smaf.c
The comment does not match the actual file name.

You could give a brief summary of the file(s), if you're feeling gracious ;-)


> +
> +/**
> + * smaf_grant_access - return true if the specified device can get access
> + * to the memory area
> + *
Reading this makes me wonder if {request,allow}_access won't be better name ?


> +static int smaf_secure_handle(struct smaf_handle *handle)
> +{
> +   if (atomic_read(>is_secure))
> +   return 0;
> +
> +   if (!have_secure_module())
> +   return -EINVAL;
> +
> +   handle->secure_ctx = smaf_dev.secure->create_ctx();
> +
Should one use a temporary variable so that the caller provided
storage is unchanged in case of an error ?

> +   if (!handle->secure_ctx)
> +   return -EINVAL;
> +
> +   atomic_set(>is_secure, 1);
> +   return 0;
> +}
> +


> +int smaf_register_secure(struct smaf_secure *s)
> +{
> +   /* make sure that secure module have all required functions
> +* to avoid test them each time later
> +*/
> +   WARN_ON(!s || !s->create_ctx || !s->destroy_ctx ||
> +   !s->grant_access || !s->revoke_access);
> +
Is something like below reasonable thing to do in the kernel ?
Same question goes for smaf_register_allocator() further down.

if (!s || )
  return -ESHOULDNEVERHAPPEN;



> +static struct vm_operations_struct smaf_vma_ops = {
Ops/vfucs normally are const data. Is there something preventing us here ?

> +   .close = smaf_vm_close,
> +};
> +
> +static int smaf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> +{
> +   struct smaf_handle *handle = dmabuf->priv;
> +   bool ret;
> +   enum dma_data_direction dir;
> +
> +   /* if no allocator attached, get the first allocator */
> +   if (!handle->allocator) {
> +   struct smaf_allocator *alloc;
> +
> +   mutex_lock(_dev.lock);
> +   alloc = smaf_get_first_allocator(dmabuf);
> +   mutex_unlock(_dev.lock);
> +
> +   /* still no allocator ? */
> +   if (!alloc)
> +   return -EINVAL;
> +
> +   handle->allocator = alloc;
> +   }
> +
> +   if (!handle->db_alloc) {
> +   struct dma_buf *db_alloc;
> +
> +   db_alloc = handle->allocator->allocate(dmabuf,
> +  handle->length,
> +  handle->flags);
> +   if (!db_alloc)
> +   return -EINVAL;
> +
> +   handle->db_alloc = db_alloc;
> +   }
> +
The above half of the function looks identical to smaf_map_dma_buf().
Worth factoring it out to a helper function ?


> +static int smaf_attach(struct dma_buf *dmabuf, struct device *dev,
> +  struct dma_buf_attachment *attach)
> +{
> +   struct smaf_handle *handle = dmabuf->priv;
> +   struct dma_buf_attachment *db_attach;
> +
> +   if (!handle->db_alloc)
> +   return 0;
> +
Shouldn't one return an error (-EINVAL or similar) here ?


> +static struct dma_buf_ops smaf_dma_buf_ops = {
const ? From a very quick look the compiler should warn us about it -
"smaf_dma_buf_ops discards const qualifier" or similar.


> +struct smaf_handle *smaf_create_handle(size_t length, unsigned int flags)
> +{
> +   struct smaf_handle *handle;
> +
> +   DEFINE_DMA_BUF_EXPORT_INFO(info);
> +
> +   handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> +   if (!handle)
> +   return ERR_PTR(-ENOMEM);
> +
Err this should be return NULL; correct ?

> +   info.ops = _dma_buf_ops;
> +   info.size = round_up(length, PAGE_SIZE);
> +   info.flags = flags;
> +   info.priv = handle;
> +
> +   handle->dmabuf = dma_buf_export();
> +   if (IS_ERR(handle->dmabuf)) {
> +   kfree(handle);
> +   return NULL;
> +   }
> +
> +   handle->length = info.size;
> +   handle->flags = flags;
> +
> +   return handle;
> +}
> +EXPORT_SYMBOL(smaf_create_handle);
> +
> +static long smaf_ioctl(struct file *file, unsigned int cmd, unsigned long 
> arg)
> +{
> +   switch (cmd) {
> +   case SMAF_IOC_CREATE:
> +   {
> +   struct smaf_create_data data;
> +   struct smaf_handle *handle;
> +
> +   if (copy_from_user(, (void __user *)arg, _IOC_SIZE(cmd)))
> +   return -EFAULT;
> +
> +   handle = smaf_create_handle(data.length, data.flags);
We want to sanitise the input data.{length,flags} before sending it
deeper in the kernel.

> +   if (!handle)
> +  

[PATCH] drm.h: Handle DragonFly like Linux

[ran...@sibernet.com]

On Tue, 17 May 2016, Francois Tigeot wrote:

>
>>> On the other hand, the non-Linux code path really is unused. I didn't want
>>> to be too intrusive in my patch but it's probably best to just remove it.
>>>
>> There is more to this world than Linux and BSD, there's Solaris as
>> well. Even though they tend to be very quiet ;-)

   I was hoping to change that a little, but there is still a fair amount 
of work going on in enough areas to keep us busy and not very talkative 
(I try to scan this list regularly, though).

>
> Right. I forgot about it since the Solaris-derived source code I have easy
> access to is illumos-gate and its drm.h hasn't been updated since 2009.
>

   If you are interested in the primary Solaris source, you will really 
want to looking at:

 
https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel

   On thing that you will notice is that this version duplicates headers 
between libdrm and the kernel driver.  The next version (a week or so) 
will have updated this to consume libdrm headers.

>> TL;DR: Please don't diverge userspace vs kernel drm headers. Just beat
>> it in shape so that it works in both cases (most likely the 'else'
>> one).
>>
>> Hopefully ^^ does not sound to hard to achieve and/or demanding ?
>
> They are divergent by design :-/
> Making the Linux headers public and removing the #else path in libdrm's
> drm.h could be the right thing to do. I'll keep thinking about it...
>

   Removing the #else path will cause Solaris compiles to fail as it does 
consume that side of the conditional (though, as we patch this file and 
don't use it as is, it would be trivial to add it or any other 
Solaris-specific requirements back in).

   From a Solaris perspective, I don't see how this file can ever -not- 
have conditional compile statements or be patched to support Solaris, as 
there are sufficient differences requiring at least minor changes.

>> P.S. Perhaps we should spend an hour or so over the next XDC trying to
>> flush any remaining differences/patches in the graphics stack ? Not
>> sure how many BSD/Solaris people will be around though.
>
> I'm afraid there won't be many *BSD people around. This year, the XDC and
> EuroBSDCon conferences fall on the same week-end :-(
> I'm not sure which one I will be attending to at this point.
>
> Thanks Emil,
>
> -- 
> Francois Tigeot


   Not sure yet if I will be attending either.  But would happily provide 
any input on this either in person (if I am there), or via email.

   Cheers!

 Randy

[PATCH 04/20] clk: sunxi: display: Add per-clock flags

[Chen-Yu Tsai]

Hi,

On Mon, May 16, 2016 at 8:47 PM, Maxime Ripard
 wrote:
> The TCON channel 0 clock that is the parent clock of our pixel clock is
> expected to change its rate depending on the resolution we want to output
> in our display engine.
>
> However, since it's only a mux, the only way it can do that is by changing
> its parents rate.
>
> Allow to give flags in our display clocks description, and add the
> CLK_SET_RATE_PARENT flag for the TCON channel 0 flag.
>
> Fixes: a3b4956ee6d9 ("clk: sunxi: display: Add per-clock flags")
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/clk/sunxi/clk-sun4i-display.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi/clk-sun4i-display.c 
> b/drivers/clk/sunxi/clk-sun4i-display.c
> index 445a7498d6df..9780fac6d029 100644
> --- a/drivers/clk/sunxi/clk-sun4i-display.c
> +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> @@ -33,6 +33,8 @@ struct sun4i_a10_display_clk_data {
>
> u8  width_div;
> u8  width_mux;
> +

Don't really need this separator, but I'm ok either way.

> +   u32 flags;
>  };
>
>  struct reset_data {
> @@ -166,7 +168,7 @@ static void __init sun4i_a10_display_init(struct 
> device_node *node,
>  data->has_div ? >hw : NULL,
>  data->has_div ? _divider_ops : NULL,
>  >hw, _gate_ops,
> -0);
> +data->flags);
> if (IS_ERR(clk)) {
> pr_err("%s: Couldn't register the clock\n", clk_name);
> goto free_div;
> @@ -232,6 +234,7 @@ static const struct sun4i_a10_display_clk_data 
> sun4i_a10_tcon_ch0_data __initcon
> .offset_rst = 29,
> .offset_mux = 24,
> .width_mux  = 2,
> +   .flags  = CLK_SET_RATE_PARENT,
>  };
>
>  static void __init sun4i_a10_tcon_ch0_setup(struct device_node *node)
> --
> 2.8.2
>

Acked-by: Chen-Yu Tsai 

[Bug 95413] Oversaturation + Artifacts on screen refresh with Redwood GPU

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

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

--- Comment #5 from Sawyer Bergeron  ---
Created attachment 123801
  --> https://bugs.freedesktop.org/attachment.cgi?id=123801=edit
4th file requested

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 95413] Oversaturation + Artifacts on screen refresh with Redwood GPU

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

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

--- Comment #4 from Sawyer Bergeron  ---
Created attachment 123800
  --> https://bugs.freedesktop.org/attachment.cgi?id=123800=edit
3rd file requested

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 95413] Oversaturation + Artifacts on screen refresh with Redwood GPU

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

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

--- Comment #3 from Sawyer Bergeron  ---
Created attachment 123799
  --> https://bugs.freedesktop.org/attachment.cgi?id=123799=edit
2nd file requested

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 95413] Oversaturation + Artifacts on screen refresh with Redwood GPU

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

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

--- Comment #2 from Sawyer Bergeron  ---
Created attachment 123798
  --> https://bugs.freedesktop.org/attachment.cgi?id=123798=edit
1st file of those requested

Uname -r returns "4.4.0-22-generic"
X -version returns "1.18.3"
I have no idea how to check ddx, but if necessary I can with instruction
(probably)

Here are the files you requested

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: