[Bug 82828] Regression: Crash in 3Dmark2001

nts/20140909/a1403aa9/attachment.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

? (A) : (B) ) -- 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/20140909/80f24f76/attachment.html>

3.7+ kernels and Radeon HD 4250 backlight

Hi! There is a notebook eMashines e442 142G25Mikk Model PEW86 with a video card Radeon HD 4250. Since a kernel 3.7.10 (tested until 3.16.1) it have a problem: screen is a white (not black) when PC is idle. A changes causing problem is: --- linux-3.6.11/drivers/gpu/drm/radeon/radeon_encoders.c

[RFC 3/3] drm/i915: Merge of visible and !visible paths for primary planes

On Tue, Sep 09, 2014 at 11:43:21AM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Fold intel_pipe_set_base() in the update primary plane path merging > pieces of code that are common to both paths. > > Basically the the pin/unpin procedures are the same for both paths > and some

[Bug 83221] laptop hangs after loading nouveau fails, pm_runtime_work thread dying

https://bugzilla.kernel.org/show_bug.cgi?id=83221 Karol Herbst changed: What|Removed |Added Resolution|--- |OBSOLETE Status|NEW

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

Can you try this 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/20140909/646d2612/attachment.html>

role of crtcs in modesetting interfaces and possible abstraction away from userspace

On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrj?l? wrote: > On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote: >> Hi, >> >> So I've been attempting to hide the 30" Dell MST monitors in the >> kernel, and ran into a number of problems, >> but the major one is how to steal a crtc and get away

[RFC 1/3] drm/i915: remove !enabled handling from commit primary plane step

On Tue, Sep 09, 2014 at 11:43:19AM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > The !crtc->enabled case will now be handled by the !visible code, > since the handling is basically the same. > > Signed-off-by: Gustavo Padovan > --- > drivers/gpu/drm/i915/intel_display.c | 26

[RFC 2/3] drm/i915: create intel_update_pipe_size()

On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Factor out a piece of code from intel_pipe_set_base() that updates > the pipe size and adjust fitter. > > This will help refactor the update primary plane path. > > Signed-off-by: Gustavo Padovan >

role of crtcs in modesetting interfaces and possible abstraction away from userspace

On 9 September 2014 10:43, Dave Airlie wrote: > Hi, > > So I've been attempting to hide the 30" Dell MST monitors in the > kernel, and ran into a number of problems, > but the major one is how to steal a crtc and get away with it. > > The standard scenario I have is > > CRTC 0: eDP monitor

[PATCH] drm/i915: pin sprite fb only if it changed

From: Gustavo Padovan Optimize code avoiding helding dev mutex if old fb and current fb are the same. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_sprite.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff

[Bug 66963] Rv6xx dpm problems

er and that's just on idle. -- 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/20140909/6dd350c4/attachment-0001.html>

[PATCH 3/3] drm/i915: Merge of visible and !visible paths for primary planes

From: Gustavo Padovan Fold intel_pipe_set_base() in the update primary plane path merging pieces of code that are common to both paths. Basically the the pin/unpin procedures are the same for both paths and some checks can also be shared (some of the were moved

[PATCH 2/3] drm/i915: create intel_update_pipe_size()

From: Gustavo Padovan Factor out a piece of code from intel_pipe_set_base() that updates the pipe size and adjust fitter. This will help refactor the update primary plane path. v2: use struct intel_crtc as argument to intel_update_pipe_size() Signed-off-by:

[PATCH 1/3] drm/i915: remove !enabled handling from commit primary plane step

From: Gustavo Padovan The !crtc->enabled case will now be handled by the !visible code, since the handling is basically the same. Signed-off-by: Gustavo Padovan Reviewed-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c | 26

[PATCH 11/11] drm/tiled: vague attempt at waving at cursors.

From: Dave Airlie This is going to be a bit of a reference counting nightmare, Since when we moved from one tile to the other, we need to transfer the framebuffer over between them. Also only universal is tackled here. Signed-off-by: Dave Airlie ---

[PATCH 10/11] drm/tiled: add page_flip support for multi-crtc monitors

From: Dave Airlie This is OMG bad, but in order to get semantics that don't defeat userspace we have to wait for both flips to complete. So rewrite the event handling code to make sure we wait for all crtcs in the tile group to complete flipping. The main problem otherwise

[PATCH 09/11] drm/crtc: workaround userspace trying to derail crtc stealing

From: Dave Airlie This is probably not the greatest idea in the world, but if userspace does a modesetting sequences initial state : crtc 0 -> eDP-1 modeset : crtc 1 -> DP-4 (dual crtc) we have to steal crtc 2 for DP-3 modeset : crtc 2 -> eDP-1 we are kind off stuck, so

[PATCH 08/11] drm/crtc: attempt to set tiled modes from userspace

From: Dave Airlie So when userspace asks us to set a mode on a tiled crtc, split it up and find the actual modes and attempt to set them. Also disable crtcs when no longer in tiled group. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_crtc.c| 51

[PATCH 07/11] drm/edid: allow patching the EDID to report monster mode

From: Dave Airlie This patches the EDID to add the special mode. TODO make this more generic. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_dp_mst_topology.c | 13 ++--- drivers/gpu/drm/drm_edid.c| 36 +++

[PATCH 06/11] drm/tile: attempt to set tiled crtcs up

From: Dave Airlie Using the tiling info attempt to set a mode across two crtcs --- drivers/gpu/drm/drm_crtc.c| 100 +- drivers/gpu/drm/drm_displayid.c | 13 - drivers/gpu/drm/drm_dp_mst_topology.c | 18 +-

[PATCH 05/11] drm/dp/mst: add concept of base connector id

From: Dave Airlie This gives us a base identifier to group tiled outputs from. However after reading about the Dell 5k monitor I expect this is probably too little, and we need some sort of hash table from the monitor EDID serial number. Signed-off-by: Dave Airlie ---

[PATCH 04/11] drm/displayid: add some DisplayID related defines/structs.

From: Dave Airlie Just enough to get the tiling info from a Dell 4k monitor. Signed-off-by: Dave Airlie --- drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_displayid.c| 68 ++ drivers/gpu/drm/drm_edid.c | 29

[PATCH 03/11] drm/mst: start caching edid for logical ports

From: Dave Airlie For the monitors with panels we only want EDID once, and they show up on logical ports, which are always connected. This is required as if we start hiding connector status we won't be able to get the EDID normally later. Signed-off-by: Dave Airlie ---

[PATCH 02/11] drm/i915: add config option to enable/disable DP MST

From: Dave Airlie Since DP MST has new userspace requirements and any effort at trying to shoehorn things into the something the current userspace can handle are doomed, lets just put this behind a config option. This also adds a command line arg to switch it on as well.

[PATCH 01/11] drm/mst: rework payload table allocation to conform better.

From: Dave Airlie The old code has problems with the Dell MST monitors due to some assumptions I made that weren't true. I initially thought the Virtual Channel Payload IDs had to be in the DPCD table in ascending order, however it appears that assumption is bogus. The old

[RFC] attempting to hide 30" monitor in kernel (raw)

All these are on top of rc3 (also in my drm-mst-hide-monitor branch). So after talking to Keith and Daniel in Chicago I decided to give another go at hiding the horror that is 30" 4k dual-panel MST monitors in the kernel. Also this hw is not going away, if anything it seems to be getting worse

[PATCH 9/9] drm/exynos/hdmi: unregister connector on removal

During component removal driver should unregister connector. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index

[PATCH 8/9] drm/exynos/dp: unregister connector on removal

During component removal driver should unregister connector. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_dp_core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index

[PATCH 7/9] drm/exynos/dpi: unregister connector and panel on removal

During component removal it should unregister connector and optionally detach the panel. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c

[PATCH 6/9] drm/exynos/dsi: unregister connector on removal

During component unbind connector should be unregistered. Also DSI host should be unregistered after KMS cleanup. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git

[PATCH 5/9] drm/exynos/crtc: fix framebuffer reference sequence

Adding reference to framebuffer should be accompanied with removing reference to old framebuffer assigned to the plane. This patch removes following warning: [ 95.038017] WARNING: CPU: 1 PID: 3067 at drivers/gpu/drm/drm_crtc.c:5115 drm_mode_config_cleanup+0x258/0x268() [ 95.048086] Modules

[PATCH 4/9] drm/exynos/fb: free exynos framebuffer on error

In case drm_framebuffer_init fails exynos_fb should be freed before returning an error. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c

[PATCH 3/9] drm/exynos/fbdev: fix fbdev gem object cleanup

exynos_gem_obj is used by exynos_drm_fbdev_destroy so it cannot be destroyed before calling the latter. exynos_gem_obj will be destroyed anyway by exynos_drm_fbdev_destroy->...->exynos_drm_fb_destroy. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 --- 1 file

[PATCH 2/9] drm/exynos: fix drm driver de-initialization order

Since components have their own cleanup routines calling drm_mode_config_cleanup before component_unbind_all causes errors due to double free of KMS objects. The patch fixes it by changing de-initialization order. Now it is exactly opposite to init order. Signed-off-by: Andrzej Hajda ---

[PATCH 1/9] drm/exynos/ipp: traverse ipp drivers list safely

On ipp subsystem removal list of ipp drivers is traversed and their members are deleted. To do it properly safe version of list_for_each* should be used. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH 0/9] drm/exynos: initialization/deinitialization fixes

This set of patches contains fixes of initialization and deinitialization code of exynos_drm core and components. It is based on exynos-drm-next branch. Patchset has been tested on trats and universal_c210 platforms. Regards Andrzej Andrzej Hajda (9): drm/exynos/ipp: traverse ipp drivers

[RFC 2/3] drm/i915: create intel_update_pipe_size()

2014-09-09 Ville Syrj?l? : > On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Factor out a piece of code from intel_pipe_set_base() that updates > > the pipe size and adjust fitter. > > > > This will help refactor the update primary plane path.

[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

vel/attachments/20140909/5b7ff192/attachment.sig>

[PATCH v2 4/4] imx-drm: ipuv3-plane: fix plane updates for active planes

While the DMA channel is running, it is not allowed to change anything but the inactive (double) buffer base address, so resizing a plane or changing to a frame buffer with different pixel format is not possible. Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipuv3-plane.c | 15

[PATCH v2 3/4] imx-drm: ipuv3-plane: enable double buffering

This allows to update the buffer base address while the DMA channel is running. It is needed to flip the frame buffer of an active plane. Signed-off-by: Philipp Zabel --- Change since v1: - Added missing ipu_idmac_select_buffer call to make the hardware double buffering actually consider the

[PATCH v2 2/4] imx-drm: ipuv3-plane: move stride setting out of base setup

Setting the stride can only be done on inactive channels, while the buffer base address can also be updated for running channels using the hardware double buffering feature. Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipuv3-plane.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH v2 1/4] imx-drm: ipuv3-plane: allow local alpha in ipu_plane_mode_set()

For the overlay plane scanning out a framebuffer with an alpha component, enable the DP local alpha feature on the partial plane. Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipuv3-plane.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

[PATCH 1/4] imx-drm: ipuv3-plane: allow local alpha in ipu_plane_mode_set()

Am Montag, den 08.09.2014, 12:50 -0700 schrieb Greg Kroah-Hartman: > On Tue, Jul 29, 2014 at 11:57:06AM +0200, Philipp Zabel wrote: > > For the overlay plane scanning out a framebuffer with an alpha component, > > enable the DP local alpha feature on the partial plane. > > > > Signed-off-by:

[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag

gt; > PAGE_SHIFT)); > + bo->placements[i].lpfn = max_offset >> PAGE_SHIFT; > > - bo->placements[i].lpfn = lpfn; > bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; > } > > -- > 2.1.0 > > > -- > Earthling Michel D?nzer| http://www.amd.com > Libre software enthusiast |Mesa and X developer -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-add-RADEON_GEM_NO_CPU_ACCESS-BO-creation-.patch Type: text/x-diff Size: 1804 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/073b383f/attachment.patch>

[PATCH] drm/radeon/dpm: set the thermal type properly for special configs

On systems with special thermal configurations make sure we make note of the thermal setup. This is required for proper firmware configuration on these systems. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_atombios.c | 26

[RFC 3/3] drm/i915: Merge of visible and !visible paths for primary planes

From: Gustavo Padovan Fold intel_pipe_set_base() in the update primary plane path merging pieces of code that are common to both paths. Basically the the pin/unpin procedures are the same for both paths and some checks can also be shared (some of the were moved

[RFC 2/3] drm/i915: create intel_update_pipe_size()

From: Gustavo Padovan Factor out a piece of code from intel_pipe_set_base() that updates the pipe size and adjust fitter. This will help refactor the update primary plane path. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 71

[RFC 1/3] drm/i915: remove !enabled handling from commit primary plane step

From: Gustavo Padovan The !crtc->enabled case will now be handled by the !visible code, since the handling is basically the same. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 26 -- 1 file changed, 26

role of crtcs in modesetting interfaces and possible abstraction away from userspace

On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote: > Hi, > > So I've been attempting to hide the 30" Dell MST monitors in the > kernel, and ran into a number of problems, > but the major one is how to steal a crtc and get away with it. > > The standard scenario I have is > > CRTC 0:

[PATCH] drm/radeon: reduce memory footprint for debugging

On Mon, 2014-09-08 at 18:28 -0400, Alex Deucher wrote: > On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko > wrote: > > There is no need to use hex_dump_to_buffer() since we have a kernel helper > > to > > dump up to 64 bytes just via printk(). In our case the actual size is 15 > > bytes. > > > >

[PATCH v2 5/8] ARM: dts: am33xx: Add external clock provider

On 09/09/2014 02:30 AM, Tony Lindgren wrote: > * Jyri Sarha [140818 14:49]: >> Add external clock provider for am33xx devices. > > Please send all the .dts and defconfig changes separately > so I can pick them up and we don't get pointless merge > conflicts. Moreover, this patch is obsolete now,

[PATCH] drm/radeon: reduce memory footprint for debugging

On Tue, Sep 9, 2014 at 4:14 AM, Andy Shevchenko wrote: > On Mon, 2014-09-08 at 18:28 -0400, Alex Deucher wrote: >> On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko >> wrote: >> > There is no need to use hex_dump_to_buffer() since we have a kernel helper >> > to >> > dump up to 64 bytes just via

[RFC] attempting to hide 30" monitor in kernel (raw)

On Tue, Sep 09, 2014 at 04:28:05PM +1000, Dave Airlie wrote: > All these are on top of rc3 (also in my drm-mst-hide-monitor branch). > > So after talking to Keith and Daniel in Chicago I decided to give > another go at hiding the horror that is 30" 4k dual-panel MST > monitors in the kernel. > >

[PATCH 02/11] drm/i915: add config option to enable/disable DP MST

On Tue, 09 Sep 2014, Dave Airlie wrote: > From: Dave Airlie > > Since DP MST has new userspace requirements and any effort at trying > to shoehorn things into the something the current userspace can handle are > doomed, lets just put this behind a config option. > > This also adds a command line

role of crtcs in modesetting interfaces and possible abstraction away from userspace

Hi, So I've been attempting to hide the 30" Dell MST monitors in the kernel, and ran into a number of problems, but the major one is how to steal a crtc and get away with it. The standard scenario I have is CRTC 0: eDP monitor connected hotplug 30" monitor, userspace decides to configure

[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag

On 09.09.2014 09:47, Michel D?nzer wrote: > On 09.09.2014 02:36, Alex Deucher wrote: >> >> Updated version with comments integrated. > > [...] > >> @@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo >> *bo, u32 domain, u64 max_offset, >> unsigned lpfn = 0; >> >>

[PATCH v5 00/11] drm: add support for Atmel HLCDC Display Controller

I used this patch to add LCD support on our SBC-SAMA5d36 with a mainline kernel and it works properly. I used fb-test to test the framebuffer and I tested the DRI device with modetest and I can set a mode and set planes. Tested-by: Anthony Harivel -Original Message- From: Boris

[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

k for the irq. If yes, sleep a bit and go back to start. So if the irq work created new work for the wq, we flush that. And if that work created new work for the irq, we check that again. Etc. 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/20140909/0ef9ea4d/attachment.sig>

[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag

On 09.09.2014 02:36, Alex Deucher wrote: > > Updated version with comments integrated. [...] > @@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 > domain, u64 max_offset, > unsigned lpfn = 0; > > /* force to pin into visible video ram */ >

[PATCH 0/2] Two imx-drm oops fixes

On Tue, Sep 09, 2014 at 11:13:41PM +0800, Shawn Guo wrote: > On Mon, Sep 08, 2014 at 12:09:49PM -0700, Greg Kroah-Hartman wrote: > > On Mon, Sep 08, 2014 at 12:08:59PM -0700, Greg Kroah-Hartman wrote: > > > On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote: > > > > Greg, > >

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140909/949ad7c0/attachment.html>

[Bug 68799] [APITRACE] Hyper-Z lockup with Falcon BMS 4.32u6 on CAYMAN

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/d997f5e5/attachment.html>

[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

On Tue, Sep 9, 2014 at 3:07 AM, Tomi Valkeinen wrote: > lockdep won't complain though since you essentially open-code a workqueue_flush, and lockdep also doesn't complain about all possible deadlocks (due to some design issues with lockdep). >>> >>> What do you mean "open-code a

[Bug 83616] System crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

https://bugzilla.kernel.org/show_bug.cgi?id=78221 --- Comment #22 from t3st3r at mail.ru --- Attempted to test on 3.17-rc4. Result: crashed in about 3 minutes of run (see below). Are some stability fixes missing 3.17-rc4 mainline? At first glance I do not see radeon-related commits in drm-fixes

[Bug 83262] Radeon DPM re-clocking fails after resume from suspend

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

[Bug 83262] Radeon DPM re-clocking fails after resume from suspend

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

[Bug 83262] Radeon DPM re-clocking fails after resume from suspend

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

[Bug 83262] Radeon DPM re-clocking fails after resume from suspend

ext part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/36b11d2f/attachment.html>

[Bug 83262] Radeon DPM re-clocking fails after resume from suspend

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

role of crtcs in modesetting interfaces and possible abstraction away from userspace

Dave Airlie writes: > Hi, > > So I've been attempting to hide the 30" Dell MST monitors in the > kernel, and ran into a number of problems, > but the major one is how to steal a crtc and get away with it. > > The standard scenario I have is > > CRTC 0: eDP monitor connected > > hotplug 30"