From: Jan Kiszka <jan.kiszka@domain.hid>
To: adeos-main <adeos-main@gna.org>, Xenomai core <Xenomai-core@domain.hid>
Subject: [Xenomai-core] Enabling classic MSI for real-time domains
Date: Mon, 25 Oct 2010 18:12:45 +0200 [thread overview]
Message-ID: <4CC5AC7D.9090700@domain.hid> (raw)
Hi,
for the past days, I had a look at the issue of classic MSIs (ie. not
MSI-X) under non-Linux I-pipe domains. Actually, the path that matters
most, IRQ delivery, is perfectly OK as is: just a simple ack on the APIC
and a NOP on completion.
Problematic are IRQ enable/disable (which automatically includes
setup/cleanup) and affinity updates. The point is that we specified at
least the first two services to be usable from RT context as well.
That's a nice-to-have with fast IRQ chips, but its a nightmare with
others. Classic MSI belongs to the latter category.
So we basically have two main options now, each having two variants:
1) disallow IRQ enabled/disable over non-root contexts
1a) confine this to certain IRQs like MSI or
1b) make it a generic API property
2) provide ipipe_irq_mask/unmask services and use them in Xenomai
2a) for MSI, either to map them on a software mask or
2b) to map them on MSI-specific services that bypass the ordinary
[un]mask_msi_irq and use hardened ones (*)
I would prefer to go for the cheaper option 1), probably 1a) as we have
non-MSI users out there that do disable/enable trickery from RT
contexts. Unfortunately, also 1a) will require some new interface
between I-pipe and Xenomai to inform the user about the limited
usability of enable/disable and likely even enforce it at Xenomai level.
Comments, ideas?
Jan
(*) Previously posted patches to address the MSI issue by hardening both
pci_config_lock and pci_lock likely failed as the latter is of too broad
scope, including wake_up_all.
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
reply other threads:[~2010-10-25 16:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4CC5AC7D.9090700@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=Xenomai-core@domain.hid \
--cc=adeos-main@gna.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.