On Tue, 15 Feb 2005, Michael Neuhauser wrote:
> On Tue, 2005-02-15 at 09:29, [EMAIL PROTECTED] wrote:
> >
> > I can for-see a couple of points that would need some careful thinking:
> >
> > 1. pending (to Linux). How is it done - a) for each new irq it is added to
> > a queue and then they are delivered exactly in this order, or b) each new
> > irq is marked pending (e.g. in a bit-mask) and then they are delivered in
> > arbitrary order? If a), then 1 per irq or possibly multiple entries per
> > irq?
>
> It is b), kind of:
[snip]
> The decision what interrupt to deliver next is done
> by__adeos_sync_stage() (with no relation to the order they happened):
> the function flnz() favours the high numbered irqs (and has the
> advantage of being only one assembler statement ("clz") for >= ARMv5.
This might be a problem. After lots of testing, over-thinking we've landed
with some version of a)... Will have to see how it goes now.
> > 2. mask-/ack-ing. Is only RTAI using real hardware irq-operations for all
> > irqs, or only for real-time irqs and further domains are allowed to mask
> > / ack themselves?
>
> When pipelining is enabled, Adeos replaces the mask, unmaks & mask_ack
> slots in the linux irq_desc[] with its own
> __adeos_override_irq_mask/unmas/mask_ack functions. These functions
> disable interrupts hard to protect the PIC and call the original Linux
> functions.
>
> __adeos_handle_irq() calls the irq acknowledge function (which actually
> does mask-ack) before calling any domain's irq-handler. Unmasking the
> irq (or doing irq-source specific clearing) is left to the irq handler.
Did I understand you right, that each Linux interrupt will be mask_acked
twice?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
