Open mfallavol opened 2 years ago
@mfallavol so gpio never got it's own standard driver.. thus, we all abuse "gpio-leds"...
best of all you can set a startup state or trigger..
Regards,
Thanks @RobertCNelson I wondered about that. So gpio-leds for outputs, I assume then gpio-keys for inputs?
exactly!
Thanks again @RobertCNelson. M fragment now looks like this:
fragment@10 {
target = <&ocp>;
__overlay__ {
leds {
compatible = "gpio-leds";
P8_24 {
gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
P9_15 {
gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
P9_23 {
gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
P9_25 {
gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
};
gpio-keys {
compatible = "gpio-keys";
P9_16 {
label = "EP_nINTR";
gpios = <&gpio1 19 0>;
linux,code = <100>;
};
};
};
};
It seems to be working now. I can see my outputs under /sys/class/leds but I can't find anything similar for my input (P9_16). That said if I export the GPIO it shows the direction as 'in'.
The only other thing that is a little bothersome is that the pin modes shown by cat'ing $PINS does not seem to reflect the expected mode but only for these GPIO pins. All of the other pins I set in the overlay seem to be show as expected.
I have a rather large overlay for a project that sets up an SPI bus, UART, RTC etc but I also need to configure some GPIOs that I control via an application using BBBioLib. I did all of this with the 3.8 kernel and it all worked fine. I've converted the overlay and it compiles and seems to load okay and all of the pins seem to be set to the correct mux except for the GPIO pins.
Here is the entire overlay:
The section that I'm concerned about fragment 10:
Is this the correct way to specify the GPIO pins?