From: Gary Thomas <gary@mlbassoc.com>
To: Sylvain Munaut <tnt@246tnt.com>
Cc: Sven Luther <sven.luther@wanadoo.fr>,
Andy Fleming <afleming@freescale.com>,
Linux/PPC Development <linuxppc-dev@lists.linuxppc.org>
Subject: Re: IRQ Level / Edge
Date: Sun, 04 Jul 2004 11:58:57 -0600 [thread overview]
Message-ID: <1088963937.6277.405.camel@hermes> (raw)
In-Reply-To: <40E83EFD.8000309@246tNt.com>
On Sun, 2004-07-04 at 11:31, Sylvain Munaut wrote:
> >
> > Err, i suppose the interesting bit is not how the board designer
> > will know wheter the interrupt is edge or level, but how the kernel
> > running on the board is able to detect it ?
> >
> > Friendly,
>
>
> Well, the kernel doesn't detect it. You have to tell him !
> That's why I asked, because in the interrupt controller code, you have
> to set it in the irq_desc[i] structure.
Indeed, the kernel *can't* detect this (at least not easily). You have
to know how the device (chip, etc) works. If it generates edge
interrupts, then typically it will only generate a small pulse and the
interrupt controller has to be set up to recognize this. For edge
interrupts, you normally only care about either a "falling" edge (the
transition from logic high to logic low) or "rising" edge (low to high).
It is then up to the device driver to tell the device to generate the
next interrupt as part of the interrupt service. Most devices will not
generate another edge until the current one has been "cleared" or
"acknowledged."
If it is a level interrupt, then the device will assert its interrupt
signal until told to remove it (by the device driver). In this case,
it is important for the interrupt controller to be aware that this
signal may persist (it's a level) and only tell the CPU about it
once. In this case, the driver needs to tell the interrupt controller
when it has serviced the interrupt so that it will recognize when
the device re-asserts its interrupt signal.
n.b. this assumes that the interrupt controller is behaving like an
edge itself, i.e. it only interrupts the CPU once per state change.
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-07-04 17:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-02 21:39 IRQ Level / Edge Sylvain Munaut
2004-07-02 22:47 ` Andy Fleming
2004-07-03 16:42 ` Sven Luther
2004-07-04 17:31 ` Sylvain Munaut
2004-07-04 17:58 ` Gary Thomas [this message]
2004-07-04 18:05 ` Sven Luther
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=1088963937.6277.405.camel@hermes \
--to=gary@mlbassoc.com \
--cc=afleming@freescale.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=sven.luther@wanadoo.fr \
--cc=tnt@246tnt.com \
/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.