From: Bob Feretich <bob.feretich@domain.hid>
To: Guenter Ebermann <guenter.ebermann@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] RTDM driver structure - an update
Date: Tue, 10 Aug 2010 02:08:24 -0700 [thread overview]
Message-ID: <4C611708.30702@domain.hid> (raw)
In-Reply-To: <8A042E82-C083-4876-AFF5-6D51A291C486@domain.hid>
Gunther,
Thank you for the information.
No, the my hardware interrupt line is not being shared by other devices.
So I really don't want it to be considered "shared". However, my concern
was on how driver IRQ request calls are handled.
If a driver invokes request_irq() without the SHARED flag, I would
expect Linux to reject subsequent request_irq() calls for the same IRQ
made by other drivers. Similarly, if the first driver invokes
request_irq() with the SHARED flag, I would expect Linux to accept
subsequent request_irq() calls for the same IRQ made by other drivers
if-and-only-if the other requests are made with the SHARED flag.
My temporary fix for the problem I encountered required me to request
the same IRQ from Linux via request_irq() and then from Xenomai via
rtdm_irq_request(). I had expected the Xenomai request to fail. However,
that expectation assumed that there are interlocks between the
environments. I perceived problems in either case. If there are no
interlocks, then both a real-time driver and a non-real-time driver may
be loaded to service the same IRQ and be ignorant of each other. This
would probably be bad.
If there are interlocks...
Then for a non-shared IRQ, the first driver to request the IRQ would
receive it. All other requestors, regardless of whether they are Xenomai
or Linux would be refused.
For a shared IRQ, the rules get much more complex. I believe that the
first driver to request the IRQ would receive it, but if the driver
specified the SHARED flag sharing would restricted the environment of
that first driver. Requests made from the other environment should be
rejected whether or not they specify SHARED.
Since my temporary fix (requesting and receiving a non-shared IRQ in
both the Linux and Xenomai environments) worked, if proved that there
were no interlocks. Phillippe stated that this is a flaw in the current
version of Xenomai.
Regards,
Bob
On 8/10/2010 12:43 AM, Guenter Ebermann wrote:
> Hi Bob,
>
> Am 10.08.2010 um 02:56 schrieb Bob Feretich:
>> Do I need to mark the IRQ SHARED in the request_irq()?
>> Does executing a rtdm_irq_request(), without the SHARED flag, fail if
>> the IRQ was reserved via request_irq()? (The purpose of the flag is not
>> documented in the API manual.)
>> Do I need to specify the SHARED flag in both request_irq() and
>> rtdm_irq_request()? I'd rather not allow any other driver access to my IRQ.
> I am relatively new to xenomai, but perhaps I can shed some light on shared
> IRQs: Shared IRQs are used if more than one device share one interrupt line.
> E.g.: Two PCI cards use the same interrupt line.
>
> The cards output has high-resistance if the interrupt is disabled. A external
> pull-up is used. So if no interrupt is pending the voltage is high on the line.
> The interrupt must also be level sensitive.
>
> Whenever a interrupt occurs one card pulls down the IRQ line to ground. This
> also works if both cards pull the IRQ down the same time (IRQ happens at the
> same time).
>
> Also the return value of the IRQ is important if the IRQ is shared. The first
> thing you have to do is check if it was your device that issued the irq (by
> accessing some registers in your device). If it was your device do what has to
> be done (ack the interrupt in the device so that it doesnt pull down the level
> to ground any more) and return IRQ_HANDLED. If its not your return
> IRQ_NO_HANDLED or such.
>
> So if you write a driver for one of this two cards you must use the IRQ_SHARED
> flag (this is the same with standard linux interrupt API - just call
> request_irq with irqflags=IRQF_SHARED) so that linux knows that after it calls
> your handler it must also call all other handlers of this IRQ.
>
> However shared IRQs can be used for all kind of devices. But PCI is the only
> example I am aware of where it really is used. It is also the root of alot of
> problems because one must be really careful to handle such shared IRQs
> correctly.
>
> So its more likely your device does not use shared IRQs.
>
> But perhaps in xenomai API this flag means a different thing I am not yet aware
> of.
>
> Kind regards,
> Guenter
next prev parent reply other threads:[~2010-08-10 9:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-05 2:49 [Xenomai-help] RTDM driver structure Bob Feretich
2010-08-05 7:07 ` Gilles Chanteperdrix
2010-08-05 18:57 ` Bob Feretich
2010-08-05 19:27 ` Gilles Chanteperdrix
2010-08-07 2:22 ` [Xenomai-help] RTDM driver structure - an update Bob Feretich
2010-08-08 9:36 ` Everett Wang
2010-08-08 12:08 ` Gilles Chanteperdrix
2010-08-08 14:32 ` Everett Wang
2010-08-10 0:56 ` Bob Feretich
2010-08-10 7:43 ` Guenter Ebermann
2010-08-10 9:08 ` Bob Feretich [this message]
2010-08-10 13:33 ` Gilles Chanteperdrix
2010-08-10 13:41 ` Philippe Gerum
2010-08-10 13:18 ` Gilles Chanteperdrix
2010-08-10 19:01 ` Bob Feretich
2010-08-10 21:41 ` Gilles Chanteperdrix
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=4C611708.30702@domain.hid \
--to=bob.feretich@domain.hid \
--cc=guenter.ebermann@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.