linux/drivers/gpu/drm, branch v2.6.32.26

drm: Only decouple the old_fb from the crtc is we call mode_set*

2010-09-20T20:18:14Z

commit 356ad3cd616185631235ffb48b3efbf39f9923b3 upstream. Otherwise when disabling the output we switch to the new fb (which is likely NULL) and skip the call to mode_set -- leaking driver private state on the old_fb. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857 Reported-by: Sitsofe Wheeler Signed-off-by: Chris Wilson Cc: Dave Airlie Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/i915: Prevent double dpms on

2010-09-20T20:18:14Z

commit 032d2a0d068b0368296a56469761394ef03207c3 upstream. Arguably this is a bug in drm-core in that we should not be called twice in succession with DPMS_ON, however this is still occuring and we see FDI link training failures on the second call leading to the occassional blank display. For the time being ignore the repeated call. Original patch by Dave Airlie Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman

i915_gem: return -EFAULT if copy_to_user fails

2010-09-20T20:18:14Z

commit c877cdce93a44eea96f6cf7fc04be7d0372db2be upstream. copy_to_user() returns the number of bytes remaining to be copied and I'm pretty sure we want to return a negative error code here. Signed-off-by: Dan Carpenter Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman

i915: return -EFAULT if copy_to_user fails

2010-09-20T20:18:14Z

commit 9927a403ca8c97798129953fa9cbb5dc259c7cb9 upstream. copy_to_user returns the number of bytes remaining to be copied, but we want to return a negative error code here. These are returned to userspace. Signed-off-by: Dan Carpenter Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman

drm: stop information leak of old kernel stack.

2010-08-26T23:41:56Z

commit b9f0aee83335db1f3915f4e42a5e21b351740afd upstream. non-critical issue, CVE-2010-2803 Userspace controls the amount of memory to be allocate, so it can get the ioctl to allocate more memory than the kernel uses, and get access to kernel stack. This can only be done for processes authenticated to the X server for DRI access, and if the user has DRI access. Fix is to just memset the data to 0 if the user doesn't copy into it in the first place. Reported-by: Kees Cook Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: fix typo in radeon_compute_pll_gain

2010-08-26T23:41:55Z

commit 0537398b211b4f040564beec458e23571042d335 upstream. Looks like this got copied from the ddx wrong. Cc: Benjamin Herrenschmidt Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/i915: add 'reclaimable' to i915 self-reclaimable page allocations

2010-08-26T23:41:46Z

commit cd9f040df6ce46573760a507cb88192d05d27d86 upstream. The hibernate issues that got fixed in commit 985b823b9192 ("drm/i915: fix hibernation since i915 self-reclaim fixes") turn out to have been incomplete. Vefa Bicakci tested lots of hibernate cycles, and without the __GFP_RECLAIMABLE flag the system eventually fails to resume. With the flag added, Vefa can apparently hibernate forever (or until he gets bored running his automated scripts, whichever comes first). The reclaimable flag was there originally, and was one of the flags that were dropped (unintentionally) by commit 4bdadb978569 ("drm/i915: Selectively enable self-reclaim") that introduced all these problems, but I didn't want to just blindly add back all the flags in commit 985b823b9192, and it looked like __GFP_RECLAIM wasn't necessary. It clearly was. I still suspect that there is some subtle reason we're missing that causes the problems, but __GFP_RECLAIMABLE is certainly not wrong to use in this context, and is what the code historically used. And we have no idea what the causes the corruption without it. Reported-and-tested-by: M. Vefa Bicakci Cc: Dave Airlie Cc: Chris Wilson Cc: KOSAKI Motohiro Cc: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drm/i915: fix hibernation since i915 self-reclaim fixes

2010-08-26T23:41:46Z

commit 985b823b919273fe1327d56d2196b4f92e5d0fae upstream. Since commit 4bdadb9785696439c6e2b3efe34aa76df1149c83 ("drm/i915: Selectively enable self-reclaim"), we've been passing GFP_MOVABLE to the i915 page allocator where we weren't before due to some over-eager removal of the page mapping gfp_flags games the code used to play. This caused hibernate on Intel hardware to result in a lot of memory corruptions on resume. See for example http://bugzilla.kernel.org/show_bug.cgi?id=13811 Reported-by: Evengi Golov (in bugzilla) Signed-off-by: Dave Airlie Tested-by: M. Vefa Bicakci Cc: Chris Wilson Cc: KOSAKI Motohiro Cc: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drm/i915/edp: Flush the write before waiting for PLLs

2010-08-26T23:41:42Z

commit 5ddb954b9ee50824977d2931e0ff58b3050b337d upstream. Signed-off-by: Chris Wilson Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman

drm/i915: Use RSEN instead of HTPLG for tfp410 monitor detection.

2010-08-13T20:19:52Z

commit f458823b864c6def488f951a79986fa205aba4f1 upstream. Presence detection of a digital monitor seems not to be reliable using the HTPLG bit. Dave Müller Signed-off-by: Greg Kroah-Hartman