3.15-rc2: i915 regression: only top 20% of screen works in X

Hi! After update to 3.15-rc2, only top 20% of screen works on X. 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

[PATCH 2/3] drm/plane-helper: Add drm_primary_helper_check_update()

On Wed, Apr 23, 2014 at 10:04:00AM -0700, Matt Roper wrote: > Pull the parameter checking from drm_primary_helper_update() out into > its own function; drivers that provide their own setplane() > implementations rather than using the helper may still want to share > this parameter checking logic.

[Bug 77835] X crash when using xrandr with R9 290X and 7870 for triple head

dri-devel/attachments/20140423/ff641e25/attachment.html>

[Bug 77582] [r600g] ogl-samples GL3.2 and GL3.3 tests doesn't run without overriding GL/GLSL version

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/32d89040/attachment-0001.html>

[Bug 77835] X crash when using xrandr with R9 290X and 7870 for triple head

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/73a14bdc/attachment.html>

[Bug 77835] X crash when using xrandr with R9 290X and 7870 for triple head

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/5c84b337/attachment.html>

[Bug 77835] X crash when using xrandr with R9 290X and 7870 for triple head

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

[Intel-gfx] [PATCH 1/3] drm: Check CRTC compatibility in setplane

On Wed, Apr 23, 2014 at 11:26:04AM -0700, Matt Roper wrote: > On Wed, Apr 23, 2014 at 08:03:50PM +0200, Daniel Vetter wrote: > > On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote: > > > The DRM core setplane code should check that the plane is usable on the > > > specified CRTC before

[Bug 77835] X crash when using xrandr with R9 290X and 7870 for triple head

use: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/7038db9b/attachment.html>

[Bug 77835] New: X crash when using xrandr with R9 290X and 7870 for triple head

el" "False" and "AccelMethod" "glamor" but it just freezes my X on startup. :) --Maik -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://list

[Intel-gfx] [PATCH 1/3] drm: Check CRTC compatibility in setplane

On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote: > The DRM core setplane code should check that the plane is usable on the > specified CRTC before calling into the driver. > > Prior to this patch, a plane's possible_crtcs field was purely > informational for userspace and was never

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote: > So, maybe you would like to finally address *my* point about TDA998x > and your solution in a way that provides a satisfactory answer. *Show* > how it can be done, or *outline* how it can be done. Let me be absolutely

[git pull] drm fixes

On Wednesday 23 April 2014 07:54:17 Dave Airlie wrote: > On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds > wrote: > > Dave, mind sending me a pull request for drm fixes? > > > > There's now at least these two: > > > > - "drm/radeon/aux: fix hpd assignment for aux bus" > > - "drm/radeon: use

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

On Wed, Apr 23, 2014 at 05:04:46PM +0200, Andrzej Hajda wrote: > On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote: > > Yes, I know that you're desperate to play that down, but you can't get > > Not true. I only try to find the best solution and the approach with > multiple re-probing just

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

The introduction of primary planes has apparently caused a bit of fb refcounting fun for people. That makes it a good time to clean up the arcane rules and slight differences between ->update_plane and ->set_config. The new rules are: - The core holds a reference for both the new and the old fb

[RFC 0/3] DRM driver for the ATMEL High end LCD controller

Hi Jean-Jacques, Am Freitag, den 18.04.2014, 11:45 +0200 schrieb Jean-Jacques Hiblot: > Hi, > > this patch serie implements a simple DRM driver for the ATMEL High end LCD > controller found in the SAMA5 familly. It's based on the tilcdc driver. > It uses the cma_helper for memory and fbdev

[git pull] drm fixes

Dave Airlie wrote: > On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds > wrote: >> Dave, mind sending me a pull request for drm fixes? >> >> There's now at least these two: >> >> - "drm/radeon/aux: fix hpd assignment for aux bus" >> - "drm/radeon: use fixed PPL ref divider if needed" >> >> that

[PATCH 1/2] drm: Simplify fb refcounting rules around ->update_plane

On Wed, Apr 23, 2014 at 4:45 PM, Matt Roper wrote: >> @@ -177,22 +176,7 @@ int drm_primary_helper_update(struct drm_plane *plane, >> struct drm_crtc *crtc, >> set.connectors = connector_list; >> set.num_connectors = num_connectors; >> >> - /* >> - * set_config() adjusts

[PATCH] drm/dp: Add missing kernel-doc

On Wed, 23 Apr 2014, Thierry Reding wrote: > From: Thierry Reding > > Commit 9dc4056026e0 (drm/dp: let drivers specify the name of the I2C- > over-AUX adapter) introduced a new field but didn't add the proper > kernel-doc for it. Thanks for fixing this. Reviewed-by: Jani Nikula >

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote: > On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote: >> On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote: >>> On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote: Separation of the interfaces exposed by the

[PATCH] drm: Introduce drm_fb_helper_prepare()

On Wed, Apr 23, 2014 at 03:40:46PM +0200, Thierry Reding wrote: > From: Thierry Reding > > To implement hotplug detection in a race-free manner, drivers must call > drm_kms_helper_poll_init() before hotplug events can be triggered. Such > events can be triggered right after any of the encoders

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

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/20140423/59e30fdd/attachment.html>

[PATCH] drm/dp: Add missing kernel-doc

From: Thierry Reding Commit 9dc4056026e0 (drm/dp: let drivers specify the name of the I2C- over-AUX adapter) introduced a new field but didn't add the proper kernel-doc for it. Signed-off-by: Thierry Reding --- include/drm/drm_dp_helper.h | 1 + 1 file changed, 1

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

merged patch. -- 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/20140423/6bf80fd7/attachment.html>

[PATCH 3/4] drm: Introduce drm_fb_helper_prepare()

rtunately lacks any form of markup, at least afaik :( > > > > I must admit I didn't check. I'll make sure I do that before sending out > > the next version. > > If it looks ugly I'm ok as-is, just wondered. Kerneldoc is a bit > simplistic ime. In the second version I just se

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

eon and test it -- 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/20140423/034d0931/attachment-0001.html>

[PATCH] drm: Introduce drm_fb_helper_prepare()

From: Thierry Reding To implement hotplug detection in a race-free manner, drivers must call drm_kms_helper_poll_init() before hotplug events can be triggered. Such events can be triggered right after any of the encoders or connectors are initialized. At the same time, if the

[RFC 4/5] drm: Introduce drm_set_unique()

lit-up of these core drm functions is > still a bit messy, so I don't mind if it's a bit inconsistent really. We > can do the suffling when someone bothers with the kerneldoc for all of > them and pulls it into the drm docbook. I ended up doing exactly that when I wrote the drm_set_unique() docbook pieces and I've sent out patches based on top of v2 of this patch just now. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/845e6645/attachment.sig>

[PATCH 2/2] drm: Document how to register devices without struct drm_bus

From: Thierry Reding With the recent addition of the drm_set_unique() function, devices can now be registered without requiring a drm_bus. Add a brief description to the DRM docbook to show how that can be achieved. Signed-off-by: Thierry Reding ---

[PATCH 1/2] drm: Add device registration documentation

From: Thierry Reding Describe how devices are registered using the drm_*_init() functions. Adding this to docbook requires a largish set of changes to the comments in drm_{pci,usb,platform}.c since they are doxygen-style rather than proper kernel-doc and therefore mess with

[PATCH v2] drm: Introduce drm_set_unique()

From: Thierry Reding Add a helper function that allows drivers to statically set the unique name of the device. This will allow platform and USB drivers to get rid of their DRM bus implementations and directly use drm_dev_alloc() and drm_dev_register(). Signed-off-by:

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

On 04/23/2014 02:55 PM, Laurent Pinchart wrote: > Hi Andrzej, > > On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote: >> On 04/23/2014 01:34 PM, Laurent Pinchart wrote: >>> On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote: On 04/21/2014 02:28 PM, YoungJun Cho wrote: > This

[PATCH] drm/tegra: restrict plane loops to legacy planes

In Matt Ropers primary plane series a set of prep patches like commit af2b653bfb4ef40931b4d101ca842ce0c5da57ef Author: Matt Roper Date: Tue Apr 1 15:22:32 2014 -0700 drm/i915: Restrict plane loops to only operate on overlay planes (v2) ensured that all exisiting users of the

[PATCH v2 04/10] drm/nouveau/fb: add GK20A support

On Wed, Apr 23, 2014 at 11:07 AM, Alexandre Courbot wrote: > On 04/22/2014 07:40 PM, Thierry Reding wrote: >> >> * PGP Signed by an unknown key >> >> >> On Mon, Apr 21, 2014 at 03:02:16PM +0900, Alexandre Courbot wrote: >> [...] >>> >>> diff --git

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

Hi Andrzej, On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote: > On 04/23/2014 01:34 PM, Laurent Pinchart wrote: > > On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote: > >> On 04/21/2014 02:28 PM, YoungJun Cho wrote: > >>> This patch adds DT bindings for s6e3fa0 panel. > >>> The

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

On 04/23/2014 01:34 PM, Laurent Pinchart wrote: > Hi Andrzej, > > On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote: >> On 04/21/2014 02:28 PM, YoungJun Cho wrote: >>> This patch adds DT bindings for s6e3fa0 panel. >>> The bindings describes panel resources, display timings and cpu timings.

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/5eb0751b/attachment.html>

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

Hi Andrzej, On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote: > On 04/21/2014 02:28 PM, YoungJun Cho wrote: > > This patch adds DT bindings for s6e3fa0 panel. > > The bindings describes panel resources, display timings and cpu timings. > > > > Changelog v2: > > - Adds unit address

[RFC PATCH 2/2 with seqcount v3] reservation: add suppport for read-only access using rcu

This adds 4 more functions to deal with rcu. reservation_object_get_fences_rcu() will obtain the list of shared and exclusive fences without obtaining the ww_mutex. reservation_object_wait_timeout_rcu() will wait on all fences of the reservation_object, without obtaining the ww_mutex.

[RFC 4/5] drm: Introduce drm_set_unique()

Hi On Wed, Apr 23, 2014 at 10:40 AM, Daniel Vetter wrote: > On Wed, Apr 23, 2014 at 09:17:16AM +0200, Thierry Reding wrote: >> On second thought, wouldn't this be better located in drm_stub.c? It >> isn't really related to the IOCTL code except that one of the IOCTLs now >> uses the information

[RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

Hi again Andrzej, On 04/23/2014 10:01 AM, YoungJun Cho wrote: > Hi Andrzej > > Thank you for comments. > > On 04/22/2014 09:15 PM, Andrzej Hajda wrote: >> Hi YoungJun, >> >> On 04/21/2014 02:28 PM, YoungJun Cho wrote: >>> Some phy control registers are not kept after software reset. >>> So this

[PULL] drm init cleanup for drm-next

On Wed, Apr 23, 2014 at 12:26:53PM +0200, Daniel Vetter wrote: > Hi Dave, > > Next pull request, this time more of the drm de-midlayering work. The big > thing is that his patch series here removes everything from drm_bus except > the set_busid callback. Thierry has a few more patches on top of

[PULL] drm init cleanup for drm-next

Hi Dave, Next pull request, this time more of the drm de-midlayering work. The big thing is that his patch series here removes everything from drm_bus except the set_busid callback. Thierry has a few more patches on top of this to make that one optional to. With that we can ditch all the non-pci

[RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

Hi YoungJun, On 04/21/2014 02:28 PM, YoungJun Cho wrote: > This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver. > > Changelog v2: > - Declares delay, size properties in probe routine instead of DT > Changelog v3: > - Moves CPU timings relevant properties from FIMD DT >

[Bug 74401] Radeon r600 has a pink-green tint

https://bugzilla.kernel.org/show_bug.cgi?id=74401 Ja?a Bartelj changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Intel-gfx] [PATCH 1/3] drm: Check CRTC compatibility in setplane

On Wed, Apr 23, 2014 at 08:03:50PM +0200, Daniel Vetter wrote: > On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote: > > The DRM core setplane code should check that the plane is usable on the > > specified CRTC before calling into the driver. > > > > Prior to this patch, a plane's

[PATCH v2 04/10] drm/nouveau/fb: add GK20A support

On 04/22/2014 07:40 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Mon, Apr 21, 2014 at 03:02:16PM +0900, Alexandre Courbot wrote: > [...] >> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c >> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c > [...] >> +

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

On 04/21/2014 02:28 PM, YoungJun Cho wrote: > This patch adds DT bindings for s6e3fa0 panel. > The bindings describes panel resources, display timings and cpu timings. > > Changelog v2: > - Adds unit address (commented by Sachin Kamat) > Changelog v3: > - Removes optional delay, size properties

[RFC 4/5] drm: Introduce drm_set_unique()

On Wed, Apr 23, 2014 at 09:17:16AM +0200, Thierry Reding wrote: > On Tue, Apr 22, 2014 at 05:48:07PM +0200, Daniel Vetter wrote: > > On Tue, Apr 22, 2014 at 05:09:32PM +0200, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > Add a helper function that allows drivers to statically set

[PATCH] drm/irq: track the irq installed in drm_irq_install in dev->irq

On Wed, Apr 23, 2014 at 09:27:58AM +0200, Thierry Reding wrote: > On Tue, Apr 22, 2014 at 10:44:20PM +0200, Daniel Vetter wrote: > [...] > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > > index 589e865832cd..7cf407bbfed5 100644 > > --- a/drivers/gpu/drm/drm_irq.c > > +++

[PATCH 2/2] drm: Handle ->disable_plane failures correctly

The ->disable_plane hook always had a return value, but only since the introduction of primary planes was there any implementation that actually failed. So handle such failures correctly. Note that drm_plane_force_disable is special: In the modeset cleanup case we first disable all crtc, so

[PATCH 1/2] drm: Simplify fb refcounting rules around ->update_plane

The introduction of primary planes has apparently caused a bit of fb refcounting fun for people. That makes it a good time to clean up the arcane rules and slight differences between ->update_plane and ->set_config. The new rules are: - The core holds a reference for both the new and the old fb

[RFC v2 PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420

On 04/21/2014 02:28 PM, YoungJun Cho wrote: > The offset of register DSIM_PLLTMR_REG in Exynos5420 is different > from the one in Exynos4 SoC. > > In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG, > and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead. > So

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

Hi Andrzej Thank you for comment. On 04/22/2014 11:02 PM, Andrzej Hajda wrote: > On 04/21/2014 02:28 PM, YoungJun Cho wrote: >> This patch adds DT bindings for s6e3fa0 panel. >> The bindings describes panel resources, display timings and cpu timings. >> >> Changelog v2: >> - Adds unit address

[RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

Hi Thierry Thank you for the comments. On 04/22/2014 04:34 PM, Thierry Reding wrote: > On Mon, Apr 21, 2014 at 09:28:33PM +0900, YoungJun Cho wrote: > [...] >> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h >> index 7209df1..244d197 100644 >> ---

[PATCH 2/3] drm/plane-helper: Add drm_primary_helper_check_update()

Pull the parameter checking from drm_primary_helper_update() out into its own function; drivers that provide their own setplane() implementations rather than using the helper may still want to share this parameter checking logic. A few of the checks here were also updated based on suggestions by

[PATCH 1/3] drm: Check CRTC compatibility in setplane

The DRM core setplane code should check that the plane is usable on the specified CRTC before calling into the driver. Prior to this patch, a plane's possible_crtcs field was purely informational for userspace and was never actually verified at the kernel level (aside from the primary plane

[RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

Hi Andrzej Thank you for comments. On 04/22/2014 09:15 PM, Andrzej Hajda wrote: > Hi YoungJun, > > On 04/21/2014 02:28 PM, YoungJun Cho wrote: >> Some phy control registers are not kept after software reset. >> So this patch makes the clocks containing phy control to be set >> after software

[PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

the panel has been enabled and we'll have to introduce .post_enable() and .pre_disable() functions. And worse, what if somebody needs something to be done between .pre_enable() and .enable()? .post_pre_enable()? Where does it end? According to the above description the only reason why we need this is to avoid visible glitches when the panel is already on, but the video stream hasn't started yet. If that's the only reason why we need this, then perhaps adding a way for a panel to expose the associated backlight would be better? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/380c83b6/attachment.sig>

[RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

On 04/23/2014 05:45 AM, YoungJun Cho wrote: > Hi again Andrzej, > > On 04/23/2014 10:01 AM, YoungJun Cho wrote: >> Hi Andrzej >> >> Thank you for comments. >> >> On 04/22/2014 09:15 PM, Andrzej Hajda wrote: >>> Hi YoungJun, >>> >>> On 04/21/2014 02:28 PM, YoungJun Cho wrote: Some phy control

[PATCH 3/4] drm: Introduce drm_fb_helper_prepare()

On Wed, Apr 23, 2014 at 09:14:41AM +0200, Thierry Reding wrote: > On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote: > > On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote: > [...] > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > > b/drivers/gpu/drm/drm_fb_helper.c >

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

ed DT bindings. I've been working on a patch to support both *-gpios and *-gpio variants with the GPIO descriptor framework. *-gpios makes sense if there can indeed be several, but for something like hotplug detection I don't think there's a reason to require the plural. Furthermore some bindin

[PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

On Tue, Apr 22, 2014 at 08:06:19PM +0530, Ajay kumar wrote: > Hi Thierry, > > > On Tue, Apr 22, 2014 at 1:49 PM, Thierry Reding > wrote: > > On Tue, Apr 22, 2014 at 04:09:11AM +0530, Ajay Kumar wrote: > >> Most of the panels need an init sequence as mentioned below: > >> -- poweron LCD

[PATCH] drm: Rip out totally bogus vga_switcheroo->can_switch locking

; include/drm/drmP.h | 2 +- > 4 files changed, 19 insertions(+), 16 deletions(-) Looks good: Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/ba02a92b/attachment.sig>

[PATCH] drm/irq: track the irq installed in drm_irq_install in dev->irq

cation/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/bc29b1c4/attachment.sig>

[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/c7a12b87/attachment.html>

[RFC 4/5] drm: Introduce drm_set_unique()

cally I think it belongs with the likes of drm_dev_alloc() and drm_dev_register(). Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/88e318bb/attachment.sig>

[PATCH 3/4] drm: Introduce drm_fb_helper_prepare()

generated DocBook? Afaik kerneldoc > unfortunately lacks any form of markup, at least afaik :( I must admit I didn't check. I'll make sure I do that before sending out the next version. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/dc7ba188/attachment.sig>

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

On Wed, Apr 23, 2014 at 05:37:30PM +0200, Daniel Vetter wrote: > The introduction of primary planes has apparently caused a bit of fb > refcounting fun for people. That makes it a good time to clean up the > arcane rules and slight differences between ->update_plane and > ->set_config. The new

An other radeon ring count patch

-- A non-text attachment was scrubbed... Name: 0001-drm-radeon-fix-count-in-uvd_v1_0_ring_test.patch Type: text/x-patch Size: 1035 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/18ddbecc/attachment-0001.bin>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/0d0e02f1/attachment.html>

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

On Wed, Apr 23, 2014 at 8:36 AM, Daniel Vetter wrote: > Hm, that's indeed a bit fishy. Otoh I don't understand how this blows > up with existing userspace since we should only hit this if userspace > does an explicit disable call on the primary plane through the ioctl. > It's a bug for sure

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

On Wed, Apr 23, 2014 at 3:08 AM, Matt Roper wrote: > On Tue, Apr 22, 2014 at 04:19:45PM +0200, Daniel Vetter wrote: >> The introduction of primary planes has apparently caused a bit of fb >> refcounting fun for people. That makes it a good time to clean up the >> arcane rules and slight

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/7682cbc0/attachment.html>

[git pull] drm fixes

On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds wrote: > Dave, mind sending me a pull request for drm fixes? > > There's now at least these two: > > - "drm/radeon/aux: fix hpd assignment for aux bus" > - "drm/radeon: use fixed PPL ref divider if needed" > > that look like fairly fatal

[PATCH] drm/tegra: restrict plane loops to legacy planes

On Wed, Apr 23, 2014 at 03:15:32PM +0200, Daniel Vetter wrote: > In Matt Ropers primary plane series a set of prep patches like > > commit af2b653bfb4ef40931b4d101ca842ce0c5da57ef > Author: Matt Roper > Date: Tue Apr 1 15:22:32 2014 -0700 > > drm/i915: Restrict plane loops to only operate

[PATCH 2/2] drm: Handle ->disable_plane failures correctly

On Wed, Apr 23, 2014 at 10:30:05AM +0200, Daniel Vetter wrote: > The ->disable_plane hook always had a return value, but only since the > introduction of primary planes was there any implementation that > actually failed. > > So handle such failures correctly. > > Note that

[PATCH 1/2] drm: Simplify fb refcounting rules around ->update_plane

On Wed, Apr 23, 2014 at 10:30:04AM +0200, Daniel Vetter wrote: > The introduction of primary planes has apparently caused a bit of fb > refcounting fun for people. That makes it a good time to clean up the > arcane rules and slight differences between ->update_plane and > ->set_config. The new

[Bug 73521] Screen backlight control fails on ASUS UX51VZ

https://bugzilla.kernel.org/show_bug.cgi?id=73521 Aaron Lu changed: What|Removed |Added Status|NEW |ASSIGNED CC|

[PATCH] drm/exynos: use %pad for dma_addr_t

(ctx->vblank_on) > schedule_work(>work); > -- > 1.7.10.4 > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/530db239/attachment.html>

[PATCH v2] drm/exynos: remove DRIVER_HAVE_IRQ feature

= exynos_drm_load, > .unload = exynos_drm_unload, > .suspend= exynos_drm_suspend, > -- > 1.8.1.2 > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/99449fd9/attachment.html>

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

description||STREET crash -- 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/20140423/6a5e92a2/attachment-0

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

description||Edition) -- 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/20140423/fb679e6a/attachment.html>

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

description||Edition) -- 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/20140423/f14f3cc9/attachment.html>

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

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

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140423/26c0a749/attachment.html>

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

https://bugs.freedesktop.org/show_bug.cgi?id=77784 --- Comment #4 from Jos? Su?rez --- I managed to switch to a VT between the a GPU recovery and a hang to save a dmesg log. See the dmesg and Xorg logs in comments 2 and 3. -- You are receiving this mail because: You are the assignee for the

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

https://bugs.freedesktop.org/show_bug.cgi?id=77784 --- Comment #3 from Jos? Su?rez --- Created attachment 97788 --> https://bugs.freedesktop.org/attachment.cgi?id=97788=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug. -- next part

[Bug 77784] Certain mono based games hang the system with radeonsi (probably llvm backend)

https://bugs.freedesktop.org/show_bug.cgi?id=77784 --- Comment #2 from Jos? Su?rez --- Created attachment 97787 --> https://bugs.freedesktop.org/attachment.cgi?id=97787=edit dmesg log -- You are receiving this mail because: You are the assignee for the bug. -- next part

[git pull] drm fixes

Hi Linus, this is just radeon fixes, primarily the two pll fix and the aux fix, it also disables dpm on rv770 gpus, fixes driver reloading, and fixes two issues with runtime PM on some GPUS. Dave. The following changes since commit 4d0fa8a0f01272d4de33704f20303dcecdb55df1: Merge tag