115 lines
3.6 KiB
Plaintext
115 lines
3.6 KiB
Plaintext
Specifying GPIO information for devices
|
|
============================================
|
|
|
|
1) gpios property
|
|
-----------------
|
|
|
|
Nodes that makes use of GPIOs should specify them using one or more
|
|
properties, each containing a 'gpio-list':
|
|
|
|
gpio-list ::= <single-gpio> [gpio-list]
|
|
single-gpio ::= <gpio-phandle> <gpio-specifier>
|
|
gpio-phandle : phandle to gpio controller node
|
|
gpio-specifier : Array of #gpio-cells specifying specific gpio
|
|
(controller specific)
|
|
|
|
GPIO properties should be named "[<name>-]gpios". Exact
|
|
meaning of each gpios property must be documented in the device tree
|
|
binding for each device.
|
|
|
|
For example, the following could be used to describe gpios pins to use
|
|
as chip select lines; with chip selects 0, 1 and 3 populated, and chip
|
|
select 2 left empty:
|
|
|
|
gpio1: gpio1 {
|
|
gpio-controller
|
|
#gpio-cells = <2>;
|
|
};
|
|
gpio2: gpio2 {
|
|
gpio-controller
|
|
#gpio-cells = <1>;
|
|
};
|
|
[...]
|
|
chipsel-gpios = <&gpio1 12 0>,
|
|
<&gpio1 13 0>,
|
|
<0>, /* holes are permitted, means no GPIO 2 */
|
|
<&gpio2 2>;
|
|
|
|
Note that gpio-specifier length is controller dependent. In the
|
|
above example, &gpio1 uses 2 cells to specify a gpio, while &gpio2
|
|
only uses one.
|
|
|
|
gpio-specifier may encode: bank, pin position inside the bank,
|
|
whether pin is open-drain and whether pin is logically inverted.
|
|
Exact meaning of each specifier cell is controller specific, and must
|
|
be documented in the device tree binding for the device.
|
|
|
|
Example of the node using GPIOs:
|
|
|
|
node {
|
|
gpios = <&qe_pio_e 18 0>;
|
|
};
|
|
|
|
In this example gpio-specifier is "18 0" and encodes GPIO pin number,
|
|
and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
|
|
|
|
2) gpio-controller nodes
|
|
------------------------
|
|
|
|
Every GPIO controller node must both an empty "gpio-controller"
|
|
property, and have #gpio-cells contain the size of the gpio-specifier.
|
|
|
|
Example of two SOC GPIO banks defined as gpio-controller nodes:
|
|
|
|
qe_pio_a: gpio-controller@1400 {
|
|
#gpio-cells = <2>;
|
|
compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
|
|
reg = <0x1400 0x18>;
|
|
gpio-controller;
|
|
};
|
|
|
|
qe_pio_e: gpio-controller@1460 {
|
|
#gpio-cells = <2>;
|
|
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
|
|
reg = <0x1460 0x18>;
|
|
gpio-controller;
|
|
};
|
|
|
|
2.1) gpio-controller and pinctrl subsystem
|
|
------------------------------------------
|
|
|
|
gpio-controller on a SOC might be tightly coupled with the pinctrl
|
|
subsystem, in the sense that the pins can be used by other functions
|
|
together with optional gpio feature.
|
|
|
|
While the pin allocation is totally managed by the pin ctrl subsystem,
|
|
gpio (under gpiolib) is still maintained by gpio drivers. It may happen
|
|
that different pin ranges in a SoC is managed by different gpio drivers.
|
|
|
|
This makes it logical to let gpio drivers announce their pin ranges to
|
|
the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
|
|
request the corresponding pin before any gpio usage.
|
|
|
|
For this, the gpio controller can use a pinctrl phandle and pins to
|
|
announce the pinrange to the pin ctrl subsystem. For example,
|
|
|
|
qe_pio_e: gpio-controller@1460 {
|
|
#gpio-cells = <2>;
|
|
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
|
|
reg = <0x1460 0x18>;
|
|
gpio-controller;
|
|
gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
|
|
|
|
}
|
|
|
|
where,
|
|
&pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node.
|
|
|
|
Next values specify the base pin and number of pins for the range
|
|
handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
|
|
pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
|
|
by this gpio controller.
|
|
|
|
The pinctrl node must have "#gpio-range-cells" property to show number of
|
|
arguments to pass with phandle from gpio controllers node.
|