linux.git/drivers/char/drm, branch v2.6.25

fix IS_I9XX macro in i915 DRM driver

2008-04-06T23:10:40+00:00

Now that we're mapping registers in the DRM driver at load time, the
driver actually checks the PCI ID, so we need to make sure the macros
have all the right bits (and longer term use the DRM headers as the sole
copy of the PCI & register definitions).

This patch adds 945GME support to the DRM headers, fixing a regression
reported in http://bugzilla.kernel.org/show_bug.cgi?id=10395.

Tested-by:  Alexander Oltu 
Signed-off-by:  Jesse Barnes 
Signed-off-by: Linus Torvalds

drm: fix for non-coherent DMA PowerPC

2008-03-29T21:57:57+00:00

This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.

It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until we have more useful
generic kernel API.

Signed-off-by: Benjamin Herrenschmidt 
Cc: "David S. Miller" 
Cc: "Luck, Tony" 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Airlie

drm: radeon: fix sparse integer as NULL pointer warnings in radeon_mem.c

2008-03-29T21:56:39+00:00

drivers/char/drm/radeon_mem.c:91:23: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:116:28: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:124:28: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:177:26: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:177:53: warning: Using plain integer as NULL pointer

Signed-off-by: Harvey Harrison 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Airlie

drm/i915: fix oops on agp=off

2008-03-29T21:53:58+00:00

From Kernel BZ 10289 - not sure why anyone would boot an intel with no agp
but it shouldn't crash.

Signed-off-by: Dave Airlie

drm/r300: fix bug in r300 userspace hardware wait emission

2008-03-29T21:51:49+00:00

This interface was originally designed wrong, confusing bit-fields and
integers, major brown paper bag going back many years...

But userspace only ever used 4 values so fix the interface for new
users and fix the implementation to deal with the 4 values userspace
has ever emitted (0x1, 0x2, 0x3, 0x6).

Signed-off-by: Dave Airlie

drivers/char/drm/ati_pcigart.c: fix printk warning

2008-03-28T21:45:21+00:00

drivers/char/drm/ati_pcigart.c: In function 'drm_ati_pcigart_init':
drivers/char/drm/ati_pcigart.c:125: warning: format '%08X' expects type 'unsigned int', but argument 3 has type 'dma_addr_t'

Cc: Dave Airlie 
Cc: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drm/ati_pcigart: fix the PCIGART to use drm_pci to allocate GART table.

2008-03-17T00:24:24+00:00

This fixes a problem on 64-bit with 4GB with ATI RS690 chipsets. It
makes sure the pcigart table is allocated in coherent memory for DMA operations.

Signed-off-by: Dave Airlie

drm/radeon: fixup RV550 chip family

2008-03-17T00:22:12+00:00

This fixes up the RV550 chips which are based on RV515, not RV530.
It also adds another RS690 PCI ID.

Signed-off-by: Dave Airlie

drm/via: attempt again to stabilise the AGP DMA command submission.

2008-03-17T00:07:20+00:00

It's worth remembering that all new bright ideas on how to make this command reader work properly and according to docs will probably fail :( Bring in some old code.

Also allow a larger SG-DMA download stride, and remove unnecessary waits for
command regulators pauses.

Signed-off-by: Dave Airlie

drm: Fix race that can lockup the kernel

2008-03-16T23:54:58+00:00

The i915_vblank_swap() function schedules an automatic buffer swap
upon receipt of the vertical sync interrupt.  Such an operation is
lengthy so it can't be allowed to happen in normal interrupt context,
thus the DRM implements this by scheduling the work in a kernel
softirq-scheduled tasklet.  In order for the buffer swap to work
safely, the DRM's central lock must be taken, via a call to
drm_lock_take() located in drivers/char/drm/drm_irq.c within the
function drm_locked_tasklet_func().  The lock-taking logic uses a
non-interrupt-blocking spinlock to implement the manipulations needed
to take the lock.  This semantic would be safe if all attempts to use
the spinlock only happen from process context.  However this buffer
swap happens from softirq context which is really a form of interrupt
context.  Thus we have an unsafe situation, in that
drm_locked_tasklet_func() can block on a spinlock already taken by a
thread in process context which will never get scheduled again because
of the blocked softirq tasklet.  This wedges the kernel hard.

To trigger this bug, run a dual-head cloned mode configuration which
uses the i915 drm, then execute an opengl application which
synchronizes buffer swaps against the vertical sync interrupt.  In my
testing, a lockup always results after running anywhere from 5 minutes
to an hour and a half.  I believe dual-head is needed to really
trigger the problem because then the vertical sync interrupt handling
is no longer predictable (due to being interrupt-sourced from two
different heads running at different speeds).  This raises the
probability of the tasklet trying to run while the userspace DRI is
doing things to the GPU (and manipulating the DRM lock).

The fix is to change the relevant spinlock semantics to be the
interrupt-blocking form.  After this change I am no longer able to
trigger the lockup; the longest test run so far was 20 hours (test
stopped after that point).

Note: I have examined the places where this spinlock is being
employed; all are reasonably short bounded sequences and should be
suitable for interrupts being blocked without impacting overall kernel
interrupt response latency.

Signed-off-by: Mike Isely 
Signed-off-by: Dave Airlie