[Bug 79011] GPU lockup, screen freeze with Radeon HD7770

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

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

--- Comment #16 from Thue Kristensen  ---
I am no longer experiencing any crashes. (running latest arch rolling release)

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

[PATCH v2] drm/imx: ipuv3-crtc: Return error if ipu_plane_init() fails for primary plane

[Liu Ying]

For primary plane initialization failure cases, ipu_plane_init() may return
a pointer encoded by ERR_PTR(). So, we should bailout instead of using that
pointer blindly.

Signed-off-by: Liu Ying 
---
v1->v2:
* Trivial commit message fix.
* Rebase onto Phillip's patch[1].
  [1] http://www.spinics.net/lists/dri-devel/msg93700.html

 drivers/gpu/drm/imx/ipuv3-crtc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 872183a..35a77e5 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -361,6 +361,10 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
dp = IPU_DP_FLOW_SYNC_BG;
ipu_crtc->plane[0] = ipu_plane_init(drm, ipu, pdata->dma[0], dp, 0,
DRM_PLANE_TYPE_PRIMARY);
+   if (IS_ERR(ipu_crtc->plane[0])) {
+   ret = PTR_ERR(ipu_crtc->plane[0]);
+   goto err_put_resources;
+   }

ret = imx_drm_add_crtc(drm, _crtc->base, _crtc->imx_crtc,
_crtc->plane[0]->base, _crtc_helper_funcs,
-- 
2.5.0

[PATCH] drm/imx: switch to universal planes

[Liu Ying]

Hi Phillip,

On Fri, Nov 06, 2015 at 11:12:20AM +0100, Philipp Zabel wrote:
> Use drm_universal_plane_init to create the planes, create the primary
> plane first and use drm_crtc_init_with_planes to associate it with
> the crtc.

It's better to mention in the commit message that this patch removes the safe
plane which is created by create_primary_plane(). Or, at least, it fixes the
NULL pointer dereference issue triggered by the drm modetest I mentioned in my
patch[1].

Otherwise, Acked-by: Liu Ying 

[1] https://lkml.org/lkml/2015/11/4/107

Regards,
Liu Ying

> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
>  drivers/gpu/drm/imx/imx-drm.h  |  3 ++-
>  drivers/gpu/drm/imx/ipuv3-crtc.c   | 20 ++--
>  drivers/gpu/drm/imx/ipuv3-plane.c  |  9 -
>  drivers/gpu/drm/imx/ipuv3-plane.h  |  2 +-
>  5 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index ee7981b..4140caa 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -340,7 +340,7 @@ err_kms:
>   * imx_drm_add_crtc - add a new crtc
>   */
>  int imx_drm_add_crtc(struct drm_device *drm, struct drm_crtc *crtc,
> - struct imx_drm_crtc **new_crtc,
> + struct imx_drm_crtc **new_crtc, struct drm_plane *primary_plane,
>   const struct imx_drm_crtc_helper_funcs *imx_drm_helper_funcs,
>   struct device_node *port)
>  {
> @@ -379,7 +379,7 @@ int imx_drm_add_crtc(struct drm_device *drm, struct 
> drm_crtc *crtc,
>   drm_crtc_helper_add(crtc,
>   imx_drm_crtc->imx_drm_helper_funcs.crtc_helper_funcs);
>  
> - drm_crtc_init(drm, crtc,
> + drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
>   imx_drm_crtc->imx_drm_helper_funcs.crtc_funcs);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
> index 10ed4e1..71380b9 100644
> --- a/drivers/gpu/drm/imx/imx-drm.h
> +++ b/drivers/gpu/drm/imx/imx-drm.h
> @@ -9,6 +9,7 @@ struct drm_display_mode;
>  struct drm_encoder;
>  struct drm_fbdev_cma;
>  struct drm_framebuffer;
> +struct drm_plane;
>  struct imx_drm_crtc;
>  struct platform_device;
>  
> @@ -24,7 +25,7 @@ struct imx_drm_crtc_helper_funcs {
>  };
>  
>  int imx_drm_add_crtc(struct drm_device *drm, struct drm_crtc *crtc,
> - struct imx_drm_crtc **new_crtc,
> + struct imx_drm_crtc **new_crtc, struct drm_plane *primary_plane,
>   const struct imx_drm_crtc_helper_funcs *imx_helper_funcs,
>   struct device_node *port);
>  int imx_drm_remove_crtc(struct imx_drm_crtc *);
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 7bc8301..872183a 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -349,7 +349,6 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
>   struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
>   int dp = -EINVAL;
>   int ret;
> - int id;
>  
>   ret = ipu_get_resources(ipu_crtc, pdata);
>   if (ret) {
> @@ -358,18 +357,19 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
>   return ret;
>   }
>  
> + if (pdata->dp >= 0)
> + dp = IPU_DP_FLOW_SYNC_BG;
> + ipu_crtc->plane[0] = ipu_plane_init(drm, ipu, pdata->dma[0], dp, 0,
> + DRM_PLANE_TYPE_PRIMARY);
> +
>   ret = imx_drm_add_crtc(drm, _crtc->base, _crtc->imx_crtc,
> - _crtc_helper_funcs, ipu_crtc->dev->of_node);
> + _crtc->plane[0]->base, _crtc_helper_funcs,
> + ipu_crtc->dev->of_node);
>   if (ret) {
>   dev_err(ipu_crtc->dev, "adding crtc failed with %d.\n", ret);
>   goto err_put_resources;
>   }
>  
> - if (pdata->dp >= 0)
> - dp = IPU_DP_FLOW_SYNC_BG;
> - id = imx_drm_crtc_id(ipu_crtc->imx_crtc);
> - ipu_crtc->plane[0] = ipu_plane_init(ipu_crtc->base.dev, ipu,
> - pdata->dma[0], dp, BIT(id), true);
>   ret = ipu_plane_get_resources(ipu_crtc->plane[0]);
>   if (ret) {
>   dev_err(ipu_crtc->dev, "getting plane 0 resources failed with 
> %d.\n",
> @@ -379,10 +379,10 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
>  
>   /* If this crtc is using the DP, add an overlay plane */
>   if (pdata->dp >= 0 && pdata->dma[1] > 0) {
> - ipu_crtc->plane[1] = ipu_plane_init(ipu_crtc->base.dev, ipu,
> - pdata->dma[1],
> + ipu_crtc->plane[1] = ipu_plane_init(drm, ipu, pdata->dma[1],
>   IPU_DP_FLOW_SYNC_FG,
> - BIT(id), false);
> +  

[Bug 92850] Segfault loading War Thunder

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

inated with signal SIGSEGV, Segmentation fault.
#0  0x7f3851f5bde6 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so
[Current thread is 1 (Thread 0x7f384eccc700 (LWP 3923))]

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

[Bug 92836] amdgpu does not resume properly from suspend

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

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

--- Comment #6 from Alex Deucher  ---
Does booting with apci_osi=Linux on the kernel command line help?  A lot of new
laptops use d3cold to support windows 10 which Linux in general doesn't support
at the moment.

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

[Bug 92836] amdgpu does not resume properly from suspend

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

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

--- Comment #5 from David Walker  ---
I've attached dmesg and Xorg.0.log files for 4.3.0-1.g7b374a4.  It appears that
the GPU faults have gone away, but the visual symptom is still the same; the
screen is blank after a resume.

You'll also note that there are a *lot* of "xhci_hcd :00:10.0: WARN
Successful completion on short TX" messages in the dmesg output.  I suspect
they're unrelated, but they don't appear under 4.2.3-1.4.

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

[Bug 92836] amdgpu does not resume properly from suspend

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

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

--- Comment #4 from David Walker  ---
Created attachment 119453
  --> https://bugs.freedesktop.org/attachment.cgi?id=119453=edit
Xorg.0.log from 4.3.0-1.g7b374a4-default

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

[Bug 92836] amdgpu does not resume properly from suspend

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

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

--- Comment #3 from David Walker  ---
Created attachment 119452
  --> https://bugs.freedesktop.org/attachment.cgi?id=119452=edit
dmesg output from 4.3.0-1.g7b374a4-default

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

[PATCH 2/2] drm/imx: Remove the primary plane created by create_primary_plane()

[Liu Ying]

On Fri, Nov 06, 2015 at 11:05:48AM +0100, Philipp Zabel wrote:
> Am Mittwoch, den 04.11.2015, 18:15 +0800 schrieb Liu Ying:
> > Since we are using ipu_plane_init() to add one primary plane for each
> > IPU CRTC, it's unnecessary to create the safe one by using the helper
> > create_primary_plane().
> > 
> > Furthermore, the safe one is attached to crtc->primary, which actually
> > carries a framebuffer(crtc->primary->fb) created by the fbdev helper to
> > build up the fbcon.  Instead, the one created by ipu_plane_init() is
> > dangling, but it is the one actually does ipu_plane_mode_set() for the
> > fbcon.  This may causes the mismatch bewteen ipu_plane->enabled(true) and
> > ipu_plane->base.fb(NULL).  Thus, it brings a NULL pointer dereference
> > issue in ipu_plane_mode_set() when we try to additionally touch the
> > IDMAC channel of the ipu_plane.  This issue could be reproduced by
> > running the drm modetest with command line 'modetest -P 19:1024x768 at XR24'
> > on the i.MX6Q SabreSD platform(single LVDS display).  This patch binds
> > the plane created by ipu_plane_init() with crtc->primary and removes the
> > safe one to address this issue.
> > 
> > Signed-off-by: Liu Ying 
> > ---
> >  drivers/gpu/drm/imx/imx-drm-core.c | 3 ++-
> >  drivers/gpu/drm/imx/ipuv3-crtc.c   | 6 ++
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> > b/drivers/gpu/drm/imx/imx-drm-core.c
> > index 6faa735..08eceeb 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -373,7 +373,8 @@ int imx_drm_add_crtc(struct drm_device *drm, struct 
> > drm_crtc *crtc,
> > drm_crtc_helper_add(crtc,
> > imx_drm_crtc->imx_drm_helper_funcs.crtc_helper_funcs);
> >  
> > -   drm_crtc_init(drm, crtc,
> > +   /* The related primary plane will be created in ipu_plane_init(). */
> > +   drm_crtc_init_with_planes(drm, crtc, NULL, NULL,
> > imx_drm_crtc->imx_drm_helper_funcs.crtc_funcs);
> 
> We rather should generate the plane first and add the primary_plane
> parameter to imx_drm_add_crtc than calling drm_crtc_init_with_planes
> without planes.

Yes, that is the regular way.  I thought about that, though I took the easy
approach here.

The question is that we currently generate the crtc pipe number in
imx_drm_add_crtc() first, and then pass it to ipu_plane_init().
Do you think it would be good to add OF alias id for IPU, pass the id to
ipu_crtc_init() via struct ipu_soc and determine the pipe number in
ipu_crtc_init() by using the IPU id and pdata->di?  This way, ipu_plane_init()
may know the pipe number in the first place.  Or, any other suggestions?

Regards,
Liu Ying

> 
> regards
> Philipp
> 

[PATCH 1/2] drm/imx: ipuv3-crtc: Return error if ipu_plane_init() fails for primary plane

[Liu Ying]

On Fri, Nov 06, 2015 at 11:05:54AM +0100, Philipp Zabel wrote:
> Hi Liu,
> 
> Am Mittwoch, den 04.11.2015, 18:15 +0800 schrieb Liu Ying:
> > For primary plane initialization failure cases, ipu_plane_init() may return
> > a pointer encoded by ERR_PTR(). So, we should bailout instead of use that
> > pointer blindly.
> > 
> > Signed-off-by: Liu Ying 
> > ---
> >  drivers/gpu/drm/imx/ipuv3-crtc.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > index 7bc8301..8d68697 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > @@ -370,6 +370,10 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
> > id = imx_drm_crtc_id(ipu_crtc->imx_crtc);
> > ipu_crtc->plane[0] = ipu_plane_init(ipu_crtc->base.dev, ipu,
> > pdata->dma[0], dp, BIT(id), true);
> > +   if (IS_ERR(ipu_crtc->plane[0])) {
> > +   ret = PTR_ERR(ipu_crtc->plane[0]);
> > +   goto err_put_resources;
> 
> That should be "goto err_remove_crtc;"

Ah, yes, you're right.  I'll fix this.
BTW, there is nothing to free the ipu_plane allocated in ipu_plane_init() in
case something goes wrong after ipu_plane_init().  Of course, we may fix this
with another patch.

Thanks,
Liu Ying

> 
> regards
> Philipp
> 

[PATCH] drm/nouveau: Fix pre-nv50 pageflip events

[Thierry Reding]

+ * @e: the event to send
> + *
> + * A lot of drivers need to generate vblank events for the very next vblank
> + * interrupt. For example when the page flip interrupt happens when the page
> + * flip gets armed, but not when it actually executes within the next vblank
> + * period. This helper function implements exactly the required vblank arming
> + * behaviour.
> + *
> + * Caller must hold event lock. Caller must also hold a vblank reference for 
> the
> + * event @e, which will be dropped when the next vblank arrives.
> + *
> + * This is the native KMS version of drm_send_vblank_event().
> + */
> +void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
> +struct drm_pending_vblank_event *e)
> +{
> + drm_arm_vblank_event(crtc->dev, drm_crtc_index(crtc), e);
> +}
> +EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
> +
> +/**
>   * drm_send_vblank_event - helper to send vblank event after pageflip
>   * @dev: DRM device
>   * @pipe: CRTC index
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 184445d4abbf..041e5f84538c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -826,7 +826,6 @@ nouveau_finish_page_flip(struct nouveau_channel *chan,
>   struct drm_device *dev = drm->dev;
>   struct nouveau_page_flip_state *s;
>   unsigned long flags;
> - int crtcid = -1;
>  
>   spin_lock_irqsave(>event_lock, flags);
>  
> @@ -838,16 +837,15 @@ nouveau_finish_page_flip(struct nouveau_channel *chan,
>  
>   s = list_first_entry(>flip, struct nouveau_page_flip_state, head);
>   if (s->event) {
> - /* Vblank timestamps/counts are only correct on >= NV-50 */
> - if (drm->device.info.family >= NV_DEVICE_INFO_V0_TESLA)
> - crtcid = s->crtc;
> -
> - drm_send_vblank_event(dev, crtcid, s->event);
> + if (drm->device.info.family < NV_DEVICE_INFO_V0_TESLA) {
> + drm_arm_vblank_event(dev, s->crtc, s->event);
> + } else {
> + drm_send_vblank_event(dev, s->crtc, s->event);
> + /* Give up ownership of vblank for page-flipped crtc */
> + drm_vblank_put(dev, s->crtc);
> + }
>   }
>  
> - /* Give up ownership of vblank for page-flipped crtc */
> - drm_vblank_put(dev, s->crtc);
> -
>   list_del(>head);
>   if (ps)
>   *ps = *s;
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index eb513341b6ee..4c91ac419d5d 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -948,6 +948,10 @@ extern void drm_send_vblank_event(struct drm_device 
> *dev, unsigned int pipe,
> struct drm_pending_vblank_event *e);
>  extern void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
>  struct drm_pending_vblank_event *e);
> +void drm_send_vblank_event(struct drm_device *dev, unsigned int pipe,
> +struct drm_pending_vblank_event *e);
> +void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> + struct drm_pending_vblank_event *e);
>  extern bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
>  extern bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
>  extern int drm_vblank_get(struct drm_device *dev, unsigned int pipe);
> -- 
> 2.5.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151106/7fb50964/attachment.sig>

[Bug 92722] radeon 0000:01:00.0: VCE init error (-22) on Kernel >= 4.2

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

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

Alex Deucher  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|DRM/Radeon
Version|11.0|unspecified
Product|Mesa|DRI
 QA Contact|dri-devel at lists.freedesktop |
   |.org|

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

[Bug 107381] New: radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics

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

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

Bug ID: 107381
   Summary: radeon VCE init error (-110) -- AMD/Intel Mars Hybrid
Graphics
   Product: Drivers
   Version: 2.5
Kernel Version: 4.3
  Hardware: x86-64
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: schmod at gmail.com
Regression: No

Created attachment 192261
  --> https://bugzilla.kernel.org/attachment.cgi?id=192261=edit
dmesg output

Since upgrading to Ubuntu 15.10, I have encountered graphics performance
issues, and have occasionally experienced lockups during boot.

I have encountered this issue on kernel 4.2.0 and 4.3.0, and it seems to have
affected users on other distributions as well:

https://bugs.launchpad.net/fedora/+source/linux/+bug/1512848
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803087
https://bugzilla.redhat.com/show_bug.cgi?id=1262649

Notably, this issue seems to primarily impact users with The ATI "Mars"
chipset, on machines that have an Intel/AMD hybrid graphics hardware
configuration.

This shows up in dmesg (full log attached, because there's a fair amount of
seemingly-useful context): 
[ 4.917369] radeon :01:00.0: VCE init error (-110).


Some other context from my PC: 

$ xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x6a cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 5
associated providers: 2 name:Intel
Provider 1: id: 0x41 cap: 0x6, Sink Output, Source Offload crtcs: 2 outputs: 0
associated providers: 2 name:radeon
Provider 2: id: 0x41 cap: 0x6, Sink Output, Source Offload crtcs: 2 outputs: 0
associated providers: 2 name:radeon

$ lspci -k (trimmed to omit likely-irrelevant devices)
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller
(rev 09)
Subsystem: Samsung Electronics Co Ltd Device c0e6
Kernel driver in use: ivb_uncore
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor
PCI Express Root Port (rev 09)
Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
DeviceName: Onboard IGD
Subsystem: Samsung Electronics Co Ltd Device c0e6
Kernel driver in use: i915
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon
HD 8670A/8670M/8750M] (rev ff)
Kernel driver in use: radeon

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

[PATCH 07/19] drm/panel: simple: Add timings for the Olimex LCD-OLinuXino-4.3TS

[Maxime Ripard]

Hi Thierry,

On Fri, Oct 30, 2015 at 06:32:30PM +0100, Thierry Reding wrote:
> On Fri, Oct 30, 2015 at 03:20:53PM +0100, Maxime Ripard wrote:
> > Add support for the Olimex LCD-OLinuXino-4.3TS panel to the DRM simple
> > panel driver.
> > 
> > It is a 480x272 panel connected through a 24-bits RGB interface.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 26 ++
> >  1 file changed, 26 insertions(+)
> 
> I don't see a patch adding the DT binding documentation for this panel.
> 
> Also, the olimex vendor prefix isn't defined.
> 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index f97b73ec4713..3a9ecb64d1e6 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1096,6 +1096,29 @@ static const struct panel_desc 
> > shelly_sca07010_bfn_lnn = {
> > .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> >  };
> >  
> > +static const struct drm_display_mode olimex_lcd_olinuxino_43ts_mode = {
> > +   .clock = 9000,
> > +   .hdisplay = 480,
> > +   .hsync_start = 480 + 5,
> > +   .hsync_end = 480 + 5 + 30,
> > +   .htotal = 480 + 5 + 30 + 10,
> > +   .vdisplay = 272,
> > +   .vsync_start = 272 + 8,
> > +   .vsync_end = 272 + 8 + 5,
> > +   .vtotal = 272 + 8 + 5 + 3,
> > +   .vrefresh = 60,
> > +};
> > +
> > +static const struct panel_desc olimex_lcd_olinuxino_43ts = {
> > +   .modes = _lcd_olinuxino_43ts_mode,
> > +   .num_modes = 1,
> > +   .size = {
> > +   .width = 105,
> > +   .height = 67,
> > +   },
> > +   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > +};
> > +
> 
> These mode and panel descriptors are all sorted alphabetically (by
> vendor, by model), please keep it so.
> 
> >  static const struct of_device_id platform_of_match[] = {
> > {
> > .compatible = "ampire,am800480r3tmqwa1h",
> > @@ -1191,6 +1214,9 @@ static const struct of_device_id platform_of_match[] 
> > = {
> > .compatible = "shelly,sca07010-bfn-lnn",
> > .data = _sca07010_bfn_lnn,
> > }, {
> > +   .compatible = "olimex,lcd-olinuxino-43-ts",
> > +   .data = _lcd_olinuxino_43ts,
> > +   }, {
> > /* sentinel */
> > }
> 
> Here as well.

Thanks for your feedback, consider it fixed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151106/1652315b/attachment.sig>

[linux-sunxi] [PATCH 11/19] drm: sun4i: Add composite output

[Maxime Ripard]

On Mon, Nov 02, 2015 at 01:53:20PM +1100, Jonathan Liu wrote:
> > +   ret = sun4i_tv_init(drm);
> > +   if (ret) {
> > +   dev_err(drm->dev, "Couldn't create our RGB output\n");
> 
> RGB should be composite. Seems like a copy-paste error.

Good catch. Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151106/7855b955/attachment.sig>

[PATCH] drm/imx: switch to universal planes

[Philipp Zabel]

Am Freitag, den 06.11.2015, 21:58 +0800 schrieb Liu Ying:
> Hi Phillip,
> 
> On Fri, Nov 06, 2015 at 11:12:20AM +0100, Philipp Zabel wrote:
> > Use drm_universal_plane_init to create the planes, create the primary
> > plane first and use drm_crtc_init_with_planes to associate it with
> > the crtc.
> 
> It's better to mention in the commit message that this patch removes the safe
> plane which is created by create_primary_plane(). Or, at least, it fixes the
> NULL pointer dereference issue triggered by the drm modetest I mentioned in my
> patch[1].
> 
> Otherwise, Acked-by: Liu Ying 
> 
> [1] https://lkml.org/lkml/2015/11/4/107

Thank you, I'll apply it referencing this thread.

regards
Philipp

[PATCH v2] drm/imx: ipuv3-crtc: Return error if ipu_plane_init() fails for primary plane

[Philipp Zabel]

Am Freitag, den 06.11.2015, 22:42 +0800 schrieb Liu Ying:
> For primary plane initialization failure cases, ipu_plane_init() may return
> a pointer encoded by ERR_PTR(). So, we should bailout instead of using that
> pointer blindly.
> 
> Signed-off-by: Liu Ying 
> ---
> v1->v2:
> * Trivial commit message fix.
> * Rebase onto Phillip's patch[1].
>   [1] http://www.spinics.net/lists/dri-devel/msg93700.html
> 
>  drivers/gpu/drm/imx/ipuv3-crtc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 872183a..35a77e5 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -361,6 +361,10 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
>   dp = IPU_DP_FLOW_SYNC_BG;
>   ipu_crtc->plane[0] = ipu_plane_init(drm, ipu, pdata->dma[0], dp, 0,
>   DRM_PLANE_TYPE_PRIMARY);
> + if (IS_ERR(ipu_crtc->plane[0])) {
> + ret = PTR_ERR(ipu_crtc->plane[0]);
> + goto err_put_resources;
> + }
>  
>   ret = imx_drm_add_crtc(drm, _crtc->base, _crtc->imx_crtc,
>   _crtc->plane[0]->base, _crtc_helper_funcs,

Applied, thanks.

regards
Philipp

[PATCH 04/19] clk: sunxi: Add TCON channel1 clock

[Maxime Ripard]

Hi,

On Fri, Oct 30, 2015 at 02:37:34PM -0700, Stephen Boyd wrote:
> On 10/30, Maxime Ripard wrote:
> > The TCON is a controller generating the timings to output videos signals,
> > acting like both a CRTC and an encoder.
> > 
> > It has two channels depending on the output, each channel being driven by
> > its own clock (and own clock controller).
> > 
> > Add a driver for the channel 1 clock.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Similar comments apply to patches 3 and 4. Was the same code
> copy/pasted two more times and then changed to have different
> values?

I don't really recall, but I probably used the same skeleton yeah.

> Looks like we should consolidate all that stuff into something more
> generic so that we don't have the same problems 3 times.

Does it?

They're both pretty different actually. One is a gate + mux + reset
(patch 3), the other one is actually a combination of two clocks, one
that is the parent of the other, the former being a gate + mux, the
latter a gate + div.

At least at the hardware level, they're very different, and adding
more code to deal with both case would complicate quite a lot the
probe code, for no real reasons.

Maxime

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

[PATCH] GPU-DRM-vc4: Delete unnecessary checks before two function calls

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 6 Nov 2015 16:04:22 +0100

The following functions test whether their argument is NULL and then
return immediately.
* drm_fbdev_cma_hotplug_event
* drm_fbdev_cma_restore_mode

Thus the tests around their calls are not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 3 +--
 drivers/gpu/drm/vc4/vc4_kms.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 6e73060..df348c0 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -54,8 +54,7 @@ static void vc4_lastclose(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);

-   if (vc4->fbdev)
-   drm_fbdev_cma_restore_mode(vc4->fbdev);
+   drm_fbdev_cma_restore_mode(vc4->fbdev);
 }

 static const struct file_operations vc4_drm_fops = {
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 2e5597d..1778203 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -25,8 +25,7 @@ static void vc4_output_poll_changed(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);

-   if (vc4->fbdev)
-   drm_fbdev_cma_hotplug_event(vc4->fbdev);
+   drm_fbdev_cma_hotplug_event(vc4->fbdev);
 }

 static const struct drm_mode_config_funcs vc4_mode_funcs = {
-- 
2.6.2

[PATCH 04/19] clk: sunxi: Add TCON channel1 clock

[Maxime Ripard]

Hi,

On Sat, Oct 31, 2015 at 05:53:26PM +0800, Chen-Yu Tsai wrote:
> On Fri, Oct 30, 2015 at 10:20 PM, Maxime Ripard
>  wrote:
> > The TCON is a controller generating the timings to output videos signals,
> > acting like both a CRTC and an encoder.
> >
> > It has two channels depending on the output, each channel being driven by
> > its own clock (and own clock controller).
> >
> > Add a driver for the channel 1 clock.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/clk/sunxi/Makefile |   1 +
> >  drivers/clk/sunxi/clk-sun4i-tcon-ch1.c | 167 
> > +
> >  2 files changed, 168 insertions(+)
> >  create mode 100644 drivers/clk/sunxi/clk-sun4i-tcon-ch1.c
> 
> According to the documents I have, this variant of the TCON clock
> is specific to sun5i. On sun4i/sun7i, TCON CH1 clock has the same
> layout as TCON CH0 and the other display clocks.

At least for the A20, it's not true.

Make sure you do not confuse LCD1 CH0 (p79, which is a channel 0
clock), with LCD0 CH1 (p81, which is a channel 1 clock).

> > +   sclk1_parents[0] = sclk2_name;
> > +   sclk1_parents[1] = sclk2d2_name;
> 
> Is there any need to expose these 2 clocks via DT using of_clk_add_provider?

No, as far as I'm aware, there's no user external to this clock
driver.

> Note that these complex clock trees within a clock node breaks the
> assigned-clock-parents mechanism, as you can no longer specify the output
> clock's direct parents.

There's no point of changing the parent either. Hardware blocks are
always connected to the leaf clock (sclk1). We could also model it as
an extra 1-bit divider, which would simplify a bit the logic though.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151106/2524a5a4/attachment.sig>

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave -

Here's a handful of i915 fixes for drm-next/v4.4. Imre's commit alone
should address the remaining warnings galore you experienced on
Skylake. Almost all of the rest are also fixes against user or QA
reported bugs, with references.

Without going into specifics, please know that we're at work improving
our QA and processes, and your feedback has not gone unnoticed.


BR,
Jani.

The following changes since commit 606bb5e0b28b540685fb94c22902cd9a948a3779:

  drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks 
(2015-10-19 17:56:02 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-11-06

for you to fetch changes up to 1b0e3a049efe471c399674fd954500ce97438d30:

  drm/i915/skl: disable display side power well support for now (2015-11-06 
14:46:05 +0200)


Imre Deak (1):
  drm/i915/skl: disable display side power well support for now

Jani Nikula (3):
  drm/i915: add hotplug activation period to hotplug update mask
  drm/i915: disable CPU PWM also on LPT/SPT backlight disable
  drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015)

Maarten Lankhorst (2):
  drm/i915/skl: Prevent unclaimed register writes on skylake.
  drm/i915: Extend DSL readout fix to BDW and SKL.

Mika Kuoppala (1):
  drm/i915: Do graphics device reset under forcewake

Thomas Daniel (1):
  drm/i915: Fix maxfifo watermark calc on vlv cursor planes

Vivek Kasireddy (1):
  drm/i915: Skip fence installation for objects with rotated views (v4)

 drivers/gpu/drm/i915/i915_irq.c |  9 
 drivers/gpu/drm/i915/i915_params.c  |  5 +++--
 drivers/gpu/drm/i915/intel_display.c| 39 +++--
 drivers/gpu/drm/i915/intel_panel.c  | 14 
 drivers/gpu/drm/i915/intel_pm.c |  7 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 18 +++
 drivers/gpu/drm/i915/intel_uncore.c | 11 +-
 7 files changed, 79 insertions(+), 24 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 01/19] clk: sunxi: Add display clock

[Maxime Ripard]

Hi Stephen,

Thanks for your feedback!

On Fri, Oct 30, 2015 at 02:29:02PM -0700, Stephen Boyd wrote:
> > +
> > +   mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> > +   if (!mux)
> [..]
> > +   goto free_reset;
> > +   }
> > +
> > +   return;
> > +
> > +free_reset:
> > +   kfree(reset_data);
> > +free_clk:
> > +   clk_unregister(clk);
> 
> We really ought to have a clk_composite_unregister() API.

Can we?

We can always unregister the clock itself, but do we have a way to
retrieve the structure that has been allocated in there?

(note that it also applies to the generic clocks registration: muxes,
dividers, and so on).

Maxime

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

GPU-DRM-i915: Delete an unnecessary check before the function call "pwm_put"

[Jani Nikula]

On Fri, 06 Nov 2015, SF Markus Elfring  wrote:
>>> The pwm_put() function tests whether its argument is NULL and then
>>> returns immediately. Thus the test around the call is not needed.
>> 
>> The compiler doesn't need it, but IMO it's useful documentation for humans.
>
> How do you think about to extend the explicit documentation for
> the affected parameters in the Linux programming interfaces?

The question is, while reading intel_panel.c, which one conveys the
reader better the idea that panel->backlight.pwm may be NULL for some
connectors:

a)  if (panel->backlight.pwm)
pwm_put(panel->backlight.pwm);

b)  pwm_put(panel->backlight.pwm);

No amount of documentation in pwm_put() kernel-doc is going to help with
that. In most cases, panel->backlight.pwm is in fact NULL. IMO
unconditionally calling pwm_put() on it gives the reader the wrong idea.

Others may disagree.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] HDMI-HDCP: Delete an unnecessary check before the function call "kfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 6 Nov 2015 15:00:22 +0100

The kfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

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

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
index 1dc9c34..205e931 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
@@ -1430,7 +1430,7 @@ struct hdmi_hdcp_ctrl *hdmi_hdcp_init(struct hdmi *hdmi)

 void hdmi_hdcp_destroy(struct hdmi *hdmi)
 {
-   if (hdmi && hdmi->hdcp_ctrl) {
+   if (hdmi) {
kfree(hdmi->hdcp_ctrl);
hdmi->hdcp_ctrl = NULL;
}
-- 
2.6.2

[RFC PATCH 0/7] reset: make RESET_CONTROLLER a select'ed option

[Masahiro Yamada]

Hi Arnd,



2015-11-05 23:49 GMT+09:00 Arnd Bergmann :
> On Thursday 05 November 2015 20:15:21 Masahiro Yamada wrote:
>> When I was implementing a new reset controller for my SoCs,
>> I struggled to make my sub-menu shown under the reset
>> controller menu.
>> I noticed the Kconfig in reset sub-system are screwed up due to two
>> config options (ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER).
>>
>> I think only the former should be select'ed by relevant SoCs,
>> but in fact the latter is also select'ed here and there.
>> Mixing "select" to a user-configurable option is a mess.
>>
>> Finally, I started to wonder whether it could be more simpler?
>>
>> The first patch drops ARCH_HAS_RESET_CONTROLLER.
>> RESET_CONTROLLER should be directly selected by SoCs.
>>
>> The rest of this series are minor clean ups in other
>> sub-systems.
>> I can postpone them if changes over cross sub-systems
>> are not preferred.
>
> Thanks a lot for picking up this topic! It has been annoying me
> for a while and I have submitted an experimental patch some time
> ago, but not finished it myself.
>
> For some reason, I only see a subset of your patches here (patch 1, 4 and 6),
> so I don't know exactly what you did.

All the patches CCed linux-kernel at vger.kernel.org,
so you can dig into LKML log or the following patchwork
https://patchwork.kernel.org/project/LKML/list/




> For reference, you can find
> my original patch below. Please check if I did things that your
> series doesn't do, and whether those are still needed.

Thanks.

Yours looks mostly nice, and this work is worth continuing.
(I am pleased to review it when you submit the next version.)

I have some comments.

[1]
Why is ARCH_HAS_RESET_CONTROLLER select'ed by
ARCH_MULTIPLATFORM, but not by others?
This seems weird.

We do not have such options like
  ARCH_HAS_PINCTRL,  ARCH_HAS_COMMON_CLK...


[2]
The difference is that yours is adding per-driver options such as
RESET_SOCFPGA, RESET_BERLIN, etc.
I think this is a good idea.

But, I notice lowlevel drivers select RESET_CONTROLLER,
for example, RESET_SOCFPGA select RESET_CONTROLLER.

We generally do the opposite in other subsystems, I think.


For example, the whole of clk menu is guarded by "depends on COMMON_CLK".

menu "Common Clock Framework"
 depends on COMMON_CLK

 

endmenu


Likewise for pinctrl.





-- 
Best Regards
Masahiro Yamada

[PATCH] GPU-DRM-i915: Delete an unnecessary check before the function call "pwm_put"

[Jani Nikula]

On Fri, 06 Nov 2015, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Fri, 6 Nov 2015 13:38:22 +0100
>
> The pwm_put() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.

The compiler doesn't need it, but IMO it's useful documentation for
humans.

BR,
Jani.


>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index a24df35..3d8d913 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1729,8 +1729,7 @@ void intel_panel_destroy_backlight(struct drm_connector 
> *connector)
>   struct intel_panel *panel = _connector->panel;
>  
>   /* dispose of the pwm */
> - if (panel->backlight.pwm)
> - pwm_put(panel->backlight.pwm);
> + pwm_put(panel->backlight.pwm);
>  
>   panel->backlight.present = false;
>  }

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] GPU-DRM-ps8622: Delete an unnecessary check before backlight_device_unregister()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 6 Nov 2015 14:38:34 +0100

The backlight_device_unregister() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/bridge/parade-ps8622.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c 
b/drivers/gpu/drm/bridge/parade-ps8622.c
index be881e9..046fba0 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -646,9 +646,7 @@ static int ps8622_remove(struct i2c_client *client)
 {
struct ps8622_bridge *ps8622 = i2c_get_clientdata(client);

-   if (ps8622->bl)
-   backlight_device_unregister(ps8622->bl);
-
+   backlight_device_unregister(ps8622->bl);
drm_bridge_remove(>bridge);

return 0;
-- 
2.6.2

[PATCH 09/19] drm: sun4i: Add DT bindings documentation

[Maxime Ripard]

Hi Rob,

On Fri, Oct 30, 2015 at 11:40:03AM -0500, Rob Herring wrote:
> > +Display Engine Backend
> > +--
> > +
> > +The display engine backend exposes layers and sprites to the
> > +system. It's split into two components, the frontend and backend, the
> > +frontend doing formats conversion, scaling, deinterlacing, while the
> > +backend actually manages the layers.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +* allwinner,sun5i-a13-display-engine
> > +
> > +  - reg: base address and size of the memory-mapped region. Two are needed:
> > +* backend0: registers of the display engine backend
> > +* frontend0: registers of the display engine frontend
> 
> Why the zeros? I think they should be dropped.

We have SoCs that have two backends and two frontends, hence why I
added 0. I guess I can also add several devices for them, but then I'd
need to move to the component framework I guess (which was the plan anyway).

> > +
> > +  - allwinner,tcon: phandle to the TCON in our pipeline
> 
> Use of-graph or just let the relationship live in the driver. If there
> is only 1 instance of the blocks, the latter is fine.

We can also have several TCON instances in the SoC, and even though
you can on a theorical point of view use any TCON with any backend,
usually you're tied because of how the pins are routed on the boards.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151106/77e51878/attachment.sig>

[PATCH 03/19] clk: sunxi: Add TCON channel0 clock

[Maxime Ripard]

Hi,

On Sat, Oct 31, 2015 at 06:19:59PM +0800, Chen-Yu Tsai wrote:
> > +#define SUN4I_A10_TCON_CH0_RESET_SHIFT 29
> 
> This is sun5i specific.
> 
> A10s manual says bit 30 is the LCD reset, while bit 29 is the TV
> encoder reset.  A13/R8 don't mention TCON_CH0 clock. A10/A20 have no
> separate TV encoder reset.
> 
> Please rename the clock.

This thing with the A10s is odd, the channel 0 is only used for the
LCD interface, and not the tv encoder (and both the A13 and R8 do have
a TCON).

But you're right, I've fixed it.

Thanks!
Maxime

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

[PATCH] drm/ttm: Set CPU caching mode to cached for BOs being swapped out

[Thomas Hellstrom]

On 11/06/2015 03:33 AM, Michel Dänzer wrote:
> On 05.11.2015 17:47, Thomas Hellstrom wrote:
>> Hi, Michel,
>>
>> On 11/05/2015 09:08 AM, Michel Dänzer wrote:
>>> From: Michel Dänzer 
>>>
>>> I ran into the BUG_ON in ttm_tt_swapout, presumably the BO being swapped
>>> out was using a write-combined CPU mapping.
>>>
>>> Instead of BUGging out, just set the caching mode to what's needed.
>>>
>>> Signed-off-by: Michel Dänzer 
>>> ---
>>>  drivers/gpu/drm/ttm/ttm_tt.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>>> index 4e19d0f..c2794eb 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
>>> @@ -334,7 +334,8 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
>>> *persistent_swap_storage)
>>> int ret = -ENOMEM;
>>>  
>>> BUG_ON(ttm->state != tt_unbound && ttm->state != tt_unpopulated);
>>> -   BUG_ON(ttm->caching_state != tt_cached);
>>> +
>>> +   ttm_tt_set_caching(ttm, tt_cached);
>>>  
>>> if (!persistent_swap_storage) {
>>> swap_storage = shmem_file_setup("ttm swap",
>> This *is* actually a bug somewhere, since before ttm_tt_swapout,
>> ttm_bo_swapout should have moved out the bo to system and set
>> the correct caching.
> Maybe ttm_bo_swapout needs to check ttm->caching_state explicitly?
> AFAICT it only checks the placement flags, but we allow all caching
> modes for GTT.
>

bo->mem.placement should only have two flags set, one for the current
memory type corresponding to bo->mem.mem_type, the other for the current
caching. If there are more than one caching flag set at this point,
that's a bug. The preferred caching mode is chosen from a set of modes
in ttm_bo_select_caching(), and bo->mem is reassigned to incorporate the
current caching mode after a successful move.

I quickly eyed through the TTM default move functions and they seem to
do the correct thing from what I can tell. Is the radeon ttm driver
assigning bo->mem in a move callback perhaps?

/Thomas

GPU-DRM-i915: Delete an unnecessary check before the function call "pwm_put"

[SF Markus Elfring]

>> The pwm_put() function tests whether its argument is NULL and then
>> returns immediately. Thus the test around the call is not needed.
> 
> The compiler doesn't need it, but IMO it's useful documentation for humans.

How do you think about to extend the explicit documentation for
the affected parameters in the Linux programming interfaces?

Regards,
Markus

Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

[Pavel Machek]

On Fri 2015-11-06 11:25:09, Michel Dänzer wrote:
> On 06.11.2015 05:23, Pavel Machek wrote:
> > Hi!
> > 
>  The flickering would vanish completely if that's the reason for the issue
>  you are seeing.
> >>>
>  Try setting ref_div_min and ref_div_max to 2 in
>   radeon_compute_pll_avivo().
> >>>
> >>> Ok, I did this, but no luck, still flickers. But the flicker only
> >>> happens when something changes on screen, like dragging a big
> >>> window. Is that consistent with wrong PLL timings?
> >>
> >> Does it go away with radeon.dpm=0?  Sounds more like either memory
> >> reclocking happening outside of vblank, or underflow to the display
> >> controllers.
> > 
> > No, it does not:
> > 
> > pavel at half:~$ cat /proc/cmdline
> > BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
> > resume=/dev/sda1 radeon.dpm=0
> > 
> > ..and same issue. And yes, it looks like an underflow to me. How can I
> > debug reclocking / underflows?
> 
> Does radeon.disp_priority=2 help?

Tried this, and no change, still flickers.

pavel at half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0 radeon.disp_priority=2
pavel at half:~$

I searched for some more config options, and tried:

pavel at half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0 radeon.disp_priority=2
radeon.amdgpu_runtime_pm=0 radeon.bapm=0 radeon.sched_hw_submission=0
radeon.enable_semaphores=0
pavel at half:~$

..still flickers.

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

[PATCH] GPU-DRM-i915: Delete an unnecessary check before the function call "pwm_put"

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 6 Nov 2015 13:38:22 +0100

The pwm_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/i915/intel_panel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index a24df35..3d8d913 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1729,8 +1729,7 @@ void intel_panel_destroy_backlight(struct drm_connector 
*connector)
struct intel_panel *panel = _connector->panel;

/* dispose of the pwm */
-   if (panel->backlight.pwm)
-   pwm_put(panel->backlight.pwm);
+   pwm_put(panel->backlight.pwm);

panel->backlight.present = false;
 }
-- 
2.6.2

[Bug 91993] Graphical glitch in Astromenace (open-source game).

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

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

Nicolai Hähnle  changed:

   What|Removed |Added

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

--- Comment #22 from Nicolai Hähnle  ---
The fix for this has been in Mesa master for a while now (rev 24c9088), let's
mark this as resolved.

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

[RESEND PATCH] drm/rockchip: vop: Correct enabled clocks during setup

[Sjoerd Simons]

When doing the initial setup both the hclk and the aclk need to be
enabled otherwise the board will simply hang. This only occurs when
building the vop driver as a module, when its built-in the initial setup
happens to run before the clock framework shuts of unused clocks
(including the aclk).

While there also switch to doing prepare and enable in one step rather
then separate steps to reduce the amount of code required.

Signed-off-by: Sjoerd Simons 
Acked-by: Mark Yao 
Tested-by: Yakir Yang 
Tested-by: Romain Perier 
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 +++--
 1 file changed, 14 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..48719df 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1575,32 +1575,25 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}

-   ret = clk_prepare(vop->hclk);
-   if (ret < 0) {
-   dev_err(vop->dev, "failed to prepare hclk\n");
-   return ret;
-   }
-
ret = clk_prepare(vop->dclk);
if (ret < 0) {
dev_err(vop->dev, "failed to prepare dclk\n");
-   goto err_unprepare_hclk;
+   return ret;
}

-   ret = clk_prepare(vop->aclk);
+   /* Enable both the hclk and aclk to setup the vop */
+   ret = clk_prepare_enable(vop->hclk);
if (ret < 0) {
-   dev_err(vop->dev, "failed to prepare aclk\n");
+   dev_err(vop->dev, "failed to prepare/enable hclk\n");
goto err_unprepare_dclk;
}

-   /*
-* enable hclk, so that we can config vop register.
-*/
-   ret = clk_enable(vop->hclk);
+   ret = clk_prepare_enable(vop->aclk);
if (ret < 0) {
-   dev_err(vop->dev, "failed to prepare aclk\n");
-   goto err_unprepare_aclk;
+   dev_err(vop->dev, "failed to prepare/enable aclk\n");
+   goto err_disable_hclk;
}
+
/*
 * do hclk_reset, reset all vop registers.
 */
@@ -1608,7 +1601,7 @@ static int vop_initial(struct vop *vop)
if (IS_ERR(ahb_rst)) {
dev_err(vop->dev, "failed to get ahb reset\n");
ret = PTR_ERR(ahb_rst);
-   goto err_disable_hclk;
+   goto err_disable_aclk;
}
reset_control_assert(ahb_rst);
usleep_range(10, 20);
@@ -1634,26 +1627,25 @@ static int vop_initial(struct vop *vop)
if (IS_ERR(vop->dclk_rst)) {
dev_err(vop->dev, "failed to get dclk reset\n");
ret = PTR_ERR(vop->dclk_rst);
-   goto err_unprepare_aclk;
+   goto err_disable_aclk;
}
reset_control_assert(vop->dclk_rst);
usleep_range(10, 20);
reset_control_deassert(vop->dclk_rst);

clk_disable(vop->hclk);
+   clk_disable(vop->aclk);

vop->is_enabled = false;

return 0;

+err_disable_aclk:
+   clk_disable_unprepare(vop->aclk);
 err_disable_hclk:
-   clk_disable(vop->hclk);
-err_unprepare_aclk:
-   clk_unprepare(vop->aclk);
+   clk_disable_unprepare(vop->hclk);
 err_unprepare_dclk:
clk_unprepare(vop->dclk);
-err_unprepare_hclk:
-   clk_unprepare(vop->hclk);
return ret;
 }

-- 
2.6.2

[PATCH] GPU-DRM: Delete unnecessary checks before drm_property_unreference_blob()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 6 Nov 2015 12:03:46 +0100

The drm_property_unreference_blob() function tests whether its argument
is NULL and then returns immediately.
Thus the tests around the calls are not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/drm_atomic.c| 9 +++--
 drivers/gpu/drm/drm_atomic_helper.c | 5 ++---
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7bb3845..d65dc31 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -316,8 +316,7 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
return 0;

-   if (state->mode_blob)
-   drm_property_unreference_blob(state->mode_blob);
+   drm_property_unreference_blob(state->mode_blob);
state->mode_blob = NULL;

if (mode) {
@@ -363,8 +362,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state 
*state,
if (blob == state->mode_blob)
return 0;

-   if (state->mode_blob)
-   drm_property_unreference_blob(state->mode_blob);
+   drm_property_unreference_blob(state->mode_blob);
state->mode_blob = NULL;

if (blob) {
@@ -419,8 +417,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
-   if (mode)
-   drm_property_unreference_blob(mode);
+   drm_property_unreference_blob(mode);
return ret;
}
else if (crtc->funcs->atomic_set_property)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0c6f621..9870c70 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2173,7 +2173,7 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
  */
 void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc)
 {
-   if (crtc->state && crtc->state->mode_blob)
+   if (crtc->state)
drm_property_unreference_blob(crtc->state->mode_blob);
kfree(crtc->state);
crtc->state = kzalloc(sizeof(*crtc->state), GFP_KERNEL);
@@ -2241,8 +2241,7 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
 void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state)
 {
-   if (state->mode_blob)
-   drm_property_unreference_blob(state->mode_blob);
+   drm_property_unreference_blob(state->mode_blob);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);

-- 
2.6.2

[PATCH 01/19] clk: sunxi: Add display clock

[Maxime Ripard]

Hi,

On Sat, Oct 31, 2015 at 06:28:16PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Fri, Oct 30, 2015 at 10:20 PM, Maxime Ripard
>  wrote:
> > The A10 SoCs and its relatives has a special clock controller to drive the
> > display engines (both frontend and backend).
> >
> > Add a driver for it.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/clk/sunxi/Makefile|   1 +
> >  drivers/clk/sunxi/clk-sun4i-display.c | 199 
> > ++
> >  2 files changed, 200 insertions(+)
> >  create mode 100644 drivers/clk/sunxi/clk-sun4i-display.c
> >
> > diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> > index cb4c299214ce..a9e1a5885846 100644
> > --- a/drivers/clk/sunxi/Makefile
> > +++ b/drivers/clk/sunxi/Makefile
> > @@ -9,6 +9,7 @@ obj-y += clk-a10-mod1.o
> >  obj-y += clk-a10-pll2.o
> >  obj-y += clk-a20-gmac.o
> >  obj-y += clk-mod0.o
> > +obj-y += clk-sun4i-display.o
> >  obj-y += clk-simple-gates.o
> >  obj-y += clk-sun8i-mbus.o
> >  obj-y += clk-sun9i-core.o
> > diff --git a/drivers/clk/sunxi/clk-sun4i-display.c 
> > b/drivers/clk/sunxi/clk-sun4i-display.c
> > new file mode 100644
> > index ..f13b095c6d7a
> > --- /dev/null
> > +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> > @@ -0,0 +1,199 @@
> > +/*
> > + * Copyright 2015 Maxime Ripard
> > + *
> > + * Maxime Ripard 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define SUN4I_A10_DISPLAY_PARENTS  3
> 
> Can we change this to 4, so we can reuse this for TCON clocks on
> sun4i/sun7i?

Good point, I'll change this.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151106/37a5dc78/attachment.sig>

[PATCH 19/19] ARM: sun5i: chip: Enable the TV Encoder

[Maxime Ripard]

Hi Chen-Yu,

On Fri, Oct 30, 2015 at 11:20:41PM +0800, Chen-Yu Tsai wrote:
> On Fri, Oct 30, 2015 at 10:21 PM, Maxime Ripard
>  wrote:
> > The TV encoder is used to drive VGA and composite display.
> >
> > Enable it on the CHIP
> 
> The commit message does not match the contents. Missing a patch? :)

No, I changed the commit a bit, and forgot to update the message :)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151106/65e75bc4/attachment.sig>

[PATCH] drm/ttm: Set CPU caching mode to cached for BOs being swapped out

[Michel Dänzer]

On 05.11.2015 17:47, Thomas Hellstrom wrote:
> Hi, Michel,
> 
> On 11/05/2015 09:08 AM, Michel Dänzer wrote:
>> From: Michel Dänzer 
>>
>> I ran into the BUG_ON in ttm_tt_swapout, presumably the BO being swapped
>> out was using a write-combined CPU mapping.
>>
>> Instead of BUGging out, just set the caching mode to what's needed.
>>
>> Signed-off-by: Michel Dänzer 
>> ---
>>  drivers/gpu/drm/ttm/ttm_tt.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>> index 4e19d0f..c2794eb 100644
>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
>> @@ -334,7 +334,8 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
>> *persistent_swap_storage)
>>  int ret = -ENOMEM;
>>  
>>  BUG_ON(ttm->state != tt_unbound && ttm->state != tt_unpopulated);
>> -BUG_ON(ttm->caching_state != tt_cached);
>> +
>> +ttm_tt_set_caching(ttm, tt_cached);
>>  
>>  if (!persistent_swap_storage) {
>>  swap_storage = shmem_file_setup("ttm swap",
> 
> This *is* actually a bug somewhere, since before ttm_tt_swapout,
> ttm_bo_swapout should have moved out the bo to system and set
> the correct caching.

Maybe ttm_bo_swapout needs to check ttm->caching_state explicitly?
AFAICT it only checks the placement flags, but we allow all caching
modes for GTT.


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

Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

[Michel Dänzer]

On 06.11.2015 05:23, Pavel Machek wrote:
> Hi!
> 
 The flickering would vanish completely if that's the reason for the issue
 you are seeing.
>>>
 Try setting ref_div_min and ref_div_max to 2 in
  radeon_compute_pll_avivo().
>>>
>>> Ok, I did this, but no luck, still flickers. But the flicker only
>>> happens when something changes on screen, like dragging a big
>>> window. Is that consistent with wrong PLL timings?
>>
>> Does it go away with radeon.dpm=0?  Sounds more like either memory
>> reclocking happening outside of vblank, or underflow to the display
>> controllers.
> 
> No, it does not:
> 
> pavel at half:~$ cat /proc/cmdline
> BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
> resume=/dev/sda1 radeon.dpm=0
> 
> ..and same issue. And yes, it looks like an underflow to me. How can I
> debug reclocking / underflows?

Does radeon.disp_priority=2 help?


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

[PATCH] drm/imx: switch to universal planes

[Philipp Zabel]

Use drm_universal_plane_init to create the planes, create the primary
plane first and use drm_crtc_init_with_planes to associate it with
the crtc.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
 drivers/gpu/drm/imx/imx-drm.h  |  3 ++-
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 20 ++--
 drivers/gpu/drm/imx/ipuv3-plane.c  |  9 -
 drivers/gpu/drm/imx/ipuv3-plane.h  |  2 +-
 5 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index ee7981b..4140caa 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -340,7 +340,7 @@ err_kms:
  * imx_drm_add_crtc - add a new crtc
  */
 int imx_drm_add_crtc(struct drm_device *drm, struct drm_crtc *crtc,
-   struct imx_drm_crtc **new_crtc,
+   struct imx_drm_crtc **new_crtc, struct drm_plane *primary_plane,
const struct imx_drm_crtc_helper_funcs *imx_drm_helper_funcs,
struct device_node *port)
 {
@@ -379,7 +379,7 @@ int imx_drm_add_crtc(struct drm_device *drm, struct 
drm_crtc *crtc,
drm_crtc_helper_add(crtc,
imx_drm_crtc->imx_drm_helper_funcs.crtc_helper_funcs);

-   drm_crtc_init(drm, crtc,
+   drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
imx_drm_crtc->imx_drm_helper_funcs.crtc_funcs);

return 0;
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 10ed4e1..71380b9 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -9,6 +9,7 @@ struct drm_display_mode;
 struct drm_encoder;
 struct drm_fbdev_cma;
 struct drm_framebuffer;
+struct drm_plane;
 struct imx_drm_crtc;
 struct platform_device;

@@ -24,7 +25,7 @@ struct imx_drm_crtc_helper_funcs {
 };

 int imx_drm_add_crtc(struct drm_device *drm, struct drm_crtc *crtc,
-   struct imx_drm_crtc **new_crtc,
+   struct imx_drm_crtc **new_crtc, struct drm_plane *primary_plane,
const struct imx_drm_crtc_helper_funcs *imx_helper_funcs,
struct device_node *port);
 int imx_drm_remove_crtc(struct imx_drm_crtc *);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 7bc8301..872183a 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -349,7 +349,6 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
int dp = -EINVAL;
int ret;
-   int id;

ret = ipu_get_resources(ipu_crtc, pdata);
if (ret) {
@@ -358,18 +357,19 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
return ret;
}

+   if (pdata->dp >= 0)
+   dp = IPU_DP_FLOW_SYNC_BG;
+   ipu_crtc->plane[0] = ipu_plane_init(drm, ipu, pdata->dma[0], dp, 0,
+   DRM_PLANE_TYPE_PRIMARY);
+
ret = imx_drm_add_crtc(drm, _crtc->base, _crtc->imx_crtc,
-   _crtc_helper_funcs, ipu_crtc->dev->of_node);
+   _crtc->plane[0]->base, _crtc_helper_funcs,
+   ipu_crtc->dev->of_node);
if (ret) {
dev_err(ipu_crtc->dev, "adding crtc failed with %d.\n", ret);
goto err_put_resources;
}

-   if (pdata->dp >= 0)
-   dp = IPU_DP_FLOW_SYNC_BG;
-   id = imx_drm_crtc_id(ipu_crtc->imx_crtc);
-   ipu_crtc->plane[0] = ipu_plane_init(ipu_crtc->base.dev, ipu,
-   pdata->dma[0], dp, BIT(id), true);
ret = ipu_plane_get_resources(ipu_crtc->plane[0]);
if (ret) {
dev_err(ipu_crtc->dev, "getting plane 0 resources failed with 
%d.\n",
@@ -379,10 +379,10 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,

/* If this crtc is using the DP, add an overlay plane */
if (pdata->dp >= 0 && pdata->dma[1] > 0) {
-   ipu_crtc->plane[1] = ipu_plane_init(ipu_crtc->base.dev, ipu,
-   pdata->dma[1],
+   ipu_crtc->plane[1] = ipu_plane_init(drm, ipu, pdata->dma[1],
IPU_DP_FLOW_SYNC_FG,
-   BIT(id), false);
+   
drm_crtc_mask(_crtc->base),
+   DRM_PLANE_TYPE_OVERLAY);
if (IS_ERR(ipu_crtc->plane[1]))
ipu_crtc->plane[1] = NULL;
}
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 0c5c4d9..d2ca451 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -453,7 +453,7 @@ static struct drm_plane_funcs ipu_plane_funcs = {

 struct ipu_plane *ipu_plane_init(struct 

[PATCH 1/2] drm/imx: ipuv3-crtc: Return error if ipu_plane_init() fails for primary plane

[Philipp Zabel]

Hi Liu,

Am Mittwoch, den 04.11.2015, 18:15 +0800 schrieb Liu Ying:
> For primary plane initialization failure cases, ipu_plane_init() may return
> a pointer encoded by ERR_PTR(). So, we should bailout instead of use that
> pointer blindly.
> 
> Signed-off-by: Liu Ying 
> ---
>  drivers/gpu/drm/imx/ipuv3-crtc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 7bc8301..8d68697 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -370,6 +370,10 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
>   id = imx_drm_crtc_id(ipu_crtc->imx_crtc);
>   ipu_crtc->plane[0] = ipu_plane_init(ipu_crtc->base.dev, ipu,
>   pdata->dma[0], dp, BIT(id), true);
> + if (IS_ERR(ipu_crtc->plane[0])) {
> + ret = PTR_ERR(ipu_crtc->plane[0]);
> + goto err_put_resources;

That should be "goto err_remove_crtc;"

regards
Philipp

[PATCH 2/2] drm/imx: Remove the primary plane created by create_primary_plane()

[Philipp Zabel]

Am Mittwoch, den 04.11.2015, 18:15 +0800 schrieb Liu Ying:
> Since we are using ipu_plane_init() to add one primary plane for each
> IPU CRTC, it's unnecessary to create the safe one by using the helper
> create_primary_plane().
> 
> Furthermore, the safe one is attached to crtc->primary, which actually
> carries a framebuffer(crtc->primary->fb) created by the fbdev helper to
> build up the fbcon.  Instead, the one created by ipu_plane_init() is
> dangling, but it is the one actually does ipu_plane_mode_set() for the
> fbcon.  This may causes the mismatch bewteen ipu_plane->enabled(true) and
> ipu_plane->base.fb(NULL).  Thus, it brings a NULL pointer dereference
> issue in ipu_plane_mode_set() when we try to additionally touch the
> IDMAC channel of the ipu_plane.  This issue could be reproduced by
> running the drm modetest with command line 'modetest -P 19:1024x768 at XR24'
> on the i.MX6Q SabreSD platform(single LVDS display).  This patch binds
> the plane created by ipu_plane_init() with crtc->primary and removes the
> safe one to address this issue.
> 
> Signed-off-by: Liu Ying 
> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 3 ++-
>  drivers/gpu/drm/imx/ipuv3-crtc.c   | 6 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 6faa735..08eceeb 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -373,7 +373,8 @@ int imx_drm_add_crtc(struct drm_device *drm, struct 
> drm_crtc *crtc,
>   drm_crtc_helper_add(crtc,
>   imx_drm_crtc->imx_drm_helper_funcs.crtc_helper_funcs);
>  
> - drm_crtc_init(drm, crtc,
> + /* The related primary plane will be created in ipu_plane_init(). */
> + drm_crtc_init_with_planes(drm, crtc, NULL, NULL,
>   imx_drm_crtc->imx_drm_helper_funcs.crtc_funcs);

We rather should generate the plane first and add the primary_plane
parameter to imx_drm_add_crtc than calling drm_crtc_init_with_planes
without planes.

regards
Philipp

[RFC PATCH 0/7] reset: make RESET_CONTROLLER a select'ed option

[Arnd Bergmann]

On Friday 06 November 2015 14:58:04 Masahiro Yamada wrote:
> 2015-11-05 23:49 GMT+09:00 Arnd Bergmann :
> [1]
> Why is ARCH_HAS_RESET_CONTROLLER select'ed by
> ARCH_MULTIPLATFORM, but not by others?
> This seems weird.

I tried to avoid having to set this from each platform separately,
and all users of ARCH_HAS_RESET_CONTROLLER on ARM are also
based on ARCH_MULTIPLATFORM. The other platforms are lagging behind
in their conversion and use neither reset controllers not
multiplatform. If anyone wants to make them use reset controllers,
we probably want them to use multiplatform as well.

> We do not have such options like
>   ARCH_HAS_PINCTRL,  ARCH_HAS_COMMON_CLK...

We could of course change it in one direction or another, but it
didn't seem urgent here.

> [2]
> The difference is that yours is adding per-driver options such as
> RESET_SOCFPGA, RESET_BERLIN, etc.
> I think this is a good idea.
> 
> But, I notice lowlevel drivers select RESET_CONTROLLER,
> for example, RESET_SOCFPGA select RESET_CONTROLLER.
> 
> We generally do the opposite in other subsystems, I think.
> 
> 
> For example, the whole of clk menu is guarded by "depends on COMMON_CLK".
> 
> menu "Common Clock Framework"
>  depends on COMMON_CLK
> 
>  
> 
> endmenu
> 
> 
> Likewise for pinctrl.

We can do that too, either way works for me, and we are using both
in other parts of the kernel. REGMAP is an example for another subsystem
that gets selected by each driver that relies on the framework.

The practical difference is only in the case that the subsystem
is enabled (e.g. by using ARCH_MULTIPLATFORM) but all reset drivers
are disabled. A device driver using the API in one case will see
the stubbed-out inline helpers and not contain any object code
that relies on non-NULL return values from them, while in the
other case it calls into the subsystem code to get the same
return value at runtime.

If you volunteer to clean up my patch, feel free to choose between
the two options as you like.

Arnd

[Bug 76490] Hang during boot when DPM is on (R9 270X)

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

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

--- Comment #60 from m.gabrielboehme at googlemail.com ---
Created attachment 119434
  --> https://bugs.freedesktop.org/attachment.cgi?id=119434=edit
PowerColor R7 370 PCS+ VBIOS

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

[Bug 76490] Hang during boot when DPM is on (R9 270X)

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

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

--- Comment #59 from m.gabrielboehme at googlemail.com ---
I switched to a PowerColor R7 370 PCS+ and have the same problems as reported
already. Starting with radeon.dpm=0 or nomodeset helps to boot up.  I'm on
Fedora 23 at the moment with a 4.2 kernel version. The quirk_list fix (in my
case: { PCI_VENDOR_ID_ATI, 0x6811, 0x148c, 0x2356, , }
) seems not to work, but I'll try some more values. I'll also add the vbios of
my card.

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

[Bug 92806] 1 second freezes during new effects UT4

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

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

--- Comment #8 from Michel Dänzer  ---
A num-compilations spike without a num-shaders-created spike means the shader
compile was triggered by the driver, either because UT4 used the GLSL shader
for the first time or because UT4 changed some OpenGL state affecting the code
generated for the shader.

A num-compilations spike with a num-shaders-created spike means the shader
compile was triggered by the state tracker or by UT4 itself.

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

[PATCH] drm/amdgpu: Fix default page access routing

[Christian König]

On 05.11.2015 20:06, Jay Cornwall wrote:
> The VM default page (used when a VM translation fails) is allocated in
> system memory. The VM is misconfigured to interpret the physical address
> as referencing a VRAM physical page.
>
> Route default page accesses to system memory.
>
> Signed-off-by: Jay Cornwall 
> Cc:  # v4.2+

Nice catch, patch is Reviewed-by: Christian König 

Do we also need this for Radeon?

Regards,
Christian.

> ---
>   drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 +
>   drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 +
>   2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index fab5471..b9836f6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -474,6 +474,7 @@ static int gmc_v7_0_gart_enable(struct amdgpu_device 
> *adev)
>   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, 
> ENABLE_L2_PDE0_CACHE_LRU_UPDATE_BY_WRITE, 1);
>   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, EFFECTIVE_L2_QUEUE_SIZE, 7);
>   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, CONTEXT1_IDENTITY_ACCESS_MODE, 1);
> + tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, 
> ENABLE_DEFAULT_PAGE_OUT_TO_SYSTEM_MEMORY, 1);
>   WREG32(mmVM_L2_CNTL, tmp);
>   tmp = REG_SET_FIELD(0, VM_L2_CNTL2, INVALIDATE_ALL_L1_TLBS, 1);
>   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL2, INVALIDATE_L2_CACHE, 1);
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index 7bc9e9f..cb4e2bb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -588,6 +588,7 @@ static int gmc_v8_0_gart_enable(struct amdgpu_device 
> *adev)
>   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, 
> ENABLE_L2_PDE0_CACHE_LRU_UPDATE_BY_WRITE, 1);
>   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, EFFECTIVE_L2_QUEUE_SIZE, 7);
>   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, CONTEXT1_IDENTITY_ACCESS_MODE, 1);
> + tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, 
> ENABLE_DEFAULT_PAGE_OUT_TO_SYSTEM_MEMORY, 1);
>   WREG32(mmVM_L2_CNTL, tmp);
>   tmp = RREG32(mmVM_L2_CNTL2);
>   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL2, INVALIDATE_ALL_L1_TLBS, 1);

[PATCH] drm/amdgpu: Fix default page access routing

[Jay Cornwall]

On 2015-11-06 02:28, Christian König wrote:
> On 05.11.2015 20:06, Jay Cornwall wrote:
>> The VM default page (used when a VM translation fails) is allocated in
>> system memory. The VM is misconfigured to interpret the physical 
>> address
>> as referencing a VRAM physical page.
>> 
>> Route default page accesses to system memory.
>> 
>> Signed-off-by: Jay Cornwall 
>> Cc:  # v4.2+
> 
> Nice catch, patch is Reviewed-by: Christian König 
> 
> 
> Do we also need this for Radeon?

It looks like this field was introduced in CIK. This change could be 
replicated in radeon on those parts, but I haven't got one to test with.

I'm not sure if this misconfiguration is fatal. The default page should 
be used for loads only. I haven't been able to get anything besides 0 
from a faulting load on my Fiji with a system or VRAM default page. A 
physical address > VRAM doesn't seem to cause problems, either.

My primary motivation for this change is to allow HSA to handle faulting 
atomic operations. The KFD exposes a MTYPE=UC aperture to the user which 
allows atomics to be forwarded to system memory, via MC/BIF/PCI. When 
one of these atomic operations faults the MC is unable to handle the 
VRAM atomic (atomics are implemented by TC) and the TC hangs waiting for 
a response.

If the default page is directed towards BIF then the atomic is correctly 
discarded.

-- 
Jay Cornwall

[git pull] vmwgfx-next

[Thomas Hellstrom]

Dave,

One is fix for a regression in 4.3, One irq locking rework.


The following changes since commit b76ff5ea1cf6fe648e7ce2b84e636f8a95849a0b:

  drm/vmwgfx: Replace iowrite/ioread with volatile memory accesses (2015-11-02 
00:16:05 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux vmwgfx-next

for you to fetch changes up to d2e8851a909c76c6f0b34553f2c9993808bc1d58:

  drm/vmwgfx: Relax irq locking somewhat (2015-11-06 16:15:40 +0100)


Thomas Hellstrom (2):
  drm/vmwgfx: Properly flush cursor updates and page-flips
  drm/vmwgfx: Relax irq locking somewhat

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   9 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |  23 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c  | 104 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |   2 +
 6 files changed, 42 insertions(+), 100 deletions(-)

[Bug 92806] 1 second freezes during new effects UT4

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

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

--- Comment #7 from bellamorte42 at gmail.com ---
Are num compilations the same as shader compilations?  Also iirc I had the same
issue on my 6950 system so it might not be radeonsi specific.

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

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #287 from bugs.freedesktop.org at spam.lublink.net ---
The following commands from comment #239 seems to have corrected the issue on
my Raden HD3650 Mobility:

>> echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
>> echo performance > /sys/class/drm/card0/device/power_dpm_state

This seems to be equivalent to the patch in comment #244. Any chance of getting
this patch into the kernel?

If anyone is willing to write a fix, as opposed to a workaround, for this
issue, I would be happy to test it on my device.

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