xref: /openbmc/linux/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt (revision 03ab8e6297acd1bc0eedaa050e2a1635c576fd11)
17a865277SStephen Warren== Introduction ==
27a865277SStephen Warren
37a865277SStephen WarrenHardware modules that control pin multiplexing or configuration parameters
47a865277SStephen Warrensuch as pull-up/down, tri-state, drive-strength etc are designated as pin
57a865277SStephen Warrencontrollers. Each pin controller must be represented as a node in device tree,
67a865277SStephen Warrenjust like any other hardware module.
77a865277SStephen Warren
87a865277SStephen WarrenHardware modules whose signals are affected by pin configuration are
97a865277SStephen Warrendesignated client devices. Again, each client device must be represented as a
107a865277SStephen Warrennode in device tree, just like any other hardware module.
117a865277SStephen Warren
127a865277SStephen WarrenFor a client device to operate correctly, certain pin controllers must
137a865277SStephen Warrenset up certain specific pin configurations. Some client devices need a
147a865277SStephen Warrensingle static pin configuration, e.g. set up during initialization. Others
157a865277SStephen Warrenneed to reconfigure pins at run-time, for example to tri-state pins when the
167a865277SStephen Warrendevice is inactive. Hence, each client device can define a set of named
177a865277SStephen Warrenstates. The number and names of those states is defined by the client device's
187a865277SStephen Warrenown binding.
197a865277SStephen Warren
207a865277SStephen WarrenThe common pinctrl bindings defined in this file provide an infrastructure
217a865277SStephen Warrenfor client device device tree nodes to map those state names to the pin
227a865277SStephen Warrenconfiguration used by those states.
237a865277SStephen Warren
247a865277SStephen WarrenNote that pin controllers themselves may also be client devices of themselves.
257a865277SStephen WarrenFor example, a pin controller may set up its own "active" state when the
267a865277SStephen Warrendriver loads. This would allow representing a board's static pin configuration
277a865277SStephen Warrenin a single place, rather than splitting it across multiple client device
287a865277SStephen Warrennodes. The decision to do this or not somewhat rests with the author of
297a865277SStephen Warrenindividual board device tree files, and any requirements imposed by the
307a865277SStephen Warrenbindings for the individual client devices in use by that board, i.e. whether
317a865277SStephen Warrenthey require certain specific named states for dynamic pin configuration.
327a865277SStephen Warren
337a865277SStephen Warren== Pinctrl client devices ==
347a865277SStephen Warren
357a865277SStephen WarrenFor each client device individually, every pin state is assigned an integer
367a865277SStephen WarrenID. These numbers start at 0, and are contiguous. For each state ID, a unique
377a865277SStephen Warrenproperty exists to define the pin configuration. Each state may also be
387a865277SStephen Warrenassigned a name. When names are used, another property exists to map from
397a865277SStephen Warrenthose names to the integer IDs.
407a865277SStephen Warren
41f5efed80SBaruch SiachEach client device's own binding determines the set of states that must be
427a865277SStephen Warrendefined in its device tree node, and whether to define the set of state
437a865277SStephen WarrenIDs that must be provided, or whether to define the set of state names that
447a865277SStephen Warrenmust be provided.
457a865277SStephen Warren
467a865277SStephen WarrenRequired properties:
477a865277SStephen Warrenpinctrl-0:	List of phandles, each pointing at a pin configuration
487a865277SStephen Warren		node. These referenced pin configuration nodes must be child
497a865277SStephen Warren		nodes of the pin controller that they configure. Multiple
507a865277SStephen Warren		entries may exist in this list so that multiple pin
517a865277SStephen Warren		controllers may be configured, or so that a state may be built
527a865277SStephen Warren		from multiple nodes for a single pin controller, each
537a865277SStephen Warren		contributing part of the overall configuration. See the next
547a865277SStephen Warren		section of this document for details of the format of these
557a865277SStephen Warren		pin configuration nodes.
567a865277SStephen Warren
577a865277SStephen Warren		In some cases, it may be useful to define a state, but for it
587a865277SStephen Warren		to be empty. This may be required when a common IP block is
597a865277SStephen Warren		used in an SoC either without a pin controller, or where the
607a865277SStephen Warren		pin controller does not affect the HW module in question. If
617a865277SStephen Warren		the binding for that IP block requires certain pin states to
627a865277SStephen Warren		exist, they must still be defined, but may be left empty.
637a865277SStephen Warren
647a865277SStephen WarrenOptional properties:
657a865277SStephen Warrenpinctrl-1:	List of phandles, each pointing at a pin configuration
667a865277SStephen Warren		node within a pin controller.
677a865277SStephen Warren...
687a865277SStephen Warrenpinctrl-n:	List of phandles, each pointing at a pin configuration
697a865277SStephen Warren		node within a pin controller.
707a865277SStephen Warrenpinctrl-names:	The list of names to assign states. List entry 0 defines the
717a865277SStephen Warren		name for integer state ID 0, list entry 1 for state ID 1, and
727a865277SStephen Warren		so on.
737a865277SStephen Warren
747a865277SStephen WarrenFor example:
757a865277SStephen Warren
767a865277SStephen Warren	/* For a client device requiring named states */
777a865277SStephen Warren	device {
787a865277SStephen Warren		pinctrl-names = "active", "idle";
797a865277SStephen Warren		pinctrl-0 = <&state_0_node_a>;
8074f2dd44SGeert Uytterhoeven		pinctrl-1 = <&state_1_node_a>, <&state_1_node_b>;
817a865277SStephen Warren	};
827a865277SStephen Warren
837a865277SStephen Warren	/* For the same device if using state IDs */
847a865277SStephen Warren	device {
857a865277SStephen Warren		pinctrl-0 = <&state_0_node_a>;
8674f2dd44SGeert Uytterhoeven		pinctrl-1 = <&state_1_node_a>, <&state_1_node_b>;
877a865277SStephen Warren	};
887a865277SStephen Warren
897a865277SStephen Warren	/*
907a865277SStephen Warren	 * For an IP block whose binding supports pin configuration,
917a865277SStephen Warren	 * but in use on an SoC that doesn't have any pin control hardware
927a865277SStephen Warren	 */
937a865277SStephen Warren	device {
947a865277SStephen Warren		pinctrl-names = "active", "idle";
957a865277SStephen Warren		pinctrl-0 = <>;
967a865277SStephen Warren		pinctrl-1 = <>;
977a865277SStephen Warren	};
987a865277SStephen Warren
997a865277SStephen Warren== Pin controller devices ==
10042124bc5STony Lindgren
101*896568e5SRafał MiłeckiSee pinctrl.yaml
1027db9af4bSHeiko Stübner
10390d09938SLinus Walleij== Generic pin multiplexing node content ==
10490d09938SLinus Walleij
1053af50e54SRob HerringSee pinmux-node.yaml
1068d5e7c5dSJacopo Mondi
107bcd0c8c2SStephen Warren== Generic pin configuration node content ==
1087db9af4bSHeiko Stübner
1093af50e54SRob HerringSee pincfg-node.yaml
110