linux/drivers/gpu/drm, branch v3.4.11

drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot

2012-09-14T17:00:33Z

commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream. This will cause udev to load vmwgfx instead of waiting for X to do it. Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

Revert "drm/radeon: fix bo creation retry path"

2012-09-14T17:00:19Z

commit 676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7 upstream. This reverts commit d1c7871ddb1f588b8eb35affd9ee1a3d5e11cd0c. ttm_bo_init() destroys the BO on failure. So this patch makes the retry path work with freed memory. This ends up causing kernel panics when this path is hit. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm: stop vmgfx driver explosion

2012-09-14T17:00:19Z

commit f5869a8308f77e3dfdc2e3640842b285aa788ff8 upstream. If you do a page flip with no flags set then event is NULL. If event is NULL then the vmw_gfx driver likes to go digging into NULL and extracts NULL->base.file_priv. On a modern kernel with NULL mapping protection it's just another oops, without it there are some "intriguing" possibilities. What it should do is an open question but that for the driver owners to sort out. Signed-off-by: Alan Cox Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix bank tiling parameters on evergreen

2012-08-26T22:00:42Z

commit c8d15edc17d836686d1f071e564800e1a2724fa6 upstream. Handle the 16 bank case. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix bank tiling parameters on cayman

2012-08-26T22:00:41Z

commit 5b23c9045a8b61352986270b2d109edf5085e113 upstream. Handle the 16 bank case. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/radeon: do not reenable crtc after moving vram start address

2012-08-26T22:00:41Z

commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream. It seems we can not update the crtc scanout address. After disabling crtc, update to base address do not take effect after crtc being reenable leading to at least frame being scanout from the old crtc base address. Disabling crtc display request lead to same behavior. So after changing the vram address if we don't keep crtc disabled we will have the GPU trying to read some random system memory address with some iommu this will broke the crtc engine and will lead to broken display and iommu error message. So to avoid this, disable crtc. For flicker less boot we will need to avoid moving the vram start address. This patch should also fix : https://bugs.freedesktop.org/show_bug.cgi?id=42373 Signed-off-by: Jerome Glisse Signed-off-by: Greg Kroah-Hartman

drm/radeon: properly handle crtc powergating

2012-08-26T22:00:41Z

commit 6c0ae2ab85fc4a95cae82047a7db1f688a7737ab upstream. Need to make sure the crtc is gated on before modesetting. Explicitly gate the crtc on in prepare() and set a flag so that the dpms functions don't gate it off during mode set. Noticed by sylware on IRC. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/i915: reorder edp disabling to fix ivb MacBook Air

2012-08-26T22:00:40Z

commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 upstream. eDP is tons of fun. It turns out that at least the new MacBook Air 5,1 model absolutely doesn't like the new force vdd dance we've introduced in commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 Author: Daniel Vetter Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel But that patch also tried to fix some neat edp sequence issue with the force_vdd timings. Closer inspection reveals that we've raised force_vdd only to do the aux channel communication dp_sink_dpms. If we move the edp_panel_off below that, we don't need any force_vdd for the disable sequence, which makes the Air happy. Unfortunately the reporter of the original bug that the above commit fixed is travelling, so we can't test whether this regresses things. But my theory is that since we don't check for any power-off -> force_vdd-on delays in edp_panel_vdd_on, this was the actual root-cause of this failure. With that force_vdd dance completely eliminated, I'm hopeful the original bug stays fixed, too. For reference the old bug, which hopefully doesn't get broken by this: https://bugzilla.kernel.org/show_bug.cgi?id=43163 In any case, regression fixers win over plain bugfixes, so this needs to go in asap. v2: The crucial pieces seems to be to clear the force_vdd flag uncoditionally, too, in edp_panel_off. Looks like this is left behind by the firmware somehow. v3: The Apple firmware seems to switch off the panel on it's own, hence we still need to keep force_vdd on, but properly clear it when switching the panel off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671 Tested-by: Roberto Romer Tested-by: Daniel Wagner Tested-by: Keith Packard Cc: Keith Packard Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: ignore eDP bpc settings from vbt

2012-08-26T22:00:40Z

commit 4344b813f105a19f793f1fd93ad775b784648b95 upstream. This has originally been introduced to not oversubscribe the dp links in commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18 Author: Zhenyu Wang Date: Tue Jan 12 05:38:31 2010 +0800 drm/i915: fix pixel color depth setting on eDP Since then we've fixed up the dp link bandwidth calculation code and should now automatically fall back to 6bpc dithering. So this is unnecessary. Furthermore it seems to break the new MacbookPro with retina display, hence let's just rip this out. Reported-by: Benoit Gschwind Cc: Benoit Gschwind Cc: Francois Rigaut Tested-by: Benoit Gschwind Tested-by: Bernhard Froemel Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman -- Testing feedback highgly welcome, and thanks for Benoit for finding out that the bpc computations are busted. -Daniel

drm/i915: correctly order the ring init sequence

2012-08-26T22:00:40Z

commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream. We may only start to set up the new register values after having confirmed that the ring is truely off. Otherwise the hw might lose the newly written register values. This is caught later on in the init sequence, when we check whether the register writes have stuck. Reviewed-by: Jani Nikula Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 Tested-by: Yang Guang Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman