user/sven/linux.git/drivers/gpu/drm/drm_gem.c, branch v3.2.67

drm/gem: add functions for mmap offset creation

2011-08-30T10:06:06Z

Signed-off-by: Rob Clark Signed-off-by: Dave Airlie

drm/gem: add support for private objects

2011-07-25T11:07:15Z

These small changes should allow GEM to be used with non shmem objects as well as shmem objects. In the GMA500 case it allows the base framebuffer to appear as a GEM object and thus acquire a handle and work with KMS. For i915 it ought to be trivial to get back the wasted memory but putting the system fb back into stolen RAM and in general I can imagine it allowing the use of GEM and thus KMS with all the older cards that have their framebuffer firmly placed in video RAM. Signed-off-by: Alan Cox Tested-by: Rob Clark Signed-off-by: Dave Airlie

Merge 3.0-rc7 into drm-core-next

2011-07-13T07:30:22Z

This pulls in all the drm fixes up to this point which are needed for some -next patches to work.

drm/i915: use shmem_read_mapping_page

2011-06-28T01:00:13Z

Soon tmpfs will stop supporting ->readpage and read_cache_page_gfp(): once "tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can be applied to ease the transition. Make i915_gem_object_get_pages_gtt() use shmem_read_mapping_page_gfp() in the one place it's needed; elsewhere use shmem_read_mapping_page(), with the mapping's gfp_mask properly initialized. Forget about __GFP_COLD: since tmpfs initializes its pages with memset, asking for a cold page is counter-productive. Include linux/shmem_fs.h also in drm_gem.c: with shmem_file_setup() now declared there too, we shall remove the prototype from linux/mm.h later. Signed-off-by: Hugh Dickins Cc: Christoph Hellwig Cc: Chris Wilson Cc: Keith Packard Cc: Dave Airlie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drm/gem: add hooks to notify driver when object handle is created/destroyed

2011-06-21T02:32:33Z

Nouveau is going to use these hooks to map/unmap objects from a client's private GPU address space. Signed-off-by: Ben Skeggs Signed-off-by: Dave Airlie

drm: Fix use-after-free in drm_gem_vm_close()

2011-03-20T23:15:22Z

As we may release the last reference, we need to store the device in a local variable in order to unlock afterwards. [ 60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f [ 60.140973] IP: [] __mutex_unlock_slowpath+0x5a/0x111 [ 60.141014] *pdpt = 0000000024a54001 *pde = 0000000000000000 [ 60.141014] Oops: 0002 [#1] PREEMPT SMP [ 60.141014] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now [ 60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev [ 60.141014] [ 60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1 EXOPC EXOPG06411/EXOPG06411 [ 60.141014] EIP: 0060:[] EFLAGS: 00010046 CPU: 0 [ 60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111 [ 60.141014] EAX: 00000100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580 [ 60.141014] ESI: db162558 EDI: 00000246 EBP: e480be50 ESP: e480be44 [ 60.141014] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0 task.ti=e480a000) [ 60.141014] Stack: [ 60.141014] e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b db162558 [ 60.141014] db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc 000155fe [ 60.141014] f760241c f5a2f838 f5a2f8c8 00000000 e480bea4 c1037c24 00000000 f5a2f838 [ 60.141014] Call Trace: [ 60.141014] [] ? mutex_unlock+0x8/0xa [ 60.141014] [] ? drm_gem_vm_close+0x39/0x3d [ 60.141014] [] ? remove_vma+0x2d/0x58 [ 60.141014] [] ? exit_mmap+0x126/0x13f [ 60.141014] [] ? mmput+0x37/0x9a [ 60.141014] [] ? exec_mmap+0x178/0x19c [ 60.141014] [] ? _raw_spin_unlock+0x1d/0x36 [ 60.141014] [] ? flush_old_exec+0x42/0x75 [ 60.141014] [] ? load_elf_binary+0x32a/0x922 [ 60.141014] [] ? search_binary_handler+0x200/0x2ea [ 60.141014] [] ? search_binary_handler+0x159/0x2ea [ 60.141014] [] ? load_elf_binary+0x0/0x922 [ 60.141014] [] ? do_execve+0x1ff/0x2e6 [ 60.141014] [] ? sys_execve+0x2d/0x55 [ 60.141014] [] ? ptregs_execve+0x12/0x18 [ 60.141014] [] ? sysenter_do_call+0x12/0x3c [ 60.141014] [] ? init_centaur+0x9c/0x1ba [ 60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff 9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 66 0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef [ 60.141014] EIP: [] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP 0068:e480be44 [ 60.141014] CR2: 000000006b6b6b9f Reported-by: Rusty Lynch Signed-off-by: Chris Wilson Cc: stable@kernel.org Signed-off-by: Dave Airlie

drm: Trim the GEM mmap offset hashtab

2011-02-23T01:15:39Z

Using an order 19 drm_ht for the mmap offsets is a little obscene. That means that will a fully populated GTT with every single object mmaped at least once in its lifetime, there will be exactly one object in each bucket. Typically systems only have at most a few thousand objects, though you may see a KDE desktop hit 50000. And most of those should never be mapped... On my systems, just using an order 10 ht would still have an average occupancy less than 1, so apply a small safety factor and use an order 12 ht, like the other mmap offset ht. Signed-off-by: Chris Wilson Signed-off-by: Dave Airlie

drm: dumb scanout create/mmap for intel/radeon (v3)

2011-02-07T02:16:14Z

This is just an idea that might or might not be a good idea, it basically adds two ioctls to create a dumb and map a dumb buffer suitable for scanout. The handle can be passed to the KMS ioctls to create a framebuffer. It looks to me like it would be useful in the following cases: a) in development drivers - we can always provide a shadowfb fallback. b) libkms users - we can clean up libkms a lot and avoid linking to libdrm_*. c) plymouth via libkms is a lot easier. Userspace bits would be just calls + mmaps. We could probably mark these handles somehow as not being suitable for acceleartion so as top stop people who are dumber than dumb. Signed-off-by: Dave Airlie

Merge remote branch 'korg/drm-fixes' into drm-vmware-next

2010-10-06T01:10:48Z

necessary for some of the vmware fixes to be pushed in. Conflicts: drivers/gpu/drm/drm_gem.c drivers/gpu/drm/i915/intel_fb.c include/drm/drmP.h

drm: Move the GTT accounting to i915

2010-10-01T13:45:20Z

Only drm/i915 does the bookkeeping that makes the information useful, and the information maintained is driver specific, so move it out of the core and into its single user. Signed-off-by: Chris Wilson Cc: Dave Airlie