RTEMS GPIO API interrupt handling
André Marques
andre.lousa.marques at gmail.com
Sat Jul 18 18:23:13 UTC 2015
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.
More information about the devel
mailing list