[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #78 from Dieter Nützel  ---
(In reply to Gustaw Smolarczyk from comment #77)
> No pauses after I applied attachment 166571 [details] and "drm/radeon: do a
> posting read in si_set_irq" from posting-read branch on top of v3.19. So I
> guess these commits combined fix this issue.
> 
> @Dieter: I did not need to apply this patch in order to fix this issue.

Thanks Gustaw!

In the meantime I have it running on r600g/NI/Turks XT with:

drm-next-4.1-wip
+
HDMI fixes from 'audio-fixes'
+
' posting-read'
drm-radeon-do-a-posting-read-in-evergreen_set_irq.patch
drm-radeon-do-a-posting-read-in-r600_set_irq.patch (better more than less...;-)
+
attachment 166571
drm-radeon-fix-wait-to-actually-occur-after-the-signaling-callback.patch
+
drm-radeon-fix-DRM_IOCTL_RADEON_CS-oops.patch

Cheers,
   Dieter

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #77 from Gustaw Smolarczyk  ---
No pauses after I applied attachment 166571 and "drm/radeon: do a posting read
in si_set_irq" from posting-read branch on top of v3.19. So I guess these
commits combined fix this issue.

@Dieter: I did not need to apply this patch in order to fix this issue.

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

[PATCH] drm/i915: Fix modeset state confusion in the load detect code

[Daniel Vetter]

On Tue, Mar 03, 2015 at 09:12:47AM -0800, Linus Torvalds wrote:
> On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter  wrote:
> >
> > Fine with me. If you haven't pushed out yet can you maybe clarify the
> > commit message?
> 
> Oh well. I already applied and tagged it, so it's what it is..

No biggie, the explanation is correct and just glosses a bit over that
detail.  In case someone hit this the other way round and fell all over
plane->fb being freed instead of state->fb. But really unlikely - these
old machines don't tend to run fancy non-X compositors ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/i915: Fix modeset state confusion in the load detect code

[Daniel Vetter]

On Tue, Mar 03, 2015 at 09:03:32AM -0800, Linus Torvalds wrote:
> On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter  
> wrote:
> >
> > Fix this all by applying the same duct-tape as for the legacy setcrtc
> > ioctl code and set crtc->primary->crtc properly.
> 
> Ack. Tests fine on the machine that showed issues for me.
> 
> I'll apply it manually directly to my tree, since I want to release
> rc2 and I was holding that up in the hope this would get released (I
> hate releasing even early rc's with issues that I know about and that
> break machines I have access to).

Fine with me. If you haven't pushed out yet can you maybe clarify the
commit message?

The setcrtc step must be one that disables the crtc, only then will we
(again) skip the book-keeping for plane->state->fb and unref to 0 in the
drm core. If you directly switch to another fb/mode then we'll unref to 0
in the state duplicate and then blow up in the drm core when doing the
unref for plane->old_fb.

But since X generally disable everything before enabling the new config
the previuos one is how we more likely blow up, and hence also why
duplicate_state blows up.

> If it ends up in your tree too and I'll get a duplicate commit later,
> git will sort it all out, so it's fine.

The revert and another patch to make the load detect code testable in an
automated fashion on modern platfroms to avoid another occurence of this
mess are fully independent of this one line. So no conflicts to be
expected.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 90741] Radeon: System pauses on TAHITI

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

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

Dieter Nützel  changed:

   What|Removed |Added

 CC||Dieter at nuetzel-hh.de

--- Comment #76 from Dieter Nützel  ---
Hello Maarten,

is https://bugzilla.kernel.org/attachment.cgi?id=168581
needed or obsolete with Alex's patches?

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

[PATCH] Revert "drm/i915: Switch planes from transitional helpers to full atomic helpers"

[Daniel Vetter]

On Mon, Mar 02, 2015 at 04:35:20PM +0100, Daniel Vetter wrote:
> This reverts commit 3f678c96abb43a977d2ea41aefccdc49e8a3e896.
> 
> We've been a bit too optimistic with this one here :(
> 
> The trouble is that internally we're still using these plane
> update/disable hooks. Which was totally ok pre-atomic since the drm
> core did all the book-keeping updating and these just mostly updated
> hw state. But with atomic there's lots more going on, and it causes
> heaps of trouble with the load detect code.
> 
> This one specifically cause a deadlock since both the load detect code
> and the nested plane atomic helper functions tried to grab the same
> locks. It only blows up because of the evil tricks though we play with
> the implicit ww acquire context.
> 
> Applying this revert unearths the NULL deref on already freed
> framebuffer objects reported as a regression in 4.0 by various people.
> 
> Fixing this will be fairly invasive, hence revert even for the
> 4.1-next queue.
> 
> Cc: Matt Roper 
> Cc: Linus Torvalds 
> Cc: Paul Bolle 
> Signed-off-by: Daniel Vetter 

Queued for -next with Matt's ack.
-Daniel
> ---
> Just to make it really clear: This is 4.1-next material. It's simply
> the explanation for why we didn't notice the oops ourselves. The 4.0
> oops itself looks like some glue lacking in the load detect code,
> still working on that one.
> -Daniel
> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 3156d77b2215..cc3305e30c1b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12179,8 +12179,8 @@ void intel_plane_destroy(struct drm_plane *plane)
>  }
>  
>  const struct drm_plane_funcs intel_plane_funcs = {
> - .update_plane = drm_atomic_helper_update_plane,
> - .disable_plane = drm_atomic_helper_disable_plane,
> + .update_plane = drm_plane_helper_update,
> + .disable_plane = drm_plane_helper_disable,
>   .destroy = intel_plane_destroy,
>   .set_property = drm_atomic_helper_plane_set_property,
>   .atomic_get_property = intel_plane_atomic_get_property,
> -- 
> 1.8.4.rc3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/i915: Fix modeset state confusion in the load detect code

[Daniel Vetter]

This is a tricky story of the new atomic state handling and the legacy
code fighting over each another. The bug at hand is an underrun of the
framebuffer reference with subsequent hilarity caused by the load
detect code. Which is peculiar since the the exact same code works
fine as the implementation of the legacy setcrtc ioctl.

Let's look at the ingredients:

- Currently our code is a crazy mix of legacy modeset interfaces to
  set the parameters and half-baked atomic state tracking underneath.
  While this transition is going we're using the transitional plane
  helpers to update the atomic side (drm_plane_helper_disable/update
  and friends), i.e. plane->state->fb. Since the state structure owns
  the fb those functions take care of that themselves.

  The legacy state (specifically crtc->primary->fb) is still managed
  by the old code (and mostly by the drm core), with the fb reference
  counting done by callers (core drm for the ioctl or the i915 load
  detect code). The relevant commit is

  commit ea2c67bb4affa84080c616920f3899f123786e56
  Author: Matt Roper 
  Date:   Tue Dec 23 10:41:52 2014 -0800

  drm/i915: Move to atomic plane helpers (v9)

- drm_plane_helper_disable has special code to handle multiple calls
  in a row - it checks plane->crtc == NULL and bails out. This is to
  match the proper atomic implementation which needs the crtc to get
  at the implied locking context atomic updates always need. See

  commit acf24a395c5a9290189b080383564437101d411c
  Author: Daniel Vetter 
  Date:   Tue Jul 29 15:33:05 2014 +0200

  drm/plane-helper: transitional atomic plane helpers

- The universal plane code split out the implicit primary plane from
  the CRTC into it's own full-blown drm_plane object. As part of that
  the setcrtc ioctl (which updated both the crtc mode and primary
  plane) learned to set crtc->primary->crtc on modeset to make sure
  the plane->crtc assignments statate up to date in

  commit e13161af80c185ecd8dc4641d0f5df58f9e3e0af
  Author: Matt Roper 
  Date:   Tue Apr 1 15:22:38 2014 -0700

  drm: Add drm_crtc_init_with_planes() (v2)

  Unfortunately we've forgotten to update the load detect code. Which
  wasn't a problem since the load detect modeset is temporary and
  always undone before we drop the locks.

- Finally there is a organically grown history (i.e. don't ask) around
  who sets the legacy plane->fb for the various driver entry points.
  Originally updating that was the drivers duty, but for almost all
  places we've moved that (plus updating the refcounts) into the core.
  Again the exception is the load detect code.

Taking all together the following happens:
- The load detect code doesn't set crtc->primary->crtc. This is only
  really an issue on crtcs never before used or when userspace
  explicitly disabled the primary plane.

- The plane helper glue code short-circuits because of that and leaves
  a non-NULL fb behind in plane->state->fb and plane->fb. The state
  fb isn't a real problem (it's properly refcounted on its own), it's
  just the canary.

- Load detect code drops the reference for that fb, but doesn't set
  plane->fb = NULL. This is ok since it's still living in that old
  world where drivers had to clear the pointer but the core/callers
  handled the refcounting.

- On the next modeset the drm core notices plane->fb and takes care of
  refcounting it properly by doing another unref. This drops the
  refcount to zero, leaving state->plane now pointing at freed memory.

- intel_plane_duplicate_state still assume it owns a reference to that
  very state->fb and bad things start to happen.

Fix this all by applying the same duct-tape as for the legacy setcrtc
ioctl code and set crtc->primary->crtc properly.

Cc: Matt Roper 
Cc: Linus Torvalds 
Cc: Paul Bolle 
Cc: Rob Clark 
Cc: Paulo Zanoni 
Cc: Sean Paul 
Cc: Matt Roper 
Reported-by: Linus Torvalds 
Reported-by: Paul Bolle 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cc3305e30c1b..d116caf98a72 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8859,6 +8859,7 @@ retry:
old->release_fb->funcs->destroy(old->release_fb);
goto fail;
}
+   crtc->primary->crtc = crtc;

/* let the connector get through one full cycle before testing */
intel_wait_for_vblank(dev, intel_crtc->pipe);
-- 
2.1.4

[Bug 89374] Firefox smooth scrolling isn't smooth

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

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

--- Comment #4 from sunweb at hotmail.ru ---
No difference. Also i may took a wrong wording. Smooth scrolling can be enabled
but its not as smooth as it should be. Also i've recentley saw ff on windows
machine and it also has some animation when you press on Open Menu and far
better animation when you're going to/out Tab Groups. Those animations don't
exist on my machine. Maybe thats Firefox issue after all.

-- 
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/20150303/65c9ddc3/attachment.html>

[PATCH v5 09/11] drm/tegra: Reset the SOR on probe

[Alexandre Courbot]

On Tue, Mar 3, 2015 at 12:46 AM, Simon Glass  wrote:
> Hi,
>
> On 2 March 2015 at 01:41, Alexandre Courbot  wrote:
>>
>> On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso
>>  wrote:
>> > As there isn't a way for the firmware on the Nyan chromebooks to hand
>> > over the display to the kernel.
>>
>> Could this have a side-effect on models for which the firmware *does*
>> hand over the display to the kernel? E.g. temporary glitch or black
>> screen?
>>
>> This is probably ok though, as such a handing over would need to be
>> documented in the firmware/kernel command line, and could thus be
>> caught to disable that code block if needed.
>
> Is there a general way in which this hand-over is done, e.g. with a
> device tree binding?

simple-framebuffer has bindings that describe a framebuffer handed
over by the firmware, and they look like the right way to describe
this. simplefb however is a framebuffer driver - a DRM driver would
need to seamlessly take over the display at some point and disable
simplefb. I don't know if this is possible at the moment.

Or maybe the DRM framework could look for a simple-framebuffer
compatible node, extract the framebuffer information, and pass it to
DRM drivers at probe time. That supposes a kernel in which
simple-framebuffer is not compiled in to prevent it from taking over
the display.

[GIT PULL FOR v4.1] R-Car DU Atomic Updates

[Laurent Pinchart]

Hi Dave,

The following changes since commit 329414c4e7b7506fe3eab545b3fc9e44b7f28a10:

  Merge tag 'topic/drm-misc-2015-02-25' of git://anongit.freedesktop.org/drm-
intel into drm-next (2015-02-26 10:32:55 +1000)

are available in the git repository at:

  git://linuxtv.org/pinchartl/fbdev.git drm/next/atomic

for you to fetch changes up to 5ee5a81df57ea3a19a5e306fdf8244ab696c8916:

  drm: rcar-du: Fix race condition in hardware plane allocator (2015-03-03 
16:16:30 +0200)


Laurent Pinchart (32):
  drm: rcar-du: Don't disable unused functions at init time
  drm: rcar-du: Remove drm_fbdev_cma_restore_mode() call at init time
  drm: rcar-du: Don't set connector->encoder at init time
  drm: rcar-du: Reorder CRTC functions
  drm: rcar-du: Wait for page flip completion when turning the CRTC off
  drm: rcar-du: Turn vblank on/off when enabling/disabling CRTC
  drm: rcar-du: Disable fbdev emulation when no connector is present
  drm: rcar-du: Define macros for the max number of groups, CRTCs and LVDS
  drm: rcar-du: Implement universal plane support
  drm: rcar-du: Fix hardware plane allocation
  drm: rcar-du: Implement planes atomic operations
  drm: rcar-du: Handle primary plane config through atomic plane ops
  drm: rcar-du: Wire up atomic state object scaffolding
  drm: rcar-du: Remove private copy of plane size and position
  drm: rcar-du: Replace LVDS encoder DPMS by enable/disable
  drm: rcar-du: Rework encoder enable/disable for atomic updates
  drm: rcar-du: Rework HDMI encoder enable/disable for atomic updates
  drm: rcar-du: Rework CRTC enable/disable for atomic updates
  drm: rcar-du: Switch plane update to atomic helpers
  drm: rcar-du: Switch mode config to atomic helpers
  drm: rcar-du: Switch connector DPMS to atomic helpers
  drm: rcar-du: Replace encoder mode_fixup with atomic_check
  drm: rcar-du: Implement asynchronous commit support
  drm: rcar-du: Switch page flip to atomic helpers
  drm: rcar-du: Switch plane set_property to atomic helpers
  drm: rcar-du: Rework plane setup code
  drm: rcar-du: Replace plane crtc and enabled fields by plane state
  drm: rcar-du: Remove unneeded rcar_du_crtc plane field
  drm: rcar-du: Move plane format to plane state
  drm: rcar-du: Move plane commit code from CRTC start to CRTC resume
  drm: rcar-du: Move group locking inside rcar_du_crtc_update_planes()
  drm: rcar-du: Fix race condition in hardware plane allocator

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 400 ++---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h|   8 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  17 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |  16 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  71 +++
 drivers/gpu/drm/rcar-du/rcar_du_group.h   |   5 +
 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c |  65 +++---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 333 +++--
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  18 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |   8 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   | 419 +
 drivers/gpu/drm/rcar-du/rcar_du_plane.h   |  69 +++
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |   9 +-
 15 files changed, 822 insertions(+), 634 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH] drm: adv7511: Refactor power management

[Lars-Peter Clausen]

On 03/02/2015 02:19 PM, Laurent Pinchart wrote:
> From: Laurent Pinchart 
>
> Remove the internal dependency on DPMS mode for power management by
> using a by a powered state boolean instead, and use the new power off
> handler at probe time. This ensure that the regmap cache is properly
> marked as dirty when the device is probed, and the registers properly
> synced during the first power up.
>
> As a side effect this removes the initialization of current_edid_segment
> at probe time, as the field will be initialized when the device is
> powered on, at the latest right before reading EDID data.
>
> Signed-off-by: Laurent Pinchart 

Tested-by: Lars-Peter Clausen 
Acked-by: Lars-Peter Clausen 

Thanks.

eDP display control registers in Linux kernel

[Jani Nikula]

On Sat, 28 Feb 2015, Michael Leuchtenburg  wrote:
> No changes, even while the brightness is in the process of changing. Is it
> possible there's some other bit used on this hardware? The Broadwell chips
> are pretty new. I haven't had a chance to look for specs yet.

The DPCD info is specific to your panel, not the platform.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 3/3] RFC: dts: ifc6410: add splash screen carveout

[Rob Clark]

Add a reserved-memory region for bootloader splashscreen, and assign it
to the display device, so that drm/msm can take over the bootloader's
splashscreen.

Signed-off-by: Rob Clark 
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 416f3f5..0928129 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -15,6 +15,16 @@
0x9000 0x7000>;
};

+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   splashmem: framebuffer at 9000 {
+   reg = <0x9000 0x80>;
+   };
+   };
+
aliases {
serial0 = 
serial1 = 
@@ -183,5 +193,9 @@

};
};
+
+   mdp: qcom,mdp at 510 {
+   memory-region = <>;
+   };
};
 };
-- 
2.1.0

[PATCH 2/3] drm/msm: add support for "stolen" mem

[Rob Clark]

Add support to use the VRAM carveout (if specified in dtb) for fbdev
scanout buffer.  This allows drm/msm to take over a bootloader splash-
screen, and avoids corruption on screen that results if the kernel uses
memory that is still being scanned out for itself.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_drv.c   | 44 +
 drivers/gpu/drm/msm/msm_fbdev.c |  3 ++-
 drivers/gpu/drm/msm/msm_gem.c   | 25 ++-
 drivers/gpu/drm/msm/msm_gem.h   |  5 -
 4 files changed, 66 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index b250610..0c38f34 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -182,21 +182,57 @@ static int get_mdp_ver(struct platform_device *pdev)
return 4;
 }

+#include 
+
 static int msm_init_vram(struct drm_device *dev)
 {
struct msm_drm_private *priv = dev->dev_private;
+   unsigned long size = 0;
+   int ret = 0;
+
+#ifdef CONFIG_OF
+   /* In the device-tree world, we could have a 'memory-region'
+* phandle, which gives us a link to our "vram".  Allocating
+* is all nicely abstracted behind the dma api, but we need
+* to know the entire size to allocate it all in one go. There
+* are two cases:
+*  1) device with no IOMMU, in which case we need exclusive
+* access to a VRAM carveout big enough for all gpu
+* buffers
+*  2) device with IOMMU, but where the bootloader puts up
+* a splash screen.  In this case, the VRAM carveout
+* need only be large enough for fbdev fb.  But we need
+* exclusive access to the buffer to avoid the kernel
+* using those pages for other purposes (which appears
+* as corruption on screen before we have a chance to
+* load and do initial modeset)
+*/
+   struct device_node *node;
+
+   node = of_parse_phandle(dev->dev->of_node, "memory-region", 0);
+   if (node) {
+   struct resource r;
+   ret = of_address_to_resource(node, 0, );
+   if (ret)
+   return ret;
+   size = r.end - r.start;
+   DRM_INFO("using VRAM carveout: %lx@%08x\n", size, r.start);
+   } else
+#endif

/* if we have no IOMMU, then we need to use carveout allocator.
 * Grab the entire CMA chunk carved out in early startup in
 * mach-msm:
 */
if (!iommu_present(_bus_type)) {
+   DRM_INFO("using %s VRAM carveout\n", vram);
+   size = memparse(vram, NULL);
+   }
+
+   if (size) {
DEFINE_DMA_ATTRS(attrs);
-   unsigned long size;
void *p;

-   DBG("using %s VRAM carveout", vram);
-   size = memparse(vram, NULL);
priv->vram.size = size;

drm_mm_init(>vram.mm, 0, (size >> PAGE_SHIFT) - 1);
@@ -220,7 +256,7 @@ static int msm_init_vram(struct drm_device *dev)
(uint32_t)(priv->vram.paddr + size));
}

-   return 0;
+   return ret;
 }

 static int msm_load(struct drm_device *dev, unsigned long flags)
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index df60f65..95f6532 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -110,7 +110,8 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
DBG("allocating %d bytes for fb %d", size, dev->primary->index);
mutex_lock(>struct_mutex);
-   fbdev->bo = msm_gem_new(dev, size, MSM_BO_SCANOUT | MSM_BO_WC);
+   fbdev->bo = msm_gem_new(dev, size, MSM_BO_SCANOUT |
+   MSM_BO_WC | MSM_BO_STOLEN);
mutex_unlock(>struct_mutex);
if (IS_ERR(fbdev->bo)) {
ret = PTR_ERR(fbdev->bo);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 49dea4f..479d8af 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -32,6 +32,12 @@ static dma_addr_t physaddr(struct drm_gem_object *obj)
priv->vram.paddr;
 }

+static bool use_pages(struct drm_gem_object *obj)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   return !msm_obj->vram_node;
+}
+
 /* allocate pages from VRAM carveout, used when no IOMMU: */
 static struct page **get_pages_vram(struct drm_gem_object *obj,
int npages)
@@ -72,7 +78,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
struct page **p;
int npages = obj->size >> PAGE_SHIFT;

-   if (iommu_present(_bus_type))
+   if (use_pages(obj))
p = drm_gem_get_pages(obj);
else
p = get_pages_vram(obj, 

[PATCH 1/3] drm/msm: split out vram initialization

[Rob Clark]

We'll want to extend this a bit to handle also a reserved-memory
("stolen") region, so that drm/msm can take-over bootloader splash
screen.  First split it out into it's own fxn to reduce noise in
the following patch.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_drv.c | 58 +--
 1 file changed, 34 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index a426911..b250610 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -182,29 +182,9 @@ static int get_mdp_ver(struct platform_device *pdev)
return 4;
 }

-static int msm_load(struct drm_device *dev, unsigned long flags)
+static int msm_init_vram(struct drm_device *dev)
 {
-   struct platform_device *pdev = dev->platformdev;
-   struct msm_drm_private *priv;
-   struct msm_kms *kms;
-   int ret;
-
-   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-   if (!priv) {
-   dev_err(dev->dev, "failed to allocate private data\n");
-   return -ENOMEM;
-   }
-
-   dev->dev_private = priv;
-
-   priv->wq = alloc_ordered_workqueue("msm", 0);
-   init_waitqueue_head(>fence_event);
-   init_waitqueue_head(>pending_crtcs_event);
-
-   INIT_LIST_HEAD(>inactive_list);
-   INIT_LIST_HEAD(>fence_cbs);
-
-   drm_mode_config_init(dev);
+   struct msm_drm_private *priv = dev->dev_private;

/* if we have no IOMMU, then we need to use carveout allocator.
 * Grab the entire CMA chunk carved out in early startup in
@@ -232,8 +212,7 @@ static int msm_load(struct drm_device *dev, unsigned long 
flags)
if (!p) {
dev_err(dev->dev, "failed to allocate VRAM\n");
priv->vram.paddr = 0;
-   ret = -ENOMEM;
-   goto fail;
+   return -ENOMEM;
}

dev_info(dev->dev, "VRAM: %08x->%08x\n",
@@ -241,6 +220,37 @@ static int msm_load(struct drm_device *dev, unsigned long 
flags)
(uint32_t)(priv->vram.paddr + size));
}

+   return 0;
+}
+
+static int msm_load(struct drm_device *dev, unsigned long flags)
+{
+   struct platform_device *pdev = dev->platformdev;
+   struct msm_drm_private *priv;
+   struct msm_kms *kms;
+   int ret;
+
+   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+   if (!priv) {
+   dev_err(dev->dev, "failed to allocate private data\n");
+   return -ENOMEM;
+   }
+
+   dev->dev_private = priv;
+
+   priv->wq = alloc_ordered_workqueue("msm", 0);
+   init_waitqueue_head(>fence_event);
+   init_waitqueue_head(>pending_crtcs_event);
+
+   INIT_LIST_HEAD(>inactive_list);
+   INIT_LIST_HEAD(>fence_cbs);
+
+   drm_mode_config_init(dev);
+
+   ret = msm_init_vram(dev);
+   if (ret)
+   goto fail;
+
platform_set_drvdata(pdev, dev);

/* Bind all our sub-components: */
-- 
2.1.0

[PATCH 1/8] drm: Pass in new and old plane state to prepare_fb and cleanup_fb

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Use cases like rotation require these hooks to have some context so they
know how to prepare and cleanup the frame buffer correctly.

For i915 specifically, object backing pages need to be mapped differently
for different rotation modes and the driver needs to know which mapping to
instantiate and which to tear down when transitioning between them.

v2: Made passed in states const. (Daniel Vetter)

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_atomic_helper.c   | 13 -
 drivers/gpu/drm/drm_plane_helper.c|  5 +++--
 drivers/gpu/drm/i915/intel_display.c  |  6 --
 drivers/gpu/drm/i915/intel_drv.h  |  6 --
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c |  6 --
 drivers/gpu/drm/tegra/dc.c|  6 --
 include/drm/drm_plane_helper.h|  6 --
 7 files changed, 31 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3ce57f4..a745881 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1116,6 +1116,7 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
*dev,
for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
+   struct drm_plane_state *plane_state = state->plane_states[i];
struct drm_framebuffer *fb;

if (!plane)
@@ -1123,10 +1124,10 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
*dev,

funcs = plane->helper_private;

-   fb = state->plane_states[i]->fb;
+   fb = plane_state->fb;

if (fb && funcs->prepare_fb) {
-   ret = funcs->prepare_fb(plane, fb);
+   ret = funcs->prepare_fb(plane, fb, plane_state);
if (ret)
goto fail;
}
@@ -1138,6 +1139,7 @@ fail:
for (i--; i >= 0; i--) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
+   struct drm_plane_state *plane_state = state->plane_states[i];
struct drm_framebuffer *fb;

if (!plane)
@@ -1148,7 +1150,7 @@ fail:
fb = state->plane_states[i]->fb;

if (fb && funcs->cleanup_fb)
-   funcs->cleanup_fb(plane, fb);
+   funcs->cleanup_fb(plane, fb, plane_state);

}

@@ -1254,6 +1256,7 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
*dev,
for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = old_state->planes[i];
+   struct drm_plane_state *plane_state = 
old_state->plane_states[i];
struct drm_framebuffer *old_fb;

if (!plane)
@@ -1261,10 +1264,10 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
*dev,

funcs = plane->helper_private;

-   old_fb = old_state->plane_states[i]->fb;
+   old_fb = plane_state->fb;

if (old_fb && funcs->cleanup_fb)
-   funcs->cleanup_fb(plane, old_fb);
+   funcs->cleanup_fb(plane, old_fb, plane_state);
}
 }
 EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 5ba5792..813a066 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -437,7 +437,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,

if (plane_funcs->prepare_fb && plane_state->fb &&
plane_state->fb != old_fb) {
-   ret = plane_funcs->prepare_fb(plane, plane_state->fb);
+   ret = plane_funcs->prepare_fb(plane, plane_state->fb,
+ plane_state);
if (ret)
goto out;
}
@@ -487,7 +488,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
}

if (plane_funcs->cleanup_fb && old_fb)
-   plane_funcs->cleanup_fb(plane, old_fb);
+   plane_funcs->cleanup_fb(plane, old_fb, plane_state);
 out:
if (plane_state) {
if (plane->funcs->atomic_destroy_state)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3156d77..abeef74 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11891,7 +11891,8 @@ static void intel_shared_dpll_init(struct drm_device 
*dev)
  */
 int
 intel_prepare_plane_fb(struct drm_plane *plane,
-  struct drm_framebuffer *fb)
+  struct drm_framebuffer *fb,
+  

[Bug 94171] ati multihead black on one output

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

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

--- Comment #1 from Alex Deucher  ---
Created attachment 168731
  --> https://bugzilla.kernel.org/attachment.cgi?id=168731=edit
possible fix

Please make sure your kernel has this patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=72edd83cc9e5819ed1ee771519143d7594e059f0

Then apply this kernel patch on top of it.

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

[PATCH] drm/rockchip: Flip select/depends in Kconfig

[Jani Nikula]

[fix address for linux-kbuild at vger.kernel.org, sorry for the noise]

On Tue, 03 Mar 2015, Jani Nikula  wrote:
> On Tue, 03 Mar 2015, Daniel Vetter  wrote:
>> Otherwise Kconfig gets confused and somehow ends up creating a 2nd drm
>> submenu. I couldn't find i915 because of this any more at first.
>
> This is not it. I bisected it to
>
> commit db88c8f4e7e1d1c9e82bc5645a537782b8836cc0
> Author: Chen Gang S 
> Date:   Sun Feb 1 22:08:33 2015 +0800
>
> drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on 
> HAVE_DMA_ATTRS
>
> and reverting fixes the issue.
>
> BR,
> Jani.
>
>
>>
>> Cc: Andy Yan 
>> Cc: Russell King 
>> Cc: Philipp Zabel 
>> Cc: "Yann E. MORIN" 
>> Cc: linux-kbuild at vger.kernel.or
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/rockchip/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
>> b/drivers/gpu/drm/rockchip/Kconfig
>> index cb21e3821244..959088695da4 100644
>> --- a/drivers/gpu/drm/rockchip/Kconfig
>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>> @@ -17,8 +17,8 @@ config DRM_ROCKCHIP
>>  
>>  config ROCKCHIP_DW_HDMI
>>  tristate "Rockchip specific extensions for Synopsys DW HDMI"
>> -depends on DRM_ROCKCHIP
>>  select DRM_DW_HDMI
>> +depends on DRM_ROCKCHIP
>>  help
>>This selects support for Rockchip SoC specific extensions
>>for the Synopsys DesignWare HDMI driver. If you want to
>> -- 
>> 2.1.4
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] rnndb: Prepare for more interfaces support (WB, DSI)

[Stephane Viau]

More interfaces are soon coming into picture; rework the
interface type a bit in order to make the code more clear.
Ping Pong interrupts are not directly linked to an interface number.
This change removes the INTFn prefix for Ping Pong interrupts.
Also rename some fields linked to WB paths.

Signed-off-by: Stephane Viau 
---
 rnndb/mdp/mdp5.xml | 67 +++---
 1 file changed, 33 insertions(+), 34 deletions(-)

diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml
index 3c199a1..4d9781c 100644
--- a/rnndb/mdp/mdp5.xml
+++ b/rnndb/mdp/mdp5.xml
@@ -11,11 +11,15 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

 

-   
+   
+   




+   
+   
+   



@@ -44,11 +48,11 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-   
-   
+   
+   
+   
+   
+   



@@ -110,30 +114,25 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   



@@ -165,10 +164,10 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-   
+   
+   
+   
+   



-- 
Qualcomm Innovation Center, Inc.

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

[PATCH 4/4] drm/msm/mdp5: Make the intf connection in config module

[Stephane Viau]

Up until now, we assume that eDP is tight to intf_0 and HDMI to
intf_3. This information shall actually come from the mdp5_cfg
module since it can change from one chip to another.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   8 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |   4 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 111 ++--
 3 files changed, 74 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 72c075a..8bee023 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -62,6 +62,10 @@ const struct mdp5_cfg_hw msm8x74_config = {
.count = 4,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
},
+   .intfs = {
+   [0] = INTF_eDP,
+   [3] = INTF_HDMI,
+   },
.max_clk = 2,
 };

@@ -111,6 +115,10 @@ const struct mdp5_cfg_hw apq8084_config = {
.count = 5,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
},
+   .intfs = {
+   [0] = INTF_eDP,
+   [3] = INTF_HDMI,
+   },
.max_clk = 32000,
 };

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index be149b3..4e91f14 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -58,6 +58,8 @@ struct mdp5_smp_block {
int reserved[MAX_CLIENTS];  /* # of MMBs allocated per client */
 };

+#define MDP5_INTF_NUM_MAX  5
+
 struct mdp5_cfg_hw {
char  *name;

@@ -71,6 +73,8 @@ struct mdp5_cfg_hw {
struct mdp5_sub_block ad;
struct mdp5_sub_block intf;

+   u32 intfs[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */
+
uint32_t max_clk;
 };

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 390d9d2..8cec00e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -161,6 +161,44 @@ int mdp5_enable(struct mdp5_kms *mdp5_kms)
return 0;
 }

+static int construct_encoder(struct mdp5_kms *mdp5_kms,
+   enum mdp5_intf_type intf_type, int intf_num)
+{
+   struct drm_device *dev = mdp5_kms->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+   struct drm_encoder *encoder;
+   struct mdp5_interface intf = {
+   .num= intf_num,
+   .type   = intf_type,
+   .mode   = MDP5_INTF_MODE_NONE,
+   };
+   int ret = 0;
+
+   encoder = mdp5_encoder_init(dev, );
+   if (IS_ERR(encoder)) {
+   ret = PTR_ERR(encoder);
+   dev_err(dev->dev, "failed to construct encoder: %d\n", ret);
+   return ret;
+   }
+
+   encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
+   priv->encoders[priv->num_encoders++] = encoder;
+
+   if (intf_type == INTF_HDMI) {
+   ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
+   if (ret)
+   dev_err(dev->dev, "failed to init HDMI: %d\n", ret);
+
+   } else if (intf_type == INTF_eDP) {
+   /* Construct bridge/connector for eDP: */
+   ret = msm_edp_modeset_init(priv->edp, dev, encoder);
+   if (ret)
+   dev_err(dev->dev, "failed to init eDP: %d\n", ret);
+   }
+
+   return ret;
+}
+
 static int modeset_init(struct mdp5_kms *mdp5_kms)
 {
static const enum mdp5_pipe crtcs[] = {
@@ -171,7 +209,6 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
};
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
-   struct drm_encoder *encoder;
const struct mdp5_cfg_hw *hw_cfg;
int i, ret;

@@ -222,56 +259,29 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
}
}

-   if (priv->hdmi) {
-   struct mdp5_interface intf = {
-   .num= 3,
-   .type   = INTF_HDMI,
-   .mode   = MDP5_INTF_MODE_NONE,
-   };
-
-   /* Construct encoder for HDMI: */
-   encoder = mdp5_encoder_init(dev, );
-   if (IS_ERR(encoder)) {
-   dev_err(dev->dev, "failed to construct encoder\n");
-   ret = PTR_ERR(encoder);
-   goto fail;
-   }
-
-   encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;;
-   priv->encoders[priv->num_encoders++] = encoder;
-
-   ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
-   if (ret) {
-   dev_err(dev->dev, "failed to initialize HDMI: %d\n", 
ret);
-   goto fail;
-   }
- 

[PATCH 3/4] drm/msm/mdp5: Add START signal to kick off certain pipelines

[Stephane Viau]

Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |   7 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  31 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 247 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h |  72 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  13 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   1 +
 7 files changed, 276 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index c078f30..72c075a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -31,6 +31,7 @@ const struct mdp5_cfg_hw msm8x74_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   .flush_hw_mask = 0x0003,
},
.pipe_vig = {
.count = 3,
@@ -78,6 +79,7 @@ const struct mdp5_cfg_hw apq8084_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   .flush_hw_mask = 0x003f,
},
.pipe_vig = {
.count = 4,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index be587b8..be149b3 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -46,6 +46,11 @@ struct mdp5_lm_block {
uint32_t nb_stages; /* number of stages per blender */
 };

+struct mdp5_ctl_block {
+   MDP5_SUB_BLOCK_DEFINITION;
+   uint32_t flush_hw_mask; /* FLUSH register's hardware mask */
+};
+
 struct mdp5_smp_block {
int mmb_count;  /* number of SMP MMBs */
int mmb_size;   /* MMB: size in bytes */
@@ -57,7 +62,7 @@ struct mdp5_cfg_hw {
char  *name;

struct mdp5_smp_block smp;
-   struct mdp5_sub_block ctl;
+   struct mdp5_ctl_block ctl;
struct mdp5_sub_block pipe_vig;
struct mdp5_sub_block pipe_rgb;
struct mdp5_sub_block pipe_dma;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 15136f1..9527ad1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -82,8 +82,6 @@ static void request_pending(struct drm_crtc *crtc, uint32_t 
pending)
mdp_irq_register(_kms(crtc)->base, _crtc->vblank);
 }

-#define mdp5_lm_get_flush(lm)  mdp_ctl_flush_mask_lm(lm)
-
 static void crtc_flush(struct drm_crtc *crtc, u32 flush_mask)
 {
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
@@ -110,8 +108,8 @@ static void crtc_flush_all(struct drm_crtc *crtc)
drm_atomic_crtc_for_each_plane(plane, crtc) {
flush_mask |= mdp5_plane_get_flush(plane);
}
-   flush_mask |= mdp5_ctl_get_flush(mdp5_crtc->ctl);
-   flush_mask |= mdp5_lm_get_flush(mdp5_crtc->lm);
+
+   flush_mask |= mdp_ctl_flush_mask_lm(mdp5_crtc->lm);

crtc_flush(crtc, flush_mask);
 }
@@ -442,13 +440,14 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct mdp5_kms *mdp5_kms = get_kms(crtc);
-   struct drm_gem_object *cursor_bo, *old_bo;
+   struct drm_gem_object *cursor_bo, *old_bo = NULL;
uint32_t blendcfg, cursor_addr, stride;
int ret, bpp, lm;
unsigned int depth;
enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
uint32_t flush_mask = mdp_ctl_flush_mask_cursor(0);
uint32_t roi_w, roi_h;
+   bool cursor_enable = true;
unsigned long flags;

if ((width > CURSOR_WIDTH) || (height > CURSOR_HEIGHT)) {
@@ -461,7 +460,8 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,

if (!handle) {
DBG("Cursor off");
-   return mdp5_ctl_set_cursor(mdp5_crtc->ctl, false);
+   cursor_enable = false;
+   goto set_cursor;
}

cursor_bo = drm_gem_object_lookup(dev, file, handle);
@@ -502,11 +502,14 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,

spin_unlock_irqrestore(_crtc->cursor.lock, flags);

-   ret = mdp5_ctl_set_cursor(mdp5_crtc->ctl, true);
-   if (ret)
+set_cursor:
+   ret = mdp5_ctl_set_cursor(mdp5_crtc->ctl, 0, cursor_enable);
+   if (ret) {
+   dev_err(dev->dev, "failed to %sable cursor: %d\n",
+   cursor_enable ? "en" : "dis", 

[PATCH 2/4] drm/msm/mdp5: Enhance operation mode for pipeline configuration

[Stephane Viau]

DSI and WB interfaces need a more complex pipeline configuration
than the current mdp5_ctl_set_intf().

For example, memory output connections need to be selected for
WB. Interface mode (Video vs. Command modes) also need to be
configured for DSI.

This change takes care of configuring the whole pipeline as far
as operation mode goes. DSI and WB interfaces will be added
later.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 39 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 91 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h |  3 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 29 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 16 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 48 ---
 7 files changed, 157 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index dba4d52..be587b8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -31,6 +31,8 @@ extern const struct mdp5_cfg_hw *mdp5_cfg;

 typedef DECLARE_BITMAP(mdp5_smp_state_t, MAX_SMP_BLOCKS);

+#define MDP5_INTF_IS_VIRTUAL_DISPLAY(intf_type)   ((intf_type) >= INTF_VIRTUAL)
+
 #define MDP5_SUB_BLOCK_DEFINITION \
int count; \
uint32_t base[MAX_BASES]
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index bfba236..15136f1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -611,48 +611,17 @@ void mdp5_crtc_cancel_pending_flip(struct drm_crtc *crtc, 
struct drm_file *file)
 }

 /* set interface for routing crtc->encoder: */
-void mdp5_crtc_set_intf(struct drm_crtc *crtc, int intf,
-   enum mdp5_intf intf_id)
+void mdp5_crtc_set_intf(struct drm_crtc *crtc, struct mdp5_interface *intf)
 {
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_kms *mdp5_kms = get_kms(crtc);
-   uint32_t intf_sel;
-   unsigned long flags;
+   int lm = mdp5_crtc_get_lm(crtc);

/* now that we know what irq's we want: */
-   mdp5_crtc->err.irqmask = intf2err(intf);
-   mdp5_crtc->vblank.irqmask = intf2vblank(intf);
+   mdp5_crtc->err.irqmask = intf2err(intf->num);
+   mdp5_crtc->vblank.irqmask = intf2vblank(lm, intf);
mdp_irq_update(_kms->base);

-   spin_lock_irqsave(_kms->resource_lock, flags);
-   intf_sel = mdp5_read(mdp5_kms, REG_MDP5_DISP_INTF_SEL);
-
-   switch (intf) {
-   case 0:
-   intf_sel &= ~MDP5_DISP_INTF_SEL_INTF0__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF0(intf_id);
-   break;
-   case 1:
-   intf_sel &= ~MDP5_DISP_INTF_SEL_INTF1__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF1(intf_id);
-   break;
-   case 2:
-   intf_sel &= ~MDP5_DISP_INTF_SEL_INTF2__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF2(intf_id);
-   break;
-   case 3:
-   intf_sel &= ~MDP5_DISP_INTF_SEL_INTF3__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF3(intf_id);
-   break;
-   default:
-   BUG();
-   break;
-   }
-
-   mdp5_write(mdp5_kms, REG_MDP5_DISP_INTF_SEL, intf_sel);
-   spin_unlock_irqrestore(_kms->resource_lock, flags);
-
-   DBG("%s: intf_sel=%08x", mdp5_crtc->name, intf_sel);
mdp5_ctl_set_intf(mdp5_crtc->ctl, intf);
 }

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index 1511290..3e88bb7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -33,6 +33,16 @@
  * requested by the client (in mdp5_crtc_mode_set()).
  */

+struct op_mode {
+   struct mdp5_interface intf;
+   /*
+* TODO: add a state variable to control the pipeline
+*
+* eg: WB interface needs both buffer addresses to be committed +
+* output buffers ready to be written into, before we can START.
+*/
+};
+
 struct mdp5_ctl {
struct mdp5_ctl_manager *ctlm;

@@ -41,8 +51,8 @@ struct mdp5_ctl {
/* whether this CTL has been allocated or not: */
bool busy;

-   /* memory output connection (@see mdp5_ctl_mode): */
-   u32 mode;
+   /* Operation Mode Configuration for the Pipeline */
+   struct op_mode pipeline;

/* REG_MDP5_CTL_*() registers access info + lock: */
spinlock_t hw_lock;
@@ -94,19 +104,81 @@ u32 ctl_read(struct mdp5_ctl *ctl, u32 reg)
return mdp5_read(mdp5_kms, reg);
 }

+static void set_display_intf(struct mdp5_kms *mdp5_kms,
+   struct mdp5_interface *intf)
+{
+   unsigned long flags;
+   u32 intf_sel;
+
+   spin_lock_irqsave(_kms->resource_lock, flags);
+   intf_sel = mdp5_read(mdp5_kms, 

[PATCH 1/4] drm/msm/mdp5: Update generated header files

[Stephane Viau]

Prepare for pipeline operation mode configuration, in particular
for DSI and WB modes.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 68 -
 1 file changed, 33 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index c276624..095a54c 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -8,7 +8,7 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git

 The rules-ng-ng source files this header was generated from are:
-- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
27229 bytes, from 2015-02-10 17:00:41)
+- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
27094 bytes, from 2015-01-23 16:27:31)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2014-06-02 18:31:15)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2015-01-23 16:20:19)

@@ -37,11 +37,14 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 */


-enum mdp5_intf {
+enum mdp5_intf_type {
+   INTF_DISABLED = 0,
INTF_DSI = 1,
INTF_HDMI = 3,
INTF_LCDC = 5,
INTF_eDP = 9,
+   INTF_VIRTUAL = 100,
+   INTF_WB = 101,
 };

 enum mdp5_intfnum {
@@ -67,11 +70,11 @@ enum mdp5_pipe {

 enum mdp5_ctl_mode {
MODE_NONE = 0,
-   MODE_ROT0 = 1,
-   MODE_ROT1 = 2,
-   MODE_WB0 = 3,
-   MODE_WB1 = 4,
-   MODE_WFD = 5,
+   MODE_WB_0_BLOCK = 1,
+   MODE_WB_1_BLOCK = 2,
+   MODE_WB_0_LINE = 3,
+   MODE_WB_1_LINE = 4,
+   MODE_WB_2_LINE = 5,
 };

 enum mdp5_pack_3d {
@@ -144,30 +147,25 @@ enum mdp5_data_format {
DATA_FORMAT_YUV = 1,
 };

-#define MDP5_IRQ_INTF0_WB_ROT_COMP 0x0001
-#define MDP5_IRQ_INTF1_WB_ROT_COMP 0x0002
-#define MDP5_IRQ_INTF2_WB_ROT_COMP 0x0004
-#define MDP5_IRQ_INTF3_WB_ROT_COMP 0x0008
-#define MDP5_IRQ_INTF0_WB_WFD  0x0010
-#define MDP5_IRQ_INTF1_WB_WFD  0x0020
-#define MDP5_IRQ_INTF2_WB_WFD  0x0040
-#define MDP5_IRQ_INTF3_WB_WFD  0x0080
-#define MDP5_IRQ_INTF0_PING_PONG_COMP  0x0100
-#define MDP5_IRQ_INTF1_PING_PONG_COMP  0x0200
-#define MDP5_IRQ_INTF2_PING_PONG_COMP  0x0400
-#define MDP5_IRQ_INTF3_PING_PONG_COMP  0x0800
-#define MDP5_IRQ_INTF0_PING_PONG_RD_PTR
0x1000
-#define MDP5_IRQ_INTF1_PING_PONG_RD_PTR
0x2000
-#define MDP5_IRQ_INTF2_PING_PONG_RD_PTR
0x4000
-#define MDP5_IRQ_INTF3_PING_PONG_RD_PTR
0x8000
-#define MDP5_IRQ_INTF0_PING_PONG_WR_PTR
0x0001
-#define MDP5_IRQ_INTF1_PING_PONG_WR_PTR
0x0002
-#define MDP5_IRQ_INTF2_PING_PONG_WR_PTR
0x0004
-#define MDP5_IRQ_INTF3_PING_PONG_WR_PTR
0x0008
-#define MDP5_IRQ_INTF0_PING_PONG_AUTO_REF  0x0010
-#define MDP5_IRQ_INTF1_PING_PONG_AUTO_REF  0x0020
-#define MDP5_IRQ_INTF2_PING_PONG_AUTO_REF  0x0040
-#define MDP5_IRQ_INTF3_PING_PONG_AUTO_REF  0x0080
+#define MDP5_IRQ_WB_0_DONE 0x0001
+#define MDP5_IRQ_WB_1_DONE 0x0002
+#define MDP5_IRQ_WB_2_DONE 0x0010
+#define MDP5_IRQ_PING_PONG_0_DONE  0x0100
+#define MDP5_IRQ_PING_PONG_1_DONE  0x0200
+#define MDP5_IRQ_PING_PONG_2_DONE  0x0400
+#define MDP5_IRQ_PING_PONG_3_DONE  0x0800
+#define MDP5_IRQ_PING_PONG_0_RD_PTR0x1000
+#define MDP5_IRQ_PING_PONG_1_RD_PTR0x2000
+#define MDP5_IRQ_PING_PONG_2_RD_PTR0x4000
+#define MDP5_IRQ_PING_PONG_3_RD_PTR0x8000
+#define MDP5_IRQ_PING_PONG_0_WR_PTR0x0001
+#define MDP5_IRQ_PING_PONG_1_WR_PTR0x0002
+#define MDP5_IRQ_PING_PONG_2_WR_PTR0x0004
+#define MDP5_IRQ_PING_PONG_3_WR_PTR0x0008
+#define MDP5_IRQ_PING_PONG_0_AUTO_REF  0x0010
+#define MDP5_IRQ_PING_PONG_1_AUTO_REF   

[PATCH 0/4] drm/msm: preparation for WB/DSI connectors

[Stephane Viau]

WB and DSI support are in the pipe and will come out soon. Before that, we
need to prepare the MDP5 driver so we can support these connectors.

Stephane Viau (4):
  drm/msm/mdp5: Update generated header files
  drm/msm/mdp5: Enhance operation mode for pipeline configuration
  drm/msm/mdp5: Add START signal to kick off certain pipelines
  drm/msm/mdp5: Make the intf connection in config module

 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h |  68 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |  10 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  13 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  70 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 326 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h |  75 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  40 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  99 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  49 -
 9 files changed, 519 insertions(+), 231 deletions(-)

-- 
Qualcomm Innovation Center, Inc.

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

[PATCH] drm/rockchip: Flip select/depends in Kconfig

[Jani Nikula]

On Tue, 03 Mar 2015, Daniel Vetter  wrote:
> Otherwise Kconfig gets confused and somehow ends up creating a 2nd drm
> submenu. I couldn't find i915 because of this any more at first.

This is not it. I bisected it to

commit db88c8f4e7e1d1c9e82bc5645a537782b8836cc0
Author: Chen Gang S 
Date:   Sun Feb 1 22:08:33 2015 +0800

drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on 
HAVE_DMA_ATTRS

and reverting fixes the issue.

BR,
Jani.


>
> Cc: Andy Yan 
> Cc: Russell King 
> Cc: Philipp Zabel 
> Cc: "Yann E. MORIN" 
> Cc: linux-kbuild at vger.kernel.or
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/rockchip/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index cb21e3821244..959088695da4 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -17,8 +17,8 @@ config DRM_ROCKCHIP
>  
>  config ROCKCHIP_DW_HDMI
>  tristate "Rockchip specific extensions for Synopsys DW HDMI"
> -depends on DRM_ROCKCHIP
>  select DRM_DW_HDMI
> +depends on DRM_ROCKCHIP
>  help
> This selects support for Rockchip SoC specific extensions
> for the Synopsys DesignWare HDMI driver. If you want to
> -- 
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/3] drm/panel: Add display_timing support

[Philipp Zabel]

Hi Thierry,

Am Montag, den 23.02.2015, 15:04 +0100 schrieb Philipp Zabel:
> Hi Thierry,
> 
> do you have any further thoughts on this?

[...]
> > Sorry for taking so long to get back on this. I generally like the idea,
> > though a couple of things are unclear to me.
> > 
> > In struct display_timing we have:
> > 
> > struct timing_entry hactive;
> > ...
> > struct timing_entry vactive;
> > 
> > I wonder if that really makes sense. Are there really datasheets that
> > provide a valid range for the number of horizontal and vertical active
> > pixels?
> 
> I could send a patch to change hactive/vactive to a single value
> and change Documentation/devicetree/bindings/video/display-timing.txt
> to clarify ranges are not allowed for these properties until somebody
> digs out a panel that actually needs this.
> Adding Steffen to Cc: in case there was a reason other than symmetry.

That seems not to be the case so far.

[...]
> > >  /**
> > >   * struct drm_panel_funcs - perform operations on a given panel
> > > @@ -38,6 +39,8 @@ struct drm_panel;
> > >   * @enable: enable panel (turn on back light, etc.)
> > >   * @get_modes: add modes to the connector that the panel is attached to 
> > > and
> > >   * return the number of modes added
> > > + * @get_timings: copy display timings into the provided array and return
> > > + * the number of display timings available
> > >   *
> > >   * The .prepare() function is typically called before the display 
> > > controller
> > >   * starts to transmit video data. Panel drivers can use this to turn the 
> > > panel
> > > @@ -68,6 +71,8 @@ struct drm_panel_funcs {
> > >   int (*prepare)(struct drm_panel *panel);
> > >   int (*enable)(struct drm_panel *panel);
> > >   int (*get_modes)(struct drm_panel *panel);
> > > + int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
> > > +struct display_timing *timings);
> > 
> > Also are there even panels that support more than one set of timings?
> > I've never heard of panels that are actually able to do more than one
> > mode, so I'm wondering if num_timings isn't overdoing it a little here.
> > I guess it doesn't hurt all that much, though.
> 
> Would you prefer
>   struct display_timing *(*get_timing)(struct drm_panel *panel);
> ?

I'd like to resend this. Please let me know if you want me to change
this function prototype.

regards
Philipp

[PATCH RFC v9 09/20] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

[Philipp Zabel]

Hi,

Am Donnerstag, den 12.02.2015, 14:01 +0800 schrieb Liu Ying:
> Signed-off-by: Liu Ying 
> ---
> v8->v9:
>  * Rebase onto the imx-drm/next branch of Philipp Zabel's open git repository.

I can't test this myself for lack of hardware, but I see no further
issues with patches 09 - 13 except for the use of
imx_drm_encoder_get_mux_id. I'll either rebase my patches that remove it
or fix it up when applying.

Thierry, may I take these patches through imx-drm, or would you rather I
waited for you to pick up the drm/dsi and drm/bridge patches?

regards
Philipp

[Bug 86043] Optimus issue with libdrm 2.4.58

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

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

--- Comment #14 from Chris Wilson  ---
(In reply to Emil Velikov from comment #13)
>  - Invalid memory access in various modules - invalid reads in various steam
> runtime components, alarming number of invalid writes in i965_dri.so.
> 
> The latter one perhaps should be looked into closer ?

Probably not, that is just valgrind not understanding GEM and its ioctls. You
need to use a libdrm compiled with --enable-valgrind to suppress the false
positives.

-- 
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/20150303/1cf5e804/attachment-0001.html>

[Bug 86043] Optimus issue with libdrm 2.4.58

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

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

--- Comment #13 from Emil Velikov  ---
(In reply to Tvrtko Ursulin from comment #12)
> I think we'll need to pull in someone from Steam since Valgrind reports some
> mismatched frees in vgui2_s.so, steamclient.so and steamui.so. 
> 
> There are not debug symbols so impossible to guess what area of the code is
> that.
> 
I'm assuming Jordan can coordinate that with Valve. Afaics he is the one
assigned for the issue over at github.

> Then this also looks pretty bad:
> 
> ERROR: ld.so: object
> '/home/vedran/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from
> LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
> ERROR: ld.so: object
> '/home/vedran/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from
> LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored
> 
Those should be harmless, as steam LD_PRELOADs a bunch of libraries. Afaik
steam is 32bit, while Vedran was running a 64bit system - thus the messages. 

There are a couple of other interesting bits in the log:
 - Alarming heap stats (allocated ~770 MiB, in-use at exit ~220MiB)
 - Invalid memory access in various modules - invalid reads in various steam
runtime components, alarming number of invalid writes in i965_dri.so.

The latter one perhaps should be looked into closer ?

> Please if someone knows any Steam devs CC them here?
Afaict unless a person is known* by bugzilla one cannot CC them. For example
one cannot CC your @intel email, so I've opted for the known @linux.intel one.

-- 
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/20150303/d9d6e43a/attachment.html>

[PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver

[Daniel Vetter]

On Tue, Mar 03, 2015 at 10:06:57AM +, Jianwei.Wang at freescale.com wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Sunday, February 22, 2015 7:35 PM
> > To: Wang Jianwei-B52261
> > Cc: dri-devel at lists.freedesktop.org; jbarnes at virtuousgeek.org; Wood
> > Scott-B07421; Xiubo Li; Wang Huan-B18965; linux-kernel at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver
> > 
> > On Fri, Feb 13, 2015 at 07:03:54PM +0800, Jianwei Wang wrote:
> > > This patch add support for Two Dimensional Animation and Compositing
> > > Engine (2D-ACE) on the Freescale LS102x SoCs.
> > >
> > > 2D-ACE is a Freescale display controller. It supports at most four
> > > plane and provide an hardware cursor.
> > >
> > > This is a simplified version, only a primary plane, a fb created for
> > > fbdev, a crtc, a connector for TFT LCD panel, an encoder, and the
> > > encoder is not in use. Now this drver support fbdev only.
> > >
> > > Signed-off-by: Alison Wang 
> > > Signed-off-by: Xiubo Li 
> > > Signed-off-by: Jianwei Wang 
> > 
> > Imo adding a new driver without primary plane support (use
> > drm_crtc_init_with_planes) and without atomic support doesn't make sense
> > any more.
> > 
> > Also, what do you mean with "support fbdev only"?
> > -Daniel
> > 
>  
> Daniel,
> 
> This driver has supported primary plane (use drm_crtc_init_with_planes) 
> Already. 
> If atomic support is a must? 2D-ACE is a simple display Controller and
> this is a simplified version. If atomic support is not a must, I want to add 
> it with patches, is it ok?

atomic is the new way the drm display subsystem works, not supporting it
in new drivers makes this transition even longer. Since I guess if you
don't want to do the conversion now no one else will do it anytime later,
and then we're stuck with this driver as-is. On top of that atomic should
simplify testing for your driver a lot (since a few things are take care
of for you in the generic atomic code).
-Daniel

> 
> " Now this drver support fbdev only." if this sentence confuses you,
> I'd like remove it. In fact I mean that this driver only create a framebuffer
> dev (use drm_fbdev_cma_init).
> 
> Thanks
> Regards,
> Wang Jianwei
> 
> > > ---
> > >  .../devicetree/bindings/video/fsl,dcfb.txt |  50 +++
> > >  drivers/gpu/drm/Kconfig|   2 +
> > >  drivers/gpu/drm/Makefile   |   1 +
> > >  drivers/gpu/drm/fsl/Kconfig|  17 +
> > >  drivers/gpu/drm/fsl/Makefile   |   7 +
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c | 412
> > +
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h |  40 ++
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c  | 323
> > 
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h  | 167 +
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c|  43 +++
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c  |  45 +++
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h  |  22 ++
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c| 124 +++
> > >  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h|  28 ++
> > >  14 files changed, 1281 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > >  create mode 100644 drivers/gpu/drm/fsl/Kconfig  create mode 100644
> > > drivers/gpu/drm/fsl/Makefile  create mode 100644
> > > drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
> > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
> > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
> > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
> > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
> > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
> > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
> > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
> > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h
> > >
> > > diff --git a/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > > b/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > > new file mode 100644
> > > index 000..de7da97
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > > @@ -0,0 +1,50 @@
> > > +* Freescale Simple Display Controller FB Driver
> > > +
> > > +Required properties:
> > > +- compatible:Should be one of "fsl,ls1021a-dcfb".
> > > +- reg:   Address and length of the register set for dcfb.
> > > +- clocks:From common clock binding: handle to dcfb clock.
> > > +- clock-names:   From common clock binding: Shall be "dcfb".
> > > +- display:   The phandle to display node.
> > > +
> > > +Optional properties:
> > > +- scfg-controller:  

[RFC] VRAM allocations with amdkfd+ttm for HSA processes

[Oded Gabbay]

On 02/24/2015 04:56 PM, Oded Gabbay wrote:
> In a nutshell:
>
> This RFC proposes a control mechanism for VRAM (GPU local memory) memory
> pinning that is initiated by HSA processes. This control mechanism is proposed
> in order to prevent starvation of graphic applications due to high VRAM usage
> by HSA processes.
>
> TOC:
> 
> 1.  amdkfd's VRAM-related IOCTLs overview
> 2.  TTM BOs migration overview
> 3.  The why
> 4.  Analyzing the use-cases
> 5.  Proposed mechanism
> 6.  Conclusion
> 
>
> 1. amdkfd's VRAM-related IOCTLs overview:
>
> amdkfd provides four IOCTLs for VRAM allocation & mapping (the names below are
> presented just for convinience and can be changed until the final
> implementation) :
>
>- Allocate memory on VRAM  -> AMDKFD_IOC_ALLOC_MEMORY_ON_GPU
>- Free memory on VRAM  -> AMDKFD_IOC_FREE_MEMORY_ON_GPU
>- Map memory to GPU-> AMDKFD_IOC_MAP_MEMORY_TO_GPU
>- Unmap memory to GPU  -> AMDKFD_IOC_UNMAP_MEMORY_FROM_GPU
>
> An HSA process which needs to use VRAM, first calls the
> AMDKFD_IOC_ALLOC_MEMORY_ON_GPU IOCTL. This IOCTL allocates a list of BOs
> (Buffer Objects) that represent the amount of memory the HSA process wanted to
> allocate.
> e.g. If a single BO represent 1MB of VRAM, than amdkfd will allocate a list
> of 100 BOs for an allocation request of 100MB of VRAM.
>
> Before the memory can be used, the HSA process needs to call the
> AMDKFD_IOC_MAP_MEMORY_TO_GPU IOCTL. This IOCTL pins the relevant BOs (part or
> all of the BOs that were created in the alloc IOCTL) and updates the PT/PD of
> the GPUVM.
> e.g. In regard to the previous example, if the HSA process wants to
> dispatch a kernel that will use the last 10MB (of the 100MB it allocated), 
> then
> amdkfd will pin the last ten BOs in the list.
>
> After the GPU kernel has finished using the memory, the HSA process needs to
> call the AMDKFD_IOC_UNMAP_MEMORY_FROM_GPU IOCTL. This IOCTL unpins the BOs and
> updates the PT/PD of the GPUVM.
>
> If the HSA process wants to dispatch another GPU kernel which will use the
> same memory, than it can again call the AMDKFD_IOC_MAP_MEMORY_TO_GPU IOCTL.
> After the kernel finishes, the HSA process needs to call the
> AMDKFD_IOC_UNMAP_MEMORY_FROM_GPU IOCTL.
>
> Finally, when the memory has no more use, the HSA process needs to call the
> AMDKFD_IOC_FREE_MEMORY_ON_GPU IOCTL. This IOCTL destroys the BOs. This action
> will also be performed on process tear-down.
>
> The important point to remember is that once the HSA process calls the
> AMDKFD_IOC_MAP_MEMORY_TO_GPU IOCTL and amdkfd pins a list of BOs, than from
> amdkfd's POV, those BOs are in use and must not be unpinned & moved, even if
> they are currently idle (not used by a GPU kernel).
>
> 2. TTM subsystem overview:
>
> For those unfamiliar with TTM, here is a short overview regarding migration of
> BOs in TTM (Note, this is a simplistic overview):
>
> Every BO has a reservation point (fence) attached to it. When the GPU
> has finished working with that BO, it writes to its resv. point to signal the
> work has been done and the BO is now idle. To enable this mechanism, the
> graphic driver (radeon) dispatches a fence packet after each CS.
>
> TTM maintains an LRU list of BOs. All the BOs are on that list, regardless if
> they are in use or idle, pinned or unpinned. When TTM encounters a memory
> pressure situation (e.g. it tries to pin a BO on VRAM but does not have enough
> space), it walks over the LRU list and tries to evict BOs who are placed in
> VRAM *and* are idle (meaning that they can be migrated to GART or system
> memory) until it has enough space for the new request.
>
> How TTM finds out if a BO is idle or not ? It checks its reservation point. If
> it is signaled, then the BO is idle and can be migrated. If not, that BO is
> still in use. The check is done in two stages. First, TTM does a simple check
> that asks if a fence is signaled or not and this one is called in atomic
> context, so the device driver can't block. The second check is the
> wait_until_signaled and that function is can block, but there is a timeout
> enforced by TTM.
>
> What is a reservation point ? It is a generic Linux kernel mechanism to
> allow sharing of fences between different device drivers. In our case, TTM
> assigns a reservation point to every BO. When TTM checks the BO's reservation
> point, it actually calls a callback function of that resv. point that tells it
> if the resv. point's fence has been signaled.
>
> The callback function is implemented by the entity using the BO. e.g. radeon
> driver. When that callback is called, radeon needs to respond whether that BO
> is idle or not. radeon has that information because it dispatches a fence
> packet after each CS. That way, when the GPU kernel has finished, the GPU
> handles the fence packet and writes to 

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #16 from Jon Arne Jørgensen  ---
Yep, that's a fix.

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

[PATCH] drm/rockchip: Flip select/depends in Kconfig

[Daniel Vetter]

Otherwise Kconfig gets confused and somehow ends up creating a 2nd drm
submenu. I couldn't find i915 because of this any more at first.

Cc: Andy Yan 
Cc: Russell King 
Cc: Philipp Zabel 
Cc: "Yann E. MORIN" 
Cc: linux-kbuild at vger.kernel.or
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/rockchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index cb21e3821244..959088695da4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -17,8 +17,8 @@ config DRM_ROCKCHIP

 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
-depends on DRM_ROCKCHIP
 select DRM_DW_HDMI
+depends on DRM_ROCKCHIP
 help
  This selects support for Rockchip SoC specific extensions
  for the Synopsys DesignWare HDMI driver. If you want to
-- 
2.1.4

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #15 from Maarten Lankhorst  ---
Ok, in that case it's probably a duplicate.

Can you attachment 166571 on top of
http://cgit.freedesktop.org/~agd5f/linux/log/?h=posting-read?

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

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #14 from Jon Arne Jørgensen  ---
I'm sorry to report that attachment 166571 doesn't fix the crash,
but I can also report that your suggestion from Bug 90741 comment 60 does fix
the crash.

That is, attachment 166571 +
if (fence->ring == R600_RING_TYPE_DMA_INDEX) udelay(50); in
radeon_fence_enable_signaling? after the irq_get.

I tried with udelay(50);, and mb(); both seems to work.

I was not able to compile the kernel with "RREG32(DMA_CNTL +
DMA0_REGISTER_OFFSET);" because of missing defines.
What header should I include?

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

[PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Tomi Valkeinen]

On 02/03/15 19:42, Russell King - ARM Linux wrote:
> On Mon, Mar 02, 2015 at 07:08:39PM +0200, Tomi Valkeinen wrote:
>> On 02/03/15 18:06, Russell King - ARM Linux wrote:
>>
>>>> This is missing the output of tda998x. It should have two ports, input
>>>> and output, output going to hdmi-connector.
>>>
>>> We don't have that kind of level of modelling in DRM right now - as far
>>> as DRM is concerned, the tda998x is both the encoder _and_ the connector
>>> since it supplies both functionalities.
>>
>> That's fine, but these are DT bindings which should reflect the
>> hardware, not the SW stack.
> 
> I still don't buy your argument.  The principle is right, but I think
> you're taking it too far.



> When we say "DT should follow the hardware" we're not talking about
> making DT be an alternative to the hardware's schematic.

I agree, and that's not what I'm suggesting. We should only model HW in
the DT when it makes sense, when it gives us something.

A HDMI connector can have (at least) two functionalities that the driver
for it may need to handle: HPD and +5V. On some SoCs/boards those are
handled by the HDMI encoder, but I have boards where they are not. So we
need to have the data somewhere, and a HDMI connector node at the end of
the video path is a logical choice.

The HDMI connector node is also a good place for a symbolic name which
can be shown to the user.

In this particular board, the HDMI encoder handles the HPD and the +5V
is always enabled, so there's no strict need to have the HDMI connector
node.

However, I still feel it's better to have the HDMI connector in .dts:

1) It's not said that a HDMI encoder always has a HDMI connector as the
next component. The next component could be a integrated panel, needing
a specific driver and there's no HDMI connector at all. Or there could
be something else, as is the case on some OMAP boards which have an ESD
protection chip (that requires controlling, i.e. a driver) between the
encoder and the connector.

2) I like that the beginning and the end of the video pipeline are
clearly defined. A video pipeline starts at a display controller, and
ends at a panel or a connector. This makes it easier to understand the
.dts as you know what to expect.

In the SW side these mean that every encoder (or whatever is doing this
stuff) should be able to handle any component after the encoder, be it a
connector, panel or something else.

If we allow leaving out the connector node, the code also needs to
handle the case when there's nothing after the encoder, which probably
means fabricating some connector data (at least if and when DRM can
handle arbitrary video pipelines).

But as I said earlier, we can do just fine without the HDMI connector
node on boards where the connector "just works". We can handle that in
the drivers with some extra code.

So if people think it's a big chore to add the connectors and don't see
the benefit in them (and they don't want the symbolic labels that could
be added there), I'm fine with having them optional.

 Tomi


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

[PATCH v5 09/11] drm/tegra: Reset the SOR on probe

[Tomeu Vizoso]

On 2 March 2015 at 09:41, Alexandre Courbot  wrote:
> On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso
>  wrote:
>> As there isn't a way for the firmware on the Nyan chromebooks to hand
>> over the display to the kernel.
>
> Could this have a side-effect on models for which the firmware *does*
> hand over the display to the kernel? E.g. temporary glitch or black
> screen?
>
> This is probably ok though, as such a handing over would need to be
> documented in the firmware/kernel command line, and could thus be
> caught to disable that code block if needed.

Hi,

my understanding from talking with Thierry is that the kernel will
read the current state of the hw as the fw left it, and just carry on
if it's compatible with the currently-requested mode.

If it's not compatible, then the SOR should better be resetted to get
it into a known state.

But he's currently rewriting the SOR driver, so I don't know if it
makes sense to merge this patch.

Thanks,

Tomeu

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] imx-drm fixes for mode fixup, dw_hdmi/imx, and parallel-display

[Philipp Zabel]

Hi Dave,

Am Dienstag, den 24.02.2015, 19:11 +0100 schrieb Philipp Zabel:
> Hi Dave,
> 
> please consider pulling in these fixes to the mode setting fixup, dw_hdmi-imx
> driver and i.MX parallel-display probing:

gentle reminder, will you merge these fixes?

regards
Philipp

> The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
> 
>   Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-fixes-2015-02-24
> 
> for you to fetch changes up to d70e96ae05928643a7b10b8a519dc27afe4750d0:
> 
>   DRM: i.MX: parallel display: Support probe deferral for finding DRM panel 
> (2015-02-23 17:19:25 +0100)
> 
> 
> imx-drm fixes for mode fixup, dw_hdmi/imx, and parallel-display
> 
> - A clock fix for too large pixel clocks depending on the
>   DI clock flag simplification patch
> - Pruning of unsupported modes and a missing end of array element
>   for dw_hdmi-imx
> - LVDS modeset fix for mode fixup
> - Fix parallel-display deferred probing if drm_panel is used
> 
> 
> Liu Ying (1):
>   DRM: i.MX: parallel display: Support probe deferral for finding DRM 
> panel
> 
> Philipp Zabel (4):
>   gpu: ipu-v3: do not divide by zero if the pixel clock is too large
>   drm/imx: dw_hdmi-imx: add mode_valid callback prune unsupported modes
>   drm/imx: dw_hdmi-imx: add end of array element to current control array
>   drm/imx: imx-ldb: enable DI clock in encoder_mode_set
> 
>  drivers/gpu/drm/imx/dw_hdmi-imx.c  | 36 
> +-
>  drivers/gpu/drm/imx/imx-ldb.c  | 28 --
>  drivers/gpu/drm/imx/parallel-display.c |  5 -
>  drivers/gpu/ipu-v3/ipu-di.c|  2 ++
>  4 files changed, 50 insertions(+), 21 deletions(-)
> 
> regards
> Philipp

[Bug 86043] Optimus issue with libdrm 2.4.58

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

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

--- Comment #12 from Tvrtko Ursulin  ---
I think we'll need to pull in someone from Steam since Valgrind reports some
mismatched frees in vgui2_s.so, steamclient.so and steamui.so. 

There are not debug symbols so impossible to guess what area of the code is
that.

Then this also looks pretty bad:

ERROR: ld.so: object
'/home/vedran/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from
LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object
'/home/vedran/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from
LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored

Please if someone knows any Steam devs CC them here?

-- 
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/20150303/1147f4c2/attachment-0001.html>

[PATCH] drm/radeon: fix DRM_IOCTL_RADEON_CS oops

[Christian König]

Good catch.

Patch is Reviewed-by: Christian König 

Regards,
Christian.

On 02.03.2015 20:36, Tommi Rantala wrote:
> Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
> following oops.
>
> Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().
>
> --
>
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>
>   static const struct drm_radeon_cs cs;
>
>   int main(int argc, char **argv)
>   {
>   return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, );
>   }
>
> --
>
> [ttrantal at test2 ~]$ ./main /dev/dri/card0
> [   46.904650] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [   46.905022] IP: [] list_sort+0x42/0x240
> [   46.905022] PGD 68f29067 PUD 688b5067 PMD 0
> [   46.905022] Oops: 0002 [#1] SMP
> [   46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58
> [   46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form 
> Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
> [   46.905022] task: 880058e2bcc0 ti: 880058e64000 task.ti: 
> 880058e64000
> [   46.905022] RIP: 0010:[]  [] 
> list_sort+0x42/0x240
> [   46.905022] RSP: 0018:880058e67998  EFLAGS: 00010246
> [   46.905022] RAX:  RBX:  RCX: 
> 
> [   46.905022] RDX: 81644410 RSI: 880058e67b40 RDI: 
> 880058e67a58
> [   46.905022] RBP: 880058e67a88 R08:  R09: 
> 
> [   46.905022] R10: 880058e2bcc0 R11: 828e6ca0 R12: 
> 81644410
> [   46.905022] R13: 8800694b8018 R14:  R15: 
> 880058e679b0
> [   46.905022] FS:  7fdc65a65700() GS:88006d60() 
> knlGS:
> [   46.905022] CS:  0010 DS:  ES:  CR0: 80050033
> [   46.905022] CR2:  CR3: 58dd9000 CR4: 
> 06f0
> [   46.905022] DR0:  DR1:  DR2: 
> 
> [   46.905022] DR3:  DR6: 4ff0 DR7: 
> 0400
> [   46.905022] Stack:
> [   46.905022]  880058e67b40 880058e2bcc0 880058e67a78 
> 
> [   46.905022]     
> 
> [   46.905022]     
> 
> [   46.905022] Call Trace:
> [   46.905022]  [] radeon_cs_parser_fini+0x195/0x220
> [   46.905022]  [] radeon_cs_ioctl+0xa9/0x960
> [   46.905022]  [] drm_ioctl+0x19c/0x640
> [   46.905022]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [   46.905022]  [] ? trace_hardirqs_on+0xd/0x10
> [   46.905022]  [] radeon_drm_ioctl+0x46/0x80
> [   46.905022]  [] do_vfs_ioctl+0x318/0x570
> [   46.905022]  [] ? selinux_file_ioctl+0x56/0x110
> [   46.905022]  [] SyS_ioctl+0x81/0xa0
> [   46.905022]  [] system_call_fastpath+0x12/0x17
> [   46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff
> ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> 
> c7
> 00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85
> [   46.905022] RIP  [] list_sort+0x42/0x240
> [   46.905022]  RSP 
> [   46.905022] CR2: 
> [   47.149253] ---[ end trace 09576b4e8b2c20b8 ]---
>
> Signed-off-by: Tommi Rantala 
> ---
>   drivers/gpu/drm/radeon/radeon_cs.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index a579ed3..4d0f96c 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -256,11 +256,13 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
> void *data)
>   u32 ring = RADEON_CS_RING_GFX;
>   s32 priority = 0;
>   
> + INIT_LIST_HEAD(>validated);
> +
>   if (!cs->num_chunks) {
>   return 0;
>   }
> +
>   /* get chunks */
> - INIT_LIST_HEAD(>validated);
>   p->idx = 0;
>   p->ib.sa_bo = NULL;
>   p->const_ib.sa_bo = NULL;

[PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver

[jianwei.w...@freescale.com]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Sunday, February 22, 2015 7:35 PM
> To: Wang Jianwei-B52261
> Cc: dri-devel at lists.freedesktop.org; jbarnes at virtuousgeek.org; Wood
> Scott-B07421; Xiubo Li; Wang Huan-B18965; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver
> 
> On Fri, Feb 13, 2015 at 07:03:54PM +0800, Jianwei Wang wrote:
> > This patch add support for Two Dimensional Animation and Compositing
> > Engine (2D-ACE) on the Freescale LS102x SoCs.
> >
> > 2D-ACE is a Freescale display controller. It supports at most four
> > plane and provide an hardware cursor.
> >
> > This is a simplified version, only a primary plane, a fb created for
> > fbdev, a crtc, a connector for TFT LCD panel, an encoder, and the
> > encoder is not in use. Now this drver support fbdev only.
> >
> > Signed-off-by: Alison Wang 
> > Signed-off-by: Xiubo Li 
> > Signed-off-by: Jianwei Wang 
> 
> Imo adding a new driver without primary plane support (use
> drm_crtc_init_with_planes) and without atomic support doesn't make sense
> any more.
> 
> Also, what do you mean with "support fbdev only"?
> -Daniel
> 

Daniel,

This driver has supported primary plane (use drm_crtc_init_with_planes) 
Already. 
If atomic support is a must? 2D-ACE is a simple display Controller and
this is a simplified version. If atomic support is not a must, I want to add 
it with patches, is it ok?

" Now this drver support fbdev only." if this sentence confuses you,
I'd like remove it. In fact I mean that this driver only create a framebuffer
dev (use drm_fbdev_cma_init).

Thanks
Regards,
Wang Jianwei

> > ---
> >  .../devicetree/bindings/video/fsl,dcfb.txt |  50 +++
> >  drivers/gpu/drm/Kconfig|   2 +
> >  drivers/gpu/drm/Makefile   |   1 +
> >  drivers/gpu/drm/fsl/Kconfig|  17 +
> >  drivers/gpu/drm/fsl/Makefile   |   7 +
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c | 412
> +
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h |  40 ++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c  | 323
> 
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h  | 167 +
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c|  43 +++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c  |  45 +++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h  |  22 ++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c| 124 +++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h|  28 ++
> >  14 files changed, 1281 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/video/fsl,dcfb.txt
> >  create mode 100644 drivers/gpu/drm/fsl/Kconfig  create mode 100644
> > drivers/gpu/drm/fsl/Makefile  create mode 100644
> > drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h
> >
> > diff --git a/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > b/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > new file mode 100644
> > index 000..de7da97
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > @@ -0,0 +1,50 @@
> > +* Freescale Simple Display Controller FB Driver
> > +
> > +Required properties:
> > +- compatible:  Should be one of "fsl,ls1021a-dcfb".
> > +- reg: Address and length of the register set for dcfb.
> > +- clocks:  From common clock binding: handle to dcfb clock.
> > +- clock-names: From common clock binding: Shall be "dcfb".
> > +- display: The phandle to display node.
> > +
> > +Optional properties:
> > +- scfg-controller: The phandle of scfg node.
> > +
> > +Required properties:
> > +- bits-per-pixel:  <16> for RGB565,
> > +   <24> for RGB888,
> > +   <32> for RGB.
> > +
> > +Required timing node for dispplay sub-node:
> > +- display-timings: Refer to binding doc display-timing.txt for
> details.
> > +
> > +Examples:
> > +dcfb: dcfb at 2ce {
> > +   compatible = "fsl,ls1021a-dcfb";
> > +   reg = <0x0 0x2ce 0x0 0x1>;
> > +   clocks = <_clk 0>;
> > +   clock-names = "dcfb";
> > +   scfg-controller = <>;
> > +   display = <>;
> > +
> > +   display: display at 0 {
> > +   bits-per-pixel = <24>;
> > +
> > +   display-timings {
> > +   

[PATCH] drm/i915: Export total subslice and EU counts

[Daniel Vetter]

On Tue, Mar 03, 2015 at 09:54:39AM +0100, Daniel Vetter wrote:
> On Mon, Mar 02, 2015 at 03:37:32PM -0800, jeff.mcgee at intel.com wrote:
> > From: Jeff McGee 
> > 
> > Setup new I915_GETPARAM ioctl entries for subslice total and
> > EU total. Userspace drivers need these values when constructing
> > GPGPU commands. This kernel query method is intended to replace
> > the PCI ID-based tables that userspace drivers currently maintain.
> > The kernel driver can employ fuse register reads as needed to
> > ensure the most accurate determination of GT config attributes.
> > This first became important with Cherryview in which the config
> > could differ between devices with the same PCI ID.
> > 
> > The kernel detection of these values is device-specific and not
> > included in this patch. Because zero is not a valid value for any of
> > these parameters, a value of zero is interpreted as unknown for the
> > device. Userspace drivers should continue to maintain ID-based tables
> > for older devices not supported by the new query method.
> > 
> > For: VIZ-4636
> > Signed-off-by: Jeff McGee 
> > ---
> >  drivers/gpu/drm/i915/i915_dma.c | 10 ++
> >  include/uapi/drm/i915_drm.h |  2 ++
> >  2 files changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 053e178..9350ea2 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -150,6 +150,16 @@ static int i915_getparam(struct drm_device *dev, void 
> > *data,
> > case I915_PARAM_MMAP_VERSION:
> > value = 1;
> > break;
> > +   case I915_PARAM_SUBSLICE_TOTAL:
> > +   value = INTEL_INFO(dev)->subslice_total;
> > +   if (!value)
> > +   return -ENODEV;
> > +   break;
> > +   case I915_PARAM_EU_TOTAL:
> > +   value = INTEL_INFO(dev)->eu_total;
> > +   if (!value)
> > +   return -ENODEV;
> 
> I need the corresponding userspace support before I can merged this.

Strike that, I've missed the beignet support. As soon as beignet
maintainers have that reviewed I can pull this in.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/radeon: fix wait to actually occur after the signaling callback

[Maarten Lankhorst]

A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.

This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst 
Reported-by: Jon Arne Jørgensen 
Reported-and-tested-by: Gustaw Smolarczyk 
Cc: stable at vger.kernel.org (v3.18+)
---
 drivers/gpu/drm/radeon/radeon_fence.c | 68 +++
 1 file changed, 45 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index d13d1b5a859f..df09ca7c4889 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -1030,37 +1030,59 @@ static inline bool radeon_test_signaled(struct 
radeon_fence *fence)
return test_bit(FENCE_FLAG_SIGNALED_BIT, >base.flags);
 }

+struct radeon_wait_cb {
+   struct fence_cb base;
+   struct task_struct *task;
+};
+
+static void
+radeon_fence_wait_cb(struct fence *fence, struct fence_cb *cb)
+{
+   struct radeon_wait_cb *wait =
+   container_of(cb, struct radeon_wait_cb, base);
+
+   wake_up_process(wait->task);
+}
+
 static signed long radeon_fence_default_wait(struct fence *f, bool intr,
 signed long t)
 {
struct radeon_fence *fence = to_radeon_fence(f);
struct radeon_device *rdev = fence->rdev;
-   bool signaled;
+   struct radeon_wait_cb cb;

-   fence_enable_sw_signaling(>base);
+   cb.task = current;

-   /*
-* This function has to return -EDEADLK, but cannot hold
-* exclusive_lock during the wait because some callers
-* may already hold it. This means checking needs_reset without
-* lock, and not fiddling with any gpu internals.
-*
-* The callback installed with fence_enable_sw_signaling will
-* run before our wait_event_*timeout call, so we will see
-* both the signaled fence and the changes to needs_reset.
-*/
+   if (fence_add_callback(f, , radeon_fence_wait_cb))
+   return t;
+
+   while (t > 0) {
+   if (intr)
+   set_current_state(TASK_INTERRUPTIBLE);
+   else
+   set_current_state(TASK_UNINTERRUPTIBLE);
+
+   /*
+* radeon_test_signaled must be called after
+* set_current_state to prevent a race with wake_up_process
+*/
+   if (radeon_test_signaled(fence))
+   break;
+
+   if (rdev->needs_reset) {
+   t = -EDEADLK;
+   break;
+   }
+
+   t = schedule_timeout(t);
+
+   if (t > 0 && intr && signal_pending(current))
+   t = -ERESTARTSYS;
+   }
+
+   __set_current_state(TASK_RUNNING);
+   fence_remove_callback(f, );

-   if (intr)
-   t = wait_event_interruptible_timeout(rdev->fence_queue,
-   ((signaled = radeon_test_signaled(fence)) ||
-rdev->needs_reset), t);
-   else
-   t = wait_event_timeout(rdev->fence_queue,
-   ((signaled = radeon_test_signaled(fence)) ||
-rdev->needs_reset), t);
-
-   if (t > 0 && !signaled)
-   return -EDEADLK;
return t;
 }

-- 
2.3.0

[PATCH] drm/i915: Export total subslice and EU counts

[Daniel Vetter]

On Mon, Mar 02, 2015 at 03:37:32PM -0800, jeff.mcgee at intel.com wrote:
> From: Jeff McGee 
> 
> Setup new I915_GETPARAM ioctl entries for subslice total and
> EU total. Userspace drivers need these values when constructing
> GPGPU commands. This kernel query method is intended to replace
> the PCI ID-based tables that userspace drivers currently maintain.
> The kernel driver can employ fuse register reads as needed to
> ensure the most accurate determination of GT config attributes.
> This first became important with Cherryview in which the config
> could differ between devices with the same PCI ID.
> 
> The kernel detection of these values is device-specific and not
> included in this patch. Because zero is not a valid value for any of
> these parameters, a value of zero is interpreted as unknown for the
> device. Userspace drivers should continue to maintain ID-based tables
> for older devices not supported by the new query method.
> 
> For: VIZ-4636
> Signed-off-by: Jeff McGee 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 10 ++
>  include/uapi/drm/i915_drm.h |  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 053e178..9350ea2 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -150,6 +150,16 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   case I915_PARAM_MMAP_VERSION:
>   value = 1;
>   break;
> + case I915_PARAM_SUBSLICE_TOTAL:
> + value = INTEL_INFO(dev)->subslice_total;
> + if (!value)
> + return -ENODEV;
> + break;
> + case I915_PARAM_EU_TOTAL:
> + value = INTEL_INFO(dev)->eu_total;
> + if (!value)
> + return -ENODEV;

I need the corresponding userspace support before I can merged this.

Thanks, Daniel

> + break;
>   default:
>   DRM_DEBUG("Unknown parameter %d\n", param->param);
>   return -EINVAL;
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 6eed16b..8672efc 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -347,6 +347,8 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_HAS_COHERENT_PHYS_GTT 29
>  #define I915_PARAM_MMAP_VERSION  30
>  #define I915_PARAM_HAS_BSD2   31
> +#define I915_PARAM_SUBSLICE_TOTAL 32
> +#define I915_PARAM_EU_TOTAL   33
>  
>  typedef struct drm_i915_getparam {
>   int param;
> -- 
> 2.3.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2] drm/imx: ipuv3-crtc: Allow to divide DI clock from TVEv2

[Philipp Zabel]

This patch allows the IPU to divide the 27 MHz input clock from
the TVE by two to obtain the 13.5 MHz pixel clock needed for
NTSC/PAL SD modes.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 98551e3..dcc31cf 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -161,13 +161,15 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
__func__, encoder_types);

/*
-* If we have DAC, TVDAC or LDB, then we need the IPU DI clock
-* to be the same as the LDB DI clock.
+* If we have DAC or LDB, then we need the IPU DI clock to be
+* the same as the LDB DI clock. For TVDAC, derive the IPU DI
+* clock from 27 MHz TVE_DI clock, but allow to divide it.
 */
if (encoder_types & (BIT(DRM_MODE_ENCODER_DAC) |
-BIT(DRM_MODE_ENCODER_TVDAC) |
 BIT(DRM_MODE_ENCODER_LVDS)))
sig_cfg.clkflags = IPU_DI_CLKMODE_SYNC | IPU_DI_CLKMODE_EXT;
+   else if (encoder_types & BIT(DRM_MODE_ENCODER_TVDAC))
+   sig_cfg.clkflags = IPU_DI_CLKMODE_EXT;
else
sig_cfg.clkflags = 0;

-- 
2.1.4

[PATCH] drm/i915: Fix modeset state confusion in the load detect code

[Linus Torvalds]

On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter  wrote:
>
> Fine with me. If you haven't pushed out yet can you maybe clarify the
> commit message?

Oh well. I already applied and tagged it, so it's what it is..

 Linus

[RFC PATCH v2 3/3] ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain

[Javier Martinez Canillas]

Hello Kukjin,

On 02/06/2015 12:27 PM, Javier Martinez Canillas wrote:
> Hello Andrzej,
> 
> On 02/06/2015 11:55 AM, Andrzej Hajda wrote:
>> FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER),
>> therefore their clocks should be enabled during power domain switch.
>> 
>> Signed-off-by: Andrzej Hajda 
>> ---
>> Hi,
>> 
>> This is 2nd version of the patch. After decrypting manual and discussion
>> with Marek I guess this set of clocks is more apropriate - async-bridges
>> are present in MIXER and FIMD, so their clocks should be enabled.
>>
> 
> I just tested this version on my Exynos5420 Peach Pit and the power domain
> failed error does not happen anymore even after enabling and disabling the
> HDMI display several times.
> 
> Thanks a lot for fixing this since the dependency was not clear to me from
> reading the manual.
> 
>> The 1st version worked for me due to fact I have forgot to remove
>> clk_ignore_unused kernel boot option during tests ;)
>>
> 
> Yes, that has bitten me too many times as well :)
> 
>> Regards
>> Andrzej
>> ---
> 
> Best regards,
> Javier
> 

Could you please pick this patch and patches 1/2 and 2/3 from the series [0]?

These are needed to fix DISP1 power domain issues and HDMI on Exynos542x.

Thanks a lot and best regards,
Javier

[0]: https://lkml.org/lkml/2015/2/5/265

[PATCH v8 0/3] Add of-graph helpers to loop over endpoints and find ports by id

[Philipp Zabel]

Hi Laurent,

Am Sonntag, den 01.03.2015, 18:20 +0200 schrieb Laurent Pinchart:
> Hi Philipp and all,
> 
> This series has been around for a long time, it seems to be time to get it 
> merged.
> 
> What's the plan ? If we wait for the v4.1 merge window there's a chance we'll 
> get more conflicts, especially on patch 1/3. Could it be merged in v4.0-rc to 
> avoid that ?

I've just sent another pull request to Grant and Rob. My favorite
outcome would be for the tag to be merged in time for v4.0 via the
device tree branch. My second most favorite outcome would be maintainer
approval to merge the same tag into both drm, media, etc. for v4.1.

regards
Philipp

> On Monday 23 February 2015 11:54:03 Philipp Zabel wrote:
> > Hi,
> > 
> > Since there now is a merge conflict in imx-drm-core, I've rebased the series
> > onto v4.0-rc1. Also a new driver touched by this change appeared, so the
> > first patch now includes a fix for am437x-vfpe, too. I'd be happy to get an
> > ack for that.
> > 
> > This series converts all existing users of of_graph_get_next_endpoint that
> > pass a non-NULL prev argument to the function and decrement its refcount
> > themselves to stop doing that. The of_node_put is moved into
> > of_graph_get_next_endpoint instead.
> > This allows to add a for_each_endpoint_of_node helper macro to loop over all
> > endpoints in a device tree node.
> > 
> > Changes since v8:
> >  - Rebased onto v4.0-rc1
> >  - Added fix to am437x-vpfe
> > 
> > The previous version can be found here: https://lkml.org/lkml/2014/12/23/219
> > 
> > regards
> > Philipp
> > 
> > Philipp Zabel (3):
> >   of: Decrement refcount of previous endpoint in
> > of_graph_get_next_endpoint
> >   of: Add for_each_endpoint_of_node helper macro
> >   of: Add of_graph_get_port_by_id function
> > 
> >  drivers/coresight/of_coresight.c  | 13 ++-
> >  drivers/gpu/drm/imx/imx-drm-core.c| 11 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 +++--
> >  drivers/media/platform/am437x/am437x-vpfe.c   |  1 -
> >  drivers/media/platform/soc_camera/soc_camera.c|  3 +-
> >  drivers/of/base.c | 41 +++-
> >  drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |  7 +---
> >  include/linux/of_graph.h  | 18 ++
> >  8 files changed, 61 insertions(+), 48 deletions(-)
> 

[PATCH] drm/i915: Fix modeset state confusion in the load detect code

[Linus Torvalds]

On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter  wrote:
>
> Fix this all by applying the same duct-tape as for the legacy setcrtc
> ioctl code and set crtc->primary->crtc properly.

Ack. Tests fine on the machine that showed issues for me.

I'll apply it manually directly to my tree, since I want to release
rc2 and I was holding that up in the hope this would get released (I
hate releasing even early rc's with issues that I know about and that
break machines I have access to).

If it ends up in your tree too and I'll get a duplicate commit later,
git will sort it all out, so it's fine.

Thanks,
Linus

[Bug 89405] radeon: *ERROR* invalid ioctl running weston-launch while X is running

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

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

Bug ID: 89405
   Summary: radeon: *ERROR* invalid ioctl running weston-launch
while X is running
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: fosero at gmail.com

Created attachment 113938
  --> https://bugs.freedesktop.org/attachment.cgi?id=113938=edit
weston-launch -u as root

If I try to start a weston instance by using weston-launch, while gdm on X is
running I get the following kernel message :

[di mrt  3 09:39:01 2015] [drm:radeon_cp_getparam_kms] *ERROR* invalid ioctl
with kms radeon_cp_getparam_kms
[di mrt  3 09:39:01 2015] [drm:radeon_engine_reset_kms] *ERROR* invalid ioctl
with kms radeon_engine_reset_kms

weston-launch refuses to run, attached a log of its debug output.

kernel - 3.19.0
libdrm - 2.4.59

RS780

weston/wayland 1.7

-- 
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/20150303/55e269dc/attachment.html>

[PATCH] drm/imx: ipuv3-crtc: Allow to divide DI clock from TVEv2

[Philipp Zabel]

Am Montag, den 02.03.2015, 16:40 +0100 schrieb Lucas Stach:
> Am Montag, den 02.03.2015, 16:24 +0100 schrieb Philipp Zabel:
> > This patch allows the IPU to divide the 27 MHz input clock from
> > the TVE by two to obtain the 13.5 MHz pixel clock needed for
> > NTSC/PAL SD modes.
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/gpu/drm/imx/ipuv3-crtc.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > index 35a3375..11a8d868 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > @@ -161,13 +161,16 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
> > __func__, encoder_types);
> >  
> > /*
> > -* If we have DAC, TVDAC or LDB, then we need the IPU DI clock
> > -* to be the same as the LDB DI clock.
> > +* If we have DAC or LDB, then we need the IPU DI clock to be
> > +* the same as the LDB DI clock. For TVDAC, derive the IPU DI
> > +* clock from 27 MHz TVE_DI clock, but allow to divide it.
> >  */
> > if (encoder_types & (BIT(DRM_MODE_ENCODER_DAC) |
> >  BIT(DRM_MODE_ENCODER_TVDAC) |
> 
> I suppose the above line has to be removed for this to work properly.

You are right. I'll fix that.

> >  BIT(DRM_MODE_ENCODER_LVDS)))
> > sig_cfg.clkflags = IPU_DI_CLKMODE_SYNC | IPU_DI_CLKMODE_EXT;
> > +   else if (encoder_types & BIT(DRM_MODE_ENCODER_TVDAC))
> > +   sig_cfg.clkflags = IPU_DI_CLKMODE_EXT;
> > else
> > sig_cfg.clkflags = 0;
> >  

thanks
Philipp

[PATCH] drm/radeon: fix DRM_IOCTL_RADEON_CS oops

[Alex Deucher]

On Tue, Mar 3, 2015 at 4:10 AM, Christian König  
wrote:
> Good catch.
>
> Patch is Reviewed-by: Christian König 
>
> Regards,
> Christian.
>

Applied to my -fixes tree.  Thanks!

Alex

>
> On 02.03.2015 20:36, Tommi Rantala wrote:
>>
>> Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
>> following oops.
>>
>> Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().
>>
>> --
>>
>>   #include 
>>   #include 
>>   #include 
>>   #include 
>>   #include 
>>
>>   static const struct drm_radeon_cs cs;
>>
>>   int main(int argc, char **argv)
>>   {
>>   return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, );
>>   }
>>
>> --
>>
>> [ttrantal at test2 ~]$ ./main /dev/dri/card0
>> [   46.904650] BUG: unable to handle kernel NULL pointer dereference at
>> (null)
>> [   46.905022] IP: [] list_sort+0x42/0x240
>> [   46.905022] PGD 68f29067 PUD 688b5067 PMD 0
>> [   46.905022] Oops: 0002 [#1] SMP
>> [   46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58
>> [   46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form
>> Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
>> [   46.905022] task: 880058e2bcc0 ti: 880058e64000 task.ti:
>> 880058e64000
>> [   46.905022] RIP: 0010:[]  []
>> list_sort+0x42/0x240
>> [   46.905022] RSP: 0018:880058e67998  EFLAGS: 00010246
>> [   46.905022] RAX:  RBX:  RCX:
>> 
>> [   46.905022] RDX: 81644410 RSI: 880058e67b40 RDI:
>> 880058e67a58
>> [   46.905022] RBP: 880058e67a88 R08:  R09:
>> 
>> [   46.905022] R10: 880058e2bcc0 R11: 828e6ca0 R12:
>> 81644410
>> [   46.905022] R13: 8800694b8018 R14:  R15:
>> 880058e679b0
>> [   46.905022] FS:  7fdc65a65700() GS:88006d60()
>> knlGS:
>> [   46.905022] CS:  0010 DS:  ES:  CR0: 80050033
>> [   46.905022] CR2:  CR3: 58dd9000 CR4:
>> 06f0
>> [   46.905022] DR0:  DR1:  DR2:
>> 
>> [   46.905022] DR3:  DR6: 4ff0 DR7:
>> 0400
>> [   46.905022] Stack:
>> [   46.905022]  880058e67b40 880058e2bcc0 880058e67a78
>> 
>> [   46.905022]    
>> 
>> [   46.905022]    
>> 
>> [   46.905022] Call Trace:
>> [   46.905022]  [] radeon_cs_parser_fini+0x195/0x220
>> [   46.905022]  [] radeon_cs_ioctl+0xa9/0x960
>> [   46.905022]  [] drm_ioctl+0x19c/0x640
>> [   46.905022]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
>> [   46.905022]  [] ? trace_hardirqs_on+0xd/0x10
>> [   46.905022]  [] radeon_drm_ioctl+0x46/0x80
>> [   46.905022]  [] do_vfs_ioctl+0x318/0x570
>> [   46.905022]  [] ? selinux_file_ioctl+0x56/0x110
>> [   46.905022]  [] SyS_ioctl+0x81/0xa0
>> [   46.905022]  [] system_call_fastpath+0x12/0x17
>> [   46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff
>> ff
>> ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08
>> <48> c7
>> 00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85
>> [   46.905022] RIP  [] list_sort+0x42/0x240
>> [   46.905022]  RSP 
>> [   46.905022] CR2: 
>> [   47.149253] ---[ end trace 09576b4e8b2c20b8 ]---
>>
>> Signed-off-by: Tommi Rantala 
>> ---
>>   drivers/gpu/drm/radeon/radeon_cs.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
>> b/drivers/gpu/drm/radeon/radeon_cs.c
>> index a579ed3..4d0f96c 100644
>> --- a/drivers/gpu/drm/radeon/radeon_cs.c
>> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
>> @@ -256,11 +256,13 @@ int radeon_cs_parser_init(struct radeon_cs_parser
>> *p, void *data)
>> u32 ring = RADEON_CS_RING_GFX;
>> s32 priority = 0;
>>   + INIT_LIST_HEAD(>validated);
>> +
>> if (!cs->num_chunks) {
>> return 0;
>> }
>> +
>> /* get chunks */
>> -   INIT_LIST_HEAD(>validated);
>> p->idx = 0;
>> p->ib.sa_bo = NULL;
>> p->const_ib.sa_bo = NULL;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 94171] New: ati multihead black on one output

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

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

Bug ID: 94171
   Summary: ati multihead black on one output
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16, 3.19, 4.0rc1
  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: mrmazda at earthlink.net
Regression: Yes

Created attachment 168641
  --> https://bugzilla.kernel.org/attachment.cgi?id=168641=edit
dmesg using cedar and 3.19.0 with drm.debug=0x0E on cmdline

ATI mailing list
http://lists.x.org/archives/xorg-driver-ati/2015-February/027079.html response
suggested I file this and that bug 91861 might be related, so I used that bug
as a guide to choosing input fields here. I'm just a user/tester who does not
build. http://marc.info/?l=linux-ide=142517892627960=2 explains that
booting test machine to openSUSE 13.2 3.16.7, openSUSE Tumbleweed 3.19.0 and
Rawhide 4.0.0.rc1 is currently somewhat painful due to long boot delay.

Cut and paste from mailing list:

[paste]
Whether starting X including this:
xrandr --dpi 144 --output DVI-0 --mode 1920x1080 --above VGA-0 --output VGA-0
--primary --mode 1920x1440 # ati dual

works or not depends on which Radeon gfxcard used, and how new the software.

The cards' info:
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/hwinfo-gfx-rv380fan.txt X600
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/hwinfo-gfx-rv516.txt X1300
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/hwinfo-gfx-cedarPC-big41.txt

rv380 works as expected regardless at least as far back as openSUSE 13.1 k3.12.
openSUSE Tumbleweed 3.19.0:
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440xover1080-rv380fan-OK

cedar works as expected as recently as Mageia 4 k3.12 and openSUSE 13.1 k3.12:
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440over1080-os131-cedarOK
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440-over1080-mag4-cedarOK

Failures in the form of black screen on only one output using rv516 and cedar
in the following:
Fedora 20 k3.17.7 cedar (black VGA):
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080OK-f20-cedar
openSUSE 13.2 k3.16.7 cedar (black VGA):
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080OK-os132-cedar
Fedora 21 cedar (black VGA):
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080OK-cedarF21-k3177
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080OK-cedarF21-k3187
openSUSE Tumbleweed k3.19.0 rv516 (black DVI):
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440OKxover1080bad-rv516
openSUSE Tumbleweed k3.19.0 cedar (black VGA):
http://fm.no-ip.com/Tmp/Linux/Xorg/ATIdual/xorg.0.log-under1440bad-over1080OK-cedar

All of above pertains to same system, with only changes made being:

1-which OS booted
2-which ATI gfxcard installed

With necessary xrandr output descriptors for Intel, results are as expected
using onboard Intel gfx instead of ATI PCIe cards.

On cedar in Tumbleweed at least, dropping analog output mode from 1920x1440 to
1600x1200 produces expected output. 
[/paste]

Dropping analog output mode from 1920x1440 to 1600x1200 on rv516 in Tumbleweed
3.19.0 does not help. With rv516, Rawhide 4.0.0rc1.gt2.1 produces boot tty1
oopses instead of booting if both video cables are connected, boots normally
with only VGA cable connected, and locks up after 32 seconds with only DVI
cable connected.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #75 from Maarten Lankhorst  ---
Michel, enabling irqs before checking the fence signaling was exactly what I
was doing already, I'm hoping the attachment plus the branch is enough. :)

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

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

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

--- Comment #34 from Erik  ---
Same issue with a HD4290 (RS880). My motherboard has AM3+ socket so is not
obsolete hardware, it's support uvd2 and the last AMD procesors. It would be
nice to fix it. If you need some help i can dirty my hands too :)

-- 
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/20150303/b2e274b6/attachment.html>

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #74 from Alex Deucher  ---
posting reads implemented here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=posting-read

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

[Bug 89374] Firefox smooth scrolling isn't smooth

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

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

--- Comment #3 from Michel Dänzer  ---
No need to install any additional packages, just put something like this in
/etc/X11/xorg.conf:

Section "Device"
Identifier "Device0"
Driver  "radeon"
Option  "AccelMethod" "glamor"
EndSection

-- 
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/20150303/f0ad4a3f/attachment.html>

[PATCH] drm: adv7511: Refactor power management

[Chris Kohn]

Hi Laurent,

> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinchart+renesas at ideasonboard.com]
> Sent: Monday, March 02, 2015 5:20 AM
> To: dri-devel at lists.freedesktop.org
> Cc: Lars-Peter Clausen; Chris Kohn; Hyun Kwon
> Subject: [PATCH] drm: adv7511: Refactor power management
> 
> From: Laurent Pinchart 
> 
> Remove the internal dependency on DPMS mode for power management by
> using a by a powered state boolean instead, and use the new power off handler
> at probe time. This ensure that the regmap cache is properly marked as dirty
> when the device is probed, and the registers properly synced during the first
> power up.
> 
> As a side effect this removes the initialization of current_edid_segment at 
> probe
> time, as the field will be initialized when the device is powered on, at the 
> latest
> right before reading EDID data.
> 
> Signed-off-by: Laurent Pinchart 

Works fine on my platform.

Tested-by: Christian Kohn 

Cheers,
Chris

> ---
>  drivers/gpu/drm/i2c/adv7511.c | 97 +++--
> --
>  1 file changed, 51 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
> index fa140e04d5fa..7fb7e22f4ad1 100644
> --- a/drivers/gpu/drm/i2c/adv7511.c
> +++ b/drivers/gpu/drm/i2c/adv7511.c
> @@ -27,7 +27,7 @@ struct adv7511 {
>   struct regmap *regmap;
>   struct regmap *packet_memory_regmap;
>   enum drm_connector_status status;
> - int dpms_mode;
> + bool powered;
> 
>   unsigned int f_tmds;
> 
> @@ -357,6 +357,46 @@ static void adv7511_set_link_config(struct adv7511
> *adv7511,
>   adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB;
> }
> 
> +static void adv7511_power_on(struct adv7511 *adv7511) {
> + adv7511->current_edid_segment = -1;
> +
> + regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
> +  ADV7511_INT0_EDID_READY |
> ADV7511_INT1_DDC_ERROR);
> + regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> +ADV7511_POWER_POWER_DOWN, 0);
> +
> + /*
> +  * Per spec it is allowed to pulse the HDP signal to indicate that the
> +  * EDID information has changed. Some monitors do this when they
> wakeup
> +  * from standby or are enabled. When the HDP goes low the adv7511 is
> +  * reset and the outputs are disabled which might cause the monitor to
> +  * go to standby again. To avoid this we ignore the HDP pin for the
> +  * first few seconds after enabling the output.
> +  */
> + regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
> +ADV7511_REG_POWER2_HDP_SRC_MASK,
> +ADV7511_REG_POWER2_HDP_SRC_NONE);
> +
> + /*
> +  * Most of the registers are reset during power down or when HPD is
> low.
> +  */
> + regcache_sync(adv7511->regmap);
> +
> + adv7511->powered = true;
> +}
> +
> +static void adv7511_power_off(struct adv7511 *adv7511) {
> + /* TODO: setup additional power down modes */
> + regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> +ADV7511_POWER_POWER_DOWN,
> +ADV7511_POWER_POWER_DOWN);
> + regcache_mark_dirty(adv7511->regmap);
> +
> + adv7511->powered = false;
> +}
> +
>  /* 
> -
>   * Interrupt and hotplug detection
>   */
> @@ -526,7 +566,7 @@ static int adv7511_get_modes(struct drm_encoder
> *encoder,
>   unsigned int count;
> 
>   /* Reading the EDID only works if the device is powered */
> - if (adv7511->dpms_mode != DRM_MODE_DPMS_ON) {
> + if (!adv7511->powered) {
>   regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
>ADV7511_INT0_EDID_READY |
> ADV7511_INT1_DDC_ERROR);
>   regmap_update_bits(adv7511->regmap,
> ADV7511_REG_POWER, @@ -536,7 +576,7 @@ static int
> adv7511_get_modes(struct drm_encoder *encoder,
> 
>   edid = drm_do_get_edid(connector, adv7511_get_edid_block,
> adv7511);
> 
> - if (adv7511->dpms_mode != DRM_MODE_DPMS_ON)
> + if (!adv7511->powered)
>   regmap_update_bits(adv7511->regmap,
> ADV7511_REG_POWER,
>  ADV7511_POWER_POWER_DOWN,
>  ADV7511_POWER_POWER_DOWN);
> @@ -558,41 +598,10 @@ static void adv7511_encoder_dpms(struct
> drm_encoder *encoder, int mode)  {
>   struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
> 
> - switch (mode) {
> - case DRM_MODE_DPMS_ON:
> - adv7511->current_edid_segment = -1;
> -
> - regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
> -  ADV7511_INT0_EDID_READY |
> ADV7511_INT1_DDC_ERROR);
> - regmap_update_bits(adv7511->regmap,
> ADV7511_REG_POWER,
> -ADV7511_POWER_POWER_DOWN, 0);
> - /*
> -  * Per spec it is 

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #73 from Michel Dänzer  ---
(In reply to Alex Deucher from comment #72)
> Does reading any arbitrary register also work?  E.g., SRBM_STATUS

I think that would indeed be the right thing to do here, to prevent the PCIe
bridge from delaying the register writes.

Probably better to also check the fence status again after enabling the IRQ, to
handle the case where the hardware might signal the fence after we check its
status but before we enable the IRQ.

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