| /linux-6.12.1/drivers/gpu/drm/ |
| D | drm_exec.c | 11 * multiple GEM objects while preparing hardware operations (e.g. command
15 * unlocks all previously locked GEM objects and locks the contended one first
16 * before locking any further objects.
53 /* Unlock all objects and drop references */
72 * @nr: the initial # of objects
74 * Initialize the object and make sure that we can track locked objects.
76 * If nr is non-zero then it is used as the initial objects table size.
85 exec->objects = kvmalloc_array(nr, sizeof(void *), GFP_KERNEL); in drm_exec_init()
88 exec->max_objects = exec->objects ? nr : 0; in drm_exec_init()
99 * Unlock all locked objects, drop the references to objects and free all memory
[all …]
|
| D | drm_lease.c | 31 * - An 'owner' is a &struct drm_master that is not leasing objects from
32 * another &struct drm_master, and hence 'owns' the objects. The owner can be
35 * - A 'lessor' is a &struct drm_master which is leasing objects to one or more
39 * - A 'lessee' is a &struct drm_master which is leasing objects from some
41 * lessor recorded in &drm_master.lessor, and holds the set of objects that
49 * The set of objects any &struct drm_master 'controls' is limited to the set
50 * of objects it leases (for lessees) or all objects (for owners).
52 * Objects not controlled by a &struct drm_master cannot be modified through
58 * Since each lessee may lease objects from a single lessor, display resource
65 * objects from the owner can be searched via the owner's
[all …]
|
| /linux-6.12.1/drivers/gpu/drm/i915/gem/ |
| D | i915_gem_region.c | 18 mutex_lock(&mem->objects.lock); in i915_gem_object_init_memory_region()
19 list_add(&obj->mm.region_link, &mem->objects.list); in i915_gem_object_init_memory_region()
20 mutex_unlock(&mem->objects.lock); in i915_gem_object_init_memory_region()
27 mutex_lock(&mem->objects.lock); in i915_gem_object_release_memory_region()
29 mutex_unlock(&mem->objects.lock); in i915_gem_object_release_memory_region()
85 * the GTT, due to alignemnt restrictions. For such special objects, in __i915_gem_object_create_region()
87 * revisit this, either by allowing special mis-aligned objects in the in __i915_gem_object_create_region()
141 * i915_gem_process_region - Iterate over all objects of a region using ops
142 * to process and optionally skip objects
147 * checking whether to skip objects, and, if not, lock the objects and
[all …]
|
| D | i915_gem_shrinker.c | 85 * up to @target pages of main memory backing storage from buffer objects.
87 * when purgeable objects should be removed from caches preferentially.
92 * Therefore code that needs to explicitly shrink buffer objects caches (e.g. to
132 * Unbinding of objects will require HW access; Let us not wake the in i915_gem_shrink()
165 * object as we may end up waiting for and/or retiring the objects. in i915_gem_shrink()
169 * removing objects. in i915_gem_shrink()
188 * We serialize our access to unreferenced objects through in i915_gem_shrink()
189 * the use of the struct_mutex. While the objects are not in i915_gem_shrink()
266 * requests to also be able to release backing storage for active objects.
301 * available GEM objects worth of pages. That is we don't want in i915_gem_shrinker_count()
[all …]
|
| /linux-6.12.1/include/drm/ |
| D | drm_exec.h | 29 * @num_objects: number of objects locked
34 * @max_objects: maximum objects in array
39 * @objects: array of the locked objects
41 struct drm_gem_object **objects; member
60 * index is within the number of locked objects. NULL otherwise.
65 return index < exec->num_objects ? exec->objects[index] : NULL; in drm_exec_obj()
69 * drm_exec_for_each_locked_object - iterate over all the locked objects
74 * Iterate over all the locked GEM objects inside the drm_exec object.
81 * objects in reverse locking order
86 * Iterate over all the locked GEM objects inside the drm_exec object in
[all …]
|
| D | drm_mode_object.h | 34 * struct drm_mode_object - base structure for modeset objects
38 * @refcount: reference count for objects which with dynamic lifetime
39 * @free_cb: free function callback, only set for objects with dynamic lifetime
41 * Base structure for modeset objects visible to userspace. Objects can be
49 * - For objects with dynamic lifetimes (as indicated by a non-NULL @free_cb) it
52 * and &drm_property_blob. These objects provide specialized reference
79 * a better job of detaching property from mode objects to avoid
99 * and drm_object_property_get_value() on mutable objects, i.e. those
|
| /linux-6.12.1/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ |
| D | overview.rst | 26 network ports to create functional objects/devices such as network
29 which DPAA2 software drivers use to operate on DPAA2 objects.
53 | Resources Objects |
71 DPIO objects.
73 Overview of DPAA2 Objects
76 The section provides a brief overview of some key DPAA2 objects.
77 A simple scenario is described illustrating the objects involved
84 types of DPAA2 objects. In the example diagram below there
85 are 8 objects of 5 types (DPMCP, DPIO, DPBP, DPNI, and DPMAC)
105 of the DPRC, discover the hardware objects present (including mappable
[all …]
|
| /linux-6.12.1/drivers/gpu/drm/i915/selftests/ |
| D | i915_gem_evict.c | 40 struct list_head *objects) in quirk_add() argument
42 /* quirk is only for live tiled objects, use it to declare ownership */ in quirk_add()
45 list_add(&obj->st_link, objects); in quirk_add()
48 static int populate_ggtt(struct i915_ggtt *ggtt, struct list_head *objects) in populate_ggtt() argument
71 quirk_add(obj, objects); in populate_ggtt()
78 pr_err("No objects on the GGTT inactive list!\n"); in populate_ggtt()
111 LIST_HEAD(objects); in igt_evict_something()
114 /* Fill the GGTT with pinned objects and try to evict one. */ in igt_evict_something()
116 err = populate_ggtt(ggtt, &objects); in igt_evict_something()
149 cleanup_objects(ggtt, &objects); in igt_evict_something()
[all …]
|
| D | intel_memory_region.c | 33 struct list_head *objects) in close_objects() argument
38 list_for_each_entry_safe(obj, on, objects, st_link) { in close_objects()
62 LIST_HEAD(objects); in igt_mock_fill()
85 list_add(&obj->st_link, &objects); in igt_mock_fill()
101 close_objects(mem, &objects); in igt_mock_fill()
108 struct list_head *objects, in igt_object_create() argument
123 list_add(&obj->st_link, objects); in igt_object_create()
166 LIST_HEAD(objects); in igt_mock_reserve()
211 obj = igt_object_create(mem, &objects, size, 0); in igt_mock_reserve()
229 close_objects(mem, &objects); in igt_mock_reserve()
[all …]
|
| /linux-6.12.1/Documentation/dev-tools/ |
| D | kmemleak.rst | 7 with the difference that the orphan objects are not freed but only
17 number of new unreferenced objects found. If the ``debugfs`` isn't already
37 Note that the orphan objects are listed in the order they were allocated
39 objects to be reported as orphan.
61 marking all current reported unreferenced objects grey,
62 or free all kmemleak objects if kmemleak has been disabled.
99 1. mark all objects as white (remaining white objects will later be
105 3. scan the gray objects for matching addresses (some white objects
108 4. the remaining white objects are considered orphan and reported via
123 'clear' command to clear all reported unreferenced objects from the
[all …]
|
| /linux-6.12.1/include/linux/ |
| D | objpool.h | 28 * 1) Maximum objects (capacity) is fixed after objpool creation
29 * 2) All pre-allocated objects are managed in percpu ring array,
44 * continuous memory: CPU assigned number of objects are stored just after
98 #define OBJPOOL_NR_OBJECT_MAX (1UL << 24) /* maximum numbers of total objects */
102 * objpool_init() - initialize objpool and pre-allocated objects
104 * @nr_objs: total objects to be pre-allocated by this object pool
113 * All pre-allocated objects are to be zeroed after memory allocation.
117 * objects. It's caller's duty to perform reinitialization after each
142 * be available objects in slot, which could be ensured in __objpool_try_get_slot()
220 * the same object multiple times or wrong "objects" into objpool)
[all …]
|
| D | dynamic_queue_limits.h | 11 * 1) Objects are queued up to some limit specified as number of objects.
13 * objects.
19 * The goal of dql is to calculate the limit as the minimum number of objects
23 * dql_queued - called when objects are enqueued to record number of objects
24 * dql_avail - returns how many objects are available to be queued based
25 * on the object limit and how many objects are already enqueued
26 * dql_completed - called at completion time to indicate how many objects
122 * Record number of objects queued. Assumes that caller has already checked
146 /* Returns how many objects can be queued, < 0 indicates over limit. */
152 /* Record number of completed objects and recalculate the limit. */
|
| D | kfence.h | 40 * KFENCE objects live in a separate page range and are not to be intermixed
41 * with regular heap objects (e.g. KFENCE objects must never be added to the
76 * kfence_shutdown_cache() - handle shutdown_cache() for KFENCE objects
79 * Before shutting down a cache, one must ensure there are no remaining objects
80 * allocated from it. Because KFENCE objects are not referenced from the cache
84 * not return if allocated objects still exist: it prints an error message and
87 * If the only such objects are KFENCE objects, we will not leak the entire
89 * objects "zombie allocations". Objects may then still be used or freed (which
114 * allowing it to transparently return KFENCE-allocated objects with a low
152 * SL[AU]B-allocated objects are laid out within a page one by one, so it is
[all …]
|
| /linux-6.12.1/Documentation/core-api/ |
| D | debug-objects.rst | 11 kernel objects and validate the operations on those.
15 - Activation of uninitialized objects
17 - Initialization of active objects
19 - Usage of freed/destroyed objects
62 tracking objects and the state of the internal tracking objects pool.
75 active and destroyed objects. When debugobjects detects an error, then
98 active and destroyed objects. When debugobjects detects an error, then
112 object returns. Otherwise we keep track of stale objects.
122 active and destroyed objects. When debugobjects detects an error, then
131 objects. The fixup function checks whether the object is valid and calls
[all …]
|
| D | assoc_array.rst | 11 1. Objects are opaque pointers. The implementation does not care where they
16 Pointers to objects _must_ be zero in the least significant bit.
18 2. Objects do not need to contain linkage blocks for use by the array. This
20 Rather, the array is made up of metadata blocks that point to objects.
22 3. Objects require index keys to locate them within the array.
32 7. Index keys can include a hash to scatter objects throughout the array.
34 8. The array can iterated over. The objects will not necessarily come out in
39 circumstances, some objects may be seen more than once. If this is a
40 problem, the iterator should lock against modification. Objects will not
43 10. Objects in the array can be looked up by means of their index key.
[all …]
|
| /linux-6.12.1/Documentation/mm/ |
| D | zsmalloc.rst | 19 For simplicity, zsmalloc can only allocate objects of size up to PAGE_SIZE
79 the number of objects allocated
81 the number of objects allocated to the user
90 objects stored in the zspage. The inuse counter determines the zspage's
91 "fullness group" which is calculated as the ratio of the "inuse" objects to
92 the total number of objects the zspage can hold (objs_per_zspage). The
105 of objects that each zspage can store.
118 #100 instead of size class #96. Size class #100 is meant for objects of size
122 hold a total of 5 objects. If we need to store 13 objects of size 1568, we
126 objects of size 1568 bytes) and trace `calculate_zspage_chain_size()`, we
[all …]
|
| /linux-6.12.1/drivers/iommu/iommufd/ |
| D | main.c | 5 * iommufd provides control over the IOMMU HW objects created by IOMMU kernel
6 * drivers. IOMMU HW objects revolve around IO page tables that map incoming DMA
54 rc = xa_alloc(&ictx->objects, &obj->id, XA_ZERO_ENTRY, in _iommufd_object_alloc()
68 * destruction. Expect for special kernel-only objects there is no in-kernel way
69 * to reliably destroy a single object. Thus all APIs that are creating objects
78 old = xa_store(&ictx->objects, obj->id, obj, GFP_KERNEL); in iommufd_object_finalize()
88 old = xa_erase(&ictx->objects, obj->id); in iommufd_object_abort()
115 xa_lock(&ictx->objects); in iommufd_get_object()
116 obj = xa_load(&ictx->objects, id); in iommufd_get_object()
120 xa_unlock(&ictx->objects); in iommufd_get_object()
[all …]
|
| /linux-6.12.1/Documentation/admin-guide/mm/ |
| D | shrinker_debugfs.rst | 48 3. *Count objects*
52 <cgroup inode id> <nr of objects on node 0> <nr of objects on node 1> ...
53 <cgroup inode id> <nr of objects on node 0> <nr of objects on node 1> ...
56 If there are no objects on all numa nodes, a line is omitted. If there
57 are no objects at all, the output might be empty.
106 4. *Scan objects*
110 <cgroup inode id> <numa id> <number of objects to scan>
|
| /linux-6.12.1/Documentation/driver-api/acpi/ |
| D | scan_handlers.rst | 13 is scanned in search of device objects that generally represent various pieces
16 and the hierarchy of those struct acpi_device objects reflects the namespace
17 layout (i.e. parent device objects in the namespace are represented by parent
18 struct acpi_device objects and analogously for their children). Those struct
19 acpi_device objects are referred to as "device nodes" in what follows, but they
20 should not be confused with struct device_node objects used by the Device Trees
21 parsing code (although their role is analogous to the role of those objects).
28 information from the device objects represented by them and populating them with
38 basis of the device node's hardware ID (HID). They are performed by objects
|
| /linux-6.12.1/include/media/ |
| D | media-request.h | 3 * Media device request objects
32 * request objects are being added,
57 * @objects: List of @struct media_request_object request objects
58 * @num_incomplete_objects: The number of incomplete objects in the request
69 struct list_head objects; member
78 * media_request_lock_for_access - Lock the request to access its objects
122 * media_request_lock_for_update - Lock the request for updating its objects
314 * Since this function needs to walk the list of objects it takes
347 * request is released all completed objects will be unbound by the
350 * Buffer objects will be added to the end of the request's object
[all …]
|
| /linux-6.12.1/Documentation/ABI/testing/ |
| D | sysfs-kernel-slab | 48 The alloc_fastpath file shows how many objects have been
72 was empty but there were objects available as the result of
93 The alloc_slowpath file shows how many objects have been
105 The cache_dma file is read-only and specifies whether objects
168 has been deactivated and contained free objects that were freed
201 slabs (not objects) are freed by rcu.
230 The free_fastpath file shows how many objects have been freed
241 The free_frozen file shows how many objects have been freed to
275 The free_slowpath file shows how many objects have been freed
287 objects are aligned on cachelines.
[all …]
|
| /linux-6.12.1/arch/arm/mach-shmobile/ |
| D | Makefile | 6 # Common objects
9 # CPU objects
19 # CPU reset vector handling objects
22 # Shared SoC family objects
29 # SMP objects
36 # PM objects
|
| /linux-6.12.1/tools/build/Documentation/ |
| D | Build.txt | 5 idea and the way how objects are built is the same.
7 Basically the user provides set of 'Build' files that list objects and
11 we setup source objects, but we support more. This allows one 'Build' file to
12 carry a sources list for multiple build objects.
46 The user supplies 'Build' makefiles that contains a objects list, and connects
64 only prepares proper objects to be compiled and grouped together.
86 which creates the following objects:
91 that contain request objects names in Build files.
166 $ make util/map.o # objects
|
| /linux-6.12.1/Documentation/gpu/ |
| D | drm-mm.rst | 96 GEM is data-agnostic. It manages abstract buffer objects without knowing
134 GEM Objects Creation
137 GEM splits creation of GEM objects and allocation of the memory that
140 GEM objects are represented by an instance of struct :c:type:`struct
142 extend GEM objects with private information and thus create a
169 often the case in embedded devices. Drivers can create GEM objects with
170 no shmfs backing (called private GEM objects) by initializing them with a call
172 private GEM objects must be managed by drivers.
174 GEM Objects Lifetime
177 All GEM objects are reference-counted by the GEM core. References can be
[all …]
|
| /linux-6.12.1/drivers/gpu/drm/i915/ |
| D | i915_gem_evict.c | 79 /* Dead objects don't need pins */ in grab_vma()
130 * @start: start (inclusive) of the range from which to evict objects
131 * @end: end (exclusive) of the range from which to evict objects
168 * The goal is to evict objects and amalgamate space in rough LRU order. in i915_gem_evict_something()
169 * Since both active and inactive objects reside on the same list, in i915_gem_evict_something()
175 * 1. Inactive objects (already retired, random order) in i915_gem_evict_something()
176 * 2. Active objects (will stall on unbinding, oldest scanned first) in i915_gem_evict_something()
242 * Can we unpin some objects such as idle hw contents, in i915_gem_evict_something()
255 * the pinning for active objects such as contexts and ring, in i915_gem_evict_something()
277 * scanning, therefore store to-be-evicted objects on a in i915_gem_evict_something()
[all …]
|