Re: [parisc-linux] Thoughts on arch/parisc/irq.c

[Philipp Rumpf <prumpf@suse.de>]

> linux/arch/parisc/kernel/irq.c:irq_alloc()/request_irq() seems to be
> the method to allocate EIRR bits 

alloc_irq is just a quick hack to try to avoid sharing interrupt handlers
if possible.  It returns the next unused IRQ but isn't atomic right now.

> and register ISRs with PA ext_intr
> handler. Dino will call this to initialize it's own EIM register (IAR0).
> But to program IAR0 Dino also needs the processor HPA of whatever
> processor it is supposed to interrupt.

Not exactly right.  You can just use the broadcast EIR address (which might
be GSC-specific but we don't have docs on other hardware yet).

I am not sure how GSC devices will be managed, but if we just chose to be lame
and do it like PCI, there will be a list of GSC devices and the Dino driver
just can do gsc_writel(0xfffe0000+dev->irq, dev->hpa + DINO_IAR0);

> (BTW - anyone else modifying gecko/dino.c?)

I think I am pretty synched right now.  The GSC handling is not in place yet so
perhaps you should hardwire everything until it is.

> Support for PCI 2.2 Message Signalled Interrupts requires
> a similar interface - Dino can support this if the interface
> were present and PCI drivers wanted to use it.

I have no idea what that is.  I don't think it is in the Dino docs I have either
so I am afraid I cannot say anything about it.

> o Do GBD or other psuedo drivers need to reserve EIRR bits?
>   Ie soft interrupts to reschedule work at lower SPL levels.

I don't think so.

> o PA2.0 architecture defines EIRR to be 64-bits wide.
>   irq_alloc() and request_irq() hard code 31.
>   Using a #define with "ifdef" around it for 32/64 bit
>   differences would be better. Just trying to make the
>   transition that direction easier.

Dino at least does not support 6-bit interrupt code according to our
documentation.

> o Each processor can have it's own EIRR switch table.
>   Thus, "irq_action[]" could be an an array hanging off a per processor
>   data structure. This is interesting for large configurations where
>   the 31 bits aren't enough and sharing isn't supported.

I don't want to try things before they get tested by other architectures first
unless necessary.  I don't think per-processor irq_actions are a way to go, but
we can have another look at it when it's time to.


> o EIRR bits can be shared just like IRQ lines. A wrapper gets
>   put into the irq_action[] field when sharing is required
>   (eg run out of EIRR bits to hand out). The wrapper function

Once again, not yet.  There is no way I want to know of to run out of EIRR bits
on 712, 715 or A180s, so I'd like to get us up and running on those first.

	Philipp Rumpf