| /Linux-v6.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 | 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 …]
|
| D | i915_gem_ttm_pm.c | 34 * @backup_pinned: On backup, backup also pinned objects.
109 * i915_ttm_recover_region - Free the backup of all objects of a region
112 * Checks all objects of a region if there is backup attached and if so
129 * i915_ttm_backup_region - Back up all objects of a region to smem.
132 * @backup_pinned: Backup also pinned objects.
134 * Loops over all objects of a region and either evicts them if they are
194 * i915_ttm_restore_region - Restore backed-up objects of a region from smem.
198 * Loops over all objects of a region and if they are backed-up, restores
|
| D | i915_gem_object_types.h | 73 * idle. Active objects can be considered later. The TTM backend for
161 * scanout objects, where the display engine is not coherent with the
162 * CPU cache. For such objects I915_CACHE_NONE or I915_CACHE_WT is
234 * a lot of space for non-ttm gem objects.
327 * dealing with userspace objects the CPU fault handler is free to ignore this.
392 * we might unnecessarily flush non-scanout objects in some places, but
393 * the default assumption is that all normal objects should be using
411 * While for normal objects that are fully coherent, including special
417 * And then for objects that are not coherent at all we use:
447 * security issue when dealing with userspace objects and zeroing. Now,
[all …]
|
| /Linux-v6.1/drivers/gpu/drm/ |
| 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-v6.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-v6.1/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
75 * kfence_shutdown_cache() - handle shutdown_cache() for KFENCE objects
78 * Before shutting down a cache, one must ensure there are no remaining objects
79 * allocated from it. Because KFENCE objects are not referenced from the cache
83 * not return if allocated objects still exist: it prints an error message and
86 * If the only such objects are KFENCE objects, we will not leak the entire
88 * objects "zombie allocations". Objects may then still be used or freed (which
113 * allowing it to transparently return KFENCE-allocated objects with a low
151 * SL[AU]B-allocated objects are laid out within a page one by one, so it is
[all …]
|
| /Linux-v6.1/drivers/gpu/drm/i915/selftests/ |
| D | i915_gem_evict.c | 39 struct list_head *objects) in quirk_add() argument
41 /* quirk is only for live tiled objects, use it to declare ownership */ in quirk_add()
44 list_add(&obj->st_link, objects); in quirk_add()
47 static int populate_ggtt(struct i915_ggtt *ggtt, struct list_head *objects) in populate_ggtt() argument
70 quirk_add(obj, objects); in populate_ggtt()
77 pr_err("No objects on the GGTT inactive list!\n"); in populate_ggtt()
110 LIST_HEAD(objects); in igt_evict_something()
113 /* Fill the GGTT with pinned objects and try to evict one. */ in igt_evict_something()
115 err = populate_ggtt(ggtt, &objects); in igt_evict_something()
148 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-v6.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-v6.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-v6.1/Documentation/admin-guide/mm/ |
| D | shrinker_debugfs.rst | 50 3. *Count objects*
54 <cgroup inode id> <nr of objects on node 0> <nr of objects on node 1> ...
55 <cgroup inode id> <nr of objects on node 0> <nr of objects on node 1> ...
58 If there are no objects on all numa nodes, a line is omitted. If there
59 are no objects at all, the output might be empty.
108 4. *Scan objects*
112 <cgroup inode id> <numa id> <number of objects to scan>
|
| /Linux-v6.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-v6.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-v6.1/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
|
| /Linux-v6.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-v6.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-v6.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-v6.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-v6.1/drivers/gpu/drm/i915/ |
| D | i915_gem_evict.c | 70 /* Dead objects don't need pins */ in grab_vma()
121 * @start: start (inclusive) of the range from which to evict objects
122 * @end: end (exclusive) of the range from which to evict objects
158 * The goal is to evict objects and amalgamate space in rough LRU order. in i915_gem_evict_something()
159 * Since both active and inactive objects reside on the same list, in i915_gem_evict_something()
165 * 1. Inactive objects (already retired, random order) in i915_gem_evict_something()
166 * 2. Active objects (will stall on unbinding, oldest scanned first) in i915_gem_evict_something()
225 * Can we unpin some objects such as idle hw contents, in i915_gem_evict_something()
238 * the pinning for active objects such as contexts and ring, in i915_gem_evict_something()
260 * scanning, therefore store to-be-evicted objects on a in i915_gem_evict_something()
[all …]
|
| /Linux-v6.1/Documentation/filesystems/ |
| D | directory-locking.rst | 10 When taking the i_rwsem on multiple non-directory objects, we
70 objects - A < B iff A is an ancestor of B.
84 (3) locks on non-directory objects are acquired only after locks on
85 directory objects, and are acquired in inode pointer order.
99 non-directory objects are not included in the set of contended locks.
110 Otherwise the set of contended objects would be infinite - each of them
117 would again have an infinite set of contended objects). But that
128 source), such loop would have to contain these objects and the rest of it
143 children", so if we are going to introduce hybrid objects we will need
|
| /Linux-v6.1/tools/perf/Documentation/ |
| D | Build.txt | 18 main makefile that triggers build of all perf objects including
28 makefiles that defines build objects
36 The Makefile.perf triggers the build framework for build objects:
39 resulting in following objects:
43 Those objects are then used in final linking:
|
| /Linux-v6.1/mm/ |
| D | slub.c | 4 * objects in per cpu and per node lists.
71 * A. slab->freelist -> List of free objects in a slab
72 * B. slab->inuse -> Number of objects in use
73 * C. slab->objects -> Number of objects in slab
81 * processors may put objects onto the freelist but the processor that
82 * froze the slab is the only one that can retrieve the objects from the
96 * allocating a long series of objects that fill up slabs does not require
141 * cannot scan all objects.
150 * processor. Objects may be freed in the slab while
160 * free objects in addition to the regular freelist
[all …]
|
