objects (full) in projects: linux - OpenGrok search results

Project(s)

Full Search
Definition
Symbol
File Path
History
Type

Searched full:objects (Results 1 – 25 of 1038) sorted by relevance

12 3 4 5 6 7 8 9 10 >>...42

/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/drivers/gpu/drm/
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/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 …]
/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/drivers/iommu/iommufd/
H A 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 56 rc = xa_alloc(&ictx->objects, &obj->id, XA_ZERO_ENTRY, xa_limit_31b, in _iommufd_object_alloc() 97 * destruction. Expect for special kernel-only objects there is no in-kernel way 98 * to reliably destroy a single object. Thus all APIs that are creating objects 105 XA_STATE(xas, &ictx->objects, obj->id); in iommufd_object_finalize() 108 xa_lock(&ictx->objects); in iommufd_object_finalize() 110 xa_unlock(&ictx->objects); in iommufd_object_finalize() 118 XA_STATE(xas, &ictx->objects, obj->id); in iommufd_object_abort() 121 xa_lock(&ictx->objects); in iommufd_object_abort() [all …]
/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	49 The alloc_fastpath file shows how many objects have been 73 was empty but there were objects available as the result of 94 The alloc_slowpath file shows how many objects have been 106 The cache_dma file is read-only and specifies whether objects 169 has been deactivated and contained free objects that were freed 202 slabs (not objects) are freed by rcu. 231 The free_fastpath file shows how many objects have been freed 242 The free_frozen file shows how many objects have been freed to 276 The free_slowpath file shows how many objects have been freed 288 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/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/drivers/tee/qcomtee/
H A D	qcomtee_object.h	19 * qcomtee_object provides object refcounting, ID allocation for objects hosted 32 * The objects received from QTEE are refcounted. So the owner of these objects 33 * can issue qcomtee_object_get() to increase the refcount and pass objects 43 * core.c holds an object table for callback objects. An object ID is assigned 45 * these IDs to reference or invoke callback objects. 195 * objects of type %QCOMTEE_OBJECT_TYPE_CB. 226 * @ops: callback operations for objects of type %QCOMTEE_OBJECT_TYPE_CB. 229 * @work is used for releasing objects of %QCOMTEE_OBJECT_TYPE_TEE type. 246 /* Static instances of qcomtee_object objects. */
/linux/Documentation/networking/devlink/
H A D	netdevsim.rst	60 Rate objects 63 The ``netdevsim`` driver supports rate objects management, which includes: 65 - registering/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/mm/
H A D	slub.c	4 * lockless freeing of objects to slabs in the slowpath. 81 * A. slab->freelist -> List of free objects in a slab 82 * B. slab->inuse -> Number of objects in use 83 * C. slab->objects -> Number of objects in slab 98 * slab->objects and slab->freelist == NULL) are not placed on any list. 108 * allocated objects will be simply leaked upon freeing instead of attempting 147 * Objects may have to be freed to their slabs when they are from a remote 148 * node (where we want to avoid filling local sheaves with remote objects) 172 * cannot scan all objects 417 void objects[]; global() member 1673 inc_slabs_node(struct kmem_cache s,int node,int objects) inc_slabs_node() argument 1680 dec_slabs_node(struct kmem_cache * s,int node,int objects) dec_slabs_node() argument 2031 inc_slabs_node(struct kmem_cache * s,int node,int objects) inc_slabs_node() argument 2033 dec_slabs_node(struct kmem_cache * s,int node,int objects) dec_slabs_node() argument 2080 handle_failed_objexts_alloc(unsigned long obj_exts,struct slabobj_ext * vec,unsigned int objects) handle_failed_objexts_alloc() argument 2100 handle_failed_objexts_alloc(unsigned long obj_exts,struct slabobj_ext * vec,unsigned int objects) handle_failed_objexts_alloc() argument 2149 unsigned int objects = objs_per_slab(s, slab); alloc_slab_obj_exts() local 2401 __alloc_tagging_slab_free_hook(struct kmem_cache * s,struct slab * slab,void ** p,int objects) __alloc_tagging_slab_free_hook() argument 2425 alloc_tagging_slab_free_hook(struct kmem_cache * s,struct slab * slab,void ** p,int objects) alloc_tagging_slab_free_hook() argument 2440 alloc_tagging_slab_free_hook(struct kmem_cache * s,struct slab * slab,void ** p,int objects) alloc_tagging_slab_free_hook() argument 2476 memcg_slab_free_hook(struct kmem_cache * s,struct slab * slab,void ** p,int objects) memcg_slab_free_hook() argument 2562 memcg_slab_free_hook(struct kmem_cache * s,struct slab * slab,void ** p,int objects) memcg_slab_free_hook() argument 2852 void *objects[PCS_BATCH_MAX]; __sheaf_flush_main_batch() local 6169 struct llist_head objects; global() member 9057 unsigned int objects; cpu_partial_store() local [all...]
/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/tools/mm/
H A D	slabinfo.c	36 unsigned long partial, objects, slabs, objects_partial, objects_total; member 343 printf("Name Objects Alloc Free" in first_line() 346 printf("Name Objects Objsize %s " in first_line() 383 return slab_size(s) - s->objects * s->object_size; in slab_waste() 562 printf("\nSlabcache: %-15s Aliases: %2d Order : %2d Objects: %lu\n", in report() 563 s->name, s->aliases, s->order, s->objects); in report() 580 onoff(s->red_zone), s->objects * s->object_size); in report() 583 s->slabs * (page_size << s->order) - s->objects * s->object_size); in report() 586 (s->slab_size - s->object_size) * s->objects); in report() 587 printf("Align : %7d Objects in report() [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`
/linux/Documentation/gpu/
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 …]

12 3 4 5 6 7 8 9 10 >>...42