RTEMS GPIO API interrupt handling

[Joel Sherrill]

On July 18, 2015 1:23:13 PM CDT, "André Marques" <andre.lousa.marques at gmail.com> wrote:
>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. 

For single pins that someone wants to map to an ISR, this sounds good. But it is not uncommon to have a set of pins that are a single logical source of interrupts. 

I have seen a case where multiple pins indicated the state of a 1024 position encoder. And other uses of 2-4 pins for device state.

How will these cases be dealt with?


>After this is done another round of code review may start.
>
>Thank you for your time,
>André Marques.
>_______________________________________________
>devel mailing list
>devel at rtems.org
>http://lists.rtems.org/mailman/listinfo/devel

--joel