Searched +full:device +full:- +full:tree (Results 1 – 25 of 731) sorted by relevance
12345678910>>...30
| /Documentation/ABI/testing/ |
| 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
|
| D | sysfs-devices | 3 Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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
25 udev <linux-hotplug-devel@lists.sourceforge.net>
|
| /Documentation/arch/arm/google/ |
| D | chromebook-boot-flow.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 Most recent Chromebooks that use device tree are using the opensource
9 Image`_ which contains an OS image as well as a collection of device trees. It
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
16 - Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
17 - Board revision number, determined at runtime (perhaps by reading GPIO
19 - SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
23 - google,$(BOARD)-rev$(REV)-sku$(SKU)
24 - google,$(BOARD)-rev$(REV)
[all …]
|
| /Documentation/devicetree/ |
| D | of_unittest.rst | 1 .. SPDX-License-Identifier: GPL-2.0
13 is attached to the live tree dynamically, independent of the machine's
18 (1) Documentation/devicetree/usage-model.rst
22 provided to device driver developers to fetch the device information..etc.
23 from the unflattened device tree data structure. This interface is used by
24 most of the device drivers in various use cases.
45 from 'scripts/dtc/of_unittest_expect --help'.
48 3. Test-data
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
[all …]
|
| D | usage-model.rst | 1 .. SPDX-License-Identifier: GPL-2.0
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
44 ----------
48 Device Tree to discover the topology of the hardware at runtime, and
[all …]
|
| /Documentation/arch/powerpc/ |
| D | bootwrapper.rst | 17 others. U-Boot is typically found on embedded PowerPC hardware, but there
28 U-Boot (for versions that don't understand the device
29 tree). This image embeds a device tree blob inside
30 the image. The boot wrapper, kernel and device tree
31 are all embedded inside the U-Boot uImage file format
33 bd_info structure and loads the data into the device
34 tree before jumping into the kernel.
37 bd_info structure used in the old U-Boot interfaces,
39 U-Boot platform has a different platform init file
40 which populates the embedded device tree with data
[all …]
|
| D | booting.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 ------------------
9 bootloader <-> kernel interfaces, in order to avoid the degeneration that had
12 this scheme, but no new board support will be accepted in the main tree that
14 merged architecture for ppc32 and ppc64, new 32-bit platforms and 32-bit
19 of a device-tree whose format is defined after Open Firmware specification.
21 doesn't require the device-tree to represent every device in the system and only
23 not require you to create a node for every PCI device in the system. It is a
28 kernel can then probe those and match drivers to device, without having to hard
47 bindings to powerpc. Only the 32-bit client interface
[all …]
|
| /Documentation/arch/sh/ |
| D | booting.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 ------------------
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
9 inter-operate with old bootloaders must either use a builtin DTB or
11 that does not use device tree. Support for the latter is being phased out
12 in favor of device tree.
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices | 2 This documents additional properties of any device beyond what
3 is documented in Documentation/admin-guide/sysfs-rules.rst
7 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
9 Any device associated with a device-tree node will have
10 an of_path symlink pointing to the corresponding device
15 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
18 read, it returns full name of the device node.
22 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
25 read, it returns full name of the device node.
29 Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[all …]
|
| /Documentation/devicetree/bindings/iio/ |
| D | common.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Jonathan Cameron <jic23@kernel.org>
11 - Guido Günther <agx@sigxcpu.org>
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
[all …]
|
| /Documentation/devicetree/bindings/display/bridge/ |
| D | snps,dw-mipi-dsi.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/display/bridge/snps,dw-mipi-dsi.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Philippe CORNU <philippe.cornu@foss.st.com>
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
[all …]
|
| D | synopsys,dw-hdmi.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/display/bridge/synopsys,dw-hdmi.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
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
16 bindings for the platform-specific integrations of the DWC HDMI TX.
18 When referenced from platform device tree bindings the properties defined in
[all …]
|
| /Documentation/arch/arm/ |
| D | microchip.rst | 7 ------------
11 It is important to note that the Microchip (previously Atmel) ARM-based MPU
15 git branches/tags and email subject always contain this "at91" sub-string.
19 ---------
25 - at91rm9200
29 …http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-1768-32-bit-ARM920T-Embedded-Microprocessor-…
32 - at91sam9260
36 …ttp://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6221-32-bit-ARM926EJ-S-Embedded-Microprocesso…
38 - at91sam9xe
42 …ttp://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6254-32-bit-ARM926EJ-S-Embedded-Microprocesso…
[all …]
|
| /Documentation/dev-tools/kunit/api/ |
| D | of.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 Device Tree (OF) API
7 The KUnit device tree API is used to test device tree (of_*) dependent code.
9 .. kernel-doc:: include/kunit/of.h
12 .. kernel-doc:: drivers/of/of_kunit_helpers.c
|
| /Documentation/devicetree/bindings/ata/ |
| D | sata-common.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/ata/sata-common.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Linus Walleij <linus.walleij@linaro.org>
13 This document defines device tree properties common to most Serial
14 AT attachment (SATA) storage devices. It doesn't constitute a device tree
15 binding specification by itself but is meant to be referenced by device
16 tree bindings.
18 The SATA controller-specific device tree bindings are responsible for
[all …]
|
| D | pata-common.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/ata/pata-common.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Linus Walleij <linus.walleij@linaro.org>
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
28 "#address-cells":
[all …]
|
| /Documentation/devicetree/bindings/display/ |
| D | dsi-controller.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/display/dsi-controller.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Linus Walleij <linus.walleij@linaro.org>
13 This document defines device tree properties common to DSI, Display
15 a device tree binding specification by itself but is meant to be referenced
16 by device tree bindings.
18 When referenced from panel device tree bindings the properties defined in
19 this document are defined as follows. The panel device tree bindings are
[all …]
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | pinctrl-bindings.txt | 4 such as pull-up/down, tri-state, drive-strength etc are designated as pin
5 controllers. Each pin controller must be represented as a node in device tree,
9 designated client devices. Again, each client device must be represented as a
10 node in device tree, just like any other hardware module.
12 For a client device to operate correctly, certain pin controllers must
15 need to reconfigure pins at run-time, for example to tri-state pins when the
16 device is inactive. Hence, each client device can define a set of named
17 states. The number and names of those states is defined by the client device's
21 for client device device tree nodes to map those state names to the pin
27 in a single place, rather than splitting it across multiple client device
[all …]
|
| /Documentation/devicetree/bindings/display/panel/ |
| D | panel-common.yaml | 1 # SPDX-License-Identifier: GPL-2.0
3 ---
4 $id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Thierry Reding <thierry.reding@gmail.com>
11 - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
14 This document defines device tree properties common to several classes of
15 display panels. It doesn't constitute a device tree binding specification by
16 itself but is meant to be referenced by device tree bindings.
18 When referenced from panel device tree bindings the properties defined in this
[all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | verity.rst | 2 dm-verity
5 Device-Mapper's "verity" target provides transparent integrity checking of
7 This target is read-only.
21 This is the type of the on-disk hash format.
32 This is the device containing data, the integrity of which needs to be
33 checked. It may be specified as a path, like /dev/sdaX, or a device number,
37 This is the device that supplies the hash tree data. It may be
38 specified similarly to the device path and may be the same device. If the
39 same device is used, the hash_start should be outside the configured
40 dm-verity device.
[all …]
|
| /Documentation/power/powercap/ |
| D | dtpm.rst | 1 .. SPDX-License-Identifier: GPL-2.0
23 the device power by limiting and/or balancing a power budget among
27 device power.
34 driver to do the connection with the power manageable device.
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.
48 `-- pkg
50 |-- pd0 (cpu0-3)
52 `-- pd1 (cpu4-5)
[all …]
|
| /Documentation/iio/ |
| D | ad4695.rst | 1 .. SPDX-License-Identifier: GPL-2.0-only
26 ----------------
30 4-wire mode
35 .. code-block::
37 +-------------+ +-------------+
38 | CS |<-+------| CS |
39 | CNV |<-+ | |
42 | SDI |<--------| SDO |
43 | SDO |-------->| SDI |
44 | SCLK |<--------| SCLK |
[all …]
|
| /Documentation/admin-guide/ |
| D | efi-stub.rst | 8 along with the EFI-specific entry point that the firmware loader
10 arch/x86/boot/header.S and drivers/firmware/efi/libstub/x86-stub.c,
12 arch/arm/boot/compressed/efi-header.S and
13 drivers/firmware/efi/libstub/arm32-stub.c. EFI stub code that is shared
19 and drivers/firmware/efi/libstub/arm64-stub.c.
30 --------------------------
43 --------------------------------------------
51 --------------------
55 stub-specific command line parameter, everything else is passed to the
60 is an EFI-style path and directory elements must be separated with
[all …]
|
| /Documentation/devicetree/bindings/fsi/ |
| D | fsi.txt | 1 FSI bus & engine generic device tree bindings
4 The FSI bus is probe-able, so the OS is able to enumerate FSI slaves, and
6 nodes to probed engines. This allows for fsi engines to expose non-probeable
7 busses, which are then exposed by the device tree. For example, an FSI engine
8 that is an I2C master - the I2C bus can be described by the device tree under
9 the engine's device tree node.
13 the fsi-master-* binding specifications.
18 fsi-master {
19 /* top-level of FSI bus topology, bound to an FSI master driver and
22 fsi-slave@<link,id> {
[all …]
|
| /Documentation/devicetree/bindings/memory-controllers/ |
| D | ti-aemif.txt | 1 * Device tree bindings for Texas instruments AEMIF controller
4 provide a glue-less interface to a variety of asynchronous memory devices like
11 Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
12 OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
13 Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
17 - compatible: "ti,davinci-aemif"
18 "ti,keystone-aemif"
19 "ti,da850-aemif"
21 - reg: contains offset/length value for AEMIF control registers
24 - #address-cells: Must be 2. The partition number has to be encoded in the
[all …]
|
12345678910>>...30