From: Jan Kiszka <jan.kiszka@domain.hid>
To: Steffen Mehlfeld <S.Mehlfeld@domain.hid>
Cc: xenomai-help <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] Sharing interrupts between several RT pci devices and non RT devices
Date: Fri, 16 Feb 2007 18:40:06 +0100 [thread overview]
Message-ID: <45D5EC76.6020405@domain.hid> (raw)
In-Reply-To: <20070216130634.216140@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2435 bytes --]
Steffen Mehlfeld wrote:
> Jan Kiszka wrote:
>
>> 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.
>
> done so.
>
>>> 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.
>
> That won't work for me, because the cards are supposed to run on lots of different machines, with lots of different devices and therefore device-drivers that may share the irq-line with this rt-device.
Sounds a bit like "dynamic RT-system configuration" - scary. ;)
>
> On my development machine, the cards irq-line depends on the presence of other pci-cards, on the used pci-slot and some other parameters i can't figure out (sometimes it's on 9, 10, 11, ...).
The line is the physical trace on the board or in the chipset. What you
first of all see are moving numbers for your IRQs. But do the sharing
change as well unpredictably? Typically, there are fixed assignments
between PCI slots and lines.
>
> Is there no known way how to influence this (maybe via config-space)?
None I'm aware of. Some people reported BIOS options on the IRQ mapping,
but I never saw such thing. Normally, only flipping PCI cards or
disabling devices (or not using them) helps to get a line physically free.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
next prev parent reply other threads:[~2007-02-16 17:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-16 8:19 [Xenomai-help] Sharing interrupts between several RT pci devices and non RT devices Steffen Mehlfeld
2007-02-16 9:04 ` Jan Kiszka
[not found] ` <20070216130634.216140@domain.hid>
2007-02-16 17:40 ` Jan Kiszka [this message]
2007-02-16 9:20 ` Dmitry Adamushko
-- strict thread matches above, loose matches on Subject: below --
2007-02-16 13:08 Steffen Mehlfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45D5EC76.6020405@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=S.Mehlfeld@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.