== 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
git.samba.org / sfrench / cifs-2.6.git / blobdiff