Lines Matching +full:client +full:- +full:id
4 such as pull-up/down, tri-state, drive-strength etc are designated as pin
9 designated client devices. Again, each client device must be represented as a
12 For a client device to operate correctly, certain pin controllers must
13 set up certain specific pin configurations. Some client devices need a
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
24 Note that pin controllers themselves may also be client devices of themselves.
27 in a single place, rather than splitting it across multiple client device
30 bindings for the individual client devices in use by that board, i.e. whether
33 == Pinctrl client devices ==
35 For each client device individually, every pin state is assigned an integer
36 ID. These numbers start at 0, and are contiguous. For each state ID, a unique
41 Each client device's own binding determines the set of states that must be
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
71 name for integer state ID 0, list entry 1 for state ID 1, and
76 /* For a client device requiring named states */
78 pinctrl-names = "active", "idle";
79 pinctrl-0 = <&state_0_node_a>;
80 pinctrl-1 = <&state_1_node_a>, <&state_1_node_b>;
85 pinctrl-0 = <&state_0_node_a>;
86 pinctrl-1 = <&state_1_node_a>, <&state_1_node_b>;
94 pinctrl-names = "active", "idle";
95 pinctrl-0 = <>;
96 pinctrl-1 = <>;
105 See pinmux-node.yaml
109 See pincfg-node.yaml