Searched full:tree (Results 1 – 25 of 1021) sorted by relevance
12345678910>>...41
| /Documentation/devicetree/ |
| D | of_unittest.txt | 1 Open Firmware Device Tree Unittest
9 is attached to the live tree dynamically, independent of the machine's
19 from the unflattened device tree data structure. This interface is used by
25 The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
27 drivers/of/unittest.c. Currently, following Device Tree Source Include files
55 Un-flattened device tree structure:
57 Un-flattened device tree consists of connected device_node(s) in form of a tree
60 // following struct members are used to construct the tree
69 Figure 1, describes a generic structure of machine's un-flattened device tree
71 *parent, that is used to traverse the tree in the reverse direction. So, at
[all …]
|
| D | changesets.txt | 2 in the live tree in such a way that either the full set of changes
4 through applying the changeset, then the tree will be rolled back to the
8 When a changeset is applied, all of the changes get applied to the tree
10 receiver sees a complete and consistent state of the tree when it
17 2. A number of DT tree change calls, of_changeset_attach_node(),
20 a set of changes. No changes to the active tree are made at this point.
24 3. of_changeset_apply() - Apply the changes to the tree. Either the
25 entire changeset will get applied, or if there is an error the tree will
|
| D | dynamic-resolution-notes.txt | 1 Device Tree Dynamic Resolver Notes
5 Device Tree resolver, residing in drivers/of/resolver.c
10 The resolver is given as an input an arbitrary tree compiled with the
16 1. Get the maximum device tree phandle value from the live tree + 1.
17 2. Adjust all the local phandles of the tree to resolve by that amount.
21 in the live tree. This is the label used to tag the node.
|
| D | booting-without-of.txt | 23 2) Device tree generalities
24 3) Device tree "structure" block
25 4) Device tree "strings" block
27 III - Required content of the device tree
40 IV - "dtc", the device tree compiler
69 small device tree, though it is encouraged
97 - Add a chapter about the device-tree
99 the tree that can be "compiled" by dtc.
109 - Add some definitions of interrupt tree (simple/complex)
131 but no new board support will be accepted in the main tree that
[all …]
|
| D | usage-model.txt | 1 Linux and the Device Tree
3 The Linux usage model for device tree data
7 This article describes how Linux uses the device tree. An overview of
8 the device tree data format can be found on the device tree usage page
13 The "Open Firmware Device Tree", or simply Device Tree (DT), is a data
19 Structurally, the DT is a tree, or acyclic graph with named nodes, and
22 links from one node to another outside of the natural tree structure.
25 is defined for how data should appear in the tree to describe typical
44 Device Tree to discover the topology of the hardware at runtime, and
50 Device Tree.
[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/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.
97 tree blob inside the image.
103 a device tree to the kernel at boot. If using an older
[all …]
|
| /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
102 This structure contains the parameters of the Merkle tree to build for
108 use for the Merkle tree, such as FS_VERITY_HASH_ALG_SHA256. See
110 - ``block_size`` must be the Merkle tree block size. Currently, this
128 FS_IOC_ENABLE_VERITY causes the filesystem to build a Merkle tree for
140 stable while the Merkle tree is being built over it.)
256 - Reads of data that doesn't match the verity Merkle tree will fail
264 Direct access to the Merkle tree is not supported. Therefore, if a
273 Merkle tree to produce the "file measurement" which cryptographically
[all …]
|
| D | sharedsubtree.txt | 174 To begin with, the administrator can mark the entire mount tree
204 If the entire mount tree is visible at multiple locations, then
369 propagates to. A new propagation tree containing 'C1',..,'Cn' is
370 created. This propagation tree is identical to the propagation tree of
378 propagates to. A new propagation tree is set containing all new mounts
380 propagation tree for 'B'.
386 'B' propagates to. A new propagation tree containing the new mounts
387 'C','C1',.. 'Cn' is created. This propagation tree is identical to the
388 propagation tree for 'B'. And finally the mount 'C' and its peer group
418 replicates all the mounts in the tree belonging to the specified mount.
[all …]
|
| D | qnx6.txt | 50 data and the addressing levels in that specific tree.
56 to 16 * 256 * 256 = 1048576 blocks that can be addressed by such a tree).
61 tree levels.
87 For more than 16 blocks an indirect addressing in form of another tree is
106 With that longfilename inode number, the longfilename tree can be walked
127 Long filenames are stored in a separate addressing tree. The staring point
129 Each data block (tree leaves) holds one long filename. That filename is
138 The qnx6fs filesystem allocation bitmap is stored in a tree under bitmap
162 tree structures are treated as system blocks.
|
| /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 …]
|
| D | verity.rst | 7 Merkle tree based hashing for individual readonly files. Most of
17 - The Merkle tree, as documented in
19 <fsverity_merkle_tree>`, with the tree levels stored in order from
20 root to leaf, and the tree blocks within each level stored in their
|
| /Documentation/devicetree/bindings/display/bridge/ |
| D | dw_mipi_dsi.txt | 4 This document defines device tree properties for the Synopsys DesignWare MIPI
5 DSI host controller. It doesn't constitue a device tree binding specification
6 by itself but is meant to be referenced by platform-specific device tree
9 When referenced from platform device tree bindings the properties defined in
10 this document are defined as follows. The platform device tree bindings are
|
| D | dw_hdmi.txt | 4 This document defines device tree properties for the Synopsys DesignWare HDMI
5 TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding
7 device tree bindings.
9 When referenced from platform device tree bindings the properties defined in
10 this document are defined as follows. The platform device tree bindings are
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices | 6 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
8 Any device associated with a device-tree node will have
14 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
21 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
|
| /Documentation/devicetree/bindings/fpga/ |
| D | fpga-region.txt | 1 FPGA Region Device Tree Binding
11 - Device Tree Examples
19 the Device Tree. FPGA Regions provide a way to program FPGAs under device tree
22 This device tree binding document hits some of the high points of FPGA usage and
68 device tree.
114 4. The Device Tree overlay is accepted into the live tree.
124 FPGA Regions represent FPGA's and FPGA PR regions in the device tree. An FPGA
133 The intended use is that a Device Tree overlay (DTO) can be used to reprogram an
136 An FPGA Region that exists in the live Device Tree reflects the current state.
137 If the live tree shows a "firmware-name" property or child nodes under a FPGA
[all …]
|
| /Documentation/vm/ |
| D | ksm.rst | 25 tree.
28 the node of the stable tree that represents such KSM page points to a
30 KSM page points to the stable tree node.
33 the stable tree. The tree node becomes a "chain" that links one or
42 This way the stable tree lookup computational complexity is unaffected
45 stable tree itself.
|
| /Documentation/ |
| D | rbtree.txt | 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/core-api/ |
| D | generic-radix-tree.rst | 5 .. kernel-doc:: include/linux/generic-radix-tree.h
8 generic radix tree functions
11 .. kernel-doc:: include/linux/generic-radix-tree.h
|
| /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/arm/ |
| D | microchip.rst | 179 Device Tree for AT91 SoCs and boards
181 All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products
185 Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are
187 any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from
188 the same source tree.
195 - SoCs Device Tree Source Include files are named after the official name of
197 - Device Tree Source Include files (.dtsi) are used to collect common nodes that can be
202 - board Device Tree Source files (.dts) are prefixed by the string "at91-" so
|
| /Documentation/devicetree/bindings/arm/ti/ |
| D | k3.txt | 1 Texas Instruments K3 Multicore SoC architecture device tree bindings
10 Each device tree root node must specify which exact SoC in K3 Multicore SoC
22 In addition, each device tree root node must specify which one or more
|
| /Documentation/process/ |
| D | 7.AdvancedTopics.rst | 42 the tree, use branches, etc. An understanding of git's tools for the
82 turning a tested (hopefully) kernel tree into an untested one. But, beyond
95 an exported tree. Moving changesets between trees to avoid conflicts in
101 As the mainline (or other tree upon which a set of changes is based)
102 advances, it is tempting to merge with that tree to stay on the leading
104 another tree, but rebasing is not an option once a tree is exported to the
118 thing happening; putting up a git tree with unreviewed or off-topic patches
133 importantly, do not use a git tree to bypass the review process. Post an
134 occasional summary of the tree to the relevant list, and, when the time is
135 right, request that the tree be included in linux-next.
[all …]
|
| /Documentation/devicetree/bindings/net/ |
| D | davinci-mdio.txt | 1 TI SoC Davinci/Keystone2 MDIO Controller Device Tree Bindings
18 Future plan is to migrate hwmod data base contents into device tree
19 blob so that, all the required data will be used from device tree dts
|
12345678910>>...41