30 Aug, 2011
1 commit
-
Signed-off-by: Rob Clark
Signed-off-by: Dave Airlie
25 Jul, 2011
1 commit
-
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
13 Jul, 2011
1 commit
-
This pulls in all the drm fixes up to this point which are needed
for some -next patches to work.
28 Jun, 2011
1 commit
-
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
21 Jun, 2011
1 commit
-
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
21 Mar, 2011
1 commit
-
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: 000000006b6b6b9fReported-by: Rusty Lynch
Signed-off-by: Chris Wilson
Cc: stable@kernel.org
Signed-off-by: Dave Airlie
23 Feb, 2011
1 commit
-
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
07 Feb, 2011
1 commit
-
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
06 Oct, 2010
1 commit
-
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
01 Oct, 2010
3 commits
-
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 -
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_unlockNote 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
Signed-off-by: Chris Wilson
Cc: stable@kernel.org
Signed-off-by: Dave Airlie -
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
Signed-off-by: Dave Airlie
28 Sep, 2010
1 commit
-
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
Cc: Jesse Barnes
Signed-off-by: Chris Wilson
Acked-by: Jesse Barnes
Cc: stable@kernel.org
Signed-off-by: Dave Airlie
30 Aug, 2010
1 commit
-
Not used by any current driver.
Signed-off-by: Daniel Vetter
Signed-off-by: Dave Airlie
10 Aug, 2010
1 commit
-
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
Signed-off-by: Dave Airlie
02 Aug, 2010
1 commit
-
/* 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:
[] create_object+0x124/0x1f1
[] kmemleak_alloc+0x4c/0x90
[] kmem_cache_alloc+0xee/0x13c
[] idr_pre_get+0x24/0x61
[] drm_gem_handle_create+0x27/0x7f [drm]
[] i915_gem_create_ioctl+0x4f/0x71 [i915]
[] drm_ioctl+0x272/0x356 [drm]
[] vfs_ioctl+0x33/0x91
[] do_vfs_ioctl+0x46b/0x496
[] sys_ioctl+0x46/0x66
[] sysenter_do_call+0x12/0x38
[] 0xffffffffFixes https://bugzilla.kernel.org/show_bug.cgi?id=15803
Signed-off-by: Chris Wilson
Signed-off-by: Dave Airlie
01 Jun, 2010
1 commit
-
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
Signed-off-by: Dave Airlie
20 Apr, 2010
2 commits
-
When drivers embed the core gem object into their own structures,
they'll have to do this. Temporarily this results in an uglykfree(gem_obj);
in every gem driver.
Signed-off-by: Daniel Vetter
Acked-by: Eric Anholt
Signed-off-by: Dave Airlie -
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
Acked-by: Eric Anholt
Signed-off-by: Dave Airlie
11 Feb, 2010
2 commits
-
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
Signed-off-by: Dave Airlie -
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_objectSigned-off-by: Luca Barbieri
Signed-off-by: Dave Airlie
28 Jan, 2010
1 commit
-
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=14933v2: Pass gfp into page mapping.
v3: Use new read_cache_page_gfp() instead of open-coding.Signed-off-by: Chris Wilson
Cc: KOSAKI Motohiro
Cc: Hugh Dickins
Cc: Jesse Barnes
Cc: Eric Anholt
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds
24 Nov, 2009
1 commit
-
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
18 Sep, 2009
1 commit
-
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
Signed-off-by: Jesse Barnes
27 Aug, 2009
1 commit
-
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
Signed-off-by: Dave Airlie
15 Jul, 2009
1 commit
-
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
Signed-off-by: Dave Airlie
19 Jun, 2009
1 commit
-
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
11 Jun, 2009
1 commit
-
Calls to kcalloc() for a single element can be simplified to calls to
kzalloc().Signed-off-by: Robert P. J. Day
Cc: Dave Airlie
Cc: Eric Anholt
Signed-off-by: Andrew Morton
Signed-off-by: Dave Airlie
03 Apr, 2009
1 commit
-
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
[anholt: cleaned up unused var]
Signed-off-by: Eric Anholt
13 Mar, 2009
1 commit
-
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
userkernel 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
Acked-by: Eric Anholt
Signed-off-by: Dave Airlie
20 Feb, 2009
4 commits
-
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
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie -
The name table should only hold a single reference, so avoid leaking
additional references for secondary calls to flink().Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie -
Ensure that the object is unreferenced if we fail to allocate during
drm_gem_flink_ioctl().Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie -
Remove the member from the hash table before we free the structure!
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie
01 Feb, 2009
1 commit
-
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
29 Dec, 2008
2 commits
-
The page protections need to be checked whether they need to be more flexible.
Signed-off-by: Dave Airlie
-
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
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie
18 Oct, 2008
2 commits
-
Signed-off-by: Eric Anholt
Signed-off-by: Dave Airlie -
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
Signed-off-by: Dave Airlie