From: Grant Likely <grant.likely@secretlab.ca>
To: Tabi Timur-B04825 <B04825@freescale.com>
Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
Felix Radensky <felix@embedded-sol.com>
Subject: Re: Handling multiple GPIO controllers in 8xxx GPIO driver
Date: Thu, 29 Sep 2011 16:36:48 -0500 [thread overview]
Message-ID: <20110929213648.GA10886@ponder.secretlab.ca> (raw)
In-Reply-To: <4E84D36D.3050200@freescale.com>
On Thu, Sep 29, 2011 at 08:22:06PM +0000, Tabi Timur-B04825 wrote:
> Grant Likely wrote:
> > A chained handler has an expedited path through the interrupt code for
> > handling it (basically, it skips handling it at the parent controller
> > and passes through to the child, but it cannot handle multiple chained
> > children on a single irq input.
>
> So you can't do a shared chained handler? If the chained handler returns
> IRQ_NONE, the interrupt code just gives up?
No, you can do one or more regular handlers which acks or masks the
irq in the upstream controller, or you can do a single chained handler
which bypasses any ack/mask. It's an optimization. The code *could*
be modified to allow multiple chained handlers, but I cannot comment
on if it would be worthwhile.
Basically, a chained handler replaces the regular edge or level irq
handler. Take a look at __irq_set_handler(). Chained in this case is
really a synonym for a cascaded irq handler. Also, I believe it only
really works if the irq is level sensitive because an edge sensitive
irq would still need to be acked. It would also need to be an irq
controller that can be accessed immediately since it depends on the
child controller to ack/mask it's inputs. Something on an i2c bus
wouldn't work so well because the irq would remain asserted until
after several slow i2c transactions.
g.
next prev parent reply other threads:[~2011-09-30 0:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-27 13:59 Handling multiple GPIO controllers in 8xxx GPIO driver Felix Radensky
2011-09-27 18:29 ` Grant Likely
2011-09-27 22:07 ` Felix Radensky
2011-09-28 20:52 ` Tabi Timur-B04825
2011-09-29 17:27 ` Grant Likely
2011-09-29 20:22 ` Tabi Timur-B04825
2011-09-29 21:36 ` Grant Likely [this message]
2011-09-29 20:44 ` Felix Radensky
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=20110929213648.GA10886@ponder.secretlab.ca \
--to=grant.likely@secretlab.ca \
--cc=B04825@freescale.com \
--cc=felix@embedded-sol.com \
--cc=linuxppc-dev@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).