| /openbmc/linux/Documentation/translations/zh_CN/devicetree/ |
| H A D | usage-model.rst | 30 从结构上看，DT是一棵树，或者说是带有命名节点的无环图，节点可以有任意数量的命名
56 我们创建了一个叫做扁平化设备树（FDT）的DT表示法，它可以作为一个二进制的blob
60 支持引导现有的非DT察觉的固件。
64 有某种程度的DT支持。
72 最重要的是要明白，DT只是一个描述硬件的数据结构。它没有什么神奇之处，也不会神
81 Linux使用DT数据有三个主要目的:
89 首先，内核将使用DT中的数据来识别特定的机器。在一个理想的世界里，具体的平台对
146 在大多数情况下，DT是将数据从固件传递给内核的唯一方法，所以也被用来传递运行
177 了ARM实现的例子，但所有架构在使用DT时都会做几乎相同的事情。
181 行为。如果提供了DT，那么.init_early()和.init_irq()都能调用任何一个DT查
[all …]
|
| H A D | overlay-notes.rst | 89 如果基础DT不是用-@选项编译的，那么“&ocp”标签将不能用于将覆盖节点解析到基础
90 DT中的适当位置。在这种情况下，可以提供目标路径。通过标签的目标位置的语法是比
91 较好的，因为不管标签在DT中出现在哪里，覆盖都可以被应用到任何包含标签的基础DT上。
|
| /openbmc/linux/crypto/ |
| H A D | ansi_cprng.c | 43 unsigned char DT[DEFAULT_BLK_SZ]; member
91 hexdump("Input DT: ", ctx->DT, DEFAULT_BLK_SZ); in _get_more_prng_bytes()
106 memcpy(tmp, ctx->DT, DEFAULT_BLK_SZ); in _get_more_prng_bytes()
164 ctx->DT[i] += 1; in _get_more_prng_bytes()
165 if (ctx->DT[i] != 0) in _get_more_prng_bytes()
172 hexdump("Output DT: ", ctx->DT, DEFAULT_BLK_SZ); in _get_more_prng_bytes()
278 const unsigned char *V, const unsigned char *DT) in reset_prng_context() argument
296 if (DT) in reset_prng_context()
297 memcpy(ctx->DT, DT, DEFAULT_BLK_SZ); in reset_prng_context()
299 memset(ctx->DT, 0, DEFAULT_BLK_SZ); in reset_prng_context()
|
| /openbmc/openbmc/meta-hpe/meta-dl360poc/recipes-kernel/linux/ |
| H A D | linux-obmc_%.bbappend | 7 DT=`basename ${DTB} .dtb`
8 if [ -r "${WORKDIR}/${DT}.dts" ]; then
9 cp ${WORKDIR}/${DT}.dts \
|
| /openbmc/linux/Documentation/devicetree/bindings/ |
| H A D | submitting-patches.rst | 4 Submitting Devicetree (DT) binding patches
22 2) DT binding files are written in DT schema format using json-schema
23 vocabulary and YAML file format. The DT binding files must pass validation
31 3) DT binding files should be dual licensed. The preferred license tag is
38 and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify
39 all of the DT maintainers.
45 previously documented in the corresponding DT binding text file
50 ("checkpatch: add DT compatible string documentation checks"). ]
|
| H A D | writing-schema.rst | 22 URI typically containing the binding's filename and path. For DT schema, it must
37 A DT specific property. Contains a list of email address(es)
57 A set of sub-schema defining all the DT properties for the
62 A property can also define a child DT node with child properties defined
71 A list of DT properties from the 'properties' section that
83 The 'properties' section of the schema contains all the DT properties for a
86 validation of DT files.
123 The DT schema project must be installed in order to validate the DT schema
124 binding documents and validate DTS files using the DT schema. The DT schema
142 The DT schema binding documents must be validated using the meta-schema (the
[all …]
|
| /openbmc/linux/Documentation/translations/zh_CN/power/ |
| H A D | energy-model.rst | 95 提供的回调函数可以自由地从任何相关位置（DT、固件......）以及以任何被认为是
106 使用DT的EM注册
109 EM也可以使用OPP框架和DT "操作点-v2 "中的信息注册。DT中的每个OPP条目都可
110 以用一个包含微瓦特功率值的属性 "op-microwatt "来扩展。这个OPP DT属性允
|
| /openbmc/openbmc/meta-ibm/meta-fsp2/recipes-kernel/linux/ |
| H A D | linux-fsp2.inc | 20 DT=`basename ${DTB} .dtb`
21 if [ -r "${WORKDIR}/${DT}.dts" ]; then
22 cp ${WORKDIR}/${DT}.dts \
|
| /openbmc/openbmc/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot/corstone1000/ |
| H A D | 0035-corstone1000-purge-U-Boot-specific-DT-nodes.patch | 4 Subject: [PATCH] corstone1000: purge U-Boot specific DT nodes
6 Remove U-Boot specific DT nodes before passing the DT to Linux
32 +/* remove the DT nodes not needed in Linux */
|
| /openbmc/linux/drivers/staging/board/ |
| H A D | TODO | 1 * replace platform device code with DT nodes once the driver supports DT
|
| /openbmc/linux/Documentation/devicetree/bindings/sifive/ |
| H A D | sifive-blocks-ip-versioning.txt | 1 DT compatible string versioning for SiFive open-source IP blocks
3 This document describes the version specification for DT "compatible"
9 IP block-specific DT compatible strings are contained within the HDL,
28 DT data authors, when writing data for a particular SoC, should
|
| /openbmc/linux/Documentation/devicetree/ |
| H A D | usage-model.rst | 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
45 The DT was originally created by Open Firmware as part of the
63 Device Tree Binary (dtb) and to modify a dtb at boot time. DT was
66 existing non-DT aware firmware.
71 out of mainline (nios) have some level of DT support.
94 Linux uses DT data for three major purposes:
230 thing when using a DT.
234 and .init_irq() is used to set up interrupt handling. Using a DT
247 devices can be obtained by parsing the DT, and allocating device
[all …]
|
| /openbmc/u-boot/dts/ |
| H A D | Kconfig | 70 prompt "Provider of DTB for DT control"
74 bool "Separate DTB for DT control"
81 bool "Embedded DTB for DT control"
97 bool "Host filed DTB for DT control"
105 bool "Prior stage bootloader DTB for DT control"
107 If this option is enabled, the device tree used for DT
114 string "Default Device Tree for DT control"
122 string "List of device tree files to include for DT control"
126 This option specifies a list of device tree files to use for DT
128 or SPL will select the correct DT to use by examining the
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/pci/ |
| H A D | ti-pci.txt | 36 - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument
54 - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument
63 NOTE: Two DT nodes may be added for each PCI controller; one for host
65 work in host mode, EP mode DT node should be disabled and in order to PCI to
66 work in EP mode, host mode DT node should be disabled. Host mode and EP
|
| /openbmc/linux/Documentation/arch/arm64/ |
| H A D | arm-acpi.rst | 41 while DT explicitly does not support this. For hardware vendors, being
50 as for RAS) which are currently used in production systems. DT does not.
85 the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
113 exclusive with DT support at compile time.
129 When an Arm system boots, it can either have DT information, ACPI tables,
131 the kernel will try to use DT for device enumeration; if there is no DT
288 Clocks provide an excellent example. In DT, clocks need to be specified
308 names ("KEY0") to four characters unlike DT; (2) there is no industry
364 whether DT or ACPI is being used. This API should be used [5]; it can
366 discourage divergence between DT bindings and ACPI device properties.
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/timer/ |
| H A D | sifive,clint.yaml | 19 The clock frequency of CLINT is specified via "timebase-frequency" DT
20 property of "/cpus" DT node. The "timebase-frequency" DT property is
|
| H A D | riscv,timer.yaml | 19 "timebase-frequency" DT property of "/cpus" DT node which is described
|
| /openbmc/u-boot/doc/ |
| H A D | README.nios2 | 61 (mysystem) Default Device Tree for DT control
63 There is a selection of "Provider of DTB for DT control" in the Device
66 ( ) Separate DTB for DT control, will cat the dtb to end of u-boot
71 ( ) Embedded DTB for DT control, will include the dtb inside the u-boot
|
| /openbmc/linux/sound/soc/generic/ |
| H A D | Kconfig | 18 with OF-graph DT bindings.
27 with OF-graph DT bindings.
|
| /openbmc/u-boot/doc/uImage.FIT/ |
| H A D | overlay-fdt-boot.txt | 7 of similar boards and their expansion options. The same kernel on DT enabled
8 platforms can support this easily enough by providing a DT blob upon boot
113 Device tree overlays can be applied to a base DT and result in the same blob
199 Note the minimum amount of different DT blobs, as well as the requirement for
200 the DT blobs to have a load address; the overlay application requires the blobs
|
| /openbmc/linux/Documentation/arch/mips/ |
| H A D | booting.rst | 11 Similar to the arch/arm case (b), a DT-aware bootloader is expected to
24 DT block. In this case, Linux will look for a builtin DTB, selected via
|
| /openbmc/linux/drivers/comedi/drivers/ |
| H A D | dt3000.c | 718 { PCI_VDEVICE(DT, 0x0022), BOARD_DT3001 },
719 { PCI_VDEVICE(DT, 0x0023), BOARD_DT3002 },
720 { PCI_VDEVICE(DT, 0x0024), BOARD_DT3003 },
721 { PCI_VDEVICE(DT, 0x0025), BOARD_DT3004 },
722 { PCI_VDEVICE(DT, 0x0026), BOARD_DT3005 },
723 { PCI_VDEVICE(DT, 0x0027), BOARD_DT3001_PGL },
724 { PCI_VDEVICE(DT, 0x0028), BOARD_DT3003_PGL },
|
| /openbmc/linux/Documentation/devicetree/bindings/media/xilinx/ |
| H A D | xlnx,video.txt | 9 and IP core specific documentation, xlnx,v-*.txt, in this directory. The DT
22 - ports: Video port, using the DT bindings defined in ../video-interfaces.txt.
|
| /openbmc/linux/Documentation/devicetree/bindings/thermal/ |
| H A D | max77620_thermal.txt | 15 For more details, please refer generic thermal DT binding document
18 Please refer <devicetree/bindings/mfd/max77620.txt> for mfd DT binding
|
| /openbmc/linux/Documentation/devicetree/bindings/cpufreq/ |
| H A D | cpufreq-dt.txt | 3 It is a generic DT based cpufreq driver for frequency management. It supports
15 details. OPPs *must* be supplied either via DT, i.e. this property, or
|