If we want to map GPU memory into user-space, we need to linearize the addresses to not confuse mm-core. Currently, GEM and TTM both implement their own offset-managers to assign a pgoff to each object for user-space CPU access. GEM uses a hash-table, TTM uses an rbtree. This patch provides a unified implementation that can be used to replace both. TTM allows partial mmaps with a given offset, so we cannot use hashtables as the start address may not be known at mmap time. Hence, we use the rbtree-implementation of TTM. We could easily update drm_mm to use an rbtree instead of a linked list for it's object list and thus drop the rbtree from the vma-manager. However, this would slow down drm_mm object allocation for all other use-cases (rbtree insertion) and add another 4-8 bytes to each mm node. Hence, use the separate tree but allow for later migration. This is a rewrite of the 2012-proposal by David Airlie <airlied@linux.ie> v2: - fix Docbook integration - drop drm_mm_node_linked() and use drm_mm_node_allocated() - remove unjustified likely/unlikely usage (but keep for rbtree paths) - remove BUG_ON() as drm_mm already does that - clarify page-based vs. byte-based addresses - use drm_vma_node_reset() for initialization, too v4: - allow external locking via drm_vma_offset_un/lock_lookup() - add locked lookup helper drm_vma_offset_lookup_locked() v5: - fix drm_vma_offset_lookup() to correctly validate range-mismatches (fix (offset > start + pages)) - fix drm_vma_offset_exact_lookup() to actually do what it says - remove redundant vm_pages member (add drm_vma_node_size() helper) - remove unneeded goto - fix documentation Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com> |
||
---|---|---|
.. | ||
ast | ||
cirrus | ||
exynos | ||
gma500 | ||
i2c | ||
i810 | ||
i915 | ||
mga | ||
mgag200 | ||
nouveau | ||
omapdrm | ||
qxl | ||
r128 | ||
radeon | ||
rcar-du | ||
savage | ||
shmobile | ||
sis | ||
tdfx | ||
tilcdc | ||
ttm | ||
udl | ||
via | ||
vmwgfx | ||
ati_pcigart.c | ||
drm_agpsupport.c | ||
drm_auth.c | ||
drm_buffer.c | ||
drm_bufs.c | ||
drm_cache.c | ||
drm_context.c | ||
drm_crtc_helper.c | ||
drm_crtc.c | ||
drm_debugfs.c | ||
drm_dma.c | ||
drm_dp_helper.c | ||
drm_drv.c | ||
drm_edid_load.c | ||
drm_edid.c | ||
drm_encoder_slave.c | ||
drm_fb_cma_helper.c | ||
drm_fb_helper.c | ||
drm_fops.c | ||
drm_gem_cma_helper.c | ||
drm_gem.c | ||
drm_global.c | ||
drm_hashtab.c | ||
drm_info.c | ||
drm_ioc32.c | ||
drm_ioctl.c | ||
drm_irq.c | ||
drm_lock.c | ||
drm_memory.c | ||
drm_mm.c | ||
drm_modes.c | ||
drm_pci.c | ||
drm_platform.c | ||
drm_prime.c | ||
drm_proc.c | ||
drm_rect.c | ||
drm_scatter.c | ||
drm_stub.c | ||
drm_sysfs.c | ||
drm_trace_points.c | ||
drm_trace.h | ||
drm_usb.c | ||
drm_vm.c | ||
drm_vma_manager.c | ||
Kconfig | ||
Makefile | ||
README.drm |
************************************************************ * For the very latest on DRI development, please see: * * http://dri.freedesktop.org/ * ************************************************************ The Direct Rendering Manager (drm) is a device-independent kernel-level device driver that provides support for the XFree86 Direct Rendering Infrastructure (DRI). The DRM supports the Direct Rendering Infrastructure (DRI) in four major ways: 1. The DRM provides synchronized access to the graphics hardware via the use of an optimized two-tiered lock. 2. The DRM enforces the DRI security policy for access to the graphics hardware by only allowing authenticated X11 clients access to restricted regions of memory. 3. The DRM provides a generic DMA engine, complete with multiple queues and the ability to detect the need for an OpenGL context switch. 4. The DRM is extensible via the use of small device-specific modules that rely extensively on the API exported by the DRM module. Documentation on the DRI is available from: http://dri.freedesktop.org/wiki/Documentation http://sourceforge.net/project/showfiles.php?group_id=387 http://dri.sourceforge.net/doc/ For specific information about kernel-level support, see: The Direct Rendering Manager, Kernel Support for the Direct Rendering Infrastructure http://dri.sourceforge.net/doc/drm_low_level.html Hardware Locking for the Direct Rendering Infrastructure http://dri.sourceforge.net/doc/hardware_locking_low_level.html A Security Analysis of the Direct Rendering Infrastructure http://dri.sourceforge.net/doc/security_low_level.html