linux/drivers/gpu, branch v2.6.32

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel

2009-11-30T21:57:19Z

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: drm/i915: Select CONFIG_SHMEM drm/i915: Fix CRT hotplug detect by checking really no channels attached agp/intel: new host bridge support drm/i915: Add more registers save/restore for Ironlake suspend drm/i915: Fix IRQ stall issue on Ironlake drm/i915: HDMI hardware workaround for Ironlake drm/i915: Fix and cleanup DPLL calculation for Ironlake drm/i915: Avoid potential sleep whilst holding spinlock

drm/i915: Select CONFIG_SHMEM

2009-11-25T20:27:42Z

The driver requires shmfs as the backing filesystem to handle the buffer objects, so ensure it is selected if the user chooses to build our driver. Fixes: Bug 14662 - Dell E5500 kernel panic with KMS http://bugzilla.kernel.org/show_bug.cgi?id=14662 The revealing nature of the panic is the NULL function pointer dereference in read_cache_page_async(). Signed-off-by: Chris Wilson Reported-and-tested-by: Mateusz Kaduk Signed-off-by: Eric Anholt Cc: stable@kernel.org

drm/i915: Fix CRT hotplug detect by checking really no channels attached

2009-11-25T20:10:18Z

For CRT hotplug detect status, we have four test results as blue channel only, green channel only, both blue and green channel, and no channel attached. Origin code only marks both blue and green channel case as connected, but ignore other possible connected states. This one trys to detect CRT by checking no channel attached case instead. Signed-off-by: Zhenyu Wang Signed-off-by: Eric Anholt

drm/fb: fix FBIOGET/PUT_VSCREENINFO pixel clock handling

2009-11-24T03:04:49Z

When the framebuffer driver does not publish detailed timing information for the current video mode, the correct value for the pixclock field is zero, not -1. Since pixclock is actually unsigned, the value -1 would be interpreted as 4294967295 picoseconds (i.e., about 4 milliseconds) by register_framebuffer() and userspace programs. This patch allows X.org's fbdev driver to work. Signed-off-by: Clemens Ladisch Tested-by: Paulius Zaleckas Cc: stable@kernel.org Signed-off-by: Dave Airlie

drm: make sure page protections are updated after changing vm_flags

2009-11-24T03:02:30Z

Some architectures compute ->vm_page_prot depending on ->vm_flags, so we need to update the protections after adjusting the flags. AFAIK this only affects running X under Xen; without this patch you get lots of coloured blobs on the screen, or maybe a complete lockup. Or anything really. But that still depends on lots of out-of-tree stuff, so I don't think there are any consequences for anyone else. But it is wrong in principle. Reported-by: Jan Beulich Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Andrew Morton Signed-off-by: Dave Airlie

drm/radeon/kms: Report vga connector is connected according to ddc_probe

2009-11-24T03:02:25Z

On broken EDID we were reporting vga connector to be disconnected even if ddc probe did found a monitor. This patch report that the connector is connected on such case. This allow drm to add a fail safe mode (800x600 at the time of this patch) thus user can boot and later add a mode which match its monitor capabilities. Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie

drm: mm always protect change to unused_nodes with unused_lock spinlock

2009-11-24T03:02:18Z

unused_nodes modification needs to be protected by unused_lock spinlock. Here is an example of an usage where there is no such protection without this patch. Process 1: 1-drm_mm_pre_get(this function modify unused_nodes list) 2-spin_lock(spinlock protecting mm struct) 3-drm_mm_put_block(this function might modify unused_nodes list but doesn't protect modification with unused_lock) 4-spin_unlock(spinlock protecting mm struct) Process2: 1-drm_mm_pre_get(this function modify unused_nodes list) At this point Process1 & Process2 might both be doing modification to unused_nodes list. This patch add unused_lock protection into drm_mm_put_block to avoid such issue. Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie

drm/radeon/kms: Disable TV load detect on RS400,RC410,RS480

2009-11-24T03:02:12Z

RS400,RC410,RS480 chipset seems to report a lot of false positive with load detect on TV output. We haven't yet found a way to make load detect reliable on those chipset, thus just disable it for TV output. Would avoid user to experience phantom screen because X believe there is a monitor connected to the TV output. Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie

drm/radeon/kms: read back register before writing in IIO.

2009-11-24T03:02:07Z

This fixes RH bugzilla #527874. On resume the atom posting wasn't working, however vbe posting was going fine, after 2 weeks over irc, and 8 hrs with the hardware, I tracked it down to the memory device table and it access the MC registers via IIO, it appears the rv515 atom iio table might not be fully functional, so adding a readback before doing a write either provides enough delay to make things resume correctly. Thanks to Peng Huang at Red Hat for coming to Brisbane. Signed-off-by: Dave Airlie

drm/radeon/kms: fix handling of d1/d2 vga

2009-11-24T03:02:01Z

An rv515 laptop I got wouldn't startup with a montior plugged in, found the proper bug hopefully with us not turning off D2VGA here when we should. Signed-off-by: Dave Airlie