[GSOC] GPIO status and I2C start

Pavel Pisa ppisa4lists at pikron.com
Thu Aug 21 12:20:24 UTC 2014


Hello everybody,

I am happy that the common GPIO API for RTEMS is developed
but I have some concerns about IRQ handlers registration.

On Sunday 06 of July 2014 00:58:23 Andre Marques wrote:
> Hello,
>
> The Raspberry Pi GPIO interrupts are already working, and a test case is
> available to test that [1]. A function is also provided to debounce a
> switch if needed. The test case requires two switches and two LEDS using
> the same setup described at [2] by only changing the pin numbers.

https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_TEST_IRQ/init.c

http://wiki.rtems.org/wiki/index.php/Raspberry_Pi_BSP_Peripherals

The registered handler has no context parameter.This is unfortunate
because there is often need to do same or similar processing
for more interrupt sources and this way it means to write
individual handler or trampoline for each pin.

Please change registered handler prototype to same type
as rtems_interrupt_handler used in rtems_interrupt_handler_install

  typedef void (*rtems_interrupt_handler)(void *);

then function prototype of gpio_enable_interrupt() should add
void *arg and its value should be stored together with handler
pointer and pass to the handler when called.

In the fact, Linux kernel goes even more further where it
statically or runtime allocates numbers for individual
IO pins interrupt sources in the main interrupt table.
Then GPIO provides only function to map GPIO number
to IRQ source number and standard registration
of interrupt handler is used to register to individual
pin interrupt. That has advantage, that drivers of peripherals
do not need to distinguish if their peripheral is connected
to direct external IRQ source or to the GPIO pin which needs
cascade IRQ event processing. In RTEMS that would lead to
use of rtems_interrupt_handler_install even for GPIO IRQs.

But that would require more changes. But passing of context
to the handler is very important and fortunately RTEMS
has switched from other handler prototypes to this standard
years ago already.

Best wishes,

                Pavel



More information about the devel mailing list