aboutsummaryrefslogtreecommitdiffstats
path: root/include/drm/ttm/ttm_bo_api.h
Commit message (Collapse)AuthorAge
* drm/ttm: Convert ttm_buffer_object_init to use ttm_placementJerome Glisse2009-12-10
| | | | | | | | | | | | | | Convert ttm_buffer_object_init to use struct ttm_placement and rename to ttm_bo_init for consistency with function naming. This allow to give more complex placement at buffer creation. For instance you ask to allocate bo into vram first but if there is not enough vram you can give system as a second possible placement. It also allow to create buffer in a specific range. Also rename ttm_buffer_object_validate to ttm_bo_validate. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/ttm: Have the TTM code return -ERESTARTSYS instead of -ERESTART.Thomas Hellstrom2009-12-10
| | | | | | | | | | Return -ERESTARTSYS instead of -ERESTART when interrupted by a signal. The -ERESTARTSYS is converted to an -EINTR by the kernel signal layer before returned to user-space. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/ttm: Rework validation & memory space allocation (V3)Jerome Glisse2009-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change allow driver to pass sorted memory placement, from most prefered placement to least prefered placement. In order to avoid long function prototype a structure is used to gather memory placement informations such as range restriction (if you need a buffer to be in given range). Range restriction is determined by fpfn & lpfn which are the first page and last page number btw which allocation can happen. If those fields are set to 0 ttm will assume buffer can be put anywhere in the address space (thus it avoids putting a burden on the driver to always properly set those fields). This patch also factor few functions like evicting first entry of lru list or getting a memory space. This avoid code duplication. V2: Change API to use placement flags and array instead of packing placement order into a quadword. V3: Make sure we set the appropriate mem.placement flag when validating or allocation memory space. [Pending Thomas Hellstrom further review but okay from preliminary review so far]. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* ttm: Make parts of a struct ttm_bo_device global.Thomas Hellstrom2009-08-19
| | | | | | | | | | Common resources, like memory accounting and swap lists should be global and not per device. Introduce a struct ttm_bo_global to accomodate this, and register it with sysfs. Add a small sysfs interface to return the number of active buffer objects. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
* drm/ttm: optimize bo_kmap_type valuesPekka Paalanen2009-08-19
| | | | | | | | | | | | | | | A micro-optimization on the function ttm_kmap_obj_virtual(). By defining the values of enum ttm_bo_kmap_obj::bo_kmap_type to have a bit indicating iomem, size of the function ttm_kmap_obj_virtual() will be reduced by 16 bytes on x86_64 (gcc 4.1.2). ttm_kmap_obj_virtual() may be heavily used, when buffer objects are accessed via wrappers, that work for both kinds of memory addresses: iomem cookies and kernel virtual. Signed-off-by: Pekka Paalanen <pq@iki.fi> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Add the TTM GPU memory manager subsystem.Thomas Hellstrom2009-06-14
TTM is a GPU memory manager subsystem designed for use with GPU devices with various memory types (On-card VRAM, AGP, PCI apertures etc.). It's essentially a helper library that assists the DRM driver in creating and managing persistent buffer objects. TTM manages placement of data and CPU map setup and teardown on data movement. It can also optionally manage synchronization of data on a per-buffer-object level. TTM takes care to provide an always valid virtual user-space address to a buffer object which makes user-space sub-allocation of big buffer objects feasible. TTM uses a fine-grained per buffer-object locking scheme, taking care to release all relevant locks when waiting for the GPU. Although this implies some locking overhead, it's probably a big win for devices with multiple command submission mechanisms, since the lock contention will be minimal. TTM can be used with whatever user-space interface the driver chooses, including GEM. It's used by the upcoming Radeon KMS DRM driver and is also the GPU memory management core of various new experimental DRM drivers. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>