diff options
Diffstat (limited to 'Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt')
| -rw-r--r-- | Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 192 |
1 files changed, 2 insertions, 190 deletions
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index fcd37e93ed4d..4613bb17ace3 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -141,196 +141,8 @@ controller device. == Generic pin multiplexing node content == -pin multiplexing nodes: - -function - the mux function to select -groups - the list of groups to select with this function - (either this or "pins" must be specified) -pins - the list of pins to select with this function (either - this or "groups" must be specified) - -Example: - -state_0_node_a { - uart0 { - function = "uart0"; - groups = "u0rxtx", "u0rtscts"; - }; -}; -state_1_node_a { - spi0 { - function = "spi0"; - groups = "spi0pins"; - }; -}; -state_2_node_a { - function = "i2c0"; - 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. +See pinmux-node.yaml == Generic pin configuration node content == -Many data items that are represented in a pin configuration node are common -and generic. Pin control bindings should use the properties defined below -where they are applicable; not all of these properties are relevant or useful -for all hardware or binding structures. Each individual binding document -should state which of these generic properties, if any, are used, and the -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, "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, "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 -bias-pull-up - pull up the pin -bias-pull-down - pull down the pin -bias-pull-pin-default - use pin-default pull state -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 -drive-strength-microamp - sink or source at most X uA -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 -sleep-hardware-state - indicate this is sleep related state which will be programmed - into the registers for the sleep state. -slew-rate - set the slew rate -skew-delay - this affects the expected clock skew on input pins - and the delay before latching a value to an output - pin. Typically indicates how many double-inverters are - used to delay the signal. - -For example: - -state_0_node_a { - cts_rxd { - pins = "GPIO0_AJ5", "GPIO2_AH4"; /* CTS+RXD */ - bias-pull-up; - }; -}; -state_1_node_a { - rts_txd { - pins = "GPIO1_AJ3", "GPIO3_AH3"; /* RTS+TXD */ - output-high; - }; -}; -state_2_node_a { - foo { - group = "foo-group"; - 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. - -- pins takes a list of pin names or IDs as a required argument. The specific - 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. - -- drive-strength takes as argument the target strength in mA. - -- drive-strength-microamp takes as argument the target strength in uA. - -- input-debounce takes the debounce time in usec as argument - or 0 to disable debouncing - -More in-depth documentation on these parameters can be found in -<include/linux/pinctrl/pinconf-generic.h> +See pincfg-node.yaml |