aboutsummaryrefslogtreecommitdiff
path: root/include/drm/ttm
AgeCommit message (Collapse)Author
2009-08-20Merge Linus master to drm-nextDave Airlie
linux-next conflict reported needed resolution. Conflicts: drivers/gpu/drm/drm_crtc.c drivers/gpu/drm/drm_edid.c drivers/gpu/drm/i915/intel_sdvo.c drivers/gpu/drm/radeon/radeon_ttm.c drivers/gpu/drm/ttm/ttm_bo.c
2009-08-19ttm: Make parts of a struct ttm_bo_device global.Thomas Hellstrom
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>
2009-08-19drm/ttm: Memory accounting rework.Thomas Hellstrom
Use inclusive zones to simplify accounting and its sysfs representation. Use DMA32 accounting where applicable. Add a sysfs interface to make the heuristically determined limits readable and configurable. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-08-19drm/ttm: optimize bo_kmap_type valuesPekka Paalanen
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>
2009-07-29drm/radeon/kms: add initial colortiling support.Dave Airlie
This adds new set/get tiling interfaces where the pitch and macro/micro tiling enables can be set. Along with a flag to decide if this object should have a surface when mapped. The only thing we need to allocate with a mapped surface should be the frontbuffer. Note rotate scanout shouldn't require one, and back/depth shouldn't either, though mesa needs some fixes. It fixes the TTM interfaces along Thomas's suggestions, and I've tested the surface stealing code with two X servers and not seen any lockdep issues. I've stopped tiling the fbcon frontbuffer, as I don't see there being any advantage other than testing, I've left the testing commands in there, just flip the fb_tiled to true in radeon_fb.c Open: Can we integrate endian swapping in with this? Future features: texture tiling - need to relocate texture registers TXOFFSET* with tiling info. This also merges Michel's cleanup surfaces regs at init time patch even though it makes sense on its own, this patch really relies on it. Some PowerMac firmwares set up a tiling surface at the beginning of VRAM which messes us up otherwise. that patch is: Signed-off-by: Michel Dänzer <daenzer@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-07-15drm/ttm/radeon: add dma32 support.Dave Airlie
This add support for using dma32 memory on gpus that really need it. Currently IGPs are left without DMA32 but we might need to change that unless we can fix rs690. Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-07-15ttm: Make messages more readable.Thomas Hellstrom
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-15drm: Add the TTM GPU memory manager subsystem.Thomas Hellstrom
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>