Lines Matching +full:device +full:- +full:tree

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
29 individual board device tree files, and any requirements imposed by the
35 For each client device individually, every pin state is assigned an integer
41 Each client device's own binding determines the set of states that must be
42 defined in its device tree node, and whether to define the set of state
47 pinctrl-0: List of phandles, each pointing at a pin configuration
65 pinctrl-1: List of phandles, each pointing at a pin configuration
68 pinctrl-n: List of phandles, each pointing at a pin configuration
70 pinctrl-names: The list of names to assign states. List entry 0 defines the
76 /* For a client device requiring named states */
77 device {
78 pinctrl-names = "active", "idle";
79 pinctrl-0 = <&state_0_node_a>;
80 pinctrl-1 = <&state_1_node_a>, <&state_1_node_b>;
83 /* For the same device if using state IDs */
84 device {
85 pinctrl-0 = <&state_0_node_a>;
86 pinctrl-1 = <&state_1_node_a>, <&state_1_node_b>;
93 device {
94 pinctrl-names = "active", "idle";
95 pinctrl-0 = <>;
96 pinctrl-1 = <>;
105 See pinmux-node.yaml
109 See pincfg-node.yaml