Michael Neuhauser wrote:
On Tue, 2005-02-15 at 12:04, [EMAIL PROTECTED] wrote:
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.
This is so fundamental to Adeos on all platforms, that I don't think it
would be easy to change.
Additionally, this would mean that some dependency exists in some kernel
code between distinct interrupt sources. Given the asynchronous nature
of interrupts, I'd be interested to have a legitimate example of a
situation where a code would have enough knowledge to expect two or more
unpredictable events on a given timeline to operate properly. The only
situation which gets closer, but still different from the latter, is the
pckbd driver for x86, which happens to busy wait for a subsequent kbd
interrupt on top of its own ISR. But in this case, queuing would be
overkill since interrupts are of the same kind, counting IRQs is enough.
This said, the Adeos code is not some holy cow that should not be
suspected from failure by principle, even in design; but the fact is
that queuing was useless to reach a stable behaviour over x86, ia64 and PPC.
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?
No, as the mask_ack() call in Linux' do_IRQ() is modified like this:
#ifdef CONFIG_ADEOS_CORE
if (!adp_pipelined)
#endif /* CONFIG_ADEOS_CORE */
desc->mask_ack(irq);
i.e. don't do it if pipelining is active.
Mike
--
Philippe.
