summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_mm.c
AgeCommit message (Collapse)Author
2012-10-02UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells
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>
2012-07-15drm: Add colouring to the range allocatorChris Wilson
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>
2011-10-31gpu: Add export.h as required to drivers/gpu files.Paul Gortmaker
They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-08drm: mm: fix debug outputDaniel Vetter
The looping helper didn't do anything due to a superficial semicolon. Furthermore one of the two dump functions suffered from copy&paste fail. While staring at the code I've also noticed that the replace helper (currently unused) is a bit broken. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-02-23drm: mm: add helper to unwind scan stateDaniel Vetter
With the switch to implicit free space accounting one pointer got unused when scanning. Use it to create a single-linked list to ensure correct unwinding of the scan state. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-23drm: mm: add api for embedding struct drm_mm_nodeDaniel Vetter
The old api has a two-step process: First search for a suitable free hole, then allocate from that specific hole. No user used this to do anything clever. So drop it for the embeddable variant of the drm_mm api (the old one retains this ability, for the time being). With struct drm_mm_node embedded, we cannot track allocations anymore by checking for a NULL pointer. So keep track of this and add a small helper drm_mm_node_allocated. Also add a function to move allocations between different struct drm_mm_node. v2: Implement suggestions by Chris Wilson. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-23drm: mm: extract node insert helper functionsDaniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-23drm: mm: track free areas implicitlyDaniel Vetter
The idea is to track free holes implicitly by marking the allocation immediatly preceeding a hole. To avoid an ugly corner case add a dummy head_node to struct drm_mm to track the hole that spans to complete allocation area when the memory manager is empty. To guarantee that there's always a preceeding/following node (that might be marked as hole_follows == 1), move the mm->node_list list_head to the head_node. The main allocator and fair-lru scan code actually becomes simpler. Only the debug code slightly suffers because free areas are no longer explicit. Also add drm_mm_for_each_node (which will be much more useful when struct drm_mm_node is embeddable). Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-10-27drm_mm: add support for range-restricted fair-lru scansDaniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-08-26drm: mm: fix range restricted allocationsDaniel Vetter
With the code cleanup in 7a6b2896f261894dde287d3faefa4b432cddca53 is the first bad commit commit 7a6b2896f261894dde287d3faefa4b432cddca53 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 2 15:02:15 2010 +0100 drm_mm: extract check_free_mm_node I've botched up the range-restriction checks. The result is usually an X server dying with SIGBUS in libpixman (software fallback rendering). Change the code to adjust the start and end for range restricted allocations. IMHO this even makes the code a bit clearer. Fixes regression bug: https://bugs.freedesktop.org/show_bug.cgi?id=29738 Reported-by-Tested-by: Till MAtthiesen <entropy@everymail.net> Acked-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-07drm: implement helper functions for scanning lru listDaniel Vetter
These helper functions can be used to efficiently scan lru list for eviction. Eviction becomes a three stage process: 1. Scanning through the lru list until a suitable hole has been found. 2. Scan backwards to restore drm_mm consistency and find out which objects fall into the hole. 3. Evict the objects that fall into the hole. These helper functions don't allocate any memory (at the price of not allowing any other concurrent operations). Hence this can also be used for ttm (which does lru scanning under a spinlock). Evicting objects in this fashion should be more fair than the current approach by i915 (scan the lru for a object large enough to contain the new object). It's also more efficient than the current approach used by ttm (uncoditionally evict objects from the lru until there's enough free space). Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Hellstrom <thellstrom@vmwgfx.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-07drm_mm: extract check_free_mm_nodeDaniel Vetter
There are already two copies of this logic. And the new scanning stuff will add some more. So extract it into a small helper function. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Hellstrom <thellstrom@vmwgfx.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-07drm: sane naming for drm_mm.cDaniel Vetter
Yeah, I've kinda noticed that fl_entry is the free stack. Still give it (and the memory node list ml_entry) decent names. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Hellstrom <thellstrom@vmwgfx.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-07drm: kill dead code in drm_mm.cDaniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Hellstrom <thellstrom@vmwgfx.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-07-07drm: use list_for_each_entry in drm_mm.cDaniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Thomas Hellstrom <thellstrom@vmwgfx.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-02-15drm: Fix a bug in the range manager.Thomas Hellstrom
When searching for free space in a range, the function could return a node extending outside of the given range. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-23drm/mm: fix logic for selection of best fit blockBob Gleitsmann
This is from bug 25728. [airlied: I'm just forwarding the patch for review, Thomas, ickle?] Acked-by: Jerome Glisse <jglisse@redhat.com> Acked-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-10drm: Add memory manager debug functionJerome Glisse
drm_mm_debug_table will print the memory manager state in table allowing to give a snapshot of the manager at given point in time. Usefull for debugging. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-10drm: Add search/get functions to get a block in a specific rangeJerome Glisse
These are required for changes to TTM. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-08Merge branch 'drm-core-next' into drm-linusDave Airlie
Bring all core drm changes into 2.6.32 tree and resolve the conflict that occurs. Conflicts: drivers/gpu/drm/drm_fb_helper.c
2009-12-04drm/mm: fixup typo in debug functions.Dave Airlie
Free and used were reversed. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-11-24drm: mm always protect change to unused_nodes with unused_lock spinlockJerome Glisse
unused_nodes modification needs to be protected by unused_lock spinlock. Here is an example of an usage where there is no such protection without this patch. Process 1: 1-drm_mm_pre_get(this function modify unused_nodes list) 2-spin_lock(spinlock protecting mm struct) 3-drm_mm_put_block(this function might modify unused_nodes list but doesn't protect modification with unused_lock) 4-spin_unlock(spinlock protecting mm struct) Process2: 1-drm_mm_pre_get(this function modify unused_nodes list) At this point Process1 & Process2 might both be doing modification to unused_nodes list. This patch add unused_lock protection into drm_mm_put_block to avoid such issue. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-01drm/mm: add ability to dump mm lists via debugfsDave Airlie
This adds code to the drm_mm to talk to debugfs, and adds support to radeon to add the VRAM and GTT mm lists to debugfs. I tested with spinlock debugging and it doesn't give out. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-18drm: Apply "Memory fragmentation from lost alignment blocks"Thomas Hellstrom
also for the atomic path by using a common code-path. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-14drm: Memory fragmentation from lost alignment blocksChris Wilson
If the block needs an alignment but otherwise fits exactly into the tail, then the split-off block from the start would remain marked as non-free. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-12drm: Split out the mm declarations in a separate header. Add atomic operations.Jerome Glisse
this is a TTM preparation patch, it rearranges the mm and add operations needed to do mm operations in atomic context. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-29DRM: add mode setting supportDave Airlie
Add mode setting support to the DRM layer. This is a fairly big chunk of work that allows DRM drivers to provide full output control and configuration capabilities to userspace. It was motivated by several factors: - the fb layer's APIs aren't suited for anything but simple configurations - coordination between the fb layer, DRM layer, and various userspace drivers is poor to non-existent (radeonfb excepted) - user level mode setting drivers makes displaying panic & oops messages more difficult - suspend/resume of graphics state is possible in many more configurations with kernel level support This commit just adds the core DRM part of the mode setting APIs. Driver specific commits using these new structure and APIs will follow. Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com> Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-10-17drm: Add GEM ("graphics execution manager") to i915 driver.Eric Anholt
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>
2008-07-14drm: reorganise drm tree to be more future proof.Dave Airlie
With the coming of kernel based modesetting and the memory manager stuff, the everything in one directory approach was getting very ugly and starting to be unmanageable. This restructures the drm along the lines of other kernel components. It creates a drivers/gpu/drm directory and moves the hw drivers into subdirectores. It moves the includes into an include/drm, and sets up the unifdef for the userspace headers we should be exporting. Signed-off-by: Dave Airlie <airlied@redhat.com>