Re: [Xenomai-help] Sharing interrupts between several RT pci devices and non RT devices

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]

Steffen Mehlfeld wrote:
> Hi,
> 
> I'm trying to run several pci cards in rt mode. Therefore I call rtdm_irq_request() with the flags XN_ISR_SHARED | XN_ISR_EDGE. 

For the sake of cleanness: XN_xxx flags are for internal use only (skins
like RTDM do so), you are expected to work with RTDM_IRQTYPE_xxx here.

> 
> In the ISR I check the interrupt status register of the pci-card. If the irq was caused by that card, i handle it and return RTDM_IRQ_HANDLED. If not, I return XN_ISR_NONE, which I understand means 'not my interrupt, try the next registered ISR'.

Yep.

> 
> This works fine as long as my pci-cards have their own interrupt line. But when the PCI-BIOS let them share the interrupt line with something like the ethernet-card (which runs in non-rt mode) the problems starts. Of course the ethernet-card gets no more interrupts and stops working.
> 
> To solve this I'd have to propagate the irq to the linux domain, when i figure out that the irq wasn't called by one of my cards (i can detect this with global flags in the kernel module).
> But as soon as i start returning XN_ISR_PROPAGATE from the isr, i get the message "Xenomai: xnintr_edge_shirq_handler(): failed to get the IRQ9 line free.", which i think doesn't mean, that all is going well. 

Yes, because the IRQ line is still high, and that must not be the case
after all RT handlers were executed.

> 
> The api documentation tells not to return XN_ISR_PROPAGATE if you share irqs amongst rt devices, which i think is reasonable if you don't know, wether all rt-devices already checked their ir-flags. 
> But isn't there a way to propagate the irq to linux, if i'm sure that it belongs there?

There used to be a wrapper for XN_ISR_PROPAGATE in earlier RTDM (again:
don't use XN-flags...), but we removed it because there is not sane way
that this cross-domain sharing would work deterministically.

Reason: When you propagate the line release to Linux, you throw away any
temporal predictability of your RT driver's IRQ handling. When will
Linux execute the non-RT handler so that the RT driver can receive new
IRQs again? No one knows...

> 
> Another solution would be not to share interrupts between rt and non-rt-devices, but i have no clue how to do this, as i'm new to the whole driver development thing. As far as i understand, the PCI-BIOS tells each device via config-space which irq it has to use. Therefore it's pointless to call rtdm_irq_request() with a irq-line other than that from config-space, as it uses the irq from config-space anyway. 
> Is there a way to specify which irq a pci device should use?

If the physical IRQs end up on the same line physical line, you have
lost. Then you can only write a special stub driver for your non-RT
device, that works over RTDM, detects if the event is for that device,
shuts the IRQ up inside the hardware (there is always some kind of mask
register), and signals the arrival e.g. via rtdm_nrtsig to the Linux
handler. When Linux is able to execute its driver, it can analyse the
IRQ reason and take the measures to finally re-enable IRQs on that
device again.

That's of course still slower than an unshared IRQ design, but it is
deterministic even when you face an unpredictable non-RT IRQ load.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]