Development Plan Proposal for Unifying Interrupt and PCI APIs

[Pavel Pisa]

On Monday 25 October 2004 15:54, Joel Sherrill <joel at OARcorp.com> wrote:
> I am not even pushing a single location for the implementation inside
> the source tree.  It could be in score/cpu, libcpu, or libbsp.  I don't
> care as much about that as I do having a unified API with the
> possibility of additions on certain CPUs.  But those have to be
> minimized and justified.
>
> I do want to get ISR(vector, void *context) before we are done.

That would bring me to nirvana.
I vote for 
  int ISR(vector, void *context)
and defined constants for return value
  #define RTEMS_IRQ_NONE    0
  #define RTEMS_IRQ_HANDLED 1

Return value enables to implement correct handling for level
and edge triggered interrupts one day.

Than I could imagine next hierarchical IRQ model
using "rtems_irq_connect_data" conditionally expandable
with private/context, next and prev fields to enable shared IRQs support.
The rtems_irq_connect_data concept than can be expanded little more.

ARM CPU IRQ  -> calls one of five possible exception handlers (FIQ, IRQ, ...)

Standard like handler connected through "rtems_irq_connect_data" to IRQ
can then obtain new vector number from AITC, this can be used as index into
other (or start shifted) "rtems_irq_connect_data" array and call next
ISR level.

If this IRQ number happens to be one of PCI IRQs (A,B,C,D, than common PCI
"rtems_irq_connect_data" instance with PCI handler would be invoked there.

This common PCI IRQ handler could use circle of next/prev connected 
"rtems_irq_connect_data" for actual PCI devices. The first  
"rtems_irq_connect_data" of the bidirectionally linked list could be
pointed by private/context field located in previous level
PCI "rtems_irq_connect_data". If only one device lives on the list,
than one device ISR call is required. If there is more devices,
all should get possibility to handle IRQ. If IRQ is edge triggered,
than only way is to go through circle in loop until all handlers returns
RTEMS_IRQ_NONE.

There are one thing to decide. If we want all vector indexed
pointers to "rtems_irq_connect_data" array or we want separate
array for CPU level, AITC IRQ vector level, GPIO bit level, etc...

I am not sure about that. If we decide to have all in one array,
than there has to be zero index shift of each level.
If arrays are separate, than there could not be one common
ISR to vector number only registration function or registration
function would require level/bus/GPIO level pointer parameter.

For example, Linux unifies AITC IRQ vector and GPIO pin specific
ISR registration by shifting GPIO indexes/vector numbers after
last AITC IRQ vector number.

Best wishes

                Pavel Pisa
        e-mail: pisa at cmp.felk.cvut.cz
        www:    http://cmp.felk.cvut.cz/~pisa
        work:   http://www.pikron.com