| /kernel/linux/linux-6.6/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 | 84 * up to @target pages of main memory backing storage from buffer objects.
86 * when purgeable objects should be removed from caches preferentially.
91 * Therefore code that needs to explicitly shrink buffer objects caches (e.g. to
130 * Unbinding of objects will require HW access; Let us not wake the in i915_gem_shrink()
161 * object as we may end up waiting for and/or retiring the objects. in i915_gem_shrink()
165 * removing objects. in i915_gem_shrink()
184 * We serialize our access to unreferenced objects through in i915_gem_shrink()
185 * the use of the struct_mutex. While the objects are not in i915_gem_shrink()
262 * requests to also be able to release backing storage for active objects.
298 * available GEM objects worth of pages. That is we don't want in i915_gem_shrinker_count()
[all …]
|
| /kernel/linux/linux-6.6/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 */
73 * Initialize the object and make sure that we can track locked objects.
78 exec->objects = kmalloc(PAGE_SIZE, GFP_KERNEL); in drm_exec_init()
81 exec->max_objects = exec->objects ? PAGE_SIZE / sizeof(void *) : 0; in drm_exec_init()
92 * Unlock all locked objects, drop the references to objects and free all memory
98 kvfree(exec->objects); in drm_exec_fini()
112 * objects locked.
[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 …]
|
| /kernel/linux/linux-6.6/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 …]
|
| /kernel/linux/linux-5.10/include/linux/ |
| 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
72 * Record number of objects queued. Assumes that caller has already checked
91 /* Returns how many objects can be queued, < 0 indicates over limit. */
97 /* Record number of completed objects and recalculate the limit. */
|
| /kernel/linux/linux-6.6/include/linux/ |
| 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
72 * Record number of objects queued. Assumes that caller has already checked
91 /* Returns how many objects can be queued, < 0 indicates over limit. */
97 /* 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 …]
|
| /kernel/linux/linux-6.6/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 …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-6.6/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 …]
|
| /kernel/linux/linux-5.10/drivers/gpu/drm/i915/selftests/ |
| D | i915_gem_evict.c | 38 struct list_head *objects) in quirk_add() argument
40 /* quirk is only for live tiled objects, use it to declare ownership */ in quirk_add()
43 list_add(&obj->st_link, objects); in quirk_add()
46 static int populate_ggtt(struct i915_ggtt *ggtt, struct list_head *objects) in populate_ggtt() argument
69 quirk_add(obj, objects); in populate_ggtt()
76 pr_err("No objects on the GGTT inactive list!\n"); in populate_ggtt()
109 LIST_HEAD(objects); in igt_evict_something()
112 /* Fill the GGTT with pinned objects and try to evict one. */ in igt_evict_something()
114 err = populate_ggtt(ggtt, &objects); in igt_evict_something()
147 cleanup_objects(ggtt, &objects); in igt_evict_something()
[all …]
|
| /kernel/linux/linux-6.6/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 …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-6.6/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 …]
|
| /kernel/linux/linux-6.6/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 …]
|
| /kernel/linux/linux-5.10/drivers/gpu/drm/ |
| D | drm_lease.c | 211 * drm_lease_create - create a new drm_master with leased objects (idr_mutex not held)
212 * @lessor: lease holder (or owner) of objects
213 * @leases: objects to lease to the new drm_master
216 * make sure all of the desired objects can be leased, atomically
326 * _drm_lease_revoke - revoke access to all leased objects (idr_mutex held)
368 * drm_lease_revoke - revoke access to all leased objects (idr_mutex not held)
380 struct drm_mode_object **objects, in validate_lease() argument
392 if (objects[o]->type == DRM_MODE_OBJECT_CRTC && has_crtc == -1) { in validate_lease()
395 if (objects[o]->type == DRM_MODE_OBJECT_CONNECTOR && has_connector == -1) in validate_lease()
399 if (objects[o]->type == DRM_MODE_OBJECT_PLANE && has_plane == -1) in validate_lease()
[all …]
|
| /kernel/linux/linux-6.6/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
62 rc = xa_alloc(&ictx->objects, &obj->id, XA_ZERO_ENTRY, in _iommufd_object_alloc()
76 * destruction. Expect for special kernel-only objects there is no in-kernel way
77 * to reliably destroy a single object. Thus all APIs that are creating objects
86 old = xa_store(&ictx->objects, obj->id, obj, GFP_KERNEL); in iommufd_object_finalize()
96 old = xa_erase(&ictx->objects, obj->id); in iommufd_object_abort()
123 xa_lock(&ictx->objects); in iommufd_get_object()
124 obj = xa_load(&ictx->objects, id); in iommufd_get_object()
128 xa_unlock(&ictx->objects); in iommufd_get_object()
[all …]
|
| /kernel/linux/linux-5.10/Documentation/filesystems/caching/ |
| D | object.rst | 27 currently interested in. Such objects are represented by the fscache_cookie
30 FS-Cache also maintains a separate in-kernel representation of the objects that
31 a cache backend is currently actively caching. Such objects are represented by
34 as objects.
36 There is a 1:N relationship between cookies and objects. A cookie may be
37 represented by multiple objects - an index may exist in more than one cache -
38 or even by no objects (it may not be cached).
40 Furthermore, both cookies and objects are hierarchical. The two hierarchies
84 and DObject represent data storage objects. Indices may have representation in
85 multiple caches, but currently, non-index objects may not. Objects of any type
[all …]
|
| /kernel/linux/linux-5.10/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
|
| /kernel/linux/linux-6.6/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
|
| /kernel/linux/linux-6.6/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>
|
| /kernel/linux/linux-5.10/include/drm/ |
| 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
|
| /kernel/linux/linux-5.10/Documentation/gpu/ |
| D | drm-mm.rst | 99 GEM is data-agnostic. It manages abstract buffer objects without knowing
137 GEM Objects Creation
140 GEM splits creation of GEM objects and allocation of the memory that
143 GEM objects are represented by an instance of struct :c:type:`struct
145 extend GEM objects with private information and thus create a
172 often the case in embedded devices. Drivers can create GEM objects with
173 no shmfs backing (called private GEM objects) by initializing them with a call
175 private GEM objects must be managed by drivers.
177 GEM Objects Lifetime
180 All GEM objects are reference-counted by the GEM core. References can be
[all …]
|