diff options
Diffstat (limited to 'Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt')
| -rw-r--r-- | Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 97 |
1 files changed, 91 insertions, 6 deletions
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index b73c96d24f59..62d0f33fa65e 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -97,6 +97,11 @@ For example: }; == Pin controller devices == +Required properties: See the pin controller driver specific documentation + +Optional properties: +#pinctrl-cells: Number of pin control cells in addition to the index within the + pin controller device instance Pin controller devices should contain the pin configuration nodes that client devices reference. @@ -119,7 +124,8 @@ For example: The contents of each of those pin configuration child nodes is defined entirely by the binding for the individual pin controller device. There -exists no common standard for this content. +exists no common standard for this content. The pinctrl framework only +provides generic helper bindings that the pin controller driver can use. The pin configuration nodes need not be direct children of the pin controller device; they may be grandchildren, for example. Whether this is legal, and @@ -156,6 +162,65 @@ state_2_node_a { pins = "mfio29", "mfio30"; }; +Optionally an alternative binding can be used if more suitable depending on the +pin controller hardware. For hardware where there is a large number of identical +pin controller instances, naming each pin and function can easily become +unmaintainable. This is especially the case if the same controller is used for +different pins and functions depending on the SoC revision and packaging. + +For cases like this, the pin controller driver may use pinctrl-pin-array helper +binding with a hardware based index and a number of pin configuration values: + +pincontroller { + ... /* Standard DT properties for the device itself elided */ + #pinctrl-cells = <2>; + + state_0_node_a { + pinctrl-pin-array = < + 0 A_DELAY_PS(0) G_DELAY_PS(120) + 4 A_DELAY_PS(0) G_DELAY_PS(360) + ... + >; + }; + ... +}; + +Above #pinctrl-cells specifies the number of value cells in addition to the +index of the registers. This is similar to the interrupts-extended binding with +one exception. There is no need to specify the phandle for each entry as that +is already known as the defined pins are always children of the pin controller +node. Further having the phandle pointing to another pin controller would not +currently work as the pinctrl framework uses named modes to group pins for each +pin control device. + +The index for pinctrl-pin-array must relate to the hardware for the pinctrl +registers, and must not be a virtual index of pin instances. The reason for +this is to avoid mapping of the index in the dts files and the pin controller +driver as it can change. + +For hardware where pin multiplexing configurations have to be specified for +each single pin the number of required sub-nodes containing "pin" and +"function" properties can quickly escalate and become hard to write and +maintain. + +For cases like this, the pin controller driver may use the pinmux helper +property, where the pin identifier is provided with mux configuration settings +in a pinmux group. A pinmux group consists of the pin identifier and mux +settings represented as a single integer or an array of integers. + +The pinmux property accepts an array of pinmux groups, each of them describing +a single pin multiplexing configuration. + +pincontroller { + state_0_node_a { + pinmux = <PINMUX_GROUP>, <PINMUX_GROUP>, ...; + }; +}; + +Each individual pin controller driver bindings documentation shall specify +how pin IDs and pin multiplexing configuration are defined and assembled +together in a pinmux group. + == Generic pin configuration node content == Many data items that are represented in a pin configuration node are common @@ -168,12 +233,15 @@ structure of the DT nodes that contain these properties. Supported generic properties are: pins - the list of pins that properties in the node - apply to (either this or "group" has to be + apply to (either this, "group" or "pinmux" has to be specified) group - the group to apply the properties to, if the driver supports configuration of whole groups rather than - individual pins (either this or "pins" has to be - specified) + individual pins (either this, "pins" or "pinmux" has + to be specified) +pinmux - the list of numeric pin ids and their mux settings + that properties in the node apply to (either this, + "pins" or "groups" have to be specified) bias-disable - disable any pin bias bias-high-impedance - high impedance mode ("third-state", "floating") bias-bus-hold - latch weakly @@ -184,14 +252,20 @@ drive-push-pull - drive actively high and low drive-open-drain - drive with open drain drive-open-source - drive with open source drive-strength - sink or source at most X mA -input-enable - enable input on pin (no effect on output) -input-disable - disable input on pin (no effect on output) +input-enable - enable input on pin (no effect on output, such as + enabling an input buffer) +input-disable - disable input on pin (no effect on output, such as + disabling an input buffer) input-schmitt-enable - enable schmitt-trigger mode input-schmitt-disable - disable schmitt-trigger mode input-debounce - debounce mode with debound time X power-source - select between different power supplies low-power-enable - enable low power mode low-power-disable - disable low power mode +output-disable - disable output on a pin (such as disable an output + buffer) +output-enable - enable output on a pin without actively driving it + (such as enabling an output buffer) output-low - set the pin to output mode with low level output-high - set the pin to output mode with high level slew-rate - set the slew rate @@ -216,6 +290,12 @@ state_2_node_a { bias-pull-up; }; }; +state_3_node_a { + mux { + pinmux = <GPIOx_PINm_MUXn>, <GPIOx_PINj_MUXk)>; + input-enable; + }; +}; Some of the generic properties take arguments. For those that do, the arguments are described below. @@ -224,6 +304,11 @@ arguments are described below. binding for the hardware defines: - Whether the entries are integers or strings, and their meaning. +- pinmux takes a list of pin IDs and mux settings as required argument. The + specific bindings for the hardware defines: + - How pin IDs and mux settings are defined and assembled together in a single + integer or an array of integers. + - bias-pull-up, -down and -pin-default take as optional argument on hardware supporting it the pull strength in Ohm. bias-disable will disable the pull. |