summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/drm_gem.c
Commit message (Collapse)AuthorAgeFilesLines
* UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells2012-10-021-1/+1
| | | | | | | | | | | Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* drm: Add colouring to the range allocatorChris Wilson2012-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | In order to support snoopable memory on non-LLC architectures (so that we can bind vgem objects into the i915 GATT for example), we have to avoid the prefetcher on the GPU from crossing memory domains and so prevent allocation of a snoopable PTE immediately following an uncached PTE. To do that, we need to extend the range allocator with support for tracking and segregating different node colours. This will be used by i915 to segregate memory domains within the GTT. v2: Now with more drm_mm helpers and less driver interference. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@redhat.com Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
* drm/prime: add exported buffers to current fprivs imported buffer list (v2)Dave Airlie2012-05-231-6/+15
| | | | | | | | | | If userspace attempts to import a buffer it exported on the same device, we need to return the same GEM handle for it, not a new handle pointing at the same GEM object. v2: move removals into a single fn, no need to set to NULL. (Chris Wilson) Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Don't initialize local ret variable when not neededLaurent Pinchart2012-05-221-1/+1
| | | | | | Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: pass dev to drm_vm_{open,close}_locked()Rob Clark2012-05-111-3/+3
| | | | | | | | | | | | | | | | | | | | | Previously these functions would assume that vma->vm_file was the drm_file. Although if in some cases if the drm driver needs to use something else for the backing file (such as the tmpfs filp) then this assumption is no longer true. But vma->vm_private_data is still the GEM object. With this change, now the drm_device comes from the GEM object rather than the drm_file so the driver is more free to play with vma->vm_file. The scenario where this comes up is for mmap'ing of cached dmabuf's for non-coherent systems, where the driver needs to use fault handling and PTE shootdown to simulate coherency. We can't use the vma->vm_file of the dmabuf, which is using anon_inode's address_space. The most straightforward thing to do is to use the GEM object's obj->filp for vma->vm_file in all cases, for which we need this patch. Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Unify and fix idr error handlingVille Syrjälä2012-04-241-4/+2Star
| | | | | | | | | | | | The error handling code w.r.t. idr usage looks inconsistent. In the case of drm_mode_object_get() and drm_ctxbitmap_next() the error handling is also incomplete. Unify the code to follow the same pattern always. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: base prime/dma-buf support (v5)Dave Airlie2012-03-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the basic drm dma-buf interface layer, called PRIME. This commit doesn't add any driver support, it is simply and agreed upon starting point so we can work towards merging driver support for the next merge window. Current drivers with work done are nouveau, i915, udl, exynos and omap. The main APIs exposed to userspace allow translating a 32-bit object handle to a file descriptor, and a file descriptor to a 32-bit object handle. The flags value is currently limited to O_CLOEXEC. Acknowledgements: Daniel Vetter: lots of review Rob Clark: cleaned up lots of the internals and did lifetime review. v2: rename some functions after Chris preferred a green shed fix IS_ERR_OR_NULL -> IS_ERR v3: Fix Ville pointed out using buffer + kmalloc v4: add locking as per ickle review v5: allow re-exporting the original dma-buf (Daniel) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rob Clark <rob.clark@linaro.org> Reviewed-by: Sumit Semwal <sumit.semwal@linaro.org> Reviewed-by: Inki Dae <inki.dae@samsung.com> Acked-by: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: add core support for unplugging a device (v2)Dave Airlie2012-03-151-0/+3
| | | | | | | | | | | | | | | | Two parts to this, one is simple unplug from sysfs for the device node. The second adds an unplugged state, if we have device opens, we just set the unplugged state and return, if we have no device opens we drop the drm device. If after a lastclose we discover we are unplugged we then drop the drm device. v2: use an atomic for unplugged and wrap it for users, add checks on open + mmap + ioctl entry points. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: drop setting vm_file to filpDave Airlie2012-03-051-1/+0Star
| | | | | | | | | | | Talking to Al Viro on irc, we can see no possible reason for doing this, the upper mmap code does it. The code has been there since first import into drm tree I can find. Al tracked down this as a requirement pre 2.3.51 hasn't been needed since. Acked-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Pass the real error code back during GEM bo initialisationChris Wilson2012-01-301-1/+1
| | | | | | | | | | In particular, I found I was hitting the max-file limit in the VFS, and the EFILE was being magically transformed into ENOMEM. Confusion reigns. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/gem: add functions for mmap offset creationRob Clark2011-08-301-0/+88
| | | | | Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/gem: add support for private objectsAlan Cox2011-07-251-2/+24
| | | | | | | | | | | | | | | 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 <alan@linux.intel.com> Tested-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge 3.0-rc7 into drm-core-nextDave Airlie2011-07-131-0/+1
|\ | | | | | | | | 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_pageHugh Dickins2011-06-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <hughd@google.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Keith Packard <keithp@keithp.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | drm/gem: add hooks to notify driver when object handle is created/destroyedBen Skeggs2011-06-211-2/+19
|/ | | | | | | | Nouveau is going to use these hooks to map/unmap objects from a client's private GPU address space. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Fix use-after-free in drm_gem_vm_close()Chris Wilson2011-03-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: [<c1536d11>] __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:[<c1536d11>] 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] [<c1536dd0>] ? mutex_unlock+0x8/0xa [ 60.141014] [<c125ab1b>] ? drm_gem_vm_close+0x39/0x3d [ 60.141014] [<c10ba071>] ? remove_vma+0x2d/0x58 [ 60.141014] [<c10bb0bc>] ? exit_mmap+0x126/0x13f [ 60.141014] [<c1037c24>] ? mmput+0x37/0x9a [ 60.141014] [<c10d450d>] ? exec_mmap+0x178/0x19c [ 60.141014] [<c1537f85>] ? _raw_spin_unlock+0x1d/0x36 [ 60.141014] [<c10d4eb0>] ? flush_old_exec+0x42/0x75 [ 60.141014] [<c1104442>] ? load_elf_binary+0x32a/0x922 [ 60.141014] [<c10d3f76>] ? search_binary_handler+0x200/0x2ea [ 60.141014] [<c10d3ecf>] ? search_binary_handler+0x159/0x2ea [ 60.141014] [<c1104118>] ? load_elf_binary+0x0/0x922 [ 60.141014] [<c10d56b2>] ? do_execve+0x1ff/0x2e6 [ 60.141014] [<c100970e>] ? sys_execve+0x2d/0x55 [ 60.141014] [<c1002a5a>] ? ptregs_execve+0x12/0x18 [ 60.141014] [<c10029dc>] ? sysenter_do_call+0x12/0x3c [ 60.141014] [<c1530000>] ? 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 <f0> 66 0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef [ 60.141014] EIP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP 0068:e480be44 [ 60.141014] CR2: 000000006b6b6b9f Reported-by: Rusty Lynch <rusty.lynch@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Trim the GEM mmap offset hashtabChris Wilson2011-02-231-1/+1
| | | | | | | | | | | | | | | | 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 <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: dumb scanout create/mmap for intel/radeon (v3)Dave Airlie2011-02-071-1/+2
| | | | | | | | | | | | | | | | | | | 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 <airlied@redhat.com>
* Merge remote branch 'korg/drm-fixes' into drm-vmware-nextDave Airlie2010-10-061-27/+10Star
|\ | | | | | | | | | | | | | | | | 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: Hold the mutex when dropping the last GEM reference (v2)Chris Wilson2010-10-011-22/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to be fully threadsafe we need to check that the drm_gem_object refcount is still 0 after acquiring the mutex in order to call the free function. Otherwise, we may encounter scenarios like: Thread A: Thread B: drm_gem_close unreference_unlocked kref_put mutex_lock ... i915_gem_evict ... kref_get -> BUG ... i915_gem_unbind ... kref_put ... i915_gem_object_free ... mutex_unlock mutex_lock i915_gem_object_free -> BUG i915_gem_object_unbind kfree mutex_unlock Note that no driver is currently using the free_unlocked vfunc and it is scheduled for removal, hasten that process. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30454 Reported-and-Tested-by: Magnus Kessler <Magnus.Kessler@gmx.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/gem: handlecount isn't really a kref so don't make it one.Dave Airlie2010-10-011-6/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were lots of places being inconsistent since handle count looked like a kref but it really wasn't. Fix this my just making handle count an atomic on the object, and have it increase the normal object kref. Now i915/radeon/nouveau drivers can drop the normal reference on userspace object creation, and have the handle hold it. This patch fixes a memory leak or corruption on unload, because the driver had no way of knowing if a handle had been actually added for this object, and the fbcon object needed to know this to clean itself up properly. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm: Prune GEM vma entriesChris Wilson2010-09-281-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Hook the GEM vm open/close ops into the generic drm vm open/close so that the private vma entries are created and destroy appropriately. Fixes the leak of the drm_vma_entries during the lifetime of the filp. Reported-by: Matt Mackall <mpm@selenic.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm: Move the GTT accounting to i915Chris Wilson2010-10-011-14/+0Star
| | | | | | | | | | | | | | | | | | 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 <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@redhat.com>
* | drm: kill gem_free_object_unlocked driver callbackDaniel Vetter2010-08-301-3/+1Star
|/ | | | | | | Not used by any current driver. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Use ENOENT consistently for the error return for an unmatched handle.Chris Wilson2010-08-101-1/+1
| | | | | | | | | | | This is consistent with trying to access a filename that not exist within a directory which is a good analogy here. The main reason for the change is that it is easy to confuse the error code of EBADF as an performing an ioctl on an invalid file descriptor (rather than an unknown object). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Free the idr layers before calling idr_destroy()Chris Wilson2010-08-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | /* A typical clean-up sequence for objects stored in an idr tree, will * use idr_for_each() to free all objects, if necessary, then * idr_remove_all() to remove all ids, and idr_destroy() to free * up the cached idr_layers. */ We were missing the vital idr_rmove_all() step and so were leaking the used layers for every dri client: unreferenced object 0xf32133c0 (size 148): comm "plymouthd", pid 131, jiffies 4294678490 (age 2308.030s) hex dump (first 32 bytes): 04 00 00 00 00 00 00 00 00 00 00 00 00 40 19 f3 .............@.. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<c04e5657>] create_object+0x124/0x1f1 [<c07cf100>] kmemleak_alloc+0x4c/0x90 [<c04db6a9>] kmem_cache_alloc+0xee/0x13c [<c05c3d25>] idr_pre_get+0x24/0x61 [<f8315c9c>] drm_gem_handle_create+0x27/0x7f [drm] [<f89925b2>] i915_gem_create_ioctl+0x4f/0x71 [i915] [<f83148ac>] drm_ioctl+0x272/0x356 [drm] [<c04f27c4>] vfs_ioctl+0x33/0x91 [<c04f31cf>] do_vfs_ioctl+0x46b/0x496 [<c04f3240>] sys_ioctl+0x46/0x66 [<c040325f>] sysenter_do_call+0x12/0x38 [<ffffffff>] 0xffffffff Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15803 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Make sure the DRM offset matches the CPUJordan Crouse2010-06-011-0/+10
| | | | | | | | | The pgoff option in mmap() is defined as an unsigned long so the offset generated by DRM needs to fit into BITS_PER_LONG for the CPU in question. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: free core gem object from driver callbacksDaniel Vetter2010-04-201-7/+3Star
| | | | | | | | | | | | | When drivers embed the core gem object into their own structures, they'll have to do this. Temporarily this results in an ugly kfree(gem_obj); in every gem driver. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: extract drm_gem_object_initDaniel Vetter2010-04-201-10/+29
| | | | | | | | | This function can be used by drivers who allocate the drm gem object on their own. No functional change in here, just preparation. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Use drm_gem_object_[handle_]unreference_unlocked where possibleLuca Barbieri2010-02-111-16/+5Star
| | | | | | | | | | | Mostly obvious simplifications. The i915 pread/pwrite ioctls, intel_overlay_put_image and nouveau_gem_new were incorrectly using the locked versions without locking: this is also fixed in this patch. Signed-off-by: Luca Barbieri <luca@luca-barbieri.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: introduce drm_gem_object_[handle_]unreference_unlockedLuca Barbieri2010-02-111-5/+44
| | | | | | | | | | | | | This patch introduces the drm_gem_object_unreference_unlocked and drm_gem_object_handle_unreference_unlocked functions that do not require holding struct_mutex. drm_gem_object_unreference_unlocked calls the new ->gem_free_object_unlocked entry point if available, and otherwise just takes struct_mutex and just calls ->gem_free_object Signed-off-by: Luca Barbieri <luca@luca-barbieri.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Selectively enable self-reclaimChris Wilson2010-01-271-13/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | Having missed the ENOMEM return via i915_gem_fault(), there are probably other paths that I also missed. By not enabling NORETRY by default these paths can run the shrinker and take memory from the system (but not from our own inactive lists because our shrinker can not run whilst we hold the struct mutex) and this may allow the system to survive a little longer whilst our drivers consume all available memory. References: OOM killer unexpectedly called with kernel 2.6.32 http://bugzilla.kernel.org/show_bug.cgi?id=14933 v2: Pass gfp into page mapping. v3: Use new read_cache_page_gfp() instead of open-coding. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eric Anholt <eric@anholt.net> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* drm: make sure page protections are updated after changing vm_flagsJeremy Fitzhardinge2009-11-241-1/+1
| | | | | | | | | | | | | | | | | 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 <JBeulich@novell.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Improve behaviour under memory pressureChris Wilson2009-09-171-0/+13
| | | | | | | | | | | | | | | | | | | Due to the necessity of having to take the struct_mutex, the i915 shrinker can not free the inactive lists if we fail to allocate memory whilst processing a batch buffer, triggering an OOM and an ENOMEM that is reported back to userspace. In order to fare better under such circumstances we need to manually retry a failed allocation after evicting inactive buffers. To do so involves 3 steps: 1. Marking the backing shm pages as NORETRY. 2. Updating the get_pages() callers to evict something on failure and then retry. 3. Revamping the evict something logic to be smarter about the required buffer size and prefer to use volatile or clean inactive pages. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm: GEM handles are u32, not intPekka Paalanen2009-08-271-6/+5Star
| | | | | | | | | | Several functions in the GEM kernel API used int as handle type, but user API has it __u32 which is also the intended type. Replace int with u32. Signed-off-by: Pekka Paalanen <pq@iki.fi> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: drm_gem, check kzalloc retvalJiri Slaby2009-07-151-7/+10
| | | | | | | | | | | Check kzalloc retval against NULL in drm_gem_object_alloc and bail out appropriately. While at it merge the fail paths and jump to them by gotos at the end of the function. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
* drm: Remove memory debugging infrastructure.Eric Anholt2009-06-181-4/+4
| | | | | | | | It hasn't been used in ages, and having the user tell your how much memory is being freed at free time is a recipe for disaster even if it was ever used. Signed-off-by: Eric Anholt <eric@anholt.net>
* drm: simplify kcalloc() call to kzalloc().Robert P. J. Day2009-06-111-1/+1
| | | | | | | | | | | Calls to kcalloc() for a single element can be simplified to calls to kzalloc(). Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Cc: Dave Airlie <airlied@linux.ie> Cc: Eric Anholt <eric@anholt.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Use pgprot_writecombine in GEM GTT mapping to get the right bits for !PAT.Jesse Barnes2009-04-021-6/+1Star
| | | | | | | | | Otherwise, the PAGE_CACHE_WC would end up getting us a UC-only mapping, and the write performance of GTT maps dropped 10x. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: cleaned up unused var] Signed-off-by: Eric Anholt <eric@anholt.net>
* drm: Split drm_map and drm_local_mapBenjamin Herrenschmidt2009-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Once upon a time, the DRM made the distinction between the drm_map data structure exchanged with user space and the drm_local_map used in the kernel. For some reasons, while the BSD port still has that "feature", the linux part abused drm_map for kernel internal usage as the local map only existed as a typedef of the struct drm_map. This patch fixes it by declaring struct drm_local_map separately (though its content is currently identical to the userspace variant), and changing the kernel code to only use that, except when it's a user<->kernel interface (ie. ioctl). This allows subsequent changes to the in-kernel format I've also replaced the use of drm_local_map_t with struct drm_local_map in a couple of places. Mostly by accident but they are the same (the former is a typedef of the later) and I have some remote plans and half finished patch to completely kill the drm_local_map_t typedef so I left those bits in. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
* drm/i915: Keep refs on the object over the lifetime of vmas for GTT mmap.Jesse Barnes2009-02-201-0/+28
| | | | | | | | | | | This fixes potential fault at fault time if the object was unreferenced while the mapping still existed. Now, while the mmap_offset only lives for the lifetime of the object, the object also stays alive while a vma exists that needs it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Do not leak a new reference for flink() on an existing nameChris Wilson2009-02-201-17/+16Star
| | | | | | | | | The name table should only hold a single reference, so avoid leaking additional references for secondary calls to flink(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
* drm: Free the object ref on error.Chris Wilson2009-02-201-8/+12
| | | | | | | | | Ensure that the object is unreferenced if we fail to allocate during drm_gem_flink_ioctl(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
* drm: Potential use-after-free on error path.Chris Wilson2009-02-201-1/+1
| | | | | | | | Remove the member from the hash table before we free the structure! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
* Stop playing silly games with the VM_ACCOUNT flagLinus Torvalds2009-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | | The mmap_region() code would temporarily set the VM_ACCOUNT flag for anonymous shared mappings just to inform shmem_zero_setup() that it should enable accounting for the resulting shm object. It would then clear the flag after calling ->mmap (for the /dev/zero case) or doing shmem_zero_setup() (for the MAP_ANON case). This just resulted in vma merge issues, but also made for just unnecessary confusion. Use the already-existing VM_NORESERVE flag for this instead, and let shmem_{zero|file}_setup() just figure it out from that. This also happens to make it obvious that the new DRI2 GEM layer uses a non-reserving backing store for its object allocation - which is quite possibly not intentional. But since I didn't want to change semantics in this patch, I left it alone, and just updated the caller to use the new flag semantics. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* drm: PAGE_CACHE_WC is x86 only so farDave Airlie2008-12-291-0/+2
| | | | | | The page protections need to be checked whether they need to be more flexible. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: GEM mmap supportJesse Barnes2008-12-291-0/+109
| | | | | | | | | | | Add core support for mapping of GEM objects. Drivers should provide a vm_operations_struct if they want to support page faulting of objects. The code for handling GEM object offsets was taken from TTM, which was written by Thomas Hellström. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* DRM: Return -EBADF on bad object in flink, and return curent name if it exists.Eric Anholt2008-10-171-2/+3
| | | | | Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Add GEM ("graphics execution manager") to i915 driver.Eric Anholt2008-10-171-0/+420
GEM allows the creation of persistent buffer objects accessible by the graphics device through new ioctls for managing execution of commands on the device. The userland API is almost entirely driver-specific to ensure that any driver building on this model can easily map the interface to individual driver requirements. GEM is used by the 2d driver for managing its internal state allocations and will be used for pixmap storage to reduce memory consumption and enable zero-copy GLX_EXT_texture_from_pixmap, and in the 3d driver is used to enable GL_EXT_framebuffer_object and GL_ARB_pixel_buffer_object. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-10 02:43:23 +0200