RTEMS GPIO API interrupt handling

[André Marques]

Hello all,

as previously pointed by Gedare, the interrupt handling code in the 
RTEMS GPIO API can benefit with the use of a rtems interrupt server. The 
current design and implementation details of the API can be seen in my 
GSOC blog 
(https://asuolgsoc2014.wordpress.com/2015/07/14/rtems-gpio-api-status/).

To summarize the GPIO interrupt handling requirements it is important to 
note that a GPIO bank is composed of several pins all triggering a 
common interrupt vector, each pin being a separate interrupt source, 
which may in turn have one or more handlers of their own. This does not 
mean, however, that the pins interrupt handling is completely 
independent as although each pin has their own handler, we can not 
simply call all pin handlers on a GPIO bank every time a interrupt is 
sensed on the vector, as the pins themselves do not have interrupt state 
data.

The active/pending interrupts on a GPIO bank are stored on a register, 
meaning that every time an interrupt is sensed on an interrupt vector 
the interrupt vector handler (which should be unique) will have to read 
the register to know which pins have pending interrupts, and then call 
the respective handler/handlers.

Each pin may have more than one handler if more than one device is 
connected to the same pin, in which case each device will have a handler 
which should begin by probing their corresponding device to know if the 
culprit is their device, and if so handle it.

The pin's handlers are stored on an internal (to the API) chain, and 
called sequentially as in this case each connected device will have to 
be probed to know the origin of the interrupt (shared interrupt handler 
behavior), and these handlers are dealt with by the API.

Regarding the handling at the vector level, each bank currently has an 
unique rtems interrupt handler which probes the interrupt line on that 
bank, and calls (wakes) the corresponding pin handler task on any pin 
with a pending interrupt.

This is the part that can be replaced with a rtems interrupt server, as 
each bank can have the "same" unique handler installed on the server 
through a call to rtems_interrupt_server_handler_install, which will put 
the vector/bank handler on a chain to be processed on the server task 
(which is waked every time an interrupt is sensed). The advantage 
relative to my current implementation is that this allows a single task 
to call every handler, instead of waking a task per pin which calls the 
corresponding pin handler(s) which is unnecessary overhead on a single 
core system (a SMP system could benefit of multiple tasks/servers to 
allow interrupt handling parallelism, although the current interrupt 
server implementation only allows a single server in the whole system. 
In this situation it would also be useful if the vector was re-enabled 
as soon as possible so any interrupts generated during the handling of a 
pin's interrupt can be quickly handled in parallel, instead of waiting 
from the previous interrupts to be processed - remember that in a GPIO 
vector each pin interrupt is independent - unless it is an interrupt on 
the same pin). The handler that will be called by the rtems interrupt 
server task will probe and clear the GPIO bank interrupt line, and call 
the necessary pin handlers before allowing the interrupt server to 
re-enable the vector.

Apart from this, the API may also allow interrupts on a given 
vector/bank to be non-threaded (which is to say that they are handled on 
a regular interrupt handler, with the advantages/restrictions of an ISR 
environment).

This is the current work plan regarding the GPIO interrupt handling in 
the RTEMS GPIO API, so if anyone has any issue with it do let me know. 
After this is done another round of code review may start.

Thank you for your time,
André Marques.