linux/drivers/gpu, branch v2.6.35.6

drm/i915: Ensure that the crtcinfo is populated during mode_fixup()

2010-09-27T00:18:42Z

commit 897493504addc5609f04a2c4f73c37ab972c29b2 upstream. This should fix the mysterious mode setting failures reported during boot up and after resume, generally for i8xx class machines. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16478 Reported-and-tested-by: Xavier Chantry Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29413 Tested-by: Daniel Vetter Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman

drm/nv50: initialize ramht_refs list for faked 0 channel

2010-09-27T00:18:31Z

commit 615661f3948a066fd22a36fe8ea0c528b75ee373 upstream. We need it for PFIFO_INTR_CACHE_ERROR interrupt handling, because nouveau_fifo_swmthd looks for matching gpuobj in ramht_refs list. It fixes kernel panic in nouveau_gpuobj_ref_find. Signed-off-by: Marcin Slusarz Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman

drm/i915,agp/intel: Add second set of PCI-IDs for B43

2010-09-27T00:18:23Z

commit 41a51428916ab04587bacee2dda61c4a0c4fc02f upstream. There is a second revision of B43 (a desktop gen4 part) floating around, functionally equivalent to the original B43, so simply add the new PCI-IDs. Bugzilla: https://bugs.freedesktop.org/show_bugs.cgi?id=30221 Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman

intel_agp, drm/i915: Add all sandybridge graphics devices support

2010-09-27T00:18:21Z

New pci ids for all sandybridge graphics versions on desktop/mobile/server. [This is backport patch from upstream commit 4fefe435 and 85540480.] Signed-off-by: Zhenyu Wang Signed-off-by: Greg Kroah-Hartman

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

2010-09-20T20:36:51Z

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

Revert "drm/i915: Allow LVDS on pipe A on gen4+"

2010-09-20T20:36:50Z

commit 12e8ba25ef52f19e7a42e61aecb3c1fef83b2a82 upstream. This reverts commit 0f3ee801b332d6ff22285386675fe5aaedf035c3. Enabling LVDS on pipe A was causing excessive wakeups on otherwise idle systems due to i915 interrupts. So restrict the LVDS to pipe B once more, whilst the issue is properly diagnosed. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307 Reported-and-tested-by: Enrico Bandiello Poked-by: Florian Mickler Signed-off-by: Chris Wilson Cc: Adam Jackson Signed-off-by: Greg Kroah-Hartman

drm/i915: don't enable self-refresh on Ironlake

2010-09-20T20:36:50Z

commit dd8849c8f59ec1cee4809a0c5e603e045abe860e upstream. We don't know how to enable it safely, especially as outputs turn on and off. When disabling LP1 we also need to make sure LP2 and 3 are already disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29173 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29082 Reported-by: Chris Lord Signed-off-by: Jesse Barnes Tested-by: Daniel Vetter Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman

drm/i915: Prevent double dpms on

2010-09-20T20:36:50Z

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

drm/i915: overlay on gen2 can't address above 1G

2010-09-20T20:36:50Z

commit 9f82d23846146990d475f6753be733e55788d88d upstream. So set the coherent dma mask accordingly. This dma mask is only used for physical objects, so it won't really matter allocation-wise. Now this never really surfaced because sane 32bit kernels only have 1G of lowmem. But some eager testers (distros?) still carry around the patch to adjust lowmem via a kconfig option. And the kernel seems to favour high allocations on boot-up, hence the overlay blowing up reliably. Because the patch is tiny and nicely shows how broken gen2 is it's imho worth to merge despite the fact that mucking around with the lowmem/ highmem division is (no longer) supported. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28318 Signed-off-by: Daniel Vetter Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman

drm/i915: Allocate the PCI resource for the MCHBAR

2010-09-20T20:36:50Z

commit a25c25c2a2aa55e609099a9f74453c518aec29a6 upstream. We were failing when trying to allocate the resource for MMIO of the MCHBAR because we forgot to specify what type of resource we wanted. Signed-off-by: Chris Wilson Cc: Jesse Barnes Reviewed-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman