linux/drivers/gpu/drm/via, branch v3.6

drm: use drm_compat_ioctl for 32-bit apps

2012-09-05T20:55:02Z

Most of the DRM drivers appear to be missing the .compat_ioctl file operation entry necessary for 32-bit application compatibility. This patch uses drm_compat_ioctl for all drivers which don't have their own, and which are using drm_ioctl for .unlocked_ioctl. This leaves drivers/gpu/drm/psb/psb_drv.c unchanged; it has a custom .unlocked_ioctl and will presumably need a custom .compat_ioctl as well. Signed-off-by: Keith Packard Signed-off-by: Dave Airlie

drm/via: clean up reclaim_buffers

2012-07-20T02:48:28Z

A few things - kill reclaim_buffers, it's never ever called because via does not set DRIVER_HAVE_DMA - inline the idlelock dance into the buffer reclaim logic and make it a simple preclose cleanup function - directly call the the dma_quiescent function and kill the needless if check. v2: Actually drop the idlelock when we take it. Reported by James Simmons. v3: Rebased onto latest drm-next. v4: Fixup the refactor. v5: More fixup the refactor - I've accidentally changed the check for any master to checking whether the closing fd is the master. v6: Don't forget to drop the idlelock in the early return path, too. Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie

drm via: initialize object_idr

2012-06-16T10:18:38Z

The field obejct_idr of struct drm_via_private was introduced with the commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc . In that patch idr_init(&dev->object_name_idr) was called instead of idr_init(&dev_priv->object_idr) by mistake, leaving the dev_priv->object_idr uninitialized. To be more exact, the object_idr buffer is filled with zeros because of kzalloc(), but the dev_priv->object_idr.lock spinlock can cause system freeze at lib/idr.c:move_to_free_list() when spin_lock_irqsave() is called on this spinlock. The patch was tested on Clevo D4J, model D410J laptop, on the following hardware, without AGP kernel module loaded: # lspci -s 01:00.0 -n 01:00.0 0300: 1106:3108 (rev 01) # lspci -s 01:00.0 -v 01:00.0 VGA compatible controller: VIA Technologies, Inc. K8M800/K8N800/K8N800A [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device 4702 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at f0000000 (32-bit, prefetchable) [size=64M] Memory at d1000000 (32-bit, non-prefetchable) [size=16M] Expansion ROM at [disabled] Capabilities: [60] Power Management version 2 Capabilities: [70] AGP version 3.0 Signed-off-by: Márton Németh Reviewed-by: Daniel Vetter Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie

drm: move pci bus master enable into driver.

2012-02-16T18:31:07Z

The current enabling of bus mastering in the drm midlayer allows a large race condition under kexec. When a kexec'ed kernel re-enables bus mastering for the GPU, previously setup dma blocks may cause writes to random pieces of memory. On radeon the writeback mechanism can cause these sorts of issues. This patch doesn't fix the problem, but it moves the bus master enable under the individual drivers control so they can move enabling it until later in their load cycle and close the race. Fix for radeon kms driver will be in a follow-up patch. Signed-off-by: Dave Airlie

drm/sis|via: don't return stack garbage from free_mem ioctl

2012-01-09T12:11:39Z

Fallout from my "kill drm_sman" refactor. Unfortunately gcc seems to have failed me and not warned about this. Tested-by: Jakob Bornecrantz (on via) Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie

drm/via: use drm_mm instead of drm_sman

2011-12-21T23:33:22Z

To make the transition in a piece-wise and bisectable way possible, I've hijacked the ->owner_list from drm_sman. While transitioning, the list_add was done by the driver, while the list_del was still done by the dying sman code. Now that we are in full control of ->owner_list, do the list_del ourselves. v2: Better explain the list_del trickery as suggested by Chris Wilson. Signed-off-by: Daniel Vetter

drm/sis: track user->memblock mapping with idr

2011-12-21T23:33:21Z

Signed-off-by: Daniel Vetter

drm/via: track user->memblock mapping with idr

2011-12-21T23:33:20Z

Massive indirection through a hashtable for a simple key->pointer look-up actually just adds bloat. v2: Drop the misleading comment noted by Chris Wilson. Signed-off-by: Daniel Vetter

drm/sman: rip out owner tracking

2011-12-21T23:33:20Z

In contrast to kms drivers, sis/via _always_ associated a buffer with a drm fd. So by the time we reach lastclose, all open drm fds are gone and with them their associated objects. So when sis/via call drm_sman_cleanup in their lastclose funcs, that will free 0 objects. The owner tracking now serves no purpose at all, hence rip it ou. We can't kill the corresponding fields in struct drm_memblock_item yet because we hijack these in the new driver private owner tracking. But now that drm_sman.c doesn't touch ->owner_list anymore, we need to kill the list_move hack and properly add the item to the file_priv list. Also leave the list_del(&obj->owner_list) in drm_sman_free for the moment, it will move to the drivers when sman disappears completely. v2: Remove the redundant INIT_LIST_HEAD as noted by Chris Wilson Signed-off-by: Daniel Vetter

drm/via: track obj->drm_fd relations in the driver

2011-12-21T23:33:19Z

Exactly like the previous patch for sis. Signed-off-by: Daniel Vetter