user/sven/linux.git/drivers/gpu, branch v3.9.7

drm/nv50/kms: use dac loadval from vbios, where it's available

2013-06-20T19:01:31Z

commit d40ee48acde16894fb3b241d7e896d5fa84e0f10 upstream. Regression from merging the old nv50/nvd9 code together, and may be needed to fully fix fdo#64904. The value is ignored completely by the hardware starting from nva3. Reported-by: Emil Velikov Signed-off-by: Ben Skeggs

drm/nv50/disp: force dac power state during load detect

2013-06-20T19:01:31Z

commit ea9197cc323839ef3d5280c0453b2c622caa6bc7 upstream. fdo#64904 Reported-by: Gerhard Bräunlich Signed-off-by: Ben Skeggs

drm/i915: prefer VBT modes for SVDO-LVDS over EDID

2013-06-20T19:01:30Z

commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 upstream. In commit 53d3b4d7778daf15900867336c85d3f8dd70600c Author: Egbert Eich Date: Tue Jun 4 17:13:21 2013 +0200 drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC Egbert Eich fixed a long-standing bug where we simply used a non-working i2c controller to read the EDID for SDVO-LVDS panels. Unfortunately some machines seem to not be able to cope with the mode provided in the EDID. Specifically they seem to not be able to cope with a 4x pixel mutliplier instead of a 2x one, which seems to have been worked around by slightly changing the panels native mode in the VBT so that the dotclock is just barely above 50MHz. Since it took forever to notice the breakage it's fairly safe to assume that at least for SDVO-LVDS panels the VBT contains fairly sane data. So just switch around the order and use VBT modes first. v2: Also add EDID modes just in case, and spell Egbert correctly. v3: Elaborate a bit more about what's going on on Chris' machine. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524 Reported-and-tested-by: Chris Wilson Cc: Egbert Eich Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/gma500/cdv: Unpin framebuffer on crtc disable

2013-06-20T19:01:28Z

commit 22e7c385a80d771aaf3a15ae7ccea3b0686bbe10 upstream. The framebuffer needs to be unpinned in the crtc->disable callback because of previous pinning in psb_intel_pipe_set_base(). This will fix a memory leak where the framebuffer was released but not unpinned properly. This patch only affects Cedarview. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113 Reviewed-by: Daniel Vetter Signed-off-by: Patrik Jakobsson Signed-off-by: Greg Kroah-Hartman

drm/gma500/psb: Unpin framebuffer on crtc disable

2013-06-20T19:01:28Z

commit 820de86a90089ee607d7864538c98a23b503c846 upstream. The framebuffer needs to be unpinned in the crtc->disable callback because of previous pinning in psb_intel_pipe_set_base(). This will fix a memory leak where the framebuffer was released but not unpinned properly. This patch only affects Poulsbo. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113 Reviewed-by: Daniel Vetter Signed-off-by: Patrik Jakobsson Signed-off-by: Greg Kroah-Hartman

drm/i915: force full modeset if the connector is in DPMS OFF mode

2013-06-13T17:49:47Z

commit e3de42b68478a8c95dd27520e9adead2af9477a5 upstream. Currently the driver's assumed behavior for a modeset with an attached FB is that the corresponding connector will be switched to DPMS ON mode if it happened to be in DPMS OFF (or another power save mode). This wasn't enforced though if only the FB changed, everything else (format, connector etc.) remaining the same. In this case we only set the new FB base and left the connector in the old power save mode. Fix this by forcing a full modeset whenever there is an attached FB and any affected connector is in a power save mode. V_2: Run the test for encoders in power save mode outside the the test for fb change: user space may have just disabled the encoders but left everything else in place. Make sure the connector list is not empty before running this test. Signed-off-by: Imre Deak Signed-off-by: Egbert Eich Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61642 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59834 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64178 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65559 Acked-by: Jesse Barnes [danvet: Apply Jani's s/connector_off/is_crtc_connector_off bikeshed.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

radeon: use max_bus_speed to activate gen2 speeds

2013-06-13T17:49:44Z

commit 7e0e41963740525af702bb23edede8ae9afc4ac0 upstream. radeon currently uses a drm function to get the speed capabilities for the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard method of performing this detection and this patch changes it to use the max_bus_speed attribute. From: Lucas Kannebley Tavares Signed-off-by: Kleber Sacilotto de Souza Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/gma500: Increase max resolution for mode setting

2013-06-13T17:49:40Z

commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream. By having a higher max resolution we can now set up a virtual framebuffer that spans several monitors. 4096 should be ok since we're gen 3 or higher and should be enough for most dual head setups. Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-modesetting/+bug/1169147 Signed-off-by: Patrik Jakobsson Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus

2013-06-13T17:49:37Z

commit 7abb690a0e095717420ba78dcab4309abbbec78a upstream. Chris Wilson noticed that since commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9] Author: Daniel Vetter Date: Thu Nov 15 17:17:22 2012 +0100 drm/i915: clear up wedged transitions X can again get -EIO when it does not expect it. And even worse score a SIGBUS when accessing gtt mmaps. The established ABI is that we _only_ return an -EIO from execbuf - all other ioctls should just work. And since the reset code moves all bos out of gpu domains and clears out all the last_seqno/ring tracking there really shouldn't be any reason for non-execbuf code to ever touch the hw and see an -EIO. After some extensive discussions we've noticed that these spurios -EIO are caused by i915_gem_wait_for_error: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html That is easy to fix by returning 0 instead of -EIO, since grabbing the dev->struct_mutex does not yet mean that we actually want to touch the hw. And so there is no reason at all to fail with -EIO. But that's not the entire since, since often (at least it's easily googleable) dmesg indicates that the reset fails and we declare the gpu wedged. Then, quite a bit later X wakes up with the "Timed out waiting for the gpu reset to complete" DRM_ERROR message in wait_for_errror and brings down the desktop with an -EIO/SIGBUS. So clearly we're missing a wakeup somewhere, since the gpu reset just doesn't take 10 seconds to complete. And indeed we're do handle the terminally wedged state wrong. Fix this all up. Reviewed-by: Chris Wilson Cc: Daniel Vetter Cc: Damien Lespiau Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: no lvds quirk for hp t5740

2013-06-13T17:49:36Z

commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream. Last year, a patch was made for the "HP t5740e Thin Client" (see http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This device reports an lvds panel, but does not really have one. The predecessor of this device is the "hp t5740", which also does not have an lvds panel. This patch will add the same quirk for this device. Signed-off-by: Ben Mesman Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman