Victor Yodaiken wrote:
>
> My belief is that shared interrupts are not very useful for RT systems - does anyone
> think otherwise?
>
> If an interrupt is shared between RT and non RT devices, the RT driver must do
>
> catch_interrupt:
> examine my device
> if interrupt is mine
> do regular handling
> else
> pend interrupt for Linux/BSD
> find the interrupting non-RT device
> clear device interrupt
> re-enable interrupts from this source
>
> The key point is that the RT driver needs to look at all non-RT devices
> in order to clear the interrupt source.
> This is not too hard, but it seems not very RT.
>
Victor,
Thanks for your message, it cleared up a few things for me.
I agree with you that a RT driver shouldn't have to deal
with shared interrupts.
However, there are situations where you just can't avoid it.
I've got a motherboard here which doesn't shuffle the PCI
interrupts - intA is always on the same hardware interrupt line.
Changing slots doesn't help here.
Would it be possible to call the Linux interrupt chain from
within the RT handler? And rely on the original driver to reset
the interrupt? I know this murders the predictability but it would
allow the original driver to cope with its own hardware. Imagine
a device which clears the interrupt as a response to a data
register read, like a serial port. There might be no way to
clear the interrupt without seriously disrupting the function of
the original driver.
Can anyone think of a less horrible solution?
Kind regards,
Iwo
----- End of forwarded message from [EMAIL PROTECTED] -----
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
