| Main index | Section 4 | Options |
On a device.hints(5) based system, like MIPS, these values are configurable for gpioled:
| hint.gpioled.%d.at | |
| The gpiobus you are attaching to. Normally assigned to gpiobus0. | |
| hint.gpioled.%d.name | |
| Arbitrary name of device in /dev/led/ to create for led(4). | |
| hint.gpioled.%d.pins | |
| Which pin on the GPIO interface to map to this instance. Please note that this mask should only ever have one bit set (any other bits - i.e., pins - will be ignored). | |
| hint.gpioled.%d.invert | |
| If set to 1, the pin will be set to 0 to light the LED, and 1 to clear it. | |
| hint.gpioled.%d.state | |
| The initial state of the LED when the driver takes control over it. If set to 1 or 0, the LED will be on or off correspondingly. If set to -1, the LED will be kept in its original state. | |
On a FDT(4) based system, like ARM, the DTS part for a gpioled device usually looks like:
gpio: gpio {
gpio-controller;
...
led0 {
compatible = "gpioled";
gpios = <&gpio 16 2 0>; /* GPIO pin 16. */
name = "ok";
};
led1 {
compatible = "gpioled";
gpios = <&gpio 17 2 0>; /* GPIO pin 17. */
name = "user-led1";
};
};
Optionally, you can choose to combine all the LEDs under a single "gpio-leds" compatible node:
simplebus0 {
...
leds {
compatible = "gpio-leds";
led0 {
gpios = <&gpio 16 2 0>;
name = "ok"
};
led1 {
gpios = <&gpio 17 2 0>;
name = "user-led1"
};
};
};
Both methods are equally supported and it is possible to have the LEDs defined with any sort of mix between the methods. The only restriction is that a GPIO pin cannot be mapped by two different (gpio)leds.
For more details about the gpios property, please consult /usr/src/sys/dts/bindings-gpio.txt.
The property name is the arbitrary name of the device in /dev/led/ to create for led(4).
| GPIOLED (4) | May 23, 2019 |
| Main index | Section 4 | Options |
Please direct any comments about this manual page service to Ben Bullock. Privacy policy.
