summaryrefslogtreecommitdiffstats
path: root/Documentation/devicetree/bindings/gpio
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/devicetree/bindings/gpio')
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio.txt36
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio_atmel.txt5
-rw-r--r--Documentation/devicetree/bindings/gpio/led.txt58
3 files changed, 41 insertions, 58 deletions
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 4e16ba4..a336287 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -75,4 +75,40 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
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.
diff --git a/Documentation/devicetree/bindings/gpio/gpio_atmel.txt b/Documentation/devicetree/bindings/gpio/gpio_atmel.txt
index 66efc80..85f8c0d 100644
--- a/Documentation/devicetree/bindings/gpio/gpio_atmel.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio_atmel.txt
@@ -9,6 +9,10 @@ Required properties:
unused).
- gpio-controller: Marks the device node as a GPIO controller.
+optional properties:
+- #gpio-lines: Number of gpio if absent 32.
+
+
Example:
pioA: gpio@fffff200 {
compatible = "atmel,at91rm9200-gpio";
@@ -16,5 +20,6 @@ Example:
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
+ #gpio-lines = <19>;
};
diff --git a/Documentation/devicetree/bindings/gpio/led.txt b/Documentation/devicetree/bindings/gpio/led.txt
deleted file mode 100644
index edc83c1..0000000
--- a/Documentation/devicetree/bindings/gpio/led.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-LEDs connected to GPIO lines
-
-Required properties:
-- compatible : should be "gpio-leds".
-
-Each LED is represented as a sub-node of the gpio-leds device. Each
-node's name represents the name of the corresponding LED.
-
-LED sub-node properties:
-- gpios : Should specify the LED's GPIO, see "gpios property" in
- Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be
- indicated using flags in the GPIO specifier.
-- label : (optional) The label for this LED. If omitted, the label is
- taken from the node name (excluding the unit address).
-- linux,default-trigger : (optional) This parameter, if present, is a
- string defining the trigger assigned to the LED. Current triggers are:
- "backlight" - LED will act as a back-light, controlled by the framebuffer
- system
- "default-on" - LED will turn on, but see "default-state" below
- "heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
- "timer" - LED flashes at a fixed, configurable rate
-- default-state: (optional) The initial state of the LED. Valid
- values are "on", "off", and "keep". If the LED is already on or off
- and the default-state property is set the to same value, then no
- glitch should be produced where the LED momentarily turns off (or
- on). The "keep" setting will keep the LED at whatever its current
- state is, without producing a glitch. The default is off if this
- property is not present.
-
-Examples:
-
-leds {
- compatible = "gpio-leds";
- hdd {
- label = "IDE Activity";
- gpios = <&mcu_pio 0 1>; /* Active low */
- linux,default-trigger = "ide-disk";
- };
-
- fault {
- gpios = <&mcu_pio 1 0>;
- /* Keep LED on if BIOS detected hardware fault */
- default-state = "keep";
- };
-};
-
-run-control {
- compatible = "gpio-leds";
- red {
- gpios = <&mpc8572 6 0>;
- default-state = "off";
- };
- green {
- gpios = <&mpc8572 7 0>;
- default-state = "on";
- };
-};
OpenPOWER on IntegriCloud