| /linux/drivers/gpu/drm/ |
| H A 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 …]
|
| H A 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/include/drm/ |
| H A 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 …]
|
| /linux/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ |
| H A 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/drivers/gpu/drm/i915/selftests/ |
| H A 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 …]
|
| H A 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/Documentation/core-api/ |
| H A 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 …]
|
| H A 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/include/linux/ |
| H A 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 …]
|
| H A D | hashtable.h | 158 * hash_for_each_possible - iterate over all possible objects hashing to the
163 * @key: the key of the objects to iterate over
169 * hash_for_each_possible_rcu - iterate over all possible objects hashing to the
174 * @key: the key of the objects to iterate over
181 * hash_for_each_possible_rcu_notrace - iterate over all possible objects hashing
186 * @key: the key of the objects to iterate over
196 * hash_for_each_possible_safe - iterate over all possible objects hashing to the
202 * @key: the key of the objects to iterate over
|
| /linux/Documentation/admin-guide/mm/ |
| H A 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/Documentation/driver-api/acpi/ |
| H A 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/Documentation/ABI/testing/ |
| H A 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/lib/ |
| H A D | debugobjects.c | 3 * Generic infrastructure for lifetime debugging of objects.
39 * We limit the freeing of debug objects via workqueue at a maximum
40 * frequency of 10Hz and about 1024 objects for each freeing operation.
41 * So it is freeing at most 10k debug objects per second.
58 struct hlist_head objects; member
160 first_batch = src->objects.first; in pool_move_batch()
166 src->objects.first = next_batch; in pool_move_batch()
168 next_batch->pprev = &src->objects.first; in pool_move_batch()
171 last->next = dst->objects.first; in pool_move_batch()
174 first_batch->pprev = &dst->objects.first; in pool_move_batch()
[all …]
|
| /linux/Documentation/gpu/ |
| H A 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 …]
|
| H A D | drm-vm-bind-locking.rst | 54 order. Please refer to the ``Reservation Objects`` section of the
64 single VM. Local GEM objects share the gpu_vm's dma_resv.
72 One of the benefits of VM_BIND is that local GEM objects share the gpu_vm's
74 number of local GEM objects, only one lock is needed to make the exec
98 GEM objects.
100 external GEM objects.
150 Revalidation and eviction of local objects
159 With VM_BIND, all local objects need to be resident when the gpu is
160 executing using the gpu_vm, and the objects need to have valid
174 // gpu_vmas, but since local gem objects share the gpu_vm's
[all …]
|
| /linux/tools/build/Documentation/ |
| H A 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/arch/arm/mach-shmobile/ |
| H A 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/drivers/gpu/drm/i915/ |
| H A 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 …]
|
| /linux/drivers/gpu/drm/vmwgfx/ |
| H A D | vmwgfx_validation.h | 47 * @bo_list: List head for buffer objects
52 * buffer objects
80 * as well unless the number of resources and buffer objects per validation
98 * any buffer objects registered.
101 * Returns: Whether any buffer objects are registered
110 * vmw_validation_bo_reserve - Reserve buffer objects registered with a
127 * vmw_validation_bo_fence - Unreserve and fence buffer objects registered
131 * This function unreserves the buffer objects previously reserved using
|
| /linux/mm/ |
| H A D | slub.c | 4 * objects in per cpu and per node lists.
74 * A. slab->freelist -> List of free objects in a slab
75 * B. slab->inuse -> Number of objects in use
76 * C. slab->objects -> Number of objects in slab
85 * processors may put objects onto the freelist but the processor that
86 * froze the slab is the only one that can retrieve the objects from the
114 * allocating a long series of objects that fill up slabs does not require
159 * cannot scan all objects.
168 * processor. Objects may be freed in the slab while
178 * free objects in addition to the regular freelist
[all …]
|
| /linux/Documentation/networking/devlink/ |
| H A D | netdevsim.rst | 60 Rate objects
63 The ``netdevsim`` driver supports rate objects management, which includes:
65 - registerging/unregistering leaf rate objects per VF devlink port;
66 - creation/deletion node rate objects;
78 Same parameters are exposed for leaf objects in corresponding ports directories.
|
| /linux/drivers/acpi/acpica/ |
| H A D | nspredef.c | 4 * Module Name: nspredef - Validation of ACPI predefined methods and objects
22 * This module validates predefined ACPI objects that appear in the namespace,
24 * validation is to detect problems with BIOS-exposed predefined ACPI objects
33 * 3) For returned package objects, the count of package elements is
131 * For returned Package objects, check the type of all sub-objects. in acpi_ns_check_return_value()
151 * objects are sorted correctly (if required) or buffer objects have in acpi_ns_check_return_value()
161 * or more objects, mark the parent node to suppress further warning in acpi_ns_check_return_value()
223 /* Not one of the supported objects, must be incorrect */ in acpi_ns_check_object_type()
227 /* For reference objects, check that the reference type is correct */ in acpi_ns_check_object_type()
361 /* Not one of the supported objects, must be incorrect */ in acpi_ns_get_bitmapped_type()
|
| /linux/Documentation/filesystems/caching/ |
| H A D | cachefiles.rst | 57 the filesystem, shrinking the cache by culling the objects it contains to make
158 Renaming files in the cache might make objects appear to be other objects (the
175 discarding objects from the cache that have been used less recently than
176 anything else. Culling is based on the access time of data objects. Empty
205 The userspace daemon scans the cache to build up a table of cullable objects.
207 started as soon as space is made in the table. Objects will be skipped if
220 The active cache objects all reside in the first directory. The CacheFiles
221 kernel module moves any retired or culled objects that it can't simply unlink
228 The module represents index objects as directories with the filename "I..." or
231 Data objects are represented as files if they have no children, or directories
[all …]
|
| /linux/Documentation/admin-guide/sysctl/ |
| H A D | user.rst | 15 limits on the number of namespaces and other objects that have
19 malfunction and attempt to create a ridiculous number of objects,
24 The creation of per user per user namespace objects are charged to
28 The creation of objects is also charged to all of the users
33 This recursive counting of created objects ensures that creating a
|