Searched full:tree (Results 1 – 25 of 925) sorted by relevance
12345678910>>...37
| /Documentation/core-api/ |
| D | maple_tree.rst | 5 Maple Tree
13 The Maple Tree is a B-Tree data type which is optimized for storing
14 non-overlapping ranges, including ranges of size 1. The tree was designed to
17 entry in a cache-efficient manner. The tree can also be put into an RCU-safe
22 The Maple Tree maintains a small memory footprint and was designed to use
24 use the normal API. An :ref:`maple-tree-advanced-api` exists for more complex
25 scenarios. The most important usage of the Maple Tree is the tracking of the
28 The Maple Tree can store values between ``0`` and ``ULONG_MAX``. The Maple
29 Tree reserves values with the bottom two bits set to '10' which are below 4096
34 :ref:`maple-tree-advanced-api`, but are blocked by the normal API.
[all …]
|
| D | rbtree.rst | 12 Red-black trees are a type of self-balancing binary search tree, used for
21 three rotations, respectively, to balance the tree), with slightly slower
31 red-black tree. Virtual memory areas (VMAs) are tracked with red-black
52 tree implementations. Instead of using pointers to separate rb_node and data
55 users are expected to write their own tree search and insert functions
62 Data nodes in an rbtree tree are structures containing a struct rb_node member::
81 Writing a search function for your tree is fairly straightforward: start at the
109 Inserting data in the tree involves first searching for the place to insert the
110 new node, then inserting the node and rebalancing ("recoloring") the tree.
136 /* Add new node and rebalance tree. */
[all …]
|
| /Documentation/devicetree/ |
| D | of_unittest.rst | 13 is attached to the live tree dynamically, independent of the machine's
23 from the unflattened device tree data structure. This interface is used by
51 The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
53 drivers/of/unittest.c. Currently, following Device Tree Source Include files
83 Un-flattened device tree structure:
85 Un-flattened device tree consists of connected device_node(s) in form of a tree
88 // following struct members are used to construct the tree
97 Figure 1, describes a generic structure of machine's un-flattened device tree
99 ``*parent``, that is used to traverse the tree in the reverse direction. So, at
126 Figure 1: Generic structure of un-flattened device tree
[all …]
|
| D | changesets.rst | 8 in the live tree in such a way that either the full set of changes
10 through applying the changeset, then the tree will be rolled back to the
14 When a changeset is applied, all of the changes get applied to the tree
16 receiver sees a complete and consistent state of the tree when it
23 2. A number of DT tree change calls, of_changeset_attach_node(),
26 a set of changes. No changes to the active tree are made at this point.
30 3. of_changeset_apply() - Apply the changes to the tree. Either the
31 entire changeset will get applied, or if there is an error the tree will
|
| D | dynamic-resolution-notes.rst | 13 The resolver is given as an input an arbitrary tree compiled with the
19 1. Get the maximum device tree phandle value from the live tree + 1.
20 2. Adjust all the local phandles of the tree to resolve by that amount.
24 in the live tree. This is the label used to tag the node.
|
| D | usage-model.rst | 7 The Linux usage model for device tree data
11 This article describes how Linux uses the device tree. An overview of
12 the device tree data format can be found on the device tree usage page
17 The "Open Firmware Device Tree", or simply Devicetree (DT), is a data
23 Structurally, the DT is a tree, or acyclic graph with named nodes, and
26 links from one node to another outside of the natural tree structure.
29 is defined for how data should appear in the tree to describe typical
48 Device Tree to discover the topology of the hardware at runtime, and
54 Device Tree.
60 Tree (FDT) was created which could be passed to the kernel as a binary
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-devices | 5 The /sys/devices tree contains a snapshot of the
6 internal state of the kernel device tree. Devices will
9 devices within this tree will change.
11 Please do not rely on the format of this tree because of
13 the tree, please use the /sys/class structure and rely
15 within the /sys/devices tree of the individual devices.
17 devices being added and removed from this tree to find
|
| D | sysfs-firmware-ofw | 5 When using OpenFirmware or a Flattened Device Tree to enumerate
6 hardware, the device tree structure will be exposed in this
9 It is possible for multiple device-tree directories to exist.
10 Some device drivers use a separate detached device tree which
11 have no attachment to the system tree and will appear in a
15 path directly, but instead should follow /proc/device-tree
19 The /proc/device-tree symlink replaces the devicetree /proc
24 hierarchy of directories, one per device tree node. The
28 binary data from the device tree.
42 /sys/firmware/device-tree is deliberate: FDT is also used
|
| /Documentation/arch/arm/google/ |
| D | chromebook-boot-flow.rst | 7 Most recent Chromebooks that use device tree are using the opensource
10 is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
13 The scheme that depthcharge_ uses to pick the device tree takes into account
39 When searching for a device tree, depthcharge_ doesn't care where the
40 compatible string falls within a device tree's root compatible string array.
47 Then depthcharge_ will pick the first device tree even though
48 "google,lazor-rev4-sku0" was the second compatible listed in that device tree.
54 device tree then depthcharge_ *won't* look for a "rev3" device tree.
58 be reflected in the device tree. Thus it's fairly common to see device
62 depthcharge_ has, the most flexibility is achieved if the device tree
[all …]
|
| /Documentation/arch/powerpc/ |
| D | bootwrapper.rst | 29 tree). This image embeds a device tree blob inside
30 the image. The boot wrapper, kernel and device tree
34 tree before jumping into the kernel.
40 which populates the embedded device tree with data
47 dtbImage.%: Similar to zImage, except device tree blob is embedded
53 interface for passing a device tree directly.
67 a device tree blob. This image is a flat binary that
71 the embedded device tree for all information.
75 tree blob inside the image.
81 a device tree to the kernel at boot. If using an older
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | ifork.rst | 43 Extent Tree
47 tree. Under the old scheme, allocating a contiguous run of 1,000 blocks
56 Extents are arranged as a tree. Each node of the tree begins with a
60 points to a block containing more nodes in the extent tree. If the node
63 point to the file's data blocks. The root node of the extent tree is
67 The extent tree header is recorded in ``struct ext4_extent_header``,
93 - Depth of this extent node in the extent tree. 0 = this extent node
95 extent nodes. The extent tree can be at most 5 levels deep: a logical
101 - Generation of the tree. (Used by Lustre, but not standard ext4).
103 Internal nodes of the extent tree, also known as index nodes, are
[all …]
|
| /Documentation/arch/sh/ |
| D | booting.rst | 6 Device-tree compatible SH bootloaders are expected to provide the physical
7 address of the device tree blob in r4. Since legacy bootloaders did not
11 that does not use device tree. Support for the latter is being phased out
12 in favor of device tree.
|
| /Documentation/devicetree/bindings/iio/ |
| D | common.yaml | 14 This document defines device tree properties common to several iio
15 sensors. It doesn't constitute a device tree binding specification by itself but
16 is meant to be referenced by device tree bindings.
18 When referenced from sensor tree bindings the properties defined in this
19 document are defined as follows. The sensor tree bindings are responsible for
|
| /Documentation/devicetree/bindings/display/bridge/ |
| D | snps,dw-mipi-dsi.yaml | 13 This document defines device tree properties for the Synopsys DesignWare MIPI
14 DSI host controller. It doesn't constitute a device tree binding specification
15 by itself but is meant to be referenced by platform-specific device tree
18 When referenced from platform device tree bindings the properties defined in
19 this document are defined as follows. The platform device tree bindings are
|
| D | synopsys,dw-hdmi.yaml | 13 This document defines device tree properties for the Synopsys DesignWare HDMI
14 TX controller (DWC HDMI TX) IP core. It doesn't constitute a full device tree
15 binding specification by itself but is meant to be referenced by device tree
18 When referenced from platform device tree bindings the properties defined in
19 this document are defined as follows. The platform device tree bindings are
|
| /Documentation/filesystems/ |
| D | fsverity.rst | 22 causes the filesystem to build a Merkle tree for the file and persist
26 automatically verified against the file's Merkle tree. Reads of any
31 tree root hash) that fs-verity is enforcing for the file. This ioctl
124 This structure contains the parameters of the Merkle tree to build for
129 use for the Merkle tree, such as FS_VERITY_HASH_ALG_SHA256. See
131 - ``block_size`` is the Merkle tree block size, in bytes. In Linux
152 FS_IOC_ENABLE_VERITY causes the filesystem to build a Merkle tree for
164 stable while the Merkle tree is being built over it.)
208 a Merkle tree and is different from a traditional full-file digest.
277 Merkle tree. The blocks are returned in order from the root level
[all …]
|
| D | sharedsubtree.rst | 187 To begin with, the administrator can mark the entire mount tree
217 If the entire mount tree is visible at multiple locations, then
389 propagates to. A new propagation tree containing 'C1',..,'Cn' is
390 created. This propagation tree is identical to the propagation tree of
398 propagates to. A new propagation tree is set containing all new mounts
400 propagation tree for 'B'.
406 'B' propagates to. A new propagation tree containing the new mounts
407 'C','C1',.. 'Cn' is created. This propagation tree is identical to the
408 propagation tree for 'B'. And finally the mount 'C' and its peer group
438 replicates all the mounts in the tree belonging to the specified mount.
[all …]
|
| /Documentation/mm/ |
| D | ksm.rst | 23 tree.
26 the node of the stable tree that represents such KSM page points to a
28 KSM page points to the stable tree node.
31 the stable tree. The tree node becomes a "chain" that links one or
40 This way the stable tree lookup computational complexity is unaffected
43 stable tree itself.
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices | 7 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
9 Any device associated with a device-tree node will have
15 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
22 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
|
| /Documentation/power/powercap/ |
| D | dtpm.rst | 36 The DTPM is a tree representation describing the power constraints
39 The nodes of the tree are a virtual description aggregating the power
42 The leaves of the tree are the real power manageable devices.
64 When the nodes are inserted in the tree, their power characteristics are propagated to the parents::
90 …xample, if we set a power limitation of 3200mW at the 'SoC' root node, the resulting tree will be::
167 power constraints tree.
170 allocate and link the different nodes of the tree.
175 already existing tree at boot time.
186 The nodes of the DTPM tree are described with dtpm structure. The
200 If a device has its power characteristics changing, then the tree must
[all …]
|
| /Documentation/maintainer/ |
| D | rebasing-and-merging.rst | 50 tree and built on it; modifying your tree will create pain for them. If
64 exceptions, for example, a broken commit in a tree like this should be
67 - Do not reparent a tree without a good reason to do so. Just being on a
123 merge, say *why* the merge is being done. For a lower-level tree, "why" is
132 history into your tree, you cannot rebase that branch, even if you
153 also obscure problems with the development process in your tree; they can
160 Even then, you should not back merge a tree above your immediate upstream
161 tree; if a higher-level back merge is really required, the upstream tree
187 Another reason for doing merges of upstream or another subsystem tree is to
189 sometimes a cross-merge with another tree is the best way to resolve them;
[all …]
|
| /Documentation/dev-tools/kunit/api/ |
| D | of.rst | 4 Device Tree (OF) API
7 The KUnit device tree API is used to test device tree (of_*) dependent code.
|
| /Documentation/translations/zh_CN/core-api/ |
| D | generic-radix-tree.rst | 5 :Original: Documentation/core-api/generic-radix-tree.rst
15 通用基数树/稀疏数组的相关内容请见include/linux/generic-radix-tree.h文件中的
23 include/linux/generic-radix-tree.h
|
| /Documentation/devicetree/bindings/ata/ |
| D | pata-common.yaml | 13 This document defines device tree properties common to most Parallel
15 It doesn't constitute a device tree binding specification by itself but is
16 meant to be referenced by device tree bindings.
18 The PATA (IDE) controller-specific device tree bindings are responsible for
|
| D | sata-common.yaml | 13 This document defines device tree properties common to most Serial
14 AT attachment (SATA) storage devices. It doesn't constitute a device tree
16 tree bindings.
18 The SATA controller-specific device tree bindings are responsible for
|
12345678910>>...37