[Bug 172381] New: nouveau kernel module leaks memory on hibernate.

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

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

Bug ID: 172381
   Summary: nouveau kernel module leaks memory on hibernate.
   Product: Drivers
   Version: 2.5
Kernel Version: 4.8rc6
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: me at hussam.eu.org
Regression: No

On hibernate, it seems that nouveau pushes vram into physical ram instead of
swap (possibly on the assumption that it is going to be swaped to disk on
hibernation).
In my case, I have 4GB physical ram and vram = 2GB.
   - Hibernate only works if amount of physical ram in use is less than 2G (4 -
2 = 2), otherwise I get an "error -12 creating hibernation image" "PM: Not
enough free memory".
   - If hibernate works, on resume, vram is not freed from physical memory.
rmmoding nouveau frees 500+ MB of physical ram.
   - So far, I have reproduced this on kernels 4.4 to 4.8rc6 (I have not
attempted older kernels).
   - Cards tested are 630GT (fermi) and 730GT (kepler).

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

[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[Patrik Jakobsson]

On Tue, Sep 20, 2016 at 2:08 PM, Jani Nikula
 wrote:
> On Tue, 20 Sep 2016, Dan Carpenter  wrote:
>> Don't be a dummy...  This is easy to review an it fixes a bug.

In this particular case it might not be clear that an unknown GCT
version causes a complete GCT failure so both messages are useful.

>>
>> I'm fine with you NAKing all these patches based on who they are from.
>> I mostly just delete these without responding because the guy has
>> history of introducing bugs and never listens to feedback.  But asking
>> pointless rhetorical questions is not helpful.
>>
>> A lot of people are CC'd and you're wasting everyone's time by asking
>> questions where you know the answer.
>
> Fair enough, sorry for the noise.
>
> To be honest, I did only look at the patches, not who they were from. We
> have CI for drm/i915, but I don't think it's constructive to keep
> changing drivers like this where the upstream isn't actively developed
> and tested. But I digress. It's up to Patrik anyway.

Nothing in this series is very helpful so NAK. In general I'm not fond
of trivial changes like this since it's hard to say what motivates the
author. In theory it shouldn't matter but so far it's been directly
related to the quality of the patches. I can help test changes for
gma500 if needed but please make it worth my while.

Best regards
Patrik

>
> BR,
> Jani.
>
>
>
> --
> Jani Nikula, Intel Open Source Technology Center

[Bug 141741] drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM

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

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

--- Comment #14 from Jose Barros  ---
Created attachment 239331
  --> https://bugzilla.kernel.org/attachment.cgi?id=239331=edit
dmesg | egrep 'drm|radeon' on 4.6.0-kali1-amd64

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

[PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

[Mike Lothian]

Hi

I've bisected back to this commit in the drm-intel-nightly branch

05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit
commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460
Author: Lyude 
Date:   Wed Aug 17 15:55:57 2016 -0400

   drm/i915/skl: Ensure pipes with changed wms get added to the state

   If we're enabling a pipe, we'll need to modify the watermarks on all
   active planes. Since those planes won't be added to the state on
   their own, we need to add them ourselves.

   Signed-off-by: Lyude 
   Reviewed-by: Matt Roper 
   Cc: stable at vger.kernel.org
   Cc: Ville Syrjälä 
   Cc: Daniel Vetter 
   Cc: Radhakrishna Sripada 
   Cc: Hans de Goede 
   Signed-off-by: Maarten Lankhorst 
   Link: 
http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-6-git-send-email-cpaul
 at redhat.com

The symptoms I'm seeing look like tearing at the top of the screen and
it's especially noticeable in Chrome - reverting this commit makes the
issue go away

Let me know if you'd like me to raise a bug

Cheers

Mike

(Re-sending from Gmail - as Inbox doesn't let me send as plain text)

On 17 August 2016 at 20:55, Lyude  wrote:
> If we're enabling a pipe, we'll need to modify the watermarks on all
> active planes. Since those planes won't be added to the state on
> their own, we need to add them ourselves.
>
> Signed-off-by: Lyude 
> Reviewed-by: Matt Roper 
> Cc: stable at vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 849f039..a3d24cb 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4117,6 +4117,10 @@ skl_compute_ddb(struct drm_atomic_state *state)
> ret = skl_allocate_pipe_ddb(cstate, ddb);
> if (ret)
> return ret;
> +
> +   ret = drm_atomic_add_affected_planes(state, 
> _crtc->base);
> +   if (ret)
> +   return ret;
> }
>
> return 0;
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

[Mike Lothian]

Hi

I've bisected back to this commit in the drm-intel-nightly branch

05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit
commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460
Author: Lyude 
Date:   Wed Aug 17 15:55:57 2016 -0400

   drm/i915/skl: Ensure pipes with changed wms get added to the state

   If we're enabling a pipe, we'll need to modify the watermarks on all
   active planes. Since those planes won't be added to the state on
   their own, we need to add them ourselves.

   Signed-off-by: Lyude 
   Reviewed-by: Matt Roper 
   Cc: stable at vger.kernel.org
   Cc: Ville Syrjälä 
   Cc: Daniel Vetter 
   Cc: Radhakrishna Sripada 
   Cc: Hans de Goede 
   Signed-off-by: Maarten Lankhorst 
   Link:
http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-6-git-send-email-cpaul
 at redhat.com

The symptoms I'm seeing look like tearing at the top of the screen and it's
especially noticeable in Chrome - reverting this commit makes the issue go
away

Let me know if you'd like me to raise a bug

Cheers

Mike

On Wed, 17 Aug 2016 at 20:56 Lyude  wrote:

> If we're enabling a pipe, we'll need to modify the watermarks on all
> active planes. Since those planes won't be added to the state on
> their own, we need to add them ourselves.
>
> Signed-off-by: Lyude 
> Reviewed-by: Matt Roper 
> Cc: stable at vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 849f039..a3d24cb 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4117,6 +4117,10 @@ skl_compute_ddb(struct drm_atomic_state *state)
> ret = skl_allocate_pipe_ddb(cstate, ddb);
> if (ret)
> return ret;
> +
> +   ret = drm_atomic_add_affected_planes(state,
> _crtc->base);
> +   if (ret)
> +   return ret;
> }
>
> return 0;
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part ------
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/1ee00b89/attachment-0001.html>

[PATCH v3] dma-buf/sync_file: Increment refcount of fence when all are signaled.

[Sumit Semwal]

Hi Rafael,

On 16 September 2016 at 00:44, Rafael Antognolli
 wrote:
> When we merge several fences, if all of them are signaled already, we
> still keep one of them. So instead of using add_fence(), which will not
> increase the refcount of signaled fences, we should explicitly call
> fence_get() for the fence we are keeping.
>
> This patch fixes a kernel panic that can be triggered by creating a fence that
> is expired (or increasing the timeline until it expires), then creating a
> merged fence out of it, and deleting the merged fence. This will make the
> original expired fence's refcount go to zero.
>
> Testcase: igt/sw_sync/sync_expired_merge
> Signed-off-by: Rafael Antognolli 
> Reviewed-by: Chris Wilson 
> Reviewed-by: Gustavo Padovan 
Thanks for the patch; applied via drm-misc.

> ---
>  drivers/dma-buf/sync_file.c | 6 ++
Best,
Sumit.

[PATCH] dma-buf/sync_file: fix documentation error

[Sumit Semwal]

Hi Emilio,

On 19 September 2016 at 17:40, Gustavo Padovan
 wrote:
> Hi Emilio,
>
> 2016-09-19 Emilio López :
>
>> The ioctl name and description on the documentation block don't
>> match the ioctl being defined. This was probably overlooked while
>> renaming the ioctls during the sync file destaging. This patch
>> provides a more accurate description of what the ioctl actually does.
>>
>> Signed-off-by: Emilio López 
>> ---
>
> Reviewed-by: Gustavo Padovan 
>
Thanks; applied to drm-misc.
> Gustavo
>

Best,
Sumit.

[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

[Sumit Semwal]

Hi Baoyou,

On 20 September 2016 at 16:43, Gustavo Padovan  wrote:
> 2016-09-18 Baoyou Xie :
>
>> We get 1 warning when building kernel with W=1:
>> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 
>> 'sync_timeline_create' [-Wmissing-prototypes]
>>
>> In fact, this function is only used in the file in which it is
>> declared and don't need a declaration, but can be made static.
>> So this patch marks it 'static'.
>>
>> Signed-off-by: Baoyou Xie 
>> ---
>>  drivers/dma-buf/sw_sync.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Thanks for finding this.

Thanks for the patch; this doesn't apply to mainline yet, since the
de-staging of sw_sync code is queued for 4.9 via Greg-KH's tree.
CC'ing him.

Greg, would it be possible to please take this via your tree?
>
> Reviewed-by: Gustavo Padovan 
>
Acked-by: Sumit Semwal 

> Gustavo
>

Best regards,
Sumi

[PATCH xf86-video-ati] Use local implementation of RegionDuplicate for older xserver

[Michel Dänzer]

From: Michel Dänzer 

It was only added in xserver 1.15. Fixes build against older xserver.

Reported-by: Pali Rohár 
Signed-off-by: Michel Dänzer 
---
 configure.ac |  6 ++
 src/radeon.h | 19 +++
 2 files changed, 25 insertions(+)

diff --git a/configure.ac b/configure.ac
index 394f45a..8dc55d8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -137,6 +137,12 @@ else
 fi
 AM_CONDITIONAL(GLAMOR, test x$GLAMOR != xno)

+AC_CHECK_DECL(RegionDuplicate,
+ [AC_DEFINE(HAVE_REGIONDUPLICATE, 1,
+ [Have RegionDuplicate API])], [],
+ [#include 
+  #include ])
+
 AC_CHECK_DECL(fbGlyphs,
  [AC_DEFINE(HAVE_FBGLYPHS, 1, [Have fbGlyphs API])], [],
  [#include 
diff --git a/src/radeon.h b/src/radeon.h
index f3a3e1c..590966f 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -96,6 +96,25 @@

 struct _SyncFence;

+#ifndef HAVE_REGIONDUPLICATE
+
+static inline RegionPtr
+RegionDuplicate(RegionPtr pOld)
+{
+RegionPtr pNew;
+
+pNew = RegionCreate(>extents, 0);
+if (!pNew)
+   return NULL;
+if (!RegionCopy(pNew, pOld)) {
+   RegionDestroy(pNew);
+   return NULL;
+}
+return pNew;
+}
+
+#endif
+
 #ifndef MAX
 #define MAX(a,b) ((a)>(b)?(a):(b))
 #endif
-- 
2.9.3

[PATCH] Add drmModeAddFB2WithModifiers() which takes format modifiers

[Alexandre Courbot]

On 09/14/2016 07:07 AM, Kristian H. Kristensen wrote:
> The only current user of this open codes the ioctl. Let's add an entry
> point for this to libdrm.

Tested-by: Alexandre Courbot 

Replaced one custom (staging) ioctl on Tegra with FB modifiers, noticed
this was missing!

> 
> Signed-off-by: Kristian H. Kristensen 
> ---
>  xf86drmMode.c | 21 +
>  xf86drmMode.h |  7 +++
>  2 files changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index f7b5948..2907c5c 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -270,10 +270,10 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t 
> height, uint8_t depth,
>   return 0;
>  }
>  
> -int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
> -   uint32_t pixel_format, uint32_t bo_handles[4],
> -   uint32_t pitches[4], uint32_t offsets[4],
> -   uint32_t *buf_id, uint32_t flags)
> +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
> +   uint32_t pixel_format, uint32_t bo_handles[4],
> +   uint32_t pitches[4], uint32_t offsets[4],
> +   uint64_t modifier[4], uint32_t *buf_id, 
> uint32_t flags)
>  {
>   struct drm_mode_fb_cmd2 f;
>   int ret;
> @@ -286,6 +286,8 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
>   memcpy(f.handles, bo_handles, 4 * sizeof(bo_handles[0]));
>   memcpy(f.pitches, pitches, 4 * sizeof(pitches[0]));
>   memcpy(f.offsets, offsets, 4 * sizeof(offsets[0]));
> +if (modifier)
> + memcpy(f.modifier, modifier, 4 * sizeof(modifier[0]));
>  
>   if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, )))
>   return ret;
> @@ -294,6 +296,17 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t 
> height,
>   return 0;
>  }
>  
> +int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
> +  uint32_t pixel_format, uint32_t bo_handles[4],
> +  uint32_t pitches[4], uint32_t offsets[4],
> +  uint32_t *buf_id, uint32_t flags)
> +{
> +  return drmModeAddFB2WithModifiers(fd, width, height,
> +pixel_format, bo_handles,
> +pitches, offsets, NULL,
> +buf_id, flags);
> +}
> +
>  int drmModeRmFB(int fd, uint32_t bufferId)
>  {
>   return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, );
> diff --git a/xf86drmMode.h b/xf86drmMode.h
> index 4de7bbb..02190ea 100644
> --- a/xf86drmMode.h
> +++ b/xf86drmMode.h
> @@ -369,6 +369,13 @@ extern int drmModeAddFB2(int fd, uint32_t width, 
> uint32_t height,
>uint32_t pixel_format, uint32_t bo_handles[4],
>uint32_t pitches[4], uint32_t offsets[4],
>uint32_t *buf_id, uint32_t flags);
> +
> +/* ...with format modifiers */
> +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
> +   uint32_t pixel_format, uint32_t bo_handles[4],
> +   uint32_t pitches[4], uint32_t offsets[4],
> +   uint64_t modifier[4], uint32_t *buf_id, 
> uint32_t flags);
> +
>  /**
>   * Destroies the given framebuffer.
>   */
> 

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

--- Comment #12 from Mike Lothian  ---
Created attachment 126668
  --> https://bugs.freedesktop.org/attachment.cgi?id=126668=edit
Dmesg with issues

This is the dmesg, when the system is still semi-responsive

-- 
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/20160920/16594dcc/attachment-0001.html>

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

--- Comment #11 from Mike Lothian  ---
Created attachment 126667
  --> https://bugs.freedesktop.org/attachment.cgi?id=126667=edit
Glxgears corrupted

-- 
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/20160920/dada5c3f/attachment-0001.html>

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

--- Comment #10 from Mike Lothian  ---
Even with this reverted things aren't working correctly if I do a DRI_PRIME=1
glxgears the image is highly messed up

-- 
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/20160920/c35eac93/attachment-0001.html>

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

--- Comment #9 from Mike Lothian  ---
The first bad commit is:

abd0a5ee7a25d108e9d709a4f61ef58754b60919 is the first bad commit
commit abd0a5ee7a25d108e9d709a4f61ef58754b60919
Author: Monk Liu 
Date:   Wed Sep 14 19:10:33 2016 +0800

drm/amdgpu:correct smc fw version error

original method get wrong smc fw version.

Signed-off-by: Monk Liu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 

Reverting this one allows X to start again

-- 
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/20160920/70d06f45/attachment-0001.html>

[PATCH v3 11/20] drm: omapdrm: Check DSS manager state in the enable/disable helpers

[Tomi Valkeinen]

On 19/09/16 15:27, Laurent Pinchart wrote:
> The omapdrm DSS manager enable/disable operations check the DSS manager
> state to avoid double enabling/disabling. Move that code to the DSS
> manager to decrease the dependency of the DRM layer to the DSS layer.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c  | 1 -
>  drivers/gpu/drm/omapdrm/dss/output.c | 6 ++
>  drivers/gpu/drm/omapdrm/omap_crtc.c  | 3 ---
>  3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 535240fba671..ab150bf21dd8 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -2911,7 +2911,6 @@ bool dispc_mgr_is_enabled(enum omap_channel channel)
>  {
>   return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
>  }
> -EXPORT_SYMBOL(dispc_mgr_is_enabled);
>  
>  void dispc_wb_enable(bool enable)
>  {
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index 24f859488201..f0be621895fa 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -217,12 +217,18 @@ EXPORT_SYMBOL(dss_mgr_set_lcd_config);
>  
>  int dss_mgr_enable(enum omap_channel channel)
>  {
> + if (dispc_mgr_is_enabled(channel))
> + return 0;
> +
>   return dss_mgr_ops->enable(channel);
>  }
>  EXPORT_SYMBOL(dss_mgr_enable);
>  
>  void dss_mgr_disable(enum omap_channel channel)
>  {
> + if (!dispc_mgr_is_enabled(channel))
> + return;
> +
>   dss_mgr_ops->disable(channel);
>  }
>  EXPORT_SYMBOL(dss_mgr_disable);
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 4b7e16786e1e..a0c26592fc69 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -141,9 +141,6 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
> bool enable)
>   return;
>   }
>  
> - if (dispc_mgr_is_enabled(channel) == enable)
> - return;
> -
>   if (omap_crtc->channel == OMAP_DSS_CHANNEL_DIGIT) {
>   /*
>* Digit output produces some sync lost interrupts during the
> 

With this change omap_crtc_set_enabled() will do extra work if the
output is already enabled/disabled, and, if I'm not mistaken, will do
omap_irq_wait() there which might lead to issues.

If you remove the check, then I think the driver should make sure that
omap_crtc_set_enabled() is not called if the output is already
enabled/disabled. Maybe that can be done in
omap_crtc_dss_enable/disable, using the new enabled flag.

 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/20160920/2974e9b7/attachment-0001.sig>

[PATCH v3 10/20] drm: omapdrm: Only commit planes on active CRTCs

[Tomi Valkeinen]

On 19/09/16 15:27, Laurent Pinchart wrote:
> The DRM core supports skipping plane update for inactive CRTCs for
> hardware that don't need it or can't cope with it. That's our case, so
> use the DRM core infrastructure instead of reinventing it.

I don't follow this desc. What is omapdrm reinventing? At least this
patch does not remove any of the "reinvention".

What does DRM_PLANE_COMMIT_ACTIVE_ONLY do? Skips plane HW configuration
for planes on crtcs that are disabled? The plane HW config will still be
done when the crtc is about to be enabled, right?

 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/20160920/fb515fbd/attachment-0001.sig>

[PATCH][V2] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets

[Colin King]

From: Colin Ian King 

The check for an out of bound index into array interrupt_status_offsets
is off-by-one. Fix this and also don't compared to a hard coded array
size but use adev->mode_info.num_hpd instead.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index d3512f3..4ce4c1a 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev,
uint32_t disp_int, mask, int_control, tmp;
unsigned hpd;

-   if (entry->src_data > 6) {
+   if (entry->src_data >= adev->mode_info.num_hpd) {
DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, 
entry->src_data);
return 0;
}
-- 
2.9.3

[PATCH v3 09/20] drm: omapdrm: Replace DSS manager state check with omapdrm CRTC state

[Tomi Valkeinen]

On 19/09/16 15:27, Laurent Pinchart wrote:
> Instead of conditioning planes update based on the DD manager state, use

s/DD/DSS/

Maybe "manager HW state" to highlight that the status is read from a HW
register.

> the enabled field newly added to the omap_crtc structure. This reduces
> the dependency from the DRM layer to the DSS layer.
> 
> The enabled field is a transitory measure, the implementation should use
> the CRTC atomic state instead. However, given that CRTCs are currently
> not enabled/disabled through their .enable() and .disable() operations
> but through a convoluted code paths starting at the associated encoder
> operations, there is not clear guarantee that the atomic state always
> matches the hardware state. This will be refactored later, at which
> point the enabled field will be removed.
> 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v2:
> 
> - Use enabled field in struct omap_crtc instead of CRTC atomic state
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index cdcfda31043e..f41a638c8d65 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -40,6 +40,7 @@ struct omap_crtc {
>  
>   bool ignore_digit_sync_lost;
>  
> + bool enabled;
>   bool pending;
>   wait_queue_head_t pending_wait;
>  };
> @@ -136,6 +137,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
> bool enable)
>  
>   if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) {
>   dispc_mgr_enable(channel, enable);
> + omap_crtc->enabled = enable;
>   return;
>   }
>  
> @@ -172,6 +174,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
> bool enable)
>   }
>  
>   dispc_mgr_enable(channel, enable);
> + omap_crtc->enabled = enable;

omap_crtc_set_enabled() is only called from omap_crtc_dss_enable() and
omap_crtc_dss_disable(). It's probably a bit cleaner to set the
omap_crtc->enabled in those functions.

Btw, omap_crtc_set_enabled() has a comment:

/* Called only from the encoder enable/disable and suspend/resume
handlers. */

which doesn't seem to hold true...

 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/20160920/473f9457/attachment-0001.sig>

[PATCH] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets

[Colin Ian King]

On 20/09/16 16:39, Alex Deucher wrote:
> On Tue, Sep 20, 2016 at 11:16 AM, Colin King  
> wrote:
>> From: Colin Ian King 
>>
>> The check for an out of bound index into array interrupt_status_offsets
>> is off-by-one. Fix this and also don't compared to a hard coded array
>> size but use ARRAY_SIZE instead.
>>
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
>> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
>> index d3512f3..4ce4c1a 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
>> @@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev,
>> uint32_t disp_int, mask, int_control, tmp;
>> unsigned hpd;
>>
>> -   if (entry->src_data > 6) {
>> +   if (entry->src_data >= ARRAY_SIZE(interrupt_status_offsets)) {
> 
> This should actually be adev->mode_info.num_hpd as some asic variants
> may not have 6 hpd lines.  Thanks for catching this.
> 
> Alex

Ah, that's a better way, so:
if (entry->src_data >= adev->mode_info.num_hpd) {
...

I'll send V2

> 
>> DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, 
>> entry->src_data);
>> return 0;
>> }
>> --
>> 2.9.3
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 08/20] drm: omapdrm: Handle OCP error IRQ directly

[Tomi Valkeinen]

On 19/09/16 15:27, Laurent Pinchart wrote:
> Instead of going through a complicated registration mechanism, just
> call the OCP error IRQ handler directly from the main IRQ handler.
> 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v1:
> 
> - Rename IRQ handler to omap_irq_ocp_error_handler()
> - Replace hex error value with "OCP error" message
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.h |  1 -
>  drivers/gpu/drm/omapdrm/omap_irq.c | 28 ++--
>  2 files changed, 10 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
> b/drivers/gpu/drm/omapdrm/omap_drv.h
> index 7a1d8384147c..05375bc40091 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -103,7 +103,6 @@ struct omap_drm_private {
>   /* irq handling: */
>   struct list_head irq_list;/* list of omap_drm_irq */
>   uint32_t irq_mask;  /* enabled irqs in addition to irq_list 
> */
> - struct omap_drm_irq error_handler;
>  
>   /* atomic commit */
>   struct {
> diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
> b/drivers/gpu/drm/omapdrm/omap_irq.c
> index f0f110faf1e6..257c1f3c76f3 100644
> --- a/drivers/gpu/drm/omapdrm/omap_irq.c
> +++ b/drivers/gpu/drm/omapdrm/omap_irq.c
> @@ -21,12 +21,6 @@
>  
>  static DEFINE_SPINLOCK(list_lock);
>  
> -static void omap_irq_error_handler(struct omap_drm_irq *irq,
> - uint32_t irqstatus)
> -{
> - DRM_ERROR("errors: %08x\n", irqstatus);
> -}
> -
>  /* call with list_lock and dispc runtime held */
>  static void omap_irq_update(struct drm_device *dev)
>  {
> @@ -224,6 +218,14 @@ static void omap_irq_fifo_underflow(struct 
> omap_drm_private *priv,
>   pr_cont("(0x%08x)\n", irqstatus);
>  }
>  
> +static void omap_irq_ocp_error_handler(u32 irqstatus)
> +{
> + if (!(irqstatus & DISPC_IRQ_OCP_ERR))
> + return;
> +
> + DRM_ERROR("OCP error\n");
> +}
> +
>  static irqreturn_t omap_irq_handler(int irq, void *arg)
>  {
>   struct drm_device *dev = (struct drm_device *) arg;
> @@ -250,6 +252,7 @@ static irqreturn_t omap_irq_handler(int irq, void *arg)
>   omap_crtc_error_irq(crtc, irqstatus);
>   }
>  
> + omap_irq_ocp_error_handler(irqstatus);
>   omap_irq_fifo_underflow(priv, irqstatus);
>  
>   spin_lock_irqsave(_lock, flags);
> @@ -282,7 +285,6 @@ static const u32 error_irqs[] = {
>  int omap_drm_irq_install(struct drm_device *dev)
>  {
>   struct omap_drm_private *priv = dev->dev_private;
> - struct omap_drm_irq *error_handler = >error_handler;
>   unsigned int num_mgrs = dss_feat_get_num_mgrs();
>   unsigned int max_planes;
>   unsigned int i;
> @@ -290,7 +292,7 @@ int omap_drm_irq_install(struct drm_device *dev)
>  
>   INIT_LIST_HEAD(>irq_list);
>  
> - priv->irq_mask = 0;
> + priv->irq_mask = DISPC_IRQ_OCP_ERR;
>  
>   max_planes = min(ARRAY_SIZE(priv->planes), ARRAY_SIZE(error_irqs));
>   for (i = 0; i < max_planes; ++i) {
> @@ -309,16 +311,6 @@ int omap_drm_irq_install(struct drm_device *dev)
>   if (ret < 0)
>   return ret;
>  
> - error_handler->irq = omap_irq_error_handler;
> - error_handler->irqmask = DISPC_IRQ_OCP_ERR;
> -
> - /* for now ignore DISPC_IRQ_SYNC_LOST_DIGIT.. really I think
> -  * we just need to ignore it while enabling tv-out
> -  */
> - error_handler->irqmask &= ~DISPC_IRQ_SYNC_LOST_DIGIT;
> -
> - omap_irq_register(dev, error_handler);
> -
>   dev->irq_enabled = true;
>  
>   return 0;
> 

The removal of DISPC_IRQ_SYNC_LOST_DIGIT code above feels a bit out of
place for this patch.

 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/20160920/0156bcb1/attachment-0001.sig>

[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

[Andrzej Hajda]

On 20.09.2016 16:09, Tobias Jakobi wrote:
> Hi Andrzej,
>
>
> Andrzej Hajda wrote:
>> On 20.09.2016 14:34, Andrzej Hajda wrote:
>>> On 20.09.2016 13:23, Tobias Jakobi wrote:
 Hello Andrzej,

 first of all, I've noticed an error myself. mixer_disable() calls
 mixer_disable_plane(), so it should also be modified. I'll send a v2 later.

 Now to your points...


 Andrzej Hajda wrote:
> On 19.09.2016 16:16, Tobias Jakobi wrote:
>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>> in mixer_cfg_layer().
>> Trigger this via atomic flush.
>>
>> Signed-off-by: Tobias Jakobi 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 104 
>> ++
>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>  2 files changed, 69 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 1e78d57..d4efd9c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -99,6 +99,7 @@ struct mixer_context {
>>  struct drm_device   *drm_dev;
>>  struct exynos_drm_crtc  *crtc;
>>  struct exynos_drm_plane planes[MIXER_WIN_NR];
>> +unsigned long   state_cache;
> The name of the variable is cryptic.
 Yes, I'll try to come up with something better. It would probably be
 easier if struct mixer_context had a documentation for its fields.

 Anyway, any suggestions?
>>> (active|enabled)_(planes|windows), or sth similar?
> Thanks, I think I'll go with the 'window' terminology then.
>
>
>>  int pipe;
>>  unsigned long   flags;
>>  
>> @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>> *ctx, unsigned int height)
>>  mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>  }
>>  
>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
>> -unsigned int priority, bool enable)
>> +static void mixer_cfg_layer(struct mixer_context *ctx)
>>  {
>>  struct mixer_resources *res = >mixer_res;
>> -u32 val = enable ? ~0 : 0;
>> -
>> -switch (win) {
>> -case 0:
>> -mixer_reg_writemask(res, MXR_CFG, val, 
>> MXR_CFG_GRP0_ENABLE);
>> -mixer_reg_writemask(res, MXR_LAYER_CFG,
>> -MXR_LAYER_CFG_GRP0_VAL(priority),
>> -MXR_LAYER_CFG_GRP0_MASK);
>> -break;
>> -case 1:
>> -mixer_reg_writemask(res, MXR_CFG, val, 
>> MXR_CFG_GRP1_ENABLE);
>> -mixer_reg_writemask(res, MXR_LAYER_CFG,
>> -MXR_LAYER_CFG_GRP1_VAL(priority),
>> -MXR_LAYER_CFG_GRP1_MASK);
>> +unsigned int win;
>>  
>> -break;
>> -case VP_DEFAULT_WIN:
>> -if (test_bit(MXR_BIT_VP_ENABLED, >flags)) {
>> -vp_reg_writemask(res, VP_ENABLE, val, 
>> VP_ENABLE_ON);
>> -mixer_reg_writemask(res, MXR_CFG, val,
>> -MXR_CFG_VP_ENABLE);
>> -mixer_reg_writemask(res, MXR_LAYER_CFG,
>> -
>> MXR_LAYER_CFG_VP_VAL(priority),
>> -MXR_LAYER_CFG_VP_MASK);
>> +struct exynos_drm_plane_state *state;
>> +struct drm_framebuffer *fb;
>> +unsigned int priority;
>> +u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
>> +bool enable;
>> +
>> +for (win = 0; win < MIXER_WIN_NR; ++win) {
>> +state = 
>> to_exynos_plane_state(ctx->planes[win].base.state);
>> +fb = state->fb;
>> +
>> +priority = state->base.normalized_zpos + 1;
>> +enable = test_bit(win, >state_cache);
>> +
>> +if (!enable)
>> +continue;
>> +
>> +switch (win) {
>> +case 0:
>> +mxr_cfg |=  MXR_CFG_GRP0_ENABLE;
>> +mxr_layer_cfg |= 
>> MXR_LAYER_CFG_GRP0_VAL(priority);
>> +break;
>> +
>> +case 1:
>> +mxr_cfg |=  MXR_CFG_GRP1_ENABLE;
>> +mxr_layer_cfg |= 
>> MXR_LAYER_CFG_GRP1_VAL(priority);
>> +break;
>> +
>> +case VP_DEFAULT_WIN:
>> +

[PATCH v3 06/20] drm: omapdrm: Handle FIFO underflow IRQs internally

[Tomi Valkeinen]

On 19/09/16 15:27, Laurent Pinchart wrote:
> As the FIFO underflow IRQ handler just prints an error message to the
> kernel log, simplify the code by not registering one IRQ handler per
> plane but print the messages directly from the main IRQ handler.
> 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v1:
> 
> - Only register error IRQs that exist on the HW
> ---


> +static const u32 error_irqs[] = {
> + [OMAP_DSS_GFX] = DISPC_IRQ_GFX_FIFO_UNDERFLOW,
> + [OMAP_DSS_VIDEO1] = DISPC_IRQ_VID1_FIFO_UNDERFLOW,
> + [OMAP_DSS_VIDEO2] = DISPC_IRQ_VID2_FIFO_UNDERFLOW,
> + [OMAP_DSS_VIDEO3] = DISPC_IRQ_VID3_FIFO_UNDERFLOW,
> +};

Actually, one comment: "error_irqs" is perhaps not a good name for this.
"omap_underflow_irqs"?

Or actually, maybe it would make sense to move this into dispc, and have
a similar func to dispc_mgr_get_sync_lost_irq().

 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/20160920/7411a729/attachment-0001.sig>

[PATCH v3 06/20] drm: omapdrm: Handle FIFO underflow IRQs internally

[Tomi Valkeinen]

On 19/09/16 15:27, Laurent Pinchart wrote:
> As the FIFO underflow IRQ handler just prints an error message to the
> kernel log, simplify the code by not registering one IRQ handler per
> plane but print the messages directly from the main IRQ handler.
> 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v1:
> 
> - Only register error IRQs that exist on the HW
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c   |  4 +--
>  drivers/gpu/drm/omapdrm/omap_drv.h   |  2 +-
>  drivers/gpu/drm/omapdrm/omap_irq.c   | 66 
> ++--
>  drivers/gpu/drm/omapdrm/omap_plane.c | 24 -
>  4 files changed, 66 insertions(+), 30 deletions(-)

Reviewed-by: Tomi Valkeinen 

 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/20160920/0d488b54/attachment-0001.sig>

[PATCH] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets

[Colin King]

From: Colin Ian King 

The check for an out of bound index into array interrupt_status_offsets
is off-by-one. Fix this and also don't compared to a hard coded array
size but use ARRAY_SIZE instead.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index d3512f3..4ce4c1a 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev,
uint32_t disp_int, mask, int_control, tmp;
unsigned hpd;

-   if (entry->src_data > 6) {
+   if (entry->src_data >= ARRAY_SIZE(interrupt_status_offsets)) {
DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, 
entry->src_data);
return 0;
}
-- 
2.9.3

[PATCH v3 04/20] drm: omapdrm: fb: Simplify mode command checks when creating framebuffer

[Tomi Valkeinen]

On 19/09/16 15:27, Laurent Pinchart wrote:
> The hardware requires all planes to have an identical pitch in number of
> pixels. Given that all supported formats use the same number of bytes
> per pixel in all planes, framebuffer creation checks can be simplified.
> The implementations assumes that no format use more than two planes
> which is true with the existing hardware.
> 
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v1:
> 
> - Clarify commit message and mention explicitly in the code that only
>   one and two planes formats are supported.
> - Rebase on top of the switch to drm_format_info()
> ---
>  drivers/gpu/drm/omapdrm/omap_fb.c | 58 
> +--
>  1 file changed, 31 insertions(+), 27 deletions(-)

Reviewed-by: Tomi Valkeinen 

 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/20160920/cf4f7ff1/attachment-0001.sig>

[Bug 97806] GPU lockup with mesa-git and llvm-svn with rx 470 on Unigine Heaven and TombRaider 2013

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

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

--- Comment #7 from Laurent carlier  ---
I have the gpu lockup with Unigine Heaven only when tesselation is enabled
regardless of the level

-- 
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/20160920/4ccad3e7/attachment-0001.html>

[PATCH v3 02/20] drm: omapdrm: fb: Use format information provided by the DRM core

[Tomi Valkeinen]

On 19/09/16 15:27, Laurent Pinchart wrote:
> The driver stores in a custom structure named format several pieces of
> information about the format that are available in the DRM core. Remove
> them and get the information from the DRM core instead.
> 
> Signed-off-by: Laurent Pinchart 
> ---


> @@ -128,13 +122,13 @@ static const struct drm_framebuffer_funcs 
> omap_framebuffer_funcs = {
>  };
>  
>  static uint32_t get_linear_addr(struct plane *plane,
> - const struct format *format, int n, int x, int y)
> + const struct drm_format_info *format, int n, int x, int y)
>  {
>   uint32_t offset;
>  
> - offset = plane->offset +
> - (x * format->planes[n].stride_bpp) +
> - (y * plane->pitch / format->planes[n].sub_y);
> + offset = plane->offset
> ++ (x * format->cpp[n] / (n == 1 ? 1 : format->hsub))
> ++ (y * plane->pitch / (n == 1 ? 1 : format->vsub));

n is the plane number? Shouldn't the above be (n == 0 ? 1 : format->hsub)?

> @@ -413,28 +410,32 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
> drm_device *dev,
>  
>   fb = _fb->base;
>   omap_fb->format = format;
> + omap_fb->dss_format = dss_format;
>   mutex_init(_fb->lock);
>  
> - for (i = 0; i < n; i++) {
> + for (i = 0; i < format->num_planes; i++) {
>   struct plane *plane = _fb->planes[i];
> - int size, pitch = mode_cmd->pitches[i];
> + unsigned int pitch = mode_cmd->pitches[i];
> + unsigned int hsub = i == 0 ? 1 : format->hsub;
> + unsigned int vsub = i == 0 ? 1 : format->vsub;

This makes me wonder... Will all drivers do something like the above?
It's a bit laborious way to get the pixel subsampling factor, and I
presume something like above is quite common so that all the
calculations can be more generic (and not specific to a UV plane).

 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/20160920/3b233bda/attachment-0001.sig>

[PATCH 6/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()

[Dan Carpenter]

On Tue, Sep 20, 2016 at 01:08:12PM +0300, Jani Nikula wrote:
> On Tue, 20 Sep 2016, SF Markus Elfring  
> wrote:
> > From: Markus Elfring 
> > Date: Tue, 20 Sep 2016 10:40:22 +0200
> >
> > * Adjust a jump target.
> 
> Please don't.
> 

Also there is nothing in CodingStyle that prohibits out: labels.  I
wrote that section and I wrote it in a deliberately way because no one
wants to see a bunch of "cleanup" patches that change the label names
for no reason.

People have been complaining about this in the kernel-summit mailing
list as if CodingStyle bans out labels and that it's my fault.  Neither
of these complaints are accurate.

regards,
dan carpenter

[PULL] sti-drm-next-2016-09-20

[Vincent ABRIOU]

Hi Dave,

Here are some patches for drm-next.
It contains:
- minor fixes for typo and warning.
- sparse and coccicheck warning fixes
- bunch of patches fixing issues found while testing drm/sti with an 
atomic version of weston
- the removal of the support of stih415-416 sti platform

Regards,
Vincent

The following changes since commit d27cd40addc06d34236bf818abcbe76f3527a69d:

   drm: sti: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp() 
(2016-09-20 11:32:04 +0200)

are available in the git repository at:

   https://github.com/vinceab/linux.git sti-drm-next-2016-09-20

for you to fetch changes up to b4bba92dfbe23ccc4f1f6c93db88c39c10aa075a:

   drm/sti: remove stih415-416 platform support (2016-09-20 15:03:33 +0200)


Benjamin Gaignard (1):
   drm: sti: fix coccicheck warnings

Fabien Dessenne (8):
   drm/sti: fix debug logs
   drm/sti: run hqvdp init sequence only once
   drm/sti: run gdp init sequence only once
   drm/sti: fix atomic_disable check
   drm/sti: use different notifier_block for each pipe
   drm/sti: use vtg array instead of vtg_main/aux
   drm/sti: in crtc_atomic_flush, enable only planes of this crtc
   drm/sti: use valid video mode

Ville Syrjälä (1):
   drm/sti: Fix sparse warnings

Vincent Abriou (3):
   drm/sti: dpms function missing for HDMI connector
   drm/sti: fix compositor debugfs creation
   drm/sti: remove stih415-416 platform support

  drivers/gpu/drm/sti/Kconfig|   6 +-
  drivers/gpu/drm/sti/Makefile   |   1 -
  drivers/gpu/drm/sti/sti_compositor.c   |  51 ++---
  drivers/gpu/drm/sti/sti_compositor.h   |  14 +-
  drivers/gpu/drm/sti/sti_crtc.c |  26 +--
  drivers/gpu/drm/sti/sti_cursor.c   |   8 +-
  drivers/gpu/drm/sti/sti_drv.c  |   2 +-
  drivers/gpu/drm/sti/sti_dvo.c  |   3 +-
  drivers/gpu/drm/sti/sti_gdp.c  |  29 ++-
  drivers/gpu/drm/sti/sti_hda.c  |  39 +---
  drivers/gpu/drm/sti/sti_hdmi.c |  31 +--
  drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 
-
  drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h |  14 --
  drivers/gpu/drm/sti/sti_hqvdp.c|  25 +--
  drivers/gpu/drm/sti/sti_mixer.c|  19 --
  drivers/gpu/drm/sti/sti_tvout.c|  41 +---
  drivers/gpu/drm/sti/sti_vid.c  |   4 +-
  drivers/gpu/drm/sti/sti_vtac.c |   2 +
  drivers/gpu/drm/sti/sti_vtg.c  |   3 +-
  19 files changed, 96 insertions(+), 558 deletions(-)
  delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c
  delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h

Kernel stability on baytrail machines

[Michal Feix]

Hi, I think there might be another clue on this one.

One of the comments is also mentioning an unfixed erratum of certain 
Baytrail processors, named as "EOI Transaction May Not be Sent if 
Software Enters Core C6 During an Interrupt Service Routine". This 
erratum can be found on several different processors, even on several 
non-baytrails, like Inte Xeon 3400 and similar.

I also came across a patch that was created for SUSE and that seems to 
be adressing this issue in pre 4.X kernels:

https://build.opensuse.org/package/view_file?file=22160-Intel-C6-EOI.patch=xen=home%3Acharlesa%3AopenSUSE11.3=7

---
Michal


Dne 18.7.2016 15:30, One Thousand Gnomes napsal:
> On Tue, 12 Jul 2016 16:41:58 -0300
> Ezequiel Garcia  wrote:
> 
>> Hi Alan,
>> 
>> (Adding interested people to this thread)
>> 
>> On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
>> > > > I do feel that the importance of the mentioned bug is currently
>> > > > underestimated. Can anyone here give a note, how much current linux
>> > > > kernel is supposed to be stable on general baytrail machines?
>> > >
>> > > If you did not get any replies... you might want to check MAINTAINERS 
>> > > file, and
>> > > put Intel x86 maintainers on Cc list.
>> > >
>> > > I'm sure someone cares :-).
>> >
>> > Yes we care, and there are people looking at the various reports.
>> >
>> 
>> Are there any updates on the status of this issue?
>> 
>> The current bugzilla report [1] marks this as a power management
>> issue. However, many reports indicate that it would only freeze
>> when running X, so it's not completely clear if it's related to
>> the gfx driver too.
> 
> There are two things we are currently tracking. One of them was merged
> which seems to have made my machine stable at least and fixes a problem
> related to the MMC. The second one we may need is a power related 
> changed
> to SPI to hold the CPU in C0/C1 whenever the ACPI _SEM is held.
> 
> Graphics shows these problems up because of the way the GPU causes 
> power
> state changes.
> 
> Alan

[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[Jani Nikula]

On Tue, 20 Sep 2016, Dan Carpenter  wrote:
> Don't be a dummy...  This is easy to review an it fixes a bug.
>
> I'm fine with you NAKing all these patches based on who they are from.
> I mostly just delete these without responding because the guy has
> history of introducing bugs and never listens to feedback.  But asking
> pointless rhetorical questions is not helpful.
>
> A lot of people are CC'd and you're wasting everyone's time by asking
> questions where you know the answer.

Fair enough, sorry for the noise.

To be honest, I did only look at the patches, not who they were from. We
have CI for drm/i915, but I don't think it's constructive to keep
changing drivers like this where the upstream isn't actively developed
and tested. But I digress. It's up to Patrik anyway.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center

[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

[Andrzej Hajda]

On 20.09.2016 14:34, Andrzej Hajda wrote:
> On 20.09.2016 13:23, Tobias Jakobi wrote:
>> Hello Andrzej,
>>
>> first of all, I've noticed an error myself. mixer_disable() calls
>> mixer_disable_plane(), so it should also be modified. I'll send a v2 later.
>>
>> Now to your points...
>>
>>
>> Andrzej Hajda wrote:
>>> On 19.09.2016 16:16, Tobias Jakobi wrote:
 Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
 in mixer_cfg_layer().
 Trigger this via atomic flush.

 Signed-off-by: Tobias Jakobi 
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c | 104 
 ++
  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
  2 files changed, 69 insertions(+), 37 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 1e78d57..d4efd9c 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -99,6 +99,7 @@ struct mixer_context {
struct drm_device   *drm_dev;
struct exynos_drm_crtc  *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
 +  unsigned long   state_cache;
>>> The name of the variable is cryptic.
>> Yes, I'll try to come up with something better. It would probably be
>> easier if struct mixer_context had a documentation for its fields.
>>
>> Anyway, any suggestions?
> (active|enabled)_(planes|windows), or sth similar?
>
>>
int pipe;
unsigned long   flags;
  
 @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
 *ctx, unsigned int height)
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
  }
  
 -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
 -  unsigned int priority, bool enable)
 +static void mixer_cfg_layer(struct mixer_context *ctx)
  {
struct mixer_resources *res = >mixer_res;
 -  u32 val = enable ? ~0 : 0;
 -
 -  switch (win) {
 -  case 0:
 -  mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
 -  mixer_reg_writemask(res, MXR_LAYER_CFG,
 -  MXR_LAYER_CFG_GRP0_VAL(priority),
 -  MXR_LAYER_CFG_GRP0_MASK);
 -  break;
 -  case 1:
 -  mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
 -  mixer_reg_writemask(res, MXR_LAYER_CFG,
 -  MXR_LAYER_CFG_GRP1_VAL(priority),
 -  MXR_LAYER_CFG_GRP1_MASK);
 +  unsigned int win;
  
 -  break;
 -  case VP_DEFAULT_WIN:
 -  if (test_bit(MXR_BIT_VP_ENABLED, >flags)) {
 -  vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
 -  mixer_reg_writemask(res, MXR_CFG, val,
 -  MXR_CFG_VP_ENABLE);
 -  mixer_reg_writemask(res, MXR_LAYER_CFG,
 -  MXR_LAYER_CFG_VP_VAL(priority),
 -  MXR_LAYER_CFG_VP_MASK);
 +  struct exynos_drm_plane_state *state;
 +  struct drm_framebuffer *fb;
 +  unsigned int priority;
 +  u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
 +  bool enable;
 +
 +  for (win = 0; win < MIXER_WIN_NR; ++win) {
 +  state = to_exynos_plane_state(ctx->planes[win].base.state);
 +  fb = state->fb;
 +
 +  priority = state->base.normalized_zpos + 1;
 +  enable = test_bit(win, >state_cache);
 +
 +  if (!enable)
 +  continue;
 +
 +  switch (win) {
 +  case 0:
 +  mxr_cfg |=  MXR_CFG_GRP0_ENABLE;
 +  mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority);
 +  break;
 +
 +  case 1:
 +  mxr_cfg |=  MXR_CFG_GRP1_ENABLE;
 +  mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority);
 +  break;
 +
 +  case VP_DEFAULT_WIN:
 +  vp_enable = VP_ENABLE_ON;
 +  mxr_cfg |=  MXR_CFG_VP_ENABLE;
 +  mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority);
 +  break;
 +  }
 +
 +  if (!fb)
 +  continue;
 +
 +  /*
 +   * TODO: Don't enable alpha blending for the bottom window.
 +   */
 +  switch (win) {
 +  case 0:
 +  case 1:
 +  mixer_cfg_gfx_blend(ctx, win, 
 is_alpha_format(fb->pixel_format));
 +  break;
 +
 +  case VP_DEFAULT_WIN:
 +  mixer_cfg_vp_blend(ctx);
 +  break;
}
 - 

[PATCH v2] drm/sti: remove stih415-416 platform support

[Benjamin Gaignard]

Acked-by: Benjamin Gaignard 

2016-09-20 11:25 GMT+02:00 Vincent Abriou :
> stih415 and stih416 platform are obsolete and no more supported.
> Only stih407 and stih410 platform are maintained.
>
> Signed-off-by: Vincent Abriou 
> ---
>  drivers/gpu/drm/sti/Kconfig|   6 +-
>  drivers/gpu/drm/sti/Makefile   |   1 -
>  drivers/gpu/drm/sti/sti_compositor.c   |  19 --
>  drivers/gpu/drm/sti/sti_hda.c  |  39 +---
>  drivers/gpu/drm/sti/sti_hdmi.c |  20 --
>  drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 
> -
>  drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h |  14 --
>  drivers/gpu/drm/sti/sti_mixer.c|  19 --
>  drivers/gpu/drm/sti/sti_tvout.c|  40 +---
>  9 files changed, 14 insertions(+), 480 deletions(-)
>  delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c
>  delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h
>
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index 494ab25..acd7286 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -1,6 +1,6 @@
>  config DRM_STI
> -   tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
> -   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
> +   tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
> +   depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
> select RESET_CONTROLLER
> select DRM_KMS_HELPER
> select DRM_GEM_CMA_HELPER
> @@ -9,4 +9,4 @@ config DRM_STI
> select FW_LOADER
> select SND_SOC_HDMI_CODEC if SND_SOC
> help
> - Choose this option to enable DRM on STM stiH41x chipset
> + Choose this option to enable DRM on STM stiH4xx chipset
> diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
> index b805762..d20f7c0 100644
> --- a/drivers/gpu/drm/sti/Makefile
> +++ b/drivers/gpu/drm/sti/Makefile
> @@ -9,7 +9,6 @@ sti-drm-y := \
> sti_crtc.o \
> sti_plane.o \
> sti_hdmi.o \
> -   sti_hdmi_tx3g0c55phy.o \
> sti_hdmi_tx3g4c28phy.o \
> sti_dvo.o \
> sti_awg_utils.o \
> diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
> b/drivers/gpu/drm/sti/sti_compositor.c
> index a6f391b..f62041f 100644
> --- a/drivers/gpu/drm/sti/sti_compositor.c
> +++ b/drivers/gpu/drm/sti/sti_compositor.c
> @@ -39,22 +39,6 @@ static const struct sti_compositor_data 
> stih407_compositor_data = {
> },
>  };
>
> -/*
> - * stiH416 compositor properties
> - * Note:
> - * on stih416 MIXER_AUX has a different base address from MIXER_MAIN
> - * Moreover, GDPx is different for Main and Aux Mixer. So this subdev map 
> does
> - * not fit for stiH416 if we want to enable the MIXER_AUX.
> - */
> -static const struct sti_compositor_data stih416_compositor_data = {
> -   .nb_subdev = 3,
> -   .subdev_desc = {
> -   {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100},
> -   {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200},
> -   {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00}
> -   },
> -};
> -
>  int sti_compositor_debugfs_init(struct sti_compositor *compo,
> struct drm_minor *minor)
>  {
> @@ -179,9 +163,6 @@ static const struct component_ops sti_compositor_ops = {
>
>  static const struct of_device_id compositor_of_match[] = {
> {
> -   .compatible = "st,stih416-compositor",
> -   .data = _compositor_data,
> -   }, {
> .compatible = "st,stih407-compositor",
> .data = _compositor_data,
> }, {
> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> index a225c4d..e7c243f 100644
> --- a/drivers/gpu/drm/sti/sti_hda.c
> +++ b/drivers/gpu/drm/sti/sti_hda.c
> @@ -62,14 +62,8 @@
>  #define SCALE_CTRL_CR_DFLT  0x00DB0249
>
>  /* Video DACs control */
> -#define VIDEO_DACS_CONTROL_MASK 0x0FFF
> -#define VIDEO_DACS_CONTROL_SYSCFG2535   0x085C /* for stih416 */
> -#define DAC_CFG_HD_OFF_SHIFT5
> -#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT)
> -#define VIDEO_DACS_CONTROL_SYSCFG5072   0x0120 /* for stih407 */
>  #define DAC_CFG_HD_HZUVW_OFF_MASK   BIT(1)
>
> -
>  /* Upsampler values for the alternative 2X Filter */
>  #define SAMPLER_COEF_NB 8
>  #define HDA_ANA_SRC_Y_CFG_ALT_2X0x0113
> @@ -300,28 +294,14 @@ static bool hda_get_mode_idx(struct drm_display_mode 
> mode, int *idx)
>   */
>  static void hda_enable_hd_dacs(struct sti_hda *hda, bool enable)
>  {
> -   u32 mask;
> -
> if (hda->video_dacs_ctrl) {
> u32 val;
>
> -   switch ((u32)hda->video_dacs_ctrl & VIDEO_DACS_CONTROL_MASK) {
> -   case VIDEO_DACS_CONTROL_SYSCFG2535:
> -   mask = DAC_CFG_HD_OFF_MASK;
> -   break;
> -   

[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

[Andrzej Hajda]

On 20.09.2016 13:23, Tobias Jakobi wrote:
> Hello Andrzej,
>
> first of all, I've noticed an error myself. mixer_disable() calls
> mixer_disable_plane(), so it should also be modified. I'll send a v2 later.
>
> Now to your points...
>
>
> Andrzej Hajda wrote:
>> On 19.09.2016 16:16, Tobias Jakobi wrote:
>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>> in mixer_cfg_layer().
>>> Trigger this via atomic flush.
>>>
>>> Signed-off-by: Tobias Jakobi 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 104 
>>> ++
>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>  2 files changed, 69 insertions(+), 37 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 1e78d57..d4efd9c 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -99,6 +99,7 @@ struct mixer_context {
>>> struct drm_device   *drm_dev;
>>> struct exynos_drm_crtc  *crtc;
>>> struct exynos_drm_plane planes[MIXER_WIN_NR];
>>> +   unsigned long   state_cache;
>> The name of the variable is cryptic.
> Yes, I'll try to come up with something better. It would probably be
> easier if struct mixer_context had a documentation for its fields.
>
> Anyway, any suggestions?

(active|enabled)_(planes|windows), or sth similar?

>
>
>>> int pipe;
>>> unsigned long   flags;
>>>  
>>> @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>>> *ctx, unsigned int height)
>>> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>  }
>>>  
>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
>>> -   unsigned int priority, bool enable)
>>> +static void mixer_cfg_layer(struct mixer_context *ctx)
>>>  {
>>> struct mixer_resources *res = >mixer_res;
>>> -   u32 val = enable ? ~0 : 0;
>>> -
>>> -   switch (win) {
>>> -   case 0:
>>> -   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
>>> -   mixer_reg_writemask(res, MXR_LAYER_CFG,
>>> -   MXR_LAYER_CFG_GRP0_VAL(priority),
>>> -   MXR_LAYER_CFG_GRP0_MASK);
>>> -   break;
>>> -   case 1:
>>> -   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
>>> -   mixer_reg_writemask(res, MXR_LAYER_CFG,
>>> -   MXR_LAYER_CFG_GRP1_VAL(priority),
>>> -   MXR_LAYER_CFG_GRP1_MASK);
>>> +   unsigned int win;
>>>  
>>> -   break;
>>> -   case VP_DEFAULT_WIN:
>>> -   if (test_bit(MXR_BIT_VP_ENABLED, >flags)) {
>>> -   vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
>>> -   mixer_reg_writemask(res, MXR_CFG, val,
>>> -   MXR_CFG_VP_ENABLE);
>>> -   mixer_reg_writemask(res, MXR_LAYER_CFG,
>>> -   MXR_LAYER_CFG_VP_VAL(priority),
>>> -   MXR_LAYER_CFG_VP_MASK);
>>> +   struct exynos_drm_plane_state *state;
>>> +   struct drm_framebuffer *fb;
>>> +   unsigned int priority;
>>> +   u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
>>> +   bool enable;
>>> +
>>> +   for (win = 0; win < MIXER_WIN_NR; ++win) {
>>> +   state = to_exynos_plane_state(ctx->planes[win].base.state);
>>> +   fb = state->fb;
>>> +
>>> +   priority = state->base.normalized_zpos + 1;
>>> +   enable = test_bit(win, >state_cache);
>>> +
>>> +   if (!enable)
>>> +   continue;
>>> +
>>> +   switch (win) {
>>> +   case 0:
>>> +   mxr_cfg |=  MXR_CFG_GRP0_ENABLE;
>>> +   mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority);
>>> +   break;
>>> +
>>> +   case 1:
>>> +   mxr_cfg |=  MXR_CFG_GRP1_ENABLE;
>>> +   mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority);
>>> +   break;
>>> +
>>> +   case VP_DEFAULT_WIN:
>>> +   vp_enable = VP_ENABLE_ON;
>>> +   mxr_cfg |=  MXR_CFG_VP_ENABLE;
>>> +   mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority);
>>> +   break;
>>> +   }
>>> +
>>> +   if (!fb)
>>> +   continue;
>>> +
>>> +   /*
>>> +* TODO: Don't enable alpha blending for the bottom window.
>>> +*/
>>> +   switch (win) {
>>> +   case 0:
>>> +   case 1:
>>> +   mixer_cfg_gfx_blend(ctx, win, 
>>> is_alpha_format(fb->pixel_format));
>>> +   break;
>>> +
>>> +   case VP_DEFAULT_WIN:
>>> +   mixer_cfg_vp_blend(ctx);
>>> +   break;
>>> }
>>> -   break;
>>> }
>>> +
>>> +   if (test_bit(MXR_BIT_VP_ENABLED, >flags))
>>> +   

GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[Dan Carpenter]

On Tue, Sep 20, 2016 at 01:03:06PM +0200, SF Markus Elfring wrote:
> Are you looking for any special information to improve
> a corresponding discussion?

If you restricted yourself to only sending bug fixes and not sending
any more cleanups that would be good.

Please stop sending clean up patches.

regards,
dan carpenter

[STLinux Kernel] [PATCH v2] drm/sti: remove stih415-416 platform support

[Peter Griffin]

Hi Vincent,

On Tue, 20 Sep 2016, Vincent Abriou wrote:

> stih415 and stih416 platform are obsolete and no more supported.
> Only stih407 and stih410 platform are maintained.
> 
> Signed-off-by: Vincent Abriou 

Subject should have a v2, but apart from that: -

Acked-by: Peter Griffin 

Peter.

[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[Dan Carpenter]

On Tue, Sep 20, 2016 at 01:07:35PM +0300, Jani Nikula wrote:
> On Tue, 20 Sep 2016, SF Markus Elfring  
> wrote:
> > From: Markus Elfring 
> > Date: Tue, 20 Sep 2016 10:36:19 +0200
> >
> > A single error message should be sufficient to inform about
> > the detection of an unknown GCT revision at the end.
> > Thus return after the logging call in this case directly.
> 
> Did you test this?
> 

Don't be a dummy...  This is easy to review an it fixes a bug.

I'm fine with you NAKing all these patches based on who they are from.
I mostly just delete these without responding because the guy has
history of introducing bugs and never listens to feedback.  But asking
pointless rhetorical questions is not helpful.

A lot of people are CC'd and you're wasting everyone's time by asking
questions where you know the answer.

regards,
dan carpenter

[PATCH 04/14] drm/arm: Fix sparse warnings

[Liviu Dudau]

On Tue, Sep 20, 2016 at 09:06:24AM +0100, Liviu Dudau wrote:
> On Mon, Sep 19, 2016 at 04:33:45PM +0300, ville.syrjala at linux.intel.com 
> wrote:
> > From: Ville Syrjälä 
> > 
> > drm/arm/malidp_planes.c:49:24: warning: symbol 
> > 'malidp_duplicate_plane_state' was not declared. Should it be static?
> > drm/arm/malidp_planes.c:66:6: warning: symbol 'malidp_destroy_plane_state' 
> > was not declared. Should it be static?
> > 
> > Cc: Liviu Dudau 
> 

BTW, I have already acked this patch when Baoyou Xie submitted it!

https://lists.freedesktop.org/archives/dri-devel/2016-September/117624.html

Maybe you should acknowledge his contribution if that was the case?

Best regards,
Liviu

> Acked-by: Liviu Dudau 
> 
> Thanks for cleaning it up!
> 
> Liviu
> 
> > Cc: Brian Starkey 
> > Cc: Mali DP Maintainers 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/arm/malidp_planes.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> > b/drivers/gpu/drm/arm/malidp_planes.c
> > index 82c193e5e0d6..cc9b8e02904d 100644
> > --- a/drivers/gpu/drm/arm/malidp_planes.c
> > +++ b/drivers/gpu/drm/arm/malidp_planes.c
> > @@ -46,7 +46,7 @@ static void malidp_de_plane_destroy(struct drm_plane 
> > *plane)
> > devm_kfree(plane->dev->dev, mp);
> >  }
> >  
> > -struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane 
> > *plane)
> > +static struct drm_plane_state *malidp_duplicate_plane_state(struct 
> > drm_plane *plane)
> >  {
> > struct malidp_plane_state *state, *m_state;
> >  
> > @@ -63,8 +63,8 @@ struct drm_plane_state 
> > *malidp_duplicate_plane_state(struct drm_plane *plane)
> > return >base;
> >  }
> >  
> > -void malidp_destroy_plane_state(struct drm_plane *plane,
> > -   struct drm_plane_state *state)
> > +static void malidp_destroy_plane_state(struct drm_plane *plane,
> > +  struct drm_plane_state *state)
> >  {
> > struct malidp_plane_state *m_state = to_malidp_plane_state(state);
> >  
> > -- 
> > 2.7.4
> > 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[SF Markus Elfring]

> If you restricted yourself to only sending bug fixes and not sending
> any more cleanups that would be good.

Thanks for another bit of constructive feedback.


> Please stop sending clean up patches.

This will not happen for a while.

I am in the process of informing various developers about some software
update opportunities. The proposed changes will belong to a mixture of error
categories as you observe them so far usually.

The involved static source code analysis will point more details out
for further considerations, won't it?

Regards,
Markus

[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

[Tobias Jakobi]

Hello Andrzej,

first of all, I've noticed an error myself. mixer_disable() calls
mixer_disable_plane(), so it should also be modified. I'll send a v2 later.

Now to your points...


Andrzej Hajda wrote:
> On 19.09.2016 16:16, Tobias Jakobi wrote:
>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>> in mixer_cfg_layer().
>> Trigger this via atomic flush.
>>
>> Signed-off-by: Tobias Jakobi 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 104 
>> ++
>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>  2 files changed, 69 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 1e78d57..d4efd9c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -99,6 +99,7 @@ struct mixer_context {
>>  struct drm_device   *drm_dev;
>>  struct exynos_drm_crtc  *crtc;
>>  struct exynos_drm_plane planes[MIXER_WIN_NR];
>> +unsigned long   state_cache;
> 
> The name of the variable is cryptic.
Yes, I'll try to come up with something better. It would probably be
easier if struct mixer_context had a documentation for its fields.

Anyway, any suggestions?



> 
>>  int pipe;
>>  unsigned long   flags;
>>  
>> @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>> *ctx, unsigned int height)
>>  mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>  }
>>  
>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
>> -unsigned int priority, bool enable)
>> +static void mixer_cfg_layer(struct mixer_context *ctx)
>>  {
>>  struct mixer_resources *res = >mixer_res;
>> -u32 val = enable ? ~0 : 0;
>> -
>> -switch (win) {
>> -case 0:
>> -mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
>> -mixer_reg_writemask(res, MXR_LAYER_CFG,
>> -MXR_LAYER_CFG_GRP0_VAL(priority),
>> -MXR_LAYER_CFG_GRP0_MASK);
>> -break;
>> -case 1:
>> -mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
>> -mixer_reg_writemask(res, MXR_LAYER_CFG,
>> -MXR_LAYER_CFG_GRP1_VAL(priority),
>> -MXR_LAYER_CFG_GRP1_MASK);
>> +unsigned int win;
>>  
>> -break;
>> -case VP_DEFAULT_WIN:
>> -if (test_bit(MXR_BIT_VP_ENABLED, >flags)) {
>> -vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
>> -mixer_reg_writemask(res, MXR_CFG, val,
>> -MXR_CFG_VP_ENABLE);
>> -mixer_reg_writemask(res, MXR_LAYER_CFG,
>> -MXR_LAYER_CFG_VP_VAL(priority),
>> -MXR_LAYER_CFG_VP_MASK);
>> +struct exynos_drm_plane_state *state;
>> +struct drm_framebuffer *fb;
>> +unsigned int priority;
>> +u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
>> +bool enable;
>> +
>> +for (win = 0; win < MIXER_WIN_NR; ++win) {
>> +state = to_exynos_plane_state(ctx->planes[win].base.state);
>> +fb = state->fb;
>> +
>> +priority = state->base.normalized_zpos + 1;
>> +enable = test_bit(win, >state_cache);
>> +
>> +if (!enable)
>> +continue;
>> +
>> +switch (win) {
>> +case 0:
>> +mxr_cfg |=  MXR_CFG_GRP0_ENABLE;
>> +mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority);
>> +break;
>> +
>> +case 1:
>> +mxr_cfg |=  MXR_CFG_GRP1_ENABLE;
>> +mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority);
>> +break;
>> +
>> +case VP_DEFAULT_WIN:
>> +vp_enable = VP_ENABLE_ON;
>> +mxr_cfg |=  MXR_CFG_VP_ENABLE;
>> +mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority);
>> +break;
>> +}
>> +
>> +if (!fb)
>> +continue;
>> +
>> +/*
>> + * TODO: Don't enable alpha blending for the bottom window.
>> + */
>> +switch (win) {
>> +case 0:
>> +case 1:
>> +mixer_cfg_gfx_blend(ctx, win, 
>> is_alpha_format(fb->pixel_format));
>> +break;
>> +
>> +case VP_DEFAULT_WIN:
>> +mixer_cfg_vp_blend(ctx);
>> +break;
>>  }
>> -break;
>>  }
>> +
>> +if (test_bit(MXR_BIT_VP_ENABLED, >flags))
>> +vp_reg_writemask(res, VP_ENABLE, vp_enable, VP_ENABLE_ON);
>> +
>> +mixer_reg_writemask(res, MXR_CFG, mxr_cfg, MXR_CFG_ENABLE_MASK);
>> +

[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

[Gustavo Padovan]

2016-09-18 Baoyou Xie :

> We get 1 warning when building kernel with W=1:
> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 
> 'sync_timeline_create' [-Wmissing-prototypes]
> 
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/dma-buf/sw_sync.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks for finding this.

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 6/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()

[Jani Nikula]

On Tue, 20 Sep 2016, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Tue, 20 Sep 2016 10:40:22 +0200
>
> * Adjust a jump target.

Please don't.

BR,
Jani.

>
> * Delete the explicit initialisation for the local variable "ret"
>   which became unnecessary with this refactoring.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/gma500/mid_bios.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
> b/drivers/gpu/drm/gma500/mid_bios.c
> index e5cece0..602d16f 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -284,7 +284,7 @@ static void mid_get_vbt_data(struct drm_psb_private 
> *dev_priv)
>   u8 __iomem *vbt_virtual;
>   struct mid_vbt_header vbt_header;
>   struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI_DEVFN(2, 0));
> - int ret = -1;
> + int ret;
>  
>   /* Get the address of the platform config vbt */
>   pci_read_config_dword(pci_gfx_root, 0xFC, );
> @@ -293,18 +293,18 @@ static void mid_get_vbt_data(struct drm_psb_private 
> *dev_priv)
>   dev_dbg(dev->dev, "drm platform config address is %x\n", addr);
>  
>   if (!addr)
> - goto out;
> + goto report_failure;
>  
>   /* get the virtual address of the vbt */
>   vbt_virtual = ioremap(addr, sizeof(vbt_header));
>   if (!vbt_virtual)
> - goto out;
> + goto report_failure;
>  
>   memcpy_fromio(_header, vbt_virtual, sizeof(vbt_header));
>   iounmap(vbt_virtual);
>  
>   if (memcmp(_header.signature, "$GCT", 4))
> - goto out;
> + goto report_failure;
>  
>   dev_dbg(dev->dev, "GCT revision is %02x\n", vbt_header.revision);
>  
> @@ -322,9 +322,8 @@ static void mid_get_vbt_data(struct drm_psb_private 
> *dev_priv)
>   dev_err(dev->dev, "Unknown revision of GCT!\n");
>   return;
>   }
> -
> -out:
>   if (ret)
> + report_failure:
>   dev_err(dev->dev, "Unable to read GCT!");
>   else
>   dev_priv->has_gct = true;

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[Jani Nikula]

On Tue, 20 Sep 2016, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Tue, 20 Sep 2016 10:36:19 +0200
>
> A single error message should be sufficient to inform about
> the detection of an unknown GCT revision at the end.
> Thus return after the logging call in this case directly.

Did you test this?

BR,
Jani.

>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/gma500/mid_bios.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
> b/drivers/gpu/drm/gma500/mid_bios.c
> index 9004d30..e5cece0 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -320,6 +320,7 @@ static void mid_get_vbt_data(struct drm_psb_private 
> *dev_priv)
>   break;
>   default:
>   dev_err(dev->dev, "Unknown revision of GCT!\n");
> + return;
>   }
>  
>  out:

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/6] GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()

[Jani Nikula]

On Tue, 20 Sep 2016, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Tue, 20 Sep 2016 08:54:07 +0200
>
> A multiplication for the size determination of a memory allocation
> indicated that an array data structure should be processed.
> Thus use the corresponding function "kmalloc_array".
>
> This issue was detected by using the Coccinelle software.

Did you test this running on the hardware?

BR,
Jani.

>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/gma500/mid_bios.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
> b/drivers/gpu/drm/gma500/mid_bios.c
> index d75ecb3..a833568 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -235,7 +235,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
> *dev_priv, u32 addr)
>   if (read_vbt_r10(addr, ))
>   return -1;
>  
> - gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL);
> + gct = kmalloc_array(vbt.panel_count, sizeof(*gct), GFP_KERNEL);
>   if (!gct)
>   return -1;

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 2/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data_r10()

[Jani Nikula]

On Tue, 20 Sep 2016, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Tue, 20 Sep 2016 09:09:10 +0200
>
> Adjust a jump label according to the current Linux coding style convention.

Generally, please don't send patches to fix checkpatch issues in
existing code. Moreover, this particular "convention" is just something
someone sneaked into CodingStyle, it's subjective, and it's probably
going to be removed soon.

NAK.

BR,
Jani.

>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/gma500/mid_bios.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
> b/drivers/gpu/drm/gma500/mid_bios.c
> index a833568..cf4e605 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -242,7 +242,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
> *dev_priv, u32 addr)
>   gct_virtual = ioremap(addr + sizeof(vbt),
>   sizeof(*gct) * vbt.panel_count);
>   if (!gct_virtual)
> - goto out;
> + goto free_gct;
>   memcpy_fromio(gct, gct_virtual, sizeof(*gct));
>   iounmap(gct_virtual);
>  
> @@ -270,7 +270,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
> *dev_priv, u32 addr)
>   dp_ti->vsync_pulse_width_lo = ti->vsync_pulse_width_lo;
>  
>   ret = 0;
> -out:
> + free_gct:
>   kfree(gct);
>   return ret;
>  }

-- 
Jani Nikula, Intel Open Source Technology Center

GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[SF Markus Elfring]

>>> A single error message should be sufficient to inform about
>>> the detection of an unknown GCT revision at the end.
>>> Thus return after the logging call in this case directly.
>>
>> Did you test this?
>>
> 
> Don't be a dummy...  This is easy to review an it fixes a bug.

Thanks for this kind of constructive feedback.


> I'm fine with you NAKing all these patches based on who they are from.

Would you like to clarify such an information a bit more?


> I mostly just delete these without responding because the guy has
> history of introducing bugs and never listens to feedback.

I admit that I'll stumble on programming mistakes again occasionally
as another ordinary free software developer who is struggling various open 
issues.

I am listening to various feedback. My responses might not be pleasing enough
for you. Are you looking for any special information to improve
a corresponding discussion?

Regards,
Markus

[PATCH RESEND] drm/ast: free correct pointer in astfb_create() error paths

[Andrew Donnellan]

On 20/09/16 11:56, Andrew Donnellan wrote:
> In the err_free_vram and err_release_fbi error paths in astfb_create(), we
> attempt to free afbdev->sysram. The only jumps to these error paths occur
> before we assign afbdev->sysram = sysram. Free sysram instead.
>
> Signed-off-by: Andrew Donnellan 
>
> ---
>
> Found by Coverity Scan. Compile tested only.
>
> Resending as it looks like this didn't hit dri-devel.

It did show up after all :)

-- 
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnellan at au1.ibm.com  IBM Australia Limited

[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

[Jani Nikula]

On Tue, 20 Sep 2016, Peter Griffin  wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin  
>> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects 
> USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or 
> not?


Documentation/kbuild/kconfig-language.txt:

  Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[SF Markus Elfring]

>> A single error message should be sufficient to inform about
>> the detection of an unknown GCT revision at the end.
>> Thus return after the logging call in this case directly.
> 
> Did you test this?

What is your software development opinion for this update suggestion?

Regards,
Markus

GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()

[SF Markus Elfring]

>> A multiplication for the size determination of a memory allocation
>> indicated that an array data structure should be processed.
>> Thus use the corresponding function "kmalloc_array".
>>
>> This issue was detected by using the Coccinelle software.
> 
> Did you test this running on the hardware?

No. - My "test computer" does not provide the corresponding hardware for the
affected driver source files.

Regards,
Markus

[Bug 93456] Intel D845GVAD2 ubuntu 15.10 GPU Hangs - stuck on render ring

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

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

yann  changed:

   What|Removed |Added

Product|DRI |Mesa
Version|XOrg git|10.6
 QA Contact|intel-gfx-bugs at lists.freede |dri-devel at 
lists.freedesktop
   |sktop.org   |.org
   Assignee|intel-gfx-bugs at lists.freede |dri-devel at 
lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |Drivers/DRI/i830

--- Comment #1 from yann  ---
There were improvements pushed in kernel and Mesa that will benefit to your
system, so please re-test with latest kernel & Mesa to see if this issue is
still occurring (including new installer in
https://01.org/linuxgraphics/downloads)

Kernel: 4.2.0-16-generic
Platform: 82845G/GL[Brookdale-G]/GE - (pci id: 0x2562)
Mesa: 10.6.0 [Please confirm your mesa version]

In the meantime, assigning to Mesa product (please let me know if I am mistaken
with this GPU Hang).

>From this error dump, hung is happening in render ring batch with active head
at 0x0154, with 0x4190 (2D UNKNOWN) as IPEHR.

Batch extract (around 0x0154):

0x0128:  0x7d030081: 3DSTATE_LOAD_STATE_IMMEDIATE_2
0x012c:  0x82000180:TB0C
0x0130:  0x02000180:TB0A
0x0134:  0x7d030804: 3DSTATE_LOAD_STATE_IMMEDIATE_2
0x0138:  0x01481000:TM0S0: offset=0x01481000,
0x013c:  0x02205cc0:TM0S1: height=17, width=23,
0x0140:  0x7c08c088:TM0S2: pitch=3972,
0x0144:  0x7f1c000b:TM0S3
0x0148:  0x41c0:TM0S4: dflt color
0x014c:  0x4190: 2D UNKNOWN
0x0150:  0x4455c000: XY_SETUP_MONO_PATTERN_SL_BLT (rgb enabled, alpha
disabled, src tile 1, dst tile 0)
Bad count in XY_SETUP_MONO_PATTERN_SL_BLT
0x0154:  0x3f80:format , pitch 0, rop 0x80, clipping
disabled,
0x0158:  0x:cliprect (0,0)
0x015c:  0x4190:cliprect (0,16784)
0x0160:  0x444fc000:setup dst offset 0x444fc000
0x0164:  0x3f80:setup background color
0x0168:  0x:setup foreground color
0x016c:  0x:mono pattern dw0
0x0170:  0x444fc000:mono pattern dw1
0x0158:  0x: MI_NOOP

-- 
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/20160920/c820904e/attachment-0001.html>

[PATCH] drm/omap: fix return value check in dsi_bind()

[Peter Ujfalusi]

On 09/17/16 18:53, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Fix the retrn value check which testing the wrong variable
> in dsi_bind().

Reviewed-by: Peter Ujfalusi 

> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index e1be5e7..a567ebd 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5342,7 +5342,7 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>  
>   dsi->phy_base = devm_ioremap(>dev, res->start,
>   resource_size(res));
> - if (!dsi->proto_base) {
> + if (!dsi->phy_base) {
>   DSSERR("can't ioremap DSI PHY\n");
>   return -ENOMEM;
>   }
> @@ -5362,7 +5362,7 @@ static int dsi_bind(struct device *dev, struct device 
> *master, void *data)
>  
>   dsi->pll_base = devm_ioremap(>dev, res->start,
>   resource_size(res));
> - if (!dsi->proto_base) {
> + if (!dsi->pll_base) {
>   DSSERR("can't ioremap DSI PLL\n");
>   return -ENOMEM;
>   }
> 
> 
> 


-- 
Péter

Kernel error causing display issues.

[Jani Nikula]

On Tue, 20 Sep 2016, Edward Bartolo  wrote:
> I am experiencing display issues on HP Probook 4540s ( i5 based
> laptop). Reading /var/log/kern.log I found the cause is probably
> rooted in:
>
> [drm] Wrong MCH_SSKPD value: 0x16040307

Maybe, maybe not.

Please file a bug at [1], attaching the dmesg with drm.debug=14 module
parameter set.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


-- 
Jani Nikula, Intel Open Source Technology Center

[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

[Andrzej Hajda]

On 19.09.2016 16:16, Tobias Jakobi wrote:
> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
> in mixer_cfg_layer().
> Trigger this via atomic flush.
>
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 104 
> ++
>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>  2 files changed, 69 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 1e78d57..d4efd9c 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -99,6 +99,7 @@ struct mixer_context {
>   struct drm_device   *drm_dev;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
> + unsigned long   state_cache;

The name of the variable is cryptic.

>   int pipe;
>   unsigned long   flags;
>  
> @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
> *ctx, unsigned int height)
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>  }
>  
> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
> - unsigned int priority, bool enable)
> +static void mixer_cfg_layer(struct mixer_context *ctx)
>  {
>   struct mixer_resources *res = >mixer_res;
> - u32 val = enable ? ~0 : 0;
> -
> - switch (win) {
> - case 0:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP0_VAL(priority),
> - MXR_LAYER_CFG_GRP0_MASK);
> - break;
> - case 1:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP1_VAL(priority),
> - MXR_LAYER_CFG_GRP1_MASK);
> + unsigned int win;
>  
> - break;
> - case VP_DEFAULT_WIN:
> - if (test_bit(MXR_BIT_VP_ENABLED, >flags)) {
> - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
> - mixer_reg_writemask(res, MXR_CFG, val,
> - MXR_CFG_VP_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_VP_VAL(priority),
> - MXR_LAYER_CFG_VP_MASK);
> + struct exynos_drm_plane_state *state;
> + struct drm_framebuffer *fb;
> + unsigned int priority;
> + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
> + bool enable;
> +
> + for (win = 0; win < MIXER_WIN_NR; ++win) {
> + state = to_exynos_plane_state(ctx->planes[win].base.state);
> + fb = state->fb;
> +
> + priority = state->base.normalized_zpos + 1;
> + enable = test_bit(win, >state_cache);
> +
> + if (!enable)
> + continue;
> +
> + switch (win) {
> + case 0:
> + mxr_cfg |=  MXR_CFG_GRP0_ENABLE;
> + mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority);
> + break;
> +
> + case 1:
> + mxr_cfg |=  MXR_CFG_GRP1_ENABLE;
> + mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority);
> + break;
> +
> + case VP_DEFAULT_WIN:
> + vp_enable = VP_ENABLE_ON;
> + mxr_cfg |=  MXR_CFG_VP_ENABLE;
> + mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority);
> + break;
> + }
> +
> + if (!fb)
> + continue;
> +
> + /*
> +  * TODO: Don't enable alpha blending for the bottom window.
> +  */
> + switch (win) {
> + case 0:
> + case 1:
> + mixer_cfg_gfx_blend(ctx, win, 
> is_alpha_format(fb->pixel_format));
> + break;
> +
> + case VP_DEFAULT_WIN:
> + mixer_cfg_vp_blend(ctx);
> + break;
>   }
> - break;
>   }
> +
> + if (test_bit(MXR_BIT_VP_ENABLED, >flags))
> + vp_reg_writemask(res, VP_ENABLE, vp_enable, VP_ENABLE_ON);
> +
> + mixer_reg_writemask(res, MXR_CFG, mxr_cfg, MXR_CFG_ENABLE_MASK);
> + mixer_reg_writemask(res, MXR_LAYER_CFG, mxr_layer_cfg, 
> MXR_LAYER_CFG_MASK);

What about enabled planes which are not updated?
Corresponding bit in ctx->state_cache will be 0.
It looks like this routine will disable them in hardware, am I right?

Regards
Andrzej

>  }
>  
>  static void mixer_run(struct mixer_context *ctx)
> @@ -478,7 +510,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   struct 

[PATCH 4/6] drm/radeon: Provide page_flip_target hook

[Michel Dänzer]

On 17/09/16 09:41 PM, Mario Kleiner wrote:
> Hi Michel,
> 
> all your patches, both the already merged kernel bits in radeon/amdgpu
> and also all the userspace bits in libdrm/ati-ddx/amdgpu-ddx are all
> 
> Reviewed-and-tested-by: Mario Kleiner 
> 
> I successfully tested with old/current userspace and the new userspace
> patches from your own libdrm/ati-ddx/amdgpu-ddx repos, under radeon-kms
> with HD-5770 and amdgpu-kms with R9 380, under DRI2 and DRI3/Present
> with the new userspace and at least DRI3/Present with the old/current
> userspace (can't quite remember if i also tested with DRI2 on
> old/current userspace, but probably). Hardware measured timing tests all
> work fine.
> 
> So all is good, except for pre-DCE4 without pflip irqs, but for that see
> the patchset i just sent out, which should make those old asics work
> well as well.

Thanks for the testing and patches!


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

[PATCH 1/2] drm/radeon: Slightly more robust flip completion handling for < DCE-4

[Michel Dänzer]

On 17/09/16 09:25 PM, Mario Kleiner wrote:
> Pre DCE4 hardware doesn't have (reliable) pageflip completion
> irqs, therefore we have to use the old polling method for flip
> completion handling in vblank irq.
> 
> As vblank irqs fire a bit before start of vblank (when the
> linebuffer fifo read position reaches end of scanout), we
> have some fudge for flip completion handling in the last
> lines of active scanout. Old code assumed the threshold to
> be 99% of active scanout height, a ballpark estimate which
> worked ok. Since we know since a while how to calculate the
> actual threshold from linebuffer size, lets make use of it
> to get a more accurate threshold.
> 
> This completion path is still prone to some races in corner
> cases, especially on pre-AVIVO hardware, so document them
> a bit better in the code comments.
> 
> Signed-off-by: Mario Kleiner 

[...]

> +  * Note that this method of completion handling is still not 100% race
> +  * free, as we could execute before the radeon_flip_work_func managed
> +  * to run and set the RADEON_FLIP_SUBMITTED status, thereby we no-op,
> +  * but the flip still gets programmed into hw and completed during
> +  * vblank, leading to a delayed emission of the flip completion event.
> +  * This applies at least to pre-AVIVO hardware, where flips are always
> +  * completing inside vblank, not only at leading edge of vblank.

Does this part of the comment still apply with patch 2?

Anyway,

Acked-by: Michel Dänzer 


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

[PATCH RESEND] drm/ast: free correct pointer in astfb_create() error paths

[Andrew Donnellan]

In the err_free_vram and err_release_fbi error paths in astfb_create(), we
attempt to free afbdev->sysram. The only jumps to these error paths occur
before we assign afbdev->sysram = sysram. Free sysram instead.

Signed-off-by: Andrew Donnellan 

---

Found by Coverity Scan. Compile tested only.

Resending as it looks like this didn't hit dri-devel.
---
 drivers/gpu/drm/ast/ast_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index c017a93..0fef8ea 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -254,7 +254,7 @@ static int astfb_create(struct drm_fb_helper *helper,
 err_release_fbi:
drm_fb_helper_release_fbi(helper);
 err_free_vram:
-   vfree(afbdev->sysram);
+   vfree(sysram);
return ret;
 }

-- 
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnellan at au1.ibm.com  IBM Australia Limited

[PATCH 2/2] drm/radeon: Prevent races on pre DCE4 between flip submission and completion.

[Michel Dänzer]

On 17/09/16 09:25 PM, Mario Kleiner wrote:
> Pre DCE4 hw doesn't have reliable pageflip completion
> interrupts, so instead polling for flip completion is
> used from within the vblank irq handler to complete
> page flips.
> 
> This causes a race if pageflip ioctl is called close to
> vblank:
> 
> 1. pageflip ioctl queues execution of radeon_flip_work_func.
> 
> 2. vblank irq fires, radeon_crtc_handle_vblank checks for
>flip_status == FLIP_SUBMITTED finds none, no-ops.
> 
> 3. radeon_flip_work_func runs inside vblank, decides to
>set flip_status == FLIP_SUBMITTED and programs the
>flip into hw.
> 
> 4. hw executes flip immediately (because in vblank), but
>as 2 already happened, the flip completion routine only
>emits the flip completion event one refresh later ->
>wrong vblank count/timestamp for completion and no
>performance gain, as instead of delaying the flip until
>next vblank, we now delay the next flip by 1 refresh
>while waiting for the delayed flip completion event.
> 
> Given we often don't gain anything due to this race, but
> lose precision, prevent the programmed flip from executing
> in vblank on pre DCE4 asics to avoid this race.
> 
> On pre-AVIVO hw we can't program the hw for edge-triggered
> flips, they always execute anywhere in vblank. Therefore delay
> the actual flip programming until after vblank on pre-AVIVO.
> 
> Signed-off-by: Mario Kleiner 

Reviewed-by: Michel Dänzer 


P.S. Please send radeon (and amdgpu) driver patches to the amd-gfx
mailing list (as well).

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

[PATCH][V2] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets

[Alex Deucher]

On Tue, Sep 20, 2016 at 11:49 AM, Colin King  
wrote:
> From: Colin Ian King 
>
> The check for an out of bound index into array interrupt_status_offsets
> is off-by-one. Fix this and also don't compared to a hard coded array
> size but use adev->mode_info.num_hpd instead.
>
> Signed-off-by: Colin Ian King 

Applied!  thanks,

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index d3512f3..4ce4c1a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> @@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev,
> uint32_t disp_int, mask, int_control, tmp;
> unsigned hpd;
>
> -   if (entry->src_data > 6) {
> +   if (entry->src_data >= adev->mode_info.num_hpd) {
> DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, 
> entry->src_data);
> return 0;
> }
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets

[Alex Deucher]

On Tue, Sep 20, 2016 at 11:16 AM, Colin King  
wrote:
> From: Colin Ian King 
>
> The check for an out of bound index into array interrupt_status_offsets
> is off-by-one. Fix this and also don't compared to a hard coded array
> size but use ARRAY_SIZE instead.
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index d3512f3..4ce4c1a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> @@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev,
> uint32_t disp_int, mask, int_control, tmp;
> unsigned hpd;
>
> -   if (entry->src_data > 6) {
> +   if (entry->src_data >= ARRAY_SIZE(interrupt_status_offsets)) {

This should actually be adev->mode_info.num_hpd as some asic variants
may not have 6 hpd lines.  Thanks for catching this.

Alex

> DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, 
> entry->src_data);
> return 0;
> }
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/sti: remove stih415-416 platform support

[Vincent Abriou]

stih415 and stih416 platform are obsolete and no more supported.
Only stih407 and stih410 platform are maintained.

Signed-off-by: Vincent Abriou 
---
 drivers/gpu/drm/sti/Kconfig|   6 +-
 drivers/gpu/drm/sti/Makefile   |   1 -
 drivers/gpu/drm/sti/sti_compositor.c   |  19 --
 drivers/gpu/drm/sti/sti_hda.c  |  39 +---
 drivers/gpu/drm/sti/sti_hdmi.c |  20 --
 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 -
 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h |  14 --
 drivers/gpu/drm/sti/sti_mixer.c|  19 --
 drivers/gpu/drm/sti/sti_tvout.c|  40 +---
 9 files changed, 14 insertions(+), 480 deletions(-)
 delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c
 delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index 494ab25..acd7286 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,6 @@
 config DRM_STI
-   tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
-   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
+   tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
+   depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
select RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
@@ -9,4 +9,4 @@ config DRM_STI
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
help
- Choose this option to enable DRM on STM stiH41x chipset
+ Choose this option to enable DRM on STM stiH4xx chipset
diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index b805762..d20f7c0 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -9,7 +9,6 @@ sti-drm-y := \
sti_crtc.o \
sti_plane.o \
sti_hdmi.o \
-   sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
sti_dvo.o \
sti_awg_utils.o \
diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index a6f391b..f62041f 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -39,22 +39,6 @@ static const struct sti_compositor_data 
stih407_compositor_data = {
},
 };

-/*
- * stiH416 compositor properties
- * Note:
- * on stih416 MIXER_AUX has a different base address from MIXER_MAIN
- * Moreover, GDPx is different for Main and Aux Mixer. So this subdev map does
- * not fit for stiH416 if we want to enable the MIXER_AUX.
- */
-static const struct sti_compositor_data stih416_compositor_data = {
-   .nb_subdev = 3,
-   .subdev_desc = {
-   {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100},
-   {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200},
-   {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00}
-   },
-};
-
 int sti_compositor_debugfs_init(struct sti_compositor *compo,
struct drm_minor *minor)
 {
@@ -179,9 +163,6 @@ static const struct component_ops sti_compositor_ops = {

 static const struct of_device_id compositor_of_match[] = {
{
-   .compatible = "st,stih416-compositor",
-   .data = _compositor_data,
-   }, {
.compatible = "st,stih407-compositor",
.data = _compositor_data,
}, {
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index a225c4d..e7c243f 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -62,14 +62,8 @@
 #define SCALE_CTRL_CR_DFLT  0x00DB0249

 /* Video DACs control */
-#define VIDEO_DACS_CONTROL_MASK 0x0FFF
-#define VIDEO_DACS_CONTROL_SYSCFG2535   0x085C /* for stih416 */
-#define DAC_CFG_HD_OFF_SHIFT5
-#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT)
-#define VIDEO_DACS_CONTROL_SYSCFG5072   0x0120 /* for stih407 */
 #define DAC_CFG_HD_HZUVW_OFF_MASK   BIT(1)

-
 /* Upsampler values for the alternative 2X Filter */
 #define SAMPLER_COEF_NB 8
 #define HDA_ANA_SRC_Y_CFG_ALT_2X0x0113
@@ -300,28 +294,14 @@ static bool hda_get_mode_idx(struct drm_display_mode 
mode, int *idx)
  */
 static void hda_enable_hd_dacs(struct sti_hda *hda, bool enable)
 {
-   u32 mask;
-
if (hda->video_dacs_ctrl) {
u32 val;

-   switch ((u32)hda->video_dacs_ctrl & VIDEO_DACS_CONTROL_MASK) {
-   case VIDEO_DACS_CONTROL_SYSCFG2535:
-   mask = DAC_CFG_HD_OFF_MASK;
-   break;
-   case VIDEO_DACS_CONTROL_SYSCFG5072:
-   mask = DAC_CFG_HD_HZUVW_OFF_MASK;
-   break;
-   default:
-   DRM_INFO("Video DACS control register not supported\n");
-   return;
-   }
-
val = 

drm: NULL pointer dereference in drm_mode_object_find()

[Alexander Potapenko]

On Tue, Sep 20, 2016 at 11:21 AM, David Herrmann  
wrote:
> Hi
>
> On Mon, Sep 5, 2016 at 10:30 AM, Dmitry Vyukov  wrote:
>> On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko  
>> wrote:
>>> Hello,
>>>
>>> the program below triggers a NULL deref in DRM code when ran on QEMU:
>>>
>>> ===
>>> BUG: unable to handle kernel NULL pointer dereference at   (null)
>>> IP: [< inline >] __list_add ./include/linux/list.h:44
>>> IP: [< inline >] list_add_tail ./include/linux/list.h:77
>>> IP: [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
>>> IP: [] __mutex_lock_slowpath+0x6f/0x100
>>> kernel/locking/mutex.c:824
>>> PGD 1c555067 PUD 1c554067 PMD 0
>>> Oops: 0002 [#1] SMP
>>> Modules linked in:
>>> CPU: 0 PID: 2517 Comm: crash_drm_mode_ Not tainted 4.8.0-rc2+ #1157
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: 88001c40a700 task.stack: 88001c984000
>>> RIP: 0010:[]  []
>>> __mutex_lock_slowpath+0x6f/0x100
>>> RSP: 0018:88001c987cb0  EFLAGS: 00010282
>>> RAX:  RBX: 88001d5212a0 RCX: c100
>>> RDX: 0001 RSI: 88001c40a700 RDI: 88001d5212a4
>>> RBP: 88001c987cf8 R08: 88001c984000 R09: 
>>> R10:  R11:  R12: 88001c40a700
>>> R13: 88001d5212a4 R14:  R15: 88001d5212a8
>>> FS:  00dc9880() GS:88001f00() knlGS:
>>> CS:  0010 DS:  ES:  CR0: 80050033
>>> CR2:  CR3: 1c8a9000 CR4: 000406f0
>>> Stack:
>>>  88001d5212a8   811a398f
>>>  88001d5212a0 88001d5212a0  
>>>  81a6eb20 88001c987d10 818e85ba 88001d521000
>>> Call Trace:
>>>  [< inline >] __mutex_fastpath_lock 
>>> ./arch/x86/include/asm/mutex_64.h:28
>>>  [] mutex_lock+0x1a/0x30 kernel/locking/mutex.c:102
>>>  [] _object_find+0x23/0xc0 drivers/gpu/drm/drm_crtc.c:329
>>>  [< inline >] drm_mode_object_find drivers/gpu/drm/drm_crtc.c:360
>>>  [< inline >] drm_crtc_find ./include/drm/drm_crtc.h:2999
>>>  [] drm_mode_page_flip_ioctl+0x4e/0x300
>>> drivers/gpu/drm/drm_crtc.c:5414
>>>  [] drm_ioctl+0x2a2/0x460 drivers/gpu/drm/drm_ioctl.c:721
>>>  [< inline >] vfs_ioctl fs/ioctl.c:43
>>>  [] do_vfs_ioctl+0x8d/0x580 fs/ioctl.c:675
>>>  [< inline >] SYSC_ioctl fs/ioctl.c:690
>>>  [] SyS_ioctl+0x74/0x80 fs/ioctl.c:681
>>>  [] entry_SYSCALL_64_fastpath+0x13/0x8f
>>> arch/x86/entry/entry_64.S:207
>>> Code: e8 37 23 00 00 8b 03 83 f8 01 0f 84 95 00 00 00 48 8b 43 10 4c
>>> 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48>
>>> 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04
>>> RIP  [< inline >] __list_add ./include/linux/list.h:44
>>> RIP  [< inline >] list_add_tail ./include/linux/list.h:77
>>> RIP  [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
>>> RIP  [] __mutex_lock_slowpath+0x6f/0x100
>>> kernel/locking/mutex.c:824
>>>  RSP 
>>> CR2: 
>>> ---[ end trace 3cef4eb618ac6bb6 ]---
>>> ===
>>>
>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main()
>>> {
>>>   int fd = open("/dev/dri/card0", 0);
>>>   mmap(0x20036000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul);
>>>   memcpy((void*)0x20036ad7,
>>>  "\x1e\xa4\x45\xdc\xca\x11\xff\x25\x72\x65\x7e\x4a\x56\x54\x35"
>>>  "\x67\xe3\x8b\x41\x5c\x6d\x69\xa5\xf9\x88\x29\xb8\xc9\x6a\x45"
>>>  "\x76\xa9\xe7\x14\xd1\xf6\xa3\x59\x07\x4d\xe5\xc8\x39\xbf\x33"
>>>  "\xb9\x3d\x21\xd1\xaf\x16\x4d\xbc\xbf\xb1\x0a\x92\x97\xd9\x91"
>>>  "\x4d\xd8\xf8\xa1\xa6\xa3\x20\x02\x2c\x5e\x8f\x87\x05\x8b\xeb"
>>>  "\x9a\xb9\xbc\xa6\x60\x45\x8d\x19\x01\x7d\xb7\xef\x64\x62\x2e"
>>>  "\x5e\x3d\xfe\x65\xbf\xe2\x80\x89\x36\x48\x73\xc6\xa2\x6e\xe2"
>>>  "\x1a\x8f\x1b\x11\x6f\x49\x20\xeb\x74\x2d\x41\xb9\x8b\xb4\x8e"
>>>  "\x8b\xf5\x6d\xb7\xb1\xa3\xcb\xc4\xc2\x7f\x6d\xef\x32\xef\xa7"
>>>  "\x1c\x17\x03\x60\x7b\x31\x1f\x66",
>>>  143);
>>>   ioctl(fd, 0xbb0ul, 0x20036ad7ul, 0, 0, 0);
>>>   return 0;
>>> }
>>>
>>> I build the ToT kernel (commit
>>> 952b159f2919a8d514f13999f9f463bddcc1dae7, Aug 18) with defconfig and
>>> CONFIG_DRM_VGEM=y.
>>
>> +dri-devel
>>
>> I am also hitting this on 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of
>> linux-next.
>
> Can you tell us which DRM driver this is? vgem does not specify
> DRIVER_MODESET, so the page-flip ioctl should not be hooked up. Also,
> the mmap() operation should fail on any GEM driver. *confused*
How do I check that?
> Thanks
> David
>
> --
> You received this message because you are subscribed to the Google Groups 
> 

drm: NULL pointer dereference in drm_mode_object_find()

[David Herrmann]

Hi

On Mon, Sep 5, 2016 at 10:30 AM, Dmitry Vyukov  wrote:
> On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko  
> wrote:
>> Hello,
>>
>> the program below triggers a NULL deref in DRM code when ran on QEMU:
>>
>> ===
>> BUG: unable to handle kernel NULL pointer dereference at   (null)
>> IP: [< inline >] __list_add ./include/linux/list.h:44
>> IP: [< inline >] list_add_tail ./include/linux/list.h:77
>> IP: [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
>> IP: [] __mutex_lock_slowpath+0x6f/0x100
>> kernel/locking/mutex.c:824
>> PGD 1c555067 PUD 1c554067 PMD 0
>> Oops: 0002 [#1] SMP
>> Modules linked in:
>> CPU: 0 PID: 2517 Comm: crash_drm_mode_ Not tainted 4.8.0-rc2+ #1157
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: 88001c40a700 task.stack: 88001c984000
>> RIP: 0010:[]  []
>> __mutex_lock_slowpath+0x6f/0x100
>> RSP: 0018:88001c987cb0  EFLAGS: 00010282
>> RAX:  RBX: 88001d5212a0 RCX: c100
>> RDX: 0001 RSI: 88001c40a700 RDI: 88001d5212a4
>> RBP: 88001c987cf8 R08: 88001c984000 R09: 
>> R10:  R11:  R12: 88001c40a700
>> R13: 88001d5212a4 R14:  R15: 88001d5212a8
>> FS:  00dc9880() GS:88001f00() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2:  CR3: 1c8a9000 CR4: 000406f0
>> Stack:
>>  88001d5212a8   811a398f
>>  88001d5212a0 88001d5212a0  
>>  81a6eb20 88001c987d10 818e85ba 88001d521000
>> Call Trace:
>>  [< inline >] __mutex_fastpath_lock 
>> ./arch/x86/include/asm/mutex_64.h:28
>>  [] mutex_lock+0x1a/0x30 kernel/locking/mutex.c:102
>>  [] _object_find+0x23/0xc0 drivers/gpu/drm/drm_crtc.c:329
>>  [< inline >] drm_mode_object_find drivers/gpu/drm/drm_crtc.c:360
>>  [< inline >] drm_crtc_find ./include/drm/drm_crtc.h:2999
>>  [] drm_mode_page_flip_ioctl+0x4e/0x300
>> drivers/gpu/drm/drm_crtc.c:5414
>>  [] drm_ioctl+0x2a2/0x460 drivers/gpu/drm/drm_ioctl.c:721
>>  [< inline >] vfs_ioctl fs/ioctl.c:43
>>  [] do_vfs_ioctl+0x8d/0x580 fs/ioctl.c:675
>>  [< inline >] SYSC_ioctl fs/ioctl.c:690
>>  [] SyS_ioctl+0x74/0x80 fs/ioctl.c:681
>>  [] entry_SYSCALL_64_fastpath+0x13/0x8f
>> arch/x86/entry/entry_64.S:207
>> Code: e8 37 23 00 00 8b 03 83 f8 01 0f 84 95 00 00 00 48 8b 43 10 4c
>> 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48>
>> 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04
>> RIP  [< inline >] __list_add ./include/linux/list.h:44
>> RIP  [< inline >] list_add_tail ./include/linux/list.h:77
>> RIP  [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
>> RIP  [] __mutex_lock_slowpath+0x6f/0x100
>> kernel/locking/mutex.c:824
>>  RSP 
>> CR2: 
>> ---[ end trace 3cef4eb618ac6bb6 ]---
>> ===
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include 
>> #include 
>> #include 
>>
>> int main()
>> {
>>   int fd = open("/dev/dri/card0", 0);
>>   mmap(0x20036000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul);
>>   memcpy((void*)0x20036ad7,
>>  "\x1e\xa4\x45\xdc\xca\x11\xff\x25\x72\x65\x7e\x4a\x56\x54\x35"
>>  "\x67\xe3\x8b\x41\x5c\x6d\x69\xa5\xf9\x88\x29\xb8\xc9\x6a\x45"
>>  "\x76\xa9\xe7\x14\xd1\xf6\xa3\x59\x07\x4d\xe5\xc8\x39\xbf\x33"
>>  "\xb9\x3d\x21\xd1\xaf\x16\x4d\xbc\xbf\xb1\x0a\x92\x97\xd9\x91"
>>  "\x4d\xd8\xf8\xa1\xa6\xa3\x20\x02\x2c\x5e\x8f\x87\x05\x8b\xeb"
>>  "\x9a\xb9\xbc\xa6\x60\x45\x8d\x19\x01\x7d\xb7\xef\x64\x62\x2e"
>>  "\x5e\x3d\xfe\x65\xbf\xe2\x80\x89\x36\x48\x73\xc6\xa2\x6e\xe2"
>>  "\x1a\x8f\x1b\x11\x6f\x49\x20\xeb\x74\x2d\x41\xb9\x8b\xb4\x8e"
>>  "\x8b\xf5\x6d\xb7\xb1\xa3\xcb\xc4\xc2\x7f\x6d\xef\x32\xef\xa7"
>>  "\x1c\x17\x03\x60\x7b\x31\x1f\x66",
>>  143);
>>   ioctl(fd, 0xbb0ul, 0x20036ad7ul, 0, 0, 0);
>>   return 0;
>> }
>>
>> I build the ToT kernel (commit
>> 952b159f2919a8d514f13999f9f463bddcc1dae7, Aug 18) with defconfig and
>> CONFIG_DRM_VGEM=y.
>
> +dri-devel
>
> I am also hitting this on 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of
> linux-next.

Can you tell us which DRM driver this is? vgem does not specify
DRIVER_MODESET, so the page-flip ioctl should not be hooked up. Also,
the mmap() operation should fail on any GEM driver. *confused*

Thanks
David

[Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

[Jani Nikula]

On Mon, 19 Sep 2016, James Bottomley  
wrote:
> On Mon, 2016-09-19 at 08:09 -0700, James Bottomley wrote:
>> On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote:
>> > Hi! James & Paulo: What's the current status of this?
>> 
>> No, the only interaction has been the suggestion below for a revert,
>> which didn't fix the problem.
>> 
>> >  Was this issue discussed elsewhere or even fixed in between? Just 
>> > asking, because this issue is on the list of regressions for 4.8.
>> 
>> 
>> I'm just about to try out -rc7, but it's not fixed so far.
>
> OK, with -rc7 and the i915 fixes, there seems to be a marked
> improvement.  I can no longer crash the crtc by using lots of xrandr
> switches, which was the principal problem.
>
> I've so far only got one of these in the logs
>
> [14858.635035] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR*
> CPU pipe B FIFO underrun
>
> And the only residual problem seems to be that the monitor goes blank
> periodically, but this can be fixed by switching resolution a couple of
> times.
>
> I haven't seen any of the link training errors so far and I've run
> through my usual battery of be nasty to the external monitor tests.

Thanks for the update. We still have fixes for the underruns in the
pipeline.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 6/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 20 Sep 2016 10:40:22 +0200

* Adjust a jump target.

* Delete the explicit initialisation for the local variable "ret"
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/mid_bios.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
b/drivers/gpu/drm/gma500/mid_bios.c
index e5cece0..602d16f 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -284,7 +284,7 @@ static void mid_get_vbt_data(struct drm_psb_private 
*dev_priv)
u8 __iomem *vbt_virtual;
struct mid_vbt_header vbt_header;
struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI_DEVFN(2, 0));
-   int ret = -1;
+   int ret;

/* Get the address of the platform config vbt */
pci_read_config_dword(pci_gfx_root, 0xFC, );
@@ -293,18 +293,18 @@ static void mid_get_vbt_data(struct drm_psb_private 
*dev_priv)
dev_dbg(dev->dev, "drm platform config address is %x\n", addr);

if (!addr)
-   goto out;
+   goto report_failure;

/* get the virtual address of the vbt */
vbt_virtual = ioremap(addr, sizeof(vbt_header));
if (!vbt_virtual)
-   goto out;
+   goto report_failure;

memcpy_fromio(_header, vbt_virtual, sizeof(vbt_header));
iounmap(vbt_virtual);

if (memcmp(_header.signature, "$GCT", 4))
-   goto out;
+   goto report_failure;

dev_dbg(dev->dev, "GCT revision is %02x\n", vbt_header.revision);

@@ -322,9 +322,8 @@ static void mid_get_vbt_data(struct drm_psb_private 
*dev_priv)
dev_err(dev->dev, "Unknown revision of GCT!\n");
return;
}
-
-out:
if (ret)
+ report_failure:
dev_err(dev->dev, "Unable to read GCT!");
else
dev_priv->has_gct = true;
-- 
2.10.0

[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 20 Sep 2016 10:36:19 +0200

A single error message should be sufficient to inform about
the detection of an unknown GCT revision at the end.
Thus return after the logging call in this case directly.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/mid_bios.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
b/drivers/gpu/drm/gma500/mid_bios.c
index 9004d30..e5cece0 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -320,6 +320,7 @@ static void mid_get_vbt_data(struct drm_psb_private 
*dev_priv)
break;
default:
dev_err(dev->dev, "Unknown revision of GCT!\n");
+   return;
}

 out:
-- 
2.10.0

[PATCH 4/6] GPU-DRM-GMA500: Fix indentation for a function call parameter in mid_get_vbt_data_r10()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 20 Sep 2016 10:34:28 +0200

Adjust the indentation for a single function call parameter here.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/mid_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
b/drivers/gpu/drm/gma500/mid_bios.c
index 3caee42..9004d30 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -240,7 +240,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
*dev_priv, u32 addr)
return -1;

gct_virtual = ioremap(addr + sizeof(vbt),
-   sizeof(*gct) * vbt.panel_count);
+ sizeof(*gct) * vbt.panel_count);
if (!gct_virtual) {
ret = -1;
goto free_gct;
-- 
2.10.0

[PATCH 3/6] GPU-DRM-GMA500: Move a variable assignment in mid_get_vbt_data_r10()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 20 Sep 2016 10:32:12 +0200

One local variable was set to an error code before a concrete
error situation was detected. Thus move the corresponding assignment into
an if branch to indicate a software failure there.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/mid_bios.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
b/drivers/gpu/drm/gma500/mid_bios.c
index cf4e605..3caee42 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -230,7 +230,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
*dev_priv, u32 addr)
struct gct_r10 *gct;
struct oaktrail_timing_info *dp_ti = _priv->gct_data.DTD;
struct gct_r10_timing_info *ti;
-   int ret = -1;
+   int ret;

if (read_vbt_r10(addr, ))
return -1;
@@ -241,8 +241,10 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
*dev_priv, u32 addr)

gct_virtual = ioremap(addr + sizeof(vbt),
sizeof(*gct) * vbt.panel_count);
-   if (!gct_virtual)
+   if (!gct_virtual) {
+   ret = -1;
goto free_gct;
+   }
memcpy_fromio(gct, gct_virtual, sizeof(*gct));
iounmap(gct_virtual);

-- 
2.10.0

[PATCH 2/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data_r10()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 20 Sep 2016 09:09:10 +0200

Adjust a jump label according to the current Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/mid_bios.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
b/drivers/gpu/drm/gma500/mid_bios.c
index a833568..cf4e605 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -242,7 +242,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
*dev_priv, u32 addr)
gct_virtual = ioremap(addr + sizeof(vbt),
sizeof(*gct) * vbt.panel_count);
if (!gct_virtual)
-   goto out;
+   goto free_gct;
memcpy_fromio(gct, gct_virtual, sizeof(*gct));
iounmap(gct_virtual);

@@ -270,7 +270,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
*dev_priv, u32 addr)
dp_ti->vsync_pulse_width_lo = ti->vsync_pulse_width_lo;

ret = 0;
-out:
+ free_gct:
kfree(gct);
return ret;
 }
-- 
2.10.0

[PATCH 1/6] GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 20 Sep 2016 08:54:07 +0200

A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/mid_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mid_bios.c 
b/drivers/gpu/drm/gma500/mid_bios.c
index d75ecb3..a833568 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -235,7 +235,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private 
*dev_priv, u32 addr)
if (read_vbt_r10(addr, ))
return -1;

-   gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL);
+   gct = kmalloc_array(vbt.panel_count, sizeof(*gct), GFP_KERNEL);
if (!gct)
return -1;

-- 
2.10.0

[PATCH 0/6] GPU-DRM-GMA500: Fine-tuning for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 20 Sep 2016 10:48:04 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (6):
  Use kmalloc_array() in mid_get_vbt_data_r10()
  Rename a jump label in mid_get_vbt_data_r10()
  Move a variable assignment in mid_get_vbt_data_r10()
  Fix indentation for a function call parameter in mid_get_vbt_data_r10()
  One error message less for a GCT revision mismatch in mid_get_vbt_data()
  Rename a jump label in mid_get_vbt_data()

 drivers/gpu/drm/gma500/mid_bios.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

-- 
2.10.0

[RFC 1/2] drm/exynos: mixer: convert booleans to flags in mixer context

[Andrzej Hajda]

On 19.09.2016 15:53, Tobias Jakobi wrote:
> The mixer context struct already has a 'flags' field, so
> we can use it to store the 'interlace', 'vp_enabled' and
> 'has_sclk' booleans.
> We use the non-atomic helper functions to access these bits.
>
> Signed-off-by: Tobias Jakobi 

Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

[PATCH] drm/exynos: mark exynos_dp_crtc_clock_enable() static

[Andrzej Hajda]

On 18.09.2016 15:58, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/gpu/drm/exynos/exynos_dp.c:46:5: warning: no previous prototype for 
> 'exynos_dp_crtc_clock_enable' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie 

Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

Kernel error causing display issues.

[Edward Bartolo]

Hi,

I am experiencing display issues on HP Probook 4540s ( i5 based
laptop). Reading /var/log/kern.log I found the cause is probably
rooted in:

[drm] Wrong MCH_SSKPD value: 0x16040307

Just after the kernel takes control of the machine, I cannot read the
boot text. Successive pixel lines are shifted left relative to the
user (reader). The shift is always by the same amount.

While using Firefox in XFCE 4.10,  horizontal distortions occur as I
scroll text in a web page.

Help is much appreciated.

Edward


lspci listing follows:

$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor
Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 1 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 3 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 4 (rev c4)
00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 6 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC
Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
6-port SATA Controller [AHCI mode] (rev 04)
02:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host
Controller (rev 30)
02:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host
Controller (rev 30)
02:00.3 System peripheral: JMicron Technology Corp. MS Host Controller (rev 30)
03:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
Adapter (rev 01)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)


System:
Linux edbarx-pc3 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1
(2016-09-03) x86_64 GNU/Linux

Kernel error during boot:

Sep 18 06:58:03 edbarx-pc3 kernel: [7.471266] [drm] Wrong
MCH_SSKPD value: 0x16040307
Sep 18 06:58:03 edbarx-pc3 kernel: [7.471269] [drm] This can cause
pipe underruns and display issues.
Sep 18 06:58:03 edbarx-pc3 kernel: [7.471270] [drm] Please upgrade
your BIOS to fix this.
Sep 18 06:58:03 edbarx-pc3 kernel: [7.489912] fbcon: inteldrmfb
(fb0) is primary device
Sep 18 06:58:03 edbarx-pc3 kernel: [7.598128] EFI Variables
Facility v0.08 2004-May-17
Sep 18 06:58:03 edbarx-pc3 kernel: [7.724203] hp_accel: laptop
model unknown, using default axes configuration
Sep 18 06:58:03 edbarx-pc3 kernel: [7.729494] jmb38x_ms
:02:00.3: enabling device ( -> 0002)
Sep 18 06:58:03 edbarx-pc3 kernel: [7.757025]
[drm:ilk_display_irq_handler] *ERROR* Pipe A FIFO underrun
Sep 18 06:58:03 edbarx-pc3 kernel: [7.759849]
[drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo
underrun on pch transcoder A
Sep 18 06:58:03 edbarx-pc3 kernel: [7.759851]
[drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun
---

Module Information:
---
# modinfo i915
filename:   /lib/modules/3.16.0-4-amd64/kernel/drivers/gpu/drm/i915/i915.ko
license:GPL and additional rights
description:Intel Graphics
author: Tungsten Graphics, Inc.
alias:  pci:v8086d22B3sv*sd*bc03sc*i*
alias:  pci:v8086d22B2sv*sd*bc03sc*i*
alias:  pci:v8086d22B1sv*sd*bc03sc*i*
alias:  pci:v8086d22B0sv*sd*bc03sc*i*
alias:  pci:v8086d162Dsv*sd*bc03sc*i*
alias:  pci:v8086d162Asv*sd*bc03sc*i*
alias:  pci:v8086d162Esv*sd*bc03sc*i*
alias:  pci:v8086d162Bsv*sd*bc03sc*i*
alias:  pci:v8086d1626sv*sd*bc03sc*i*
alias:  pci:v8086d1622sv*sd*bc03sc*i*
alias:  pci:v8086d161Dsv*sd*bc03sc*i*
alias:  pci:v8086d161Asv*sd*bc03sc*i*
alias:  pci:v8086d160Dsv*sd*bc03sc*i*
alias:  pci:v8086d160Asv*sd*bc03sc*i*
alias:  pci:v8086d161Esv*sd*bc03sc*i*
alias:  pci:v8086d161Bsv*sd*bc03sc*i*
alias:  

[PATCH v3 3/3] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

[Yakir Yang]

Hi Sean,

On 09/12/2016 09:52 PM, Sean Paul wrote:
> On Fri, Sep 9, 2016 at 5:45 AM, Yakir Yang  wrote:
>> Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
>> function, or print the sink PSR error state if we failed to apply the
>> requested PSR setting.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v3:
>> - Update commit message
>> - Add DP_TIMEOUT_PSR_LOOP_MS marcos
>> - Correct the return values of analogix_dp_send_psr_spd()
>>
>> Changes in v2:
>> - A bunch of good fixes from Sean
>>
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  5 +++--
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 25 
>> --
>>   3 files changed, 28 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 5fe3982..c0ce16a 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -116,8 +116,7 @@ int analogix_dp_enable_psr(struct device *dev)
>>  psr_vsc.DB0 = 0;
>>  psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | 
>> EDP_VSC_PSR_CRC_VALUES_VALID;
>>
>> -   analogix_dp_send_psr_spd(dp, _vsc);
>> -   return 0;
>> +   return analogix_dp_send_psr_spd(dp, _vsc);
>>   }
>>   EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
>>
>> @@ -139,8 +138,7 @@ int analogix_dp_disable_psr(struct device *dev)
>>  psr_vsc.DB0 = 0;
>>  psr_vsc.DB1 = 0;
>>
>> -   analogix_dp_send_psr_spd(dp, _vsc);
>> -   return 0;
>> +   return analogix_dp_send_psr_spd(dp, _vsc);
>>   }
>>   EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> index d564e90..a27f1e3 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> @@ -20,6 +20,7 @@
>>   #define MAX_EQ_LOOP 5
>>
>>   #define DP_TIMEOUT_LOOP_MS msecs_to_jiffies(1)
>> +#define DP_TIMEOUT_PSR_LOOP_MS msecs_to_jiffies(300)
> Same comment here re: units.
>
> 300ms seems like a really long time. Why does it take this long?

This magic number '300ms' just come from my test, I haven't found the 
description in eDP 1.4a Spec about what exact time should Sink take to 
entry PSR.

- Yakir

> Sean
>
>
>>   /* DP_MAX_LANE_COUNT */
>>   #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
>> @@ -248,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct 
>> analogix_dp_device *dp);
>>   void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
>>   void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
>>   void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
>> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>> - struct edp_vsc_psr *vsc);
>> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>> +struct edp_vsc_psr *vsc);
>>   ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
>>   struct drm_dp_aux_msg *msg);
>>   #endif /* _ANALOGIX_DP_CORE_H */
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> index 15a4cf0..7fd4ed0 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> @@ -1004,10 +1004,12 @@ void analogix_dp_enable_psr_crc(struct 
>> analogix_dp_device *dp)
>>  writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
>>   }
>>
>> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>> - struct edp_vsc_psr *vsc)
>> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>> +struct edp_vsc_psr *vsc)
>>   {
>> +   unsigned long timeout;
>>  unsigned int val;
>> +   u8 sink;
>>
>>  /* don't send info frame */
>>  val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>> @@ -1048,6 +1050,25 @@ void analogix_dp_send_psr_spd(struct 
>> analogix_dp_device *dp,
>>  val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>>  val |= IF_EN;
>>  writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>> +
>> +   timeout = jiffies + DP_TIMEOUT_PSR_LOOP_MS;
>> +   while (time_before(jiffies, timeout)) {
>> +   val = drm_dp_dpcd_readb(>aux, DP_PSR_STATUS, );
>> +   if (val != 1) {
>> +   dev_err(dp->dev, "PSR_STATUS read failed ret=%d", 
>> val);
>> +   return -EBUSY;
>> +   }
>> +
>> +   if ((vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB) ||
>> +   (!vsc->DB1 && sink == DP_PSR_SINK_INACTIVE))
>> + 

[PATCH v3 2/3] drm/bridge: analogix_dp: use jiffies to simulate timeout loop

[Yakir Yang]

Hi Sean,


On 09/12/2016 09:51 PM, Sean Paul wrote:
> On Fri, Sep 9, 2016 at 5:44 AM, Yakir Yang  wrote:
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v3:
>> - Suggested by Sean
>>
>> Changes in v2: None
>>
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 ++-
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 18 +-
>>   2 files changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> index a15f076..d564e90 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> @@ -16,10 +16,11 @@
>>   #include 
>>   #include 
>>
>> -#define DP_TIMEOUT_LOOP_COUNT 100
>>   #define MAX_CR_LOOP 5
>>   #define MAX_EQ_LOOP 5
>>
>> +#define DP_TIMEOUT_LOOP_MS msecs_to_jiffies(1)
> The name suggests the units here are ms, but you're storing jiffies.
> Do the msecs_to_jiffies conversion down below.

I suddenly realized that 'analogix_dp_core.c' also used the 
'DP_TIMEOUT_LOOP_COUNT' macros, and 'analogix_dp_core.c' have four kinds 
of timeout,
   - DP_TIMEOUT_LOOP_COUNT * 1us
   - DP_TIMEOUT_LOOP_COUNT * 10us
   - DP_TIMEOUT_LOOP_COUNT * 100us
   - DP_TIMEOUT_LOOP_COUNT * 1000us

I may guess it's not necessary to replace the 'DP_TIMEOUT_LOOP_COUNT' 
now  :-)

- Yakir

>
>> +
>>   /* DP_MAX_LANE_COUNT */
>>   #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
>>   #define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> index a4d17b8..15a4cf0 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> @@ -335,7 +335,7 @@ void analogix_dp_set_analog_power_down(struct 
>> analogix_dp_device *dp,
>>   void analogix_dp_init_analog_func(struct analogix_dp_device *dp)
>>   {
>>  u32 reg;
>> -   int timeout_loop = 0;
>> +   unsigned long timeout;
>>
>>  analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);
>>
>> @@ -350,9 +350,9 @@ void analogix_dp_init_analog_func(struct 
>> analogix_dp_device *dp)
>>  if (analogix_dp_get_pll_lock_status(dp) == PLL_UNLOCKED) {
>>  analogix_dp_set_pll_power_down(dp, 0);
>>
>> +   timeout = jiffies + DP_TIMEOUT_LOOP_MS;
> timeout = jiffies + msecs_to_jiffies(DP_TIMEOUT_LOOP_MS);
>
>>  while (analogix_dp_get_pll_lock_status(dp) == PLL_UNLOCKED) 
>> {
>> -   timeout_loop++;
>> -   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
>> +   if (time_after(jiffies, timeout)) {
>>  dev_err(dp->dev, "failed to get pll lock 
>> status\n");
>>  return;
>>  }
>> @@ -501,7 +501,7 @@ int analogix_dp_start_aux_transaction(struct 
>> analogix_dp_device *dp)
>>   {
>>  int reg;
>>  int retval = 0;
>> -   int timeout_loop = 0;
>> +   unsigned long timeout;
>>
>>  /* Enable AUX CH operation */
>>  reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
>> @@ -509,10 +509,10 @@ int analogix_dp_start_aux_transaction(struct 
>> analogix_dp_device *dp)
>>  writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
>>
>>  /* Is AUX CH command reply received? */
>> +   timeout = jiffies + DP_TIMEOUT_LOOP_MS;
>>  reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
>>  while (!(reg & RPLY_RECEIV)) {
>> -   timeout_loop++;
>> -   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
>> +   if (time_after(jiffies, timeout)) {
>>  dev_err(dp->dev, "AUX CH command reply failed!\n");
>>  return -ETIMEDOUT;
>>  }
>> @@ -1055,7 +1055,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
>> *dp,
>>   {
>>  u32 reg;
>>  u8 *buffer = msg->buffer;
>> -   int timeout_loop = 0;
>> +   unsigned long timeout;
>>  unsigned int i;
>>  int num_transferred = 0;
>>
>> @@ -1123,10 +1123,10 @@ ssize_t analogix_dp_transfer(struct 
>> analogix_dp_device *dp,
>>
>>  /* Is AUX CH command reply received? */
>>  /* TODO: Wait for an interrupt instead of looping? */
>> +   timeout = jiffies + DP_TIMEOUT_LOOP_MS;
>>  reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
>>  while (!(reg & RPLY_RECEIV)) {
>> -   timeout_loop++;
>> -   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
>> +   if (time_after(jiffies, timeout)) {
>>  dev_err(dp->dev, "AUX CH command reply failed!\n");
>>  return -ETIMEDOUT;
>>  }
>> --
>> 1.9.1
>>
>>
>
>

[PATCH] drm/sti: remove stih415-416 platform support

[Vincent Abriou]

stih415 and stih416 platform are obsolete and no more supported.
Only stih407 and stih410 platform are maintained.

Signed-off-by: Vincent Abriou 
---
 drivers/gpu/drm/sti/Kconfig|   6 +-
 drivers/gpu/drm/sti/sti_compositor.c   |  19 --
 drivers/gpu/drm/sti/sti_hda.c  |  39 +---
 drivers/gpu/drm/sti/sti_hdmi.c |  20 --
 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 -
 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h |  14 --
 drivers/gpu/drm/sti/sti_mixer.c|  19 --
 drivers/gpu/drm/sti/sti_tvout.c|  40 +---
 8 files changed, 14 insertions(+), 479 deletions(-)
 delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c
 delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index 494ab25..acd7286 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,6 @@
 config DRM_STI
-   tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
-   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
+   tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
+   depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
select RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
@@ -9,4 +9,4 @@ config DRM_STI
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
help
- Choose this option to enable DRM on STM stiH41x chipset
+ Choose this option to enable DRM on STM stiH4xx chipset
diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index a6f391b..f62041f 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -39,22 +39,6 @@ static const struct sti_compositor_data 
stih407_compositor_data = {
},
 };

-/*
- * stiH416 compositor properties
- * Note:
- * on stih416 MIXER_AUX has a different base address from MIXER_MAIN
- * Moreover, GDPx is different for Main and Aux Mixer. So this subdev map does
- * not fit for stiH416 if we want to enable the MIXER_AUX.
- */
-static const struct sti_compositor_data stih416_compositor_data = {
-   .nb_subdev = 3,
-   .subdev_desc = {
-   {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100},
-   {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200},
-   {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00}
-   },
-};
-
 int sti_compositor_debugfs_init(struct sti_compositor *compo,
struct drm_minor *minor)
 {
@@ -179,9 +163,6 @@ static const struct component_ops sti_compositor_ops = {

 static const struct of_device_id compositor_of_match[] = {
{
-   .compatible = "st,stih416-compositor",
-   .data = _compositor_data,
-   }, {
.compatible = "st,stih407-compositor",
.data = _compositor_data,
}, {
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index a225c4d..e7c243f 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -62,14 +62,8 @@
 #define SCALE_CTRL_CR_DFLT  0x00DB0249

 /* Video DACs control */
-#define VIDEO_DACS_CONTROL_MASK 0x0FFF
-#define VIDEO_DACS_CONTROL_SYSCFG2535   0x085C /* for stih416 */
-#define DAC_CFG_HD_OFF_SHIFT5
-#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT)
-#define VIDEO_DACS_CONTROL_SYSCFG5072   0x0120 /* for stih407 */
 #define DAC_CFG_HD_HZUVW_OFF_MASK   BIT(1)

-
 /* Upsampler values for the alternative 2X Filter */
 #define SAMPLER_COEF_NB 8
 #define HDA_ANA_SRC_Y_CFG_ALT_2X0x0113
@@ -300,28 +294,14 @@ static bool hda_get_mode_idx(struct drm_display_mode 
mode, int *idx)
  */
 static void hda_enable_hd_dacs(struct sti_hda *hda, bool enable)
 {
-   u32 mask;
-
if (hda->video_dacs_ctrl) {
u32 val;

-   switch ((u32)hda->video_dacs_ctrl & VIDEO_DACS_CONTROL_MASK) {
-   case VIDEO_DACS_CONTROL_SYSCFG2535:
-   mask = DAC_CFG_HD_OFF_MASK;
-   break;
-   case VIDEO_DACS_CONTROL_SYSCFG5072:
-   mask = DAC_CFG_HD_HZUVW_OFF_MASK;
-   break;
-   default:
-   DRM_INFO("Video DACS control register not supported\n");
-   return;
-   }
-
val = readl(hda->video_dacs_ctrl);
if (enable)
-   val &= ~mask;
+   val &= ~DAC_CFG_HD_HZUVW_OFF_MASK;
else
-   val |= mask;
+   val |= DAC_CFG_HD_HZUVW_OFF_MASK;

writel(val, hda->video_dacs_ctrl);
}
@@ -352,24 +332,11 @@ static void hda_dbg_awg_microcode(struct seq_file *s, 
void __iomem *reg)
 static 

[PATCH 02/14] drm/blend: Fix sparse warnings

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Monday 19 Sep 2016 16:33:43 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> drm/drm_blend.c:207:5: warning: symbol 'drm_atomic_normalize_zpos' was not
> declared. Should it be static?
> 
> Cc: Marek Szyprowski 
> Cc: Benjamin Gaignard 
> Cc: Laurent Pinchart 
> Signed-off-by: Ville Syrjälä 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_blend.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 0813b7e021be..0a0b9357db35 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
> 
> -#include "drm_internal.h"
> +#include "drm_crtc_internal.h"
> 
>  /**
>   * drm_plane_create_zpos_property - create mutable zpos property

-- 
Regards,

Laurent Pinchart

[PATCH 2/8] drm/rockchip: Get rid of some unnecessary code

[Mark yao]

On 2016年09月18日 12:01, Tomasz Figa wrote:
> Hi Mark,
>
> On Sun, Sep 18, 2016 at 10:50 AM, Mark yao  wrote:
>> On 2016年09月14日 20:54, Tomasz Figa wrote:
>>> Current code implements prepare_fb and cleanup_fb callbacks only to
>>> grab/release fb references, which is already done by atomic framework
>>> when creating/destryoing plane state. Let's remove these
>>> unused bits.
>>>
>>> Signed-off-by: Tomasz Figa 
>>> ---
>>>drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 --
>>>1 file changed, 18 deletions(-)
>>
>> Hi Tomasz
>>
>> I think we can't get rid of the prepare_fb and cleanup_fb
> I think I have to disagree. Please see below for detailed explanation.
>
>> see the reason:
>> commit 44d0237a26395ac94160cf23f32769013b365590
>> Author: Mark Yao 
>> Date:   Fri Apr 29 11:37:20 2016 +0800
>>
>>  drm/rockchip: vop: fix iommu crash with async atomic
>>
>>  After async atomic_commit callback, drm_atomic_clean_old_fb will
>>  clean all old fb, but because async, the old fb may be also on
>>  the vop hardware, dma will access the old fb buffer, clean old
>>  fb will cause iommu page fault.
> I think the above is not quite right. Atomic plane state holds a
> reference to its fb and old state is not supposed to be destroyed
> until the flip completes.
>
> Indeed current rockchip_atomic_commit implementation has following
> order of calls: rockchip_atomic_wait_for_complete(),
> drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This
> means that .cleanup_fb() is called from
> drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free()
> will release references by destroying old plane states. Note that both
> are called already after rockchip_atomic_wait_for_complete(), so it
> should be already safe to free the old fbs.
>
> So the above fix doesn't really do anything, possibly just covers the
> race condition of the original wait for vblank function by delaying
> drm_atomic_state_free() a bit.
>
> Moreover, the whole series has been thoroughly tested in Chrome OS 4.4
> kernel, including async commits. (There is still a possibility some
> newer upstream changes slightly modified the semantics, but I couldn't
> find such difference. Actually one of the advantages of atomic helpers
> was to avoid manually refcounting the fbs from the driver.)
>
> Best regards,
> Tomasz
>
Hi Tomasz

You are right, plane_duplicate_state/plane_destroy_state already protect 
the old fbs.
we can get rid of prepare_fb and cleanup_fb.

-- 
ï¼­ark Yao

[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

[Peter Griffin]

Hi Emil,

On Tue, 20 Sep 2016, Emil Velikov wrote:

> On 5 September 2016 at 14:16, Peter Griffin  
> wrote:
> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> > recursive dependency.


> >
> From a humble skim through remoteproc, drm and a few other subsystems
> I think the above is wrong. All the drivers (outside of remoteproc),
> that I've seen, depend on the core component, they don't select it.

I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
why it is like it is.

For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
the other drivers in the remoteproc subsystem which has exposed this recursive
dependency issue.

For this particular kconfig symbol a quick grep reveals more drivers in
the kernel using 'select', than 'depend on'

git grep "select VIRTIO" | wc -l
14

git grep "depends on VIRTIO" | wc -l
10


> Furthermore most places explicitly hide the drivers from the menu if
> the core component isn't enabled.

Remoteproc subsystem takes a different approach, the core code is only enabled
if a driver which relies on it is enabled. This IMHO makes sense, as
remoteproc is not widely used (only a few particular ARM SoC's).

It is true that for subsystems which rely on the core component being
explicitly enabled, they often tend to hide drivers which depend on it
from the menu unless it is. This also makes sense.

> 
> Is there something that requires such a different/unusual behaviour in
> remoteproc ?
> 

I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON 
in
mfd subsystem, client drivers select MFD_CORE.

I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
recently, maybe he has some thoughts on whether this is the correct fix or not?

regards,

Peter.

[PATCH 25/38] drm: Add reference counting to drm_atomic_state

[Chris Wilson]

drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more beneficial when the lifetime of the state becomes more
convoluted than being passed to a single worker thread for the commit.

v2: Double check !intel atomic_commit functions for missing gets
v3: Update kerneldocs

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Eric Engestrom 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  3 +-
 drivers/gpu/drm/drm_atomic.c | 25 +++
 drivers/gpu/drm/drm_atomic_helper.c  | 98 +++-
 drivers/gpu/drm/drm_fb_helper.c  |  9 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  3 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |  3 +-
 drivers/gpu/drm/i915/intel_display.c | 31 +
 drivers/gpu/drm/i915/intel_sprite.c  |  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  3 +-
 drivers/gpu/drm/msm/msm_atomic.c |  3 +-
 drivers/gpu/drm/omapdrm/omap_drv.c   |  3 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
 drivers/gpu/drm/sti/sti_drv.c|  3 +-
 drivers/gpu/drm/tegra/drm.c  |  3 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 -
 drivers/gpu/drm/vc4/vc4_kms.c|  3 +-
 include/drm/drm_atomic.h | 28 +++-
 include/drm/drm_crtc.h   |  3 +
 18 files changed, 101 insertions(+), 129 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 8e7483d90c47..c9e645fa1233 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -464,7 +464,7 @@ atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit 
*commit)

drm_atomic_helper_cleanup_planes(dev, old_state);

-   drm_atomic_state_free(old_state);
+   drm_atomic_state_put(old_state);

/* Complete the commit, wake up any waiter. */
spin_lock(>commit.wait.lock);
@@ -521,6 +521,7 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device 
*dev,
/* Swap the state, this is the point of no return. */
drm_atomic_helper_swap_state(state, true);

+   drm_atomic_state_get(state);
if (async)
queue_work(dc->wq, >work);
else
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 23739609427d..5dd70540219c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -74,6 +74,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_release);
 int
 drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
 {
+   kref_init(>ref);
+
/* TODO legacy paths should maybe do a better job about
 * setting this appropriately?
 */
@@ -215,22 +217,16 @@ void drm_atomic_state_clear(struct drm_atomic_state 
*state)
 EXPORT_SYMBOL(drm_atomic_state_clear);

 /**
- * drm_atomic_state_free - free all memory for an atomic state
- * @state: atomic state to deallocate
+ * __drm_atomic_state_free - free all memory for an atomic state
+ * @ref: This atomic state to deallocate
  *
  * This frees all memory associated with an atomic state, including all the
  * per-object state for planes, crtcs and connectors.
  */
-void drm_atomic_state_free(struct drm_atomic_state *state)
+void __drm_atomic_state_free(struct kref *ref)
 {
-   struct drm_device *dev;
-   struct drm_mode_config *config;
-
-   if (!state)
-   return;
-
-   dev = state->dev;
-   config = >mode_config;
+   struct drm_atomic_state *state = container_of(ref, typeof(*state), ref);
+   struct drm_mode_config *config = >dev->mode_config;

drm_atomic_state_clear(state);

@@ -243,7 +239,7 @@ void drm_atomic_state_free(struct drm_atomic_state *state)
kfree(state);
}
 }
-EXPORT_SYMBOL(drm_atomic_state_free);
+EXPORT_SYMBOL(__drm_atomic_state_free);

 /**
  * drm_atomic_get_crtc_state - get crtc state
@@ -1742,7 +1738,7 @@ retry:
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
/*
 * Unlike commit, check_only does not clean up state.
-* Below we call drm_atomic_state_free for it.
+* Below we call drm_atomic_state_put for it.
 */
ret = drm_atomic_check_only(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
@@ -1775,8 +1771,7 @@ out:
goto retry;
}

-   if (ret || arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
-   drm_atomic_state_free(state);
+   drm_atomic_state_put(state);

drm_modeset_drop_locks();
drm_modeset_acquire_fini();
diff --git 

[PATCH 4/4] drm/sun4i: dotclock: Round to closest clock rate

[Maxime Ripard]

On Mon, Sep 19, 2016 at 11:36:18PM +0800, Chen-Yu Tsai wrote:
> On Mon, Sep 19, 2016 at 3:16 AM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > On Thu, Sep 15, 2016 at 11:14:02PM +0800, Chen-Yu Tsai wrote:
> >> With display pixel clocks we want to have the closest possible clock
> >> rate, to minimize timing and refresh rate skews. Whether the actual
> >> clock rate is higher or lower than the requested rate is less important.
> >>
> >> Also check candidates against the requested rate, rather than the
> >> ideal parent rate, the varying dividers also influence the difference
> >> between the requested rate and the rounded rate.
> >>
> >> Signed-off-by: Chen-Yu Tsai 
> >> ---
> >>  drivers/gpu/drm/sun4i/sun4i_dotclock.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c 
> >> b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> >> index 3eb99784f371..d401156490f3 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> >> @@ -90,7 +90,8 @@ static long sun4i_dclk_round_rate(struct clk_hw *hw, 
> >> unsigned long rate,
> >>   goto out;
> >>   }
> >>
> >> - if ((rounded < ideal) && (rounded > best_parent)) {
> >> + if (abs(rate - rounded / i) <
> >> + abs(rate - best_parent / best_div)) {
> >
> > I'm not sure what you're trying to do here. Why is the divider involved?
> 
> Say you want the dotclock at X, so you try Y = 6 ~ 127 for the divider.
> Now you're asking the CCF to round (X*Y).
> 
> In the original code, you were comparing the result of rounding (X * Y).
> 
> if ((rounded < ideal) && (rounded > best_parent)) {
> best_parent = rounded;
> best_div = i;
> }
> 
> where ideal = X * Y (i in the code). Given the divider increases in
> the loop, you are actually not closing in on the best divider, but the
> highest divider that doesn't give a higher rate than the ideal rate.
> 
> Including the divider makes it compare the actual dot clock frequency
> if a given divider was used.
> 
> Does this makes sense? Explaining this kind of makes my head spin...

Yes, sorry, I didn't remember rounded was actually the rounded parent
rate.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/40c61675/attachment-0001.sig>

[PATCH 4/4] drm/sun4i: dotclock: Round to closest clock rate

[Maxime Ripard]

On Thu, Sep 15, 2016 at 11:14:02PM +0800, Chen-Yu Tsai wrote:
> With display pixel clocks we want to have the closest possible clock
> rate, to minimize timing and refresh rate skews. Whether the actual
> clock rate is higher or lower than the requested rate is less important.
> 
> Also check candidates against the requested rate, rather than the
> ideal parent rate, the varying dividers also influence the difference
> between the requested rate and the rounded rate.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/81bddca7/attachment-0001.sig>

[PATCH 04/14] drm/arm: Fix sparse warnings

[Liviu Dudau]

On Mon, Sep 19, 2016 at 04:33:45PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> drm/arm/malidp_planes.c:49:24: warning: symbol 'malidp_duplicate_plane_state' 
> was not declared. Should it be static?
> drm/arm/malidp_planes.c:66:6: warning: symbol 'malidp_destroy_plane_state' 
> was not declared. Should it be static?
> 
> Cc: Liviu Dudau 

Acked-by: Liviu Dudau 

Thanks for cleaning it up!

Liviu

> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/arm/malidp_planes.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 82c193e5e0d6..cc9b8e02904d 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -46,7 +46,7 @@ static void malidp_de_plane_destroy(struct drm_plane *plane)
>   devm_kfree(plane->dev->dev, mp);
>  }
>  
> -struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane)
> +static struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane 
> *plane)
>  {
>   struct malidp_plane_state *state, *m_state;
>  
> @@ -63,8 +63,8 @@ struct drm_plane_state *malidp_duplicate_plane_state(struct 
> drm_plane *plane)
>   return >base;
>  }
>  
> -void malidp_destroy_plane_state(struct drm_plane *plane,
> - struct drm_plane_state *state)
> +static void malidp_destroy_plane_state(struct drm_plane *plane,
> +struct drm_plane_state *state)
>  {
>   struct malidp_plane_state *m_state = to_malidp_plane_state(state);
>  
> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

[PATCH 5/5] drm/imx: add exclusive fence to plane state

[Lucas Stach]

Am Montag, den 19.09.2016, 22:48 +0200 schrieb Daniel Vetter:
> On Thu, Aug 11, 2016 at 11:18 AM, Lucas Stach  
> wrote:
> > This allows the atomic helper to wait on them, instead of open-coding
> > the same in the imx-drm driver.
> >
> > Signed-off-by: Lucas Stach 
> > ---
> >  drivers/gpu/drm/imx/imx-drm-core.c | 63 
> > +-
> >  1 file changed, 28 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> > b/drivers/gpu/drm/imx/imx-drm-core.c
> > index 66b3556f7b79..2d3f32f1b13b 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -152,50 +152,43 @@ static void imx_drm_output_poll_changed(struct 
> > drm_device *drm)
> > drm_fbdev_cma_hotplug_event(imxdrm->fbhelper);
> >  }
> >
> > +static int imx_drm_atomic_commit(struct drm_device *dev,
> > +struct drm_atomic_state *state,
> > +bool nonblock)
> > +{
> > +   struct drm_plane_state *plane_state;
> > +   struct drm_plane *plane;
> > +   struct dma_buf *dma_buf;
> > +   int i;
> > +
> > +   /*
> > +* If the plane fb has an dma-buf attached, fish out the exclusive
> > +* fence for the atomic helper to wait on.
> > +*/
> > +   for_each_plane_in_state(state, plane, plane_state, i) {
> > +   if ((plane->state->fb != plane_state->fb) && 
> > plane_state->fb) {
> > +   dma_buf = drm_fb_cma_get_gem_obj(plane_state->fb,
> > +0)->base.dma_buf;
> > +   if (!dma_buf)
> > +   continue;
> > +   plane_state->fence =
> > +   
> > reservation_object_get_excl_rcu(dma_buf->resv);
> > +   }
> > +   }
> 
> Just an fyi, but the idea was that you could do this in youre
> prepare_plane hook, assuming that only when userspace flips is it
> interested in syncing (for backwards compat reasons). But this gets
> the job done too.
> 
> The upshot of doing this consistently in a prepare_plane hook is that
> it would then allow us to have a shared implementation for all cma
> based kms drivers. If you feel bored, I'd be happy to take a look at a
> refactor patch which would extract that helper (and wire it up for
> imx).
> 
Thanks for letting me know.

As our original flight to XDC has been canceled and we are re-routed to
the evening flight the boredom might actually kick in. :)

Regards,
Lucas

[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

[Emil Velikov]

On Tuesday, 20 September 2016, Emil Velikov 
wrote:


>  Did you miss my earlier question/suggestion that mentions that ?
>
Please scratch that. Just noticed the timestamps.

Emil
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/70146c43/attachment.html>

[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

[Emil Velikov]

On Monday, 19 September 2016, Peter Griffin 
wrote:

> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
> It must not select, it must depend? Did you miss my earlier
question/suggestion that mentions that ?

Regards,
Emil
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/65ca951e/attachment.html>

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #83 from Michel Dänzer  ---
(In reply to Weber K. from comment #81)
> And since I put this in grub.cfg and fstab, never had a black screen again:
>   rootflags=relatime,lazytime,commit=60 iommu=noagp radeon.dpm=1

It could be iommu=noagp, at least that would make more sense than filesystem
flags...

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

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

--- Comment #8 from Mike Lothian  ---
I'm headed off to work now, will test tonight

-- 
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/20160920/7a070355/attachment.html>

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

--- Comment #7 from Michel Dänzer  ---
(In reply to Mike Lothian from comment #6)
> I've just tested the latest wip-4.9 branch and now X won't even start

Can you bisect which change caused that?

-- 
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/20160920/6da7c42c/attachment.html>

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

--- Comment #6 from Mike Lothian  ---
Created attachment 126643
  --> https://bugs.freedesktop.org/attachment.cgi?id=126643=edit
Error

I've just tested the latest wip-4.9 branch and now X won't even start

-- 
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/20160920/94274066/attachment.html>

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #82 from Weber K.  ---
Ooops...
Forgot to mention... I appreciate your good work supporting kernel!
Thank all of you very much!

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

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #81 from Weber K.  ---
I think so as well...

Anyway before, I had to put this in kernel parameters, or else, black screen
and hang up during boot:
  radeon.dpm=0

And since I put this in grub.cfg and fstab, never had a black screen again:
  rootflags=relatime,lazytime,commit=60 iommu=noagp radeon.dpm=1

I don't understand why, but it worked...
I have pcie XFX HD6850 AMD 1055T FOSS drivers, kernel 4.4.14 .

Maybe it could help you to troubleshoot this error too.
I think it's worth a try, if you have spare time.

If this don't help you... Then I'm sorry...

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

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #5 from Michel Dänzer  ---
Mike, have you tested https://patchwork.freedesktop.org/patch/110851/ and
possibly the more recent patches on
https://patchwork.freedesktop.org/project/amd-xorg-ddx/patches/?submitter=11066
?

-- 
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/20160920/803654ff/attachment.html>

[RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite

[ayaka]

On 09/20/2016 03:12 AM, Fabio Estevam wrote:
> On Mon, Sep 19, 2016 at 4:02 PM, Randy Li  wrote:
>
>> +   vcc_sys_lcd: sys-lcd {
>> +   compatible = "regulator-fixed";
>> +   regulator-name = "vcc_5v";
>> +   regulator-min-microvolt = <500>;
>> +   regulator-max-microvolt = <500>;
>> +   gpio = < 4 GPIO_ACTIVE_HIGH>;
> Is this really active high? If so, you should add the
> 'enable-active-high' property.
I see, thank you. Btw, let me make it clearly, it is really an 
independentTransistor, not be controlled by PMIC.

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #80 from Alex Deucher  ---
dpm has nothing to do with the filesystem.

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

[RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

[Randy Li]

The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.

Signed-off-by: Randy Li 
---
 .../display/panel/chunghwa,claa070wp03xg.txt   |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt 
b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
new file mode 100644
index 000..dd22685
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa070wp03xg"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f178998..3204e6b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -583,6 +583,30 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };

+static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
+   .clock = 66770,
+   .hdisplay = 800,
+   .hsync_start = 800 + 49,
+   .hsync_end = 800 + 49 + 33,
+   .htotal = 800 + 49 + 33 + 17,
+   .vdisplay = 1280,
+   .vsync_start = 1280 + 1,
+   .vsync_end = 1280 + 1 + 7,
+   .vtotal = 1280 + 1 + 7 + 15,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc chunghwa_claa070wp03xg = {
+   .modes = _claa070wp03xg_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 94,
+   .height = 150,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -1544,6 +1568,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
+   .compatible = "chunghwa,claa070wp03xg",
+   .data = _claa070wp03xg,
+   }, {
.compatible = "chunghwa,claa101wa01a",
.data = _claa101wa01a
}, {
-- 
2.7.4

[RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite

[Randy Li]

It is actually a lvds panel connected through a rga-lvds bridge.
The touchscreen is communicated with i2c bus but the driver is not
support now.

Signed-off-by: Randy Li 
---
 arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++--
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts 
b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index b08705e..5153522 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -138,6 +138,36 @@
assigned-clocks = < CLK_MOUT_CAM0>;
assigned-clock-parents = < CLK_XUSBXTI>;
};
+
+   vcc_sys_lcd: sys-lcd {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+   };
+
+   panel: panel at 0 {
+   compatible = "chunghwa,claa070wp03xg";
+
+   power-supply = <_sys_lcd>;
+   enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   backlight = <>;
+
+   port {
+   lcd_ep: endpoint {
+   remote-endpoint = <_lvds>;
+   };
+   };
+   };
+
+   bl: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 1 500 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 5 12 16 32 64 128 255>;
+   default-brightness-level = <5>;
+   power-supply = <_sys_lcd>;
+   };
 };

  {
@@ -171,11 +201,31 @@
assigned-clock-rates = <0>, <17600>;
 };

+ {
+   pinctrl-0 = <_clk _data24>;
+   pinctrl-names = "default";
+   status = "okay";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 3 {
+   reg = <3>;
+   rga_lvds: endpoint {
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+};
+
  {
dr_mode = "peripheral";
status = "okay";
 };

+_3 {
+   status = "okay";
+};
+
 _4 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -215,9 +265,9 @@

  {
status = "okay";
-   pinctrl-0 = <_out>;
+   pinctrl-0 = <_out _out>;
pinctrl-names = "default";
-   samsung,pwm-outputs = <0>;
+   samsung,pwm-outputs = <0>, <1>;
 };

 _2 {
-- 
2.7.4

[RFC PATCH v3 0/2] adding panel claa070wp03xg support for exynos

[Randy Li]

The timings issue is still here, this version is just some modifications
in dts file.

Randy Li (2):
  ARM: dts: samsung: add rga-lvds panel in itop elite
  drm/panel: Add support for Chunghwa CLAA070WP03XG panel

 .../display/panel/chunghwa,claa070wp03xg.txt   |  7 +++
 arch/arm/boot/dts/exynos4412-itop-elite.dts| 54 +-
 drivers/gpu/drm/panel/panel-simple.c   | 27 +++
 3 files changed, 86 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt

-- 
2.7.4

drm: NULL pointer dereference in drm_mode_object_find()

[Guenter Roeck]

AFAICS the only drm driver built with "make defconfig" is i915.

CONFIG_DRM=y
CONFIG_DRM_MIPI_DSI=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_I915=y
CONFIG_DRM_I915_USERPTR=y
CONFIG_DRM_PANEL=y
CONFIG_DRM_BRIDGE=y

Guenter

On Tue, Sep 20, 2016 at 2:25 AM, Alexander Potapenko  
wrote:
> On Tue, Sep 20, 2016 at 11:21 AM, David Herrmann  
> wrote:
>> Hi
>>
>> On Mon, Sep 5, 2016 at 10:30 AM, Dmitry Vyukov  wrote:
>>> On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko  
>>> wrote:
 Hello,

 the program below triggers a NULL deref in DRM code when ran on QEMU:

 ===
 BUG: unable to handle kernel NULL pointer dereference at   (null)
 IP: [< inline >] __list_add ./include/linux/list.h:44
 IP: [< inline >] list_add_tail ./include/linux/list.h:77
 IP: [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
 IP: [] __mutex_lock_slowpath+0x6f/0x100
 kernel/locking/mutex.c:824
 PGD 1c555067 PUD 1c554067 PMD 0
 Oops: 0002 [#1] SMP
 Modules linked in:
 CPU: 0 PID: 2517 Comm: crash_drm_mode_ Not tainted 4.8.0-rc2+ #1157
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
 01/01/2011
 task: 88001c40a700 task.stack: 88001c984000
 RIP: 0010:[]  []
 __mutex_lock_slowpath+0x6f/0x100
 RSP: 0018:88001c987cb0  EFLAGS: 00010282
 RAX:  RBX: 88001d5212a0 RCX: c100
 RDX: 0001 RSI: 88001c40a700 RDI: 88001d5212a4
 RBP: 88001c987cf8 R08: 88001c984000 R09: 
 R10:  R11:  R12: 88001c40a700
 R13: 88001d5212a4 R14:  R15: 88001d5212a8
 FS:  00dc9880() GS:88001f00() 
 knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2:  CR3: 1c8a9000 CR4: 000406f0
 Stack:
  88001d5212a8   811a398f
  88001d5212a0 88001d5212a0  
  81a6eb20 88001c987d10 818e85ba 88001d521000
 Call Trace:
  [< inline >] __mutex_fastpath_lock 
 ./arch/x86/include/asm/mutex_64.h:28
  [] mutex_lock+0x1a/0x30 kernel/locking/mutex.c:102
  [] _object_find+0x23/0xc0 drivers/gpu/drm/drm_crtc.c:329
  [< inline >] drm_mode_object_find drivers/gpu/drm/drm_crtc.c:360
  [< inline >] drm_crtc_find ./include/drm/drm_crtc.h:2999
  [] drm_mode_page_flip_ioctl+0x4e/0x300
 drivers/gpu/drm/drm_crtc.c:5414
  [] drm_ioctl+0x2a2/0x460 drivers/gpu/drm/drm_ioctl.c:721
  [< inline >] vfs_ioctl fs/ioctl.c:43
  [] do_vfs_ioctl+0x8d/0x580 fs/ioctl.c:675
  [< inline >] SYSC_ioctl fs/ioctl.c:690
  [] SyS_ioctl+0x74/0x80 fs/ioctl.c:681
  [] entry_SYSCALL_64_fastpath+0x13/0x8f
 arch/x86/entry/entry_64.S:207
 Code: e8 37 23 00 00 8b 03 83 f8 01 0f 84 95 00 00 00 48 8b 43 10 4c
 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48>
 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04
 RIP  [< inline >] __list_add ./include/linux/list.h:44
 RIP  [< inline >] list_add_tail ./include/linux/list.h:77
 RIP  [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
 RIP  [] __mutex_lock_slowpath+0x6f/0x100
 kernel/locking/mutex.c:824
  RSP 
 CR2: 
 ---[ end trace 3cef4eb618ac6bb6 ]---
 ===

 // autogenerated by syzkaller (http://github.com/google/syzkaller)
 #include 
 #include 
 #include 

 int main()
 {
   int fd = open("/dev/dri/card0", 0);
   mmap(0x20036000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul);
   memcpy((void*)0x20036ad7,
  "\x1e\xa4\x45\xdc\xca\x11\xff\x25\x72\x65\x7e\x4a\x56\x54\x35"
  "\x67\xe3\x8b\x41\x5c\x6d\x69\xa5\xf9\x88\x29\xb8\xc9\x6a\x45"
  "\x76\xa9\xe7\x14\xd1\xf6\xa3\x59\x07\x4d\xe5\xc8\x39\xbf\x33"
  "\xb9\x3d\x21\xd1\xaf\x16\x4d\xbc\xbf\xb1\x0a\x92\x97\xd9\x91"
  "\x4d\xd8\xf8\xa1\xa6\xa3\x20\x02\x2c\x5e\x8f\x87\x05\x8b\xeb"
  "\x9a\xb9\xbc\xa6\x60\x45\x8d\x19\x01\x7d\xb7\xef\x64\x62\x2e"
  "\x5e\x3d\xfe\x65\xbf\xe2\x80\x89\x36\x48\x73\xc6\xa2\x6e\xe2"
  "\x1a\x8f\x1b\x11\x6f\x49\x20\xeb\x74\x2d\x41\xb9\x8b\xb4\x8e"
  "\x8b\xf5\x6d\xb7\xb1\xa3\xcb\xc4\xc2\x7f\x6d\xef\x32\xef\xa7"
  "\x1c\x17\x03\x60\x7b\x31\x1f\x66",
  143);
   ioctl(fd, 0xbb0ul, 0x20036ad7ul, 0, 0, 0);
   return 0;
 }

 I build the ToT kernel (commit
 952b159f2919a8d514f13999f9f463bddcc1dae7, Aug 18) with defconfig and