^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) DRM Memory Management
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) Modern Linux systems require large amount of graphics memory to store
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) frame buffers, textures, vertices and other graphics-related data. Given
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) the very dynamic nature of many of that data, managing graphics memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) efficiently is thus crucial for the graphics stack and plays a central
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) role in the DRM infrastructure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) The DRM core includes two memory managers, namely Translation Table Maps
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) manager to be developed and tried to be a one-size-fits-them all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) solution. It provides a single userspace API to accommodate the need of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) all hardware, supporting both Unified Memory Architecture (UMA) devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) and devices with dedicated video RAM (i.e. most discrete video cards).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) This resulted in a large, complex piece of code that turned out to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) hard to use for driver development.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) GEM started as an Intel-sponsored project in reaction to TTM's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) complexity. Its design philosophy is completely different: instead of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) providing a solution to every graphics memory-related problems, GEM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) identified common code between drivers and created a support library to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) share it. GEM has simpler initialization and execution requirements than
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) TTM, but has no video RAM management capabilities and is thus limited to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) UMA devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) The Translation Table Manager (TTM)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) ===================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) TTM design background and information belongs here.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) TTM initialization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) ------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) **Warning**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) This section is outdated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) <ttm_bo_driver>` structure to ttm_bo_device_init, together with an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) initialized global reference to the memory manager. The ttm_bo_driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) structure contains several fields with function pointers for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) initializing the TTM, allocating and freeing memory, waiting for command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) completion and fence synchronization, and memory migration.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) The :c:type:`struct drm_global_reference <drm_global_reference>` is made
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) up of several fields:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) struct drm_global_reference {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) enum ttm_global_types global_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) size_t size;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) void *object;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) int (*init) (struct drm_global_reference *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) void (*release) (struct drm_global_reference *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) There should be one global reference structure for your memory manager
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) as a whole, and there will be others for each object created by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) memory manager at runtime. Your global TTM should have a type of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) TTM_GLOBAL_TTM_MEM. The size field for the global object should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) sizeof(struct ttm_mem_global), and the init and release hooks should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) point at your driver-specific init and release routines, which probably
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) eventually call ttm_mem_global_init and ttm_mem_global_release,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) respectively.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) Once your global TTM accounting structure is set up and initialized by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) calling ttm_global_item_ref() on it, you need to create a buffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) object TTM to provide a pool for buffer object allocation by clients and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) the kernel itself. The type of this object should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) ttm_bo_global). Again, driver-specific init and release functions may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) be provided, likely eventually calling ttm_bo_global_ref_init() and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) ttm_bo_global_ref_release(), respectively. Also, like the previous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) object, ttm_global_item_ref() is used to create an initial reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) count for the TTM, which will call your initialization function.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) See the radeon_ttm.c file for an example of usage.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) The Graphics Execution Manager (GEM)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) ====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) The GEM design approach has resulted in a memory manager that doesn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) provide full coverage of all (or even all common) use cases in its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) userspace or kernel API. GEM exposes a set of standard memory-related
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) operations to userspace and a set of helper functions to drivers, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) let drivers implement hardware-specific operations with their own
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) private API.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) The GEM userspace API is described in the `GEM - the Graphics Execution
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) Manager <http://lwn.net/Articles/283798/>`__ article on LWN. While
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) slightly outdated, the document provides a good overview of the GEM API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) principles. Buffer allocation and read and write operations, described
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) as part of the common GEM API, are currently implemented using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) driver-specific ioctls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) GEM is data-agnostic. It manages abstract buffer objects without knowing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) what individual buffers contain. APIs that require knowledge of buffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) contents or purpose, such as buffer allocation or synchronization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) primitives, are thus outside of the scope of GEM and must be implemented
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) using driver-specific ioctls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) On a fundamental level, GEM involves several operations:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) - Memory allocation and freeing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) - Command execution
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) - Aperture management at command execution time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) Buffer object allocation is relatively straightforward and largely
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) provided by Linux's shmem layer, which provides memory to back each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) object.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) Device-specific operations, such as command execution, pinning, buffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) read & write, mapping, and domain ownership transfers are left to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) driver-specific ioctls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) GEM Initialization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) ------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) Drivers that use GEM must set the DRIVER_GEM bit in the struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) :c:type:`struct drm_driver <drm_driver>` driver_features
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) field. The DRM core will then automatically initialize the GEM core
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) before calling the load operation. Behind the scene, this will create a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) DRM Memory Manager object which provides an address space pool for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) object allocation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) In a KMS configuration, drivers need to allocate and initialize a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) command ring buffer following core GEM initialization if required by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) hardware. UMA devices usually have what is called a "stolen" memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) region, which provides space for the initial framebuffer and large,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) contiguous memory regions required by the device. This space is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) typically not managed by GEM, and must be initialized separately into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) its own DRM MM object.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) GEM Objects Creation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) --------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) GEM splits creation of GEM objects and allocation of the memory that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) backs them in two distinct operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) GEM objects are represented by an instance of struct :c:type:`struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) drm_gem_object <drm_gem_object>`. Drivers usually need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) extend GEM objects with private information and thus create a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) driver-specific GEM object structure type that embeds an instance of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) struct :c:type:`struct drm_gem_object <drm_gem_object>`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) To create a GEM object, a driver allocates memory for an instance of its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) specific GEM object type and initializes the embedded struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) :c:type:`struct drm_gem_object <drm_gem_object>` with a call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) to drm_gem_object_init(). The function takes a pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) to the DRM device, a pointer to the GEM object and the buffer object
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) size in bytes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) GEM uses shmem to allocate anonymous pageable memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) drm_gem_object_init() will create an shmfs file of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) requested size and store it into the struct :c:type:`struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) drm_gem_object <drm_gem_object>` filp field. The memory is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) used as either main storage for the object when the graphics hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) uses system memory directly or as a backing store otherwise.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) Drivers are responsible for the actual physical pages allocation by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) calling shmem_read_mapping_page_gfp() for each page.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) Note that they can decide to allocate pages when initializing the GEM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) object, or to delay allocation until the memory is needed (for instance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) when a page fault occurs as a result of a userspace memory access or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) when the driver needs to start a DMA transfer involving the memory).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) Anonymous pageable memory allocation is not always desired, for instance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) when the hardware requires physically contiguous system memory as is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) often the case in embedded devices. Drivers can create GEM objects with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) no shmfs backing (called private GEM objects) by initializing them with a call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) to drm_gem_private_object_init() instead of drm_gem_object_init(). Storage for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) private GEM objects must be managed by drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) GEM Objects Lifetime
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) --------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) All GEM objects are reference-counted by the GEM core. References can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) acquired and release by calling drm_gem_object_get() and drm_gem_object_put()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) respectively.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) When the last reference to a GEM object is released the GEM core calls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) the :c:type:`struct drm_driver <drm_driver>` gem_free_object_unlocked
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) operation. That operation is mandatory for GEM-enabled drivers and must
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) free the GEM object and all associated resources.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) void (\*gem_free_object) (struct drm_gem_object \*obj); Drivers are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) responsible for freeing all GEM object resources. This includes the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) resources created by the GEM core, which need to be released with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) drm_gem_object_release().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) GEM Objects Naming
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) ------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) Communication between userspace and the kernel refers to GEM objects
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) using local handles, global names or, more recently, file descriptors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) All of those are 32-bit integer values; the usual Linux kernel limits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) apply to the file descriptors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) GEM handles are local to a DRM file. Applications get a handle to a GEM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) object through a driver-specific ioctl, and can use that handle to refer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) to the GEM object in other standard or driver-specific ioctls. Closing a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) DRM file handle frees all its GEM handles and dereferences the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) associated GEM objects.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) To create a handle for a GEM object drivers call drm_gem_handle_create(). The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) function takes a pointer to the DRM file and the GEM object and returns a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) locally unique handle. When the handle is no longer needed drivers delete it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) with a call to drm_gem_handle_delete(). Finally the GEM object associated with a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) handle can be retrieved by a call to drm_gem_object_lookup().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) Handles don't take ownership of GEM objects, they only take a reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) to the object that will be dropped when the handle is destroyed. To
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) avoid leaking GEM objects, drivers must make sure they drop the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) reference(s) they own (such as the initial reference taken at object
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) creation time) as appropriate, without any special consideration for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) handle. For example, in the particular case of combined GEM object and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) handle creation in the implementation of the dumb_create operation,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) drivers must drop the initial reference to the GEM object before
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) returning the handle.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) GEM names are similar in purpose to handles but are not local to DRM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) files. They can be passed between processes to reference a GEM object
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) globally. Names can't be used directly to refer to objects in the DRM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) API, applications must convert handles to names and names to handles
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) using the DRM_IOCTL_GEM_FLINK and DRM_IOCTL_GEM_OPEN ioctls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) respectively. The conversion is handled by the DRM core without any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) driver-specific support.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) GEM also supports buffer sharing with dma-buf file descriptors through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) PRIME. GEM-based drivers must use the provided helpers functions to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) implement the exporting and importing correctly. See ?. Since sharing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) file descriptors is inherently more secure than the easily guessable and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) global GEM names it is the preferred buffer sharing mechanism. Sharing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) buffers through GEM names is only supported for legacy userspace.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) Furthermore PRIME also allows cross-device buffer sharing since it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) based on dma-bufs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) GEM Objects Mapping
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) Because mapping operations are fairly heavyweight GEM favours
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) read/write-like access to buffers, implemented through driver-specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) ioctls, over mapping buffers to userspace. However, when random access
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) to the buffer is needed (to perform software rendering for instance),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) direct access to the object can be more efficient.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) The mmap system call can't be used directly to map GEM objects, as they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) don't have their own file handle. Two alternative methods currently
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) co-exist to map GEM objects to userspace. The first method uses a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) driver-specific ioctl to perform the mapping operation, calling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) do_mmap() under the hood. This is often considered
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) dubious, seems to be discouraged for new GEM-enabled drivers, and will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) thus not be described here.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) The second method uses the mmap system call on the DRM file handle. void
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) \*mmap(void \*addr, size_t length, int prot, int flags, int fd, off_t
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) offset); DRM identifies the GEM object to be mapped by a fake offset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) passed through the mmap offset argument. Prior to being mapped, a GEM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) object must thus be associated with a fake offset. To do so, drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) must call drm_gem_create_mmap_offset() on the object.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) Once allocated, the fake offset value must be passed to the application
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) in a driver-specific way and can then be used as the mmap offset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) argument.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) The GEM core provides a helper method drm_gem_mmap() to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) handle object mapping. The method can be set directly as the mmap file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) operation handler. It will look up the GEM object based on the offset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) value and set the VMA operations to the :c:type:`struct drm_driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) <drm_driver>` gem_vm_ops field. Note that drm_gem_mmap() doesn't map memory to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) userspace, but relies on the driver-provided fault handler to map pages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) individually.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) To use drm_gem_mmap(), drivers must fill the struct :c:type:`struct drm_driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) <drm_driver>` gem_vm_ops field with a pointer to VM operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) The VM operations is a :c:type:`struct vm_operations_struct <vm_operations_struct>`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) made up of several fields, the more interesting ones being:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) struct vm_operations_struct {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) void (*open)(struct vm_area_struct * area);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) void (*close)(struct vm_area_struct * area);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) vm_fault_t (*fault)(struct vm_fault *vmf);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) The open and close operations must update the GEM object reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) count. Drivers can use the drm_gem_vm_open() and drm_gem_vm_close() helper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) functions directly as open and close handlers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) The fault operation handler is responsible for mapping individual pages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) to userspace when a page fault occurs. Depending on the memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) allocation scheme, drivers can allocate pages at fault time, or can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) decide to allocate memory for the GEM object at the time the object is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) created.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) Drivers that want to map the GEM object upfront instead of handling page
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) faults can implement their own mmap file operation handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) For platforms without MMU the GEM core provides a helper method
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) drm_gem_cma_get_unmapped_area(). The mmap() routines will call this to get a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) proposed address for the mapping.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) To use drm_gem_cma_get_unmapped_area(), drivers must fill the struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) :c:type:`struct file_operations <file_operations>` get_unmapped_area field with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) a pointer on drm_gem_cma_get_unmapped_area().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) More detailed information about get_unmapped_area can be found in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) Documentation/admin-guide/mm/nommu-mmap.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) Memory Coherency
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) ----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) When mapped to the device or used in a command buffer, backing pages for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) an object are flushed to memory and marked write combined so as to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) coherent with the GPU. Likewise, if the CPU accesses an object after the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) GPU has finished rendering to the object, then the object must be made
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) coherent with the CPU's view of memory, usually involving GPU cache
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) flushing of various kinds. This core CPU<->GPU coherency management is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) provided by a device-specific ioctl, which evaluates an object's current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) domain and performs any necessary flushing or synchronization to put the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) object into the desired coherency domain (note that the object may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) busy, i.e. an active render target; in that case, setting the domain
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) blocks the client and waits for rendering to complete before performing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) any necessary flushing operations).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) Command Execution
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) -----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) Perhaps the most important GEM function for GPU devices is providing a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) command execution interface to clients. Client programs construct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) command buffers containing references to previously allocated memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) objects, and then submit them to GEM. At that point, GEM takes care to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) bind all the objects into the GTT, execute the buffer, and provide
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) necessary synchronization between clients accessing the same buffers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) This often involves evicting some objects from the GTT and re-binding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) others (a fairly expensive operation), and providing relocation support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) which hides fixed GTT offsets from clients. Clients must take care not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) to submit command buffers that reference more objects than can fit in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) the GTT; otherwise, GEM will reject them and no rendering will occur.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) Similarly, if several objects in the buffer require fence registers to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) be allocated for correct rendering (e.g. 2D blits on pre-965 chips),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) care must be taken not to require more fence registers than are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) available to the client. Such resource management should be abstracted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) from the client in libdrm.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) GEM Function Reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) .. kernel-doc:: include/drm/drm_gem.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) .. kernel-doc:: drivers/gpu/drm/drm_gem.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) GEM CMA Helper Functions Reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) ----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) :doc: cma helpers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) .. kernel-doc:: include/drm/drm_gem_cma_helper.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) GEM SHMEM Helper Function Reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) -----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) .. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) :doc: overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) .. kernel-doc:: include/drm/drm_gem_shmem_helper.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) .. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) GEM VRAM Helper Functions Reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) -----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) .. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) :doc: overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) .. kernel-doc:: include/drm/drm_gem_vram_helper.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) .. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) GEM TTM Helper Functions Reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) -----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) .. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) :doc: overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) .. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) VMA Offset Manager
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) .. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) :doc: vma offset manager
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) .. kernel-doc:: include/drm/drm_vma_manager.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) .. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) .. _prime_buffer_sharing:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) PRIME Buffer Sharing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) PRIME is the cross device buffer sharing framework in drm, originally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) buffers are dma-buf based file descriptors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) Overview and Lifetime Rules
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) ---------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) .. kernel-doc:: drivers/gpu/drm/drm_prime.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) :doc: overview and lifetime rules
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) PRIME Helper Functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) .. kernel-doc:: drivers/gpu/drm/drm_prime.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) :doc: PRIME Helpers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) PRIME Function References
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) .. kernel-doc:: include/drm/drm_prime.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) .. kernel-doc:: drivers/gpu/drm/drm_prime.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) DRM MM Range Allocator
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) ======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) .. kernel-doc:: drivers/gpu/drm/drm_mm.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) :doc: Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) LRU Scan/Eviction Support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) .. kernel-doc:: drivers/gpu/drm/drm_mm.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) :doc: lru scan roster
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) DRM MM Range Allocator Function References
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) ------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) .. kernel-doc:: include/drm/drm_mm.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) .. kernel-doc:: drivers/gpu/drm/drm_mm.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) DRM Cache Handling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) .. kernel-doc:: drivers/gpu/drm/drm_cache.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) DRM Sync Objects
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) :doc: Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) .. kernel-doc:: include/drm/drm_syncobj.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) GPU Scheduler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) :doc: Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) Scheduler Function References
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) -----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) .. kernel-doc:: include/drm/gpu_scheduler.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) .. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506) :export:
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags