bf0f6d911d
Several bindings have an expectation of sub-nodes that describe the actual infomation. The sub-nodes don't have any compatiable so we can't key on that. So we can add the concept of a sub-node to the YAML to handle cases like 'gpio-keys', 'gpio-leds', 'pwm-leds', etc.. The sub-node in the YAML is effective the "binding" params that describe what properties should exist in the sub-node. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
86 lines
2.7 KiB
Text
86 lines
2.7 KiB
Text
title: <short description of the node>
|
|
version: 0.1
|
|
|
|
description: >
|
|
Longer free-form description of the node, with spanning
|
|
lines
|
|
|
|
inherits:
|
|
- !include other.yaml # or [other1.yaml, other2.yaml]
|
|
# Files with other bindings that also apply to the node. If an attribute is set
|
|
# both in an included file and in the file that includes it, then the value
|
|
# from the including file (the file with the !include) is used.
|
|
|
|
< parent | child >:
|
|
# parent/child is used to document implicit relation between nodes.
|
|
# This information is required to generate parent related bits in child
|
|
# attributes.
|
|
# In case parent has 'bus', slave inherits some information from master.
|
|
# parent and child should share same bus-type value.
|
|
bus: <bus-type>
|
|
|
|
sub-node:
|
|
# Used for cases in which a dts node has children, and the children dont
|
|
# require/specify a 'compatible' property. The sub-node is effective the
|
|
# binding for the child.
|
|
#
|
|
# Here's an example for a pwm-leds binding in which the child nodes
|
|
# would be required to have 'pwms' properties.
|
|
|
|
sub-node:
|
|
properties:
|
|
pwms:
|
|
type: compound
|
|
category: required
|
|
generation: define
|
|
|
|
properties:
|
|
|
|
# A typical property entry looks like this:
|
|
#
|
|
# <name of the property in the device tree - regexes are supported>:
|
|
# category: <required | optional>
|
|
# type: <string | int | boolean | array | uint8-array | string-array | compound>
|
|
# description: <description of property>
|
|
# generation: define
|
|
#
|
|
# The 'generation' attribute can be set to 'define, use-prop-name' to use the
|
|
# property name instead of a generic controller name, e.g. *_CS_GPIO_* instead
|
|
# of *_GPIOS_*.
|
|
#
|
|
# The exact value of the 'generation' attribute is ignored otherwise. The
|
|
# output is always #define's.
|
|
#
|
|
# The 'type' attribute is currently ignored.
|
|
|
|
# At a minimum, an entry for the 'compatible' property is required, for
|
|
# matching nodes
|
|
compatible: <list of string compatible matches>
|
|
category: required
|
|
type: string
|
|
description: compatible of node
|
|
generation: define
|
|
|
|
# 'reg' describes mmio registers
|
|
reg:
|
|
category: required
|
|
type: array
|
|
description: mmio register space
|
|
generation: define
|
|
|
|
# 'interrupts' specifies the interrupts that the driver may use
|
|
interrupts:
|
|
category: required
|
|
type: array
|
|
description: required interrupts
|
|
generation: define
|
|
|
|
# If a node is an interrupt controller, GPIO controller, pinmux device, or any
|
|
# device referenced via a phandle plus some number of cells, then the cell
|
|
# fields below must be present
|
|
|
|
"#cells":
|
|
- cell0 # name of first cell
|
|
- cell1 # name of second cell
|
|
- cell2 # name of third cell
|
|
- and so on and so forth
|