Thanks for the response. I found out that there is GPIO support (gpio-mxc.c) that appears to handle the GPIO setup for interrupts properly, so I get a event from the "gpio-keys" config I set up in the device tree.
The only issue (not) is that there is more than just one or more bytes that get sent as an event. Good thing all I care about is that there is an event after the gpio changes state (vary rarely) which allow a blocking read to monitor it.
There are a few web pages that talk about setting up the device tree for gpio-keys:
https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys.txt
You have to modify the GPIO pin information to match your board design. This allows your GPIO to send a "key code" to an input driver (/dev/input/event0) that works kind of like an interrupt if a program does a blocking read on the input.
Hi @flobro!
Thank you for contacting NXP Support!
For our boards, we don´t have examples, but you can see the documentation of the kernel following the link:
https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/Documentation/devicetree/bindings/gpio/gpio.txt
Best Regards!
Chavira
Thanks for the response. I found out that there is GPIO support (gpio-mxc.c) that appears to handle the GPIO setup for interrupts properly, so I get a event from the "gpio-keys" config I set up in the device tree.
The only issue (not) is that there is more than just one or more bytes that get sent as an event. Good thing all I care about is that there is an event after the gpio changes state (vary rarely) which allow a blocking read to monitor it.