Yet more on GPIO interrupts

Kit Bishop

@Boken-Lin Thanks - I must have overlooked it. I will try installing the patch and rebuilding and see what happens.
Apologies for wasting your time

Kit Bishop

YAY!! I Have got GPIO interrupts working from user mode C/C++ code.

For the record, I did the following:

Applied this patch to the OpenWrt sources (as in https://wiki.onion.io/Tutorials/Cross-Compile)
Built a release using these sources including gpio-irq (i.e. kmod-gpio-irq) and gpio-test packages
Copied the file openwrt-ar71xx-generic-onion-omega-squashfs-factory.bin from the
Installed the built release on my Omega using sysupgrade openwrt-ar71xx-generic-onion-omega-squashfs-factory.bin
Ensured gpio-irq (i.e. kmod-gpio-irq) and gpio-test were installed from the .ipk files generated above
Ran gpio-test N & (where N is the GPIO pin number) and observed that interrupts were detected and reported when the state of pin N was changed
Wrote a small amount of C code that used similar techniques to gpio-test and checked that it too correctly intercepted the interrupts.

The only relevant observation I can make is that because of this line:

int err = request_irq(irq_number, gpio_edge_interrupt, IRQ_TYPE_EDGE_BOTH, "gpio_irq_handler", data);

in gpio-irq.c the interrupt is triggered on both the rising and falling edge. The specific case can be detected from the state of the pin when the interrupt code is called. I may consider a patch that allows setting for rising or falling edges specifically, but it is not a big deal.

As a consequence, I would HIGHLY RECOMMEND to the Omega people that, in the next (or relatively soon) release of the Omega code, the patch (https://github.com/GBert/openwrt-misc/blob/master/gpio-test/src/patches-3.18/739-MIPS-ath79-add-gpio-irq-support.patch) be applied and that package kmod-gpio-irq be included.
Then, GPIO interrupts will be standardly available in the Omega without additional work.

Boken Lin

Hi @Kit-Bishop, were you able to get the edge file to work in the sysfs interface? We will definitely add the patch into our buildroot so that the next update will have the irq support built-in.

Thanks!

Kit Bishop

@Boken-Lin No, I was never able to figure out how the edge file could be created and used via the sysfs interface. But since with the kernel patch and usage of kmod-gpio-irq I can now successfully deal with GPIO interrupts in C/C++ based on the code in gpio-test I am happy with what I can now achieve.

A relevant comment is that in playing with code based on gpio-test I have found:

There is only a single irq handler that can be installed using the existing code
BUT amongst the information passed to the irq handler is a structure that in one of its fields gives both the pin number for which the handler is called and the state of the pin - with this, it will be easy to write some code that:
- Calls on to an additional handler specific for an individual pin
- Can distinguish between rising and falling changes in the pin
I will be updating my new-gpio code to incorporate GPIO pin interrupt handling capabilities based on this.

Some interesting information about how the kmod-gpio-irq code works is:

It works by detecting writes (in user mode code) information about the pin number and the process id to /sys/kernel/debug/gpio-irq to enable and disable interrupt handling for the pin
When interrupt handling for a pin is added by writting to /sys/kernel/debug/gpio-irq the following line is created in /sys/kernel/debug/gpio (e.g.for pin 6):
- gpio-6 (GPIO IRQ handler ) in lo
This line is removed when the interrupt handler for the pin is removed

As an aside, the default contents of /sys/kernel/debug/gpio are :

gpio-8 (USB power ) out hi
gpio-11 (reset ) in lo
gpio-27 (onion:amber:system ) out lo

Of these:
a. I don't understand why gpio-8 is there (????)
b. gpio-11 makes sense since pin 11 is the reset pin
c. gpio-27 makes some sense since I understand that pin 27 is the Omega LED

Kit Bishop

@Boken-Lin A few days ago, you said: We will definitely add the patch into our buildroot so that the next update will have the irq support built-in.

This is NOT meant to be a complaint or hurry up, but do you have any rough idea when the updated with GPIO irq support as per the patch will be available?

The reason I ask is that I have now got some significant C/C++ code (as an extension to the new-gpio code I posted some time ago) that from my testing appears to work well in handling GPIO interrupts.

This includes a test program that in a very simple manner can be used to set a background program running that, on an interrupt (e.g. a button press), will run any shell command specified at the time the program was started. Thus allowing running of any command to be associated with a button push - multiple such instances can be set up - one for each GPIO pin if so desired.

However, this code is dependent upon:

A kernel version with the above patch
Installation of the kmod-gpio-irq package

I would like to post this code since I believe it would be of general use, but there is no point in doing so until the update is generally available.

Boken Lin

@Kit-Bishop We will be putting out a new firmware today.

Kit Bishop

@Boken-Lin Great Thanks. Didn't mean to give you a hard time over this.

Boken Lin

Hi @Kit-Bishop, if you do an oupgrade now, you should be able to upgrade to a firmware with the patches applied. Please let me know if it works.

Kit Bishop

@Boken-Lin Unfortunately, no it doesn't seem to work after a clean update to the latest release.

The first issue is that there is no kmod-gpio-irq that I require - it is not available via opkg even after doing an opkg update - so I tried installing the version I had built using the OpenWrt cross compile environment (and which worked with the patched system image I had built and installed).

I think i have tracked the problem down to the fact that there is no /sys/kernel/debug/gpio-irq file. The GPIO irq handling works by writing to this file.

I am trying to track down what I had installed in my separately compiled image that would have created this file.

If you have any info on this, I would be interested to hear. meanwhile, I will try to keep working to track down what is different between the latest Omega build (for which GPIO irq does not work) and the system build that I produced (for which GPIO irq works)

Boken Lin

Hi @Kit-Bishop, It could have been that the patch did not get included in the build for whatever reason. I will work with @Lazar-Demin to sort it out tomorrow.

Kit Bishop

@Boken-Lin Thanks. Would be good if it was as simple as not having included the patch (it's this one: https://github.com/GBert/openwrt-misc/blob/master/gpio-test/src/patches-3.18/739-MIPS-ath79-add-gpio-irq-support.patch).
Though, it will be essential also that kmod-gpio-irq be available via opkg as well.

I'm probably about to take a break (it's getting to be evening here) - if I don't here anything more from you on this, I will keep looking tomorrow.

Lazar Demin

hey @Kit-Bishop firmware b265 and later have kmod-gpio-irq and the gpio.c patch.
I installed and ran gpio-test locally, the edge based interrupts do in fact get triggered!

Btw, I made the gpio-test package available in the Onion package repo.

Happy hacking!

Kit Bishop

@Lazar-Demin Cool Thanks for quick feedback

I am currently on firmware b264 so will shortly upgrade and try again. Will report back when done

Kit Bishop

@Lazar-Demin Absolutely fantastic! Thank you very much

Have upgraded to b266 and everything works perfectly - including my GPIO IRQ and test program.

My IRQ code is basically an extension to the code I have previously posted for new GPIO access (https://community.onion.io/topic/143/alternative-c-code-for-gpio-access) with the addition of IRQ handling capabilities.

Because it may be of use to others, I will do the following:

Send the test program and needed library with some basic documentation on its use in a separate post
Later, update the package and details in https://community.onion.io/topic/143/alternative-c-code-for-gpio-access with the latest sources and full documentation