[EMAIL PROTECTED] wrote:
Thanks for the answer, Paolo
i am afraid, I still don't understand:
On Fri, 11 Feb 2005, Paolo Mantegazza wrote:
Not exactly so. When the RTAI hal is started it virtualises all the irqs
to a single ADEOS handler (rtai_irq_trampoline)
"all the irqs" - for whom? I thought the structure was roughly
Adeos Adeos
irq-pipe0 irq-pipeN
[ ] - ... [ ] - Linux
[ ] - ... [ ] - RTAI
^ ^
| ... |
irq0 ... irqN
which doesn't seem to hold. By virtualising all interrupts to one, you
mean, that for all hardware irqs Adeos calls only one RTAI handler
(dispatcher), right? That seems already to contradict Adeos' concept. If
it is so, then who delivers interrupts further to Linux? Adeos on the pipe
or RTAI bypassing Adeos? And then, rt_release_irq(RTAI_TIMER_IRQ); gives
the RTAI interrupt free, not Linux, right? But normally, when this
function is called there isn't a rt-timer ISR yet? Or is it done to make
calling rt_request_timer() multiple times without releasing the timer?
It is RTAI in power of everything, as it is the trampoline that delivers
to Linux by using the ADEOS propagate concept. So
rt_release_irq(RTAI_TIMER_IRQ) frees the RTAI own interrupt pointer,
thus the RTAI trampoline knows he has just to propagate it to Linux.
When the handler is installed instead it is in charge of asking for any
needed propagation.
The alternative way would be making rt_request_irq a wrapper for a
direct use of adeos_virtualise_irq_from. Clearly the trampoline solution
is simpler in maintaining RTAI classic APIS but pays for one more call.
No problem if that becomes a real bottle neck, there is a more drastic
immediate solution.
that abstracts RTAI from
ADEOS. So ADEOS calls the RTAI trampoline and the RTAI interface appears
as an independent one.
Thus rt_release_irq(RTAI_TIMER_IRQ) releases just the the HAL part. The
trampoline still sees the related interrupt as a hard one, but having no
own handler just propagate it to Linux.
Well, looks like trampoline has not much chance to propagate the interrupt
to Linux, as after releasing the timer-irq it gets immediately requested
again (in rt_request_timer())?
OK, my answer shooted at the wrong aim. In this case
rt_release_irq(RTAI_TIMER_IRQ) is likely just to be sure the following
timer request is not refused, because an irq handler is already
installed. In short the release is a reset to be sure the following
request is granted.
Notice I'm answering because I think that in magma all architectures are
fairly similar with respect to hal. Maybe Michael has more precise and
different answers.
Paolo.
