From: tglx@linutronix.de (Thomas Gleixner)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH 4/9] pinctrl: meson: allow gpio to request irq
Date: Tue, 25 Oct 2016 12:39:02 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1610251137420.4990@nanos> (raw)
In-Reply-To: <CACRpkdYUVXny57AC9rKX3VRAyooEk_2XLvqe9jOuT3rOaE75rg@mail.gmail.com>
On Tue, 25 Oct 2016, Linus Walleij wrote:
> On Fri, Oct 21, 2016 at 11:06 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> >> Isn't this usecase (also as described in the cover letter) a textbook
> >> example of when you should be using hierarchical irqdomain?
> >>
> >> Please check with Marc et al on hierarchical irqdomains.
> >
> > Linus,
> > Do you mean I should create a new hierarchical irqdomains in each of
> > the two pinctrl instances we have in these SoC, these domains being
> > stacked on the one I just added for controller in irqchip ?
> >
> > I did not understand this is what you meant when I asked you the
> > question at ELCE.
>
> Honestly, I do not understand when and where to properly use
> hierarchical irqdomain, even after Marc's talk at ELC-E.
Hierarchical irqdomains are used when you have several levels of interrupt
hardware to deliver an interrupt.
For example on x86 we have:
device --- [IOAPIC] -- [VECTOR]
and we can have this expanded to
device --- [IOAPIC] -- [IRQ Remapping] -- [VECTOR]
and we have more things hanging off the VECTOR domain
device --- [IOAPIC] ---
|--- [VECTOR]
device --- [PCIMSI] ---
So with irq remapping this might look like this:
device --- [IOAPIC] ---
|-----------------------
device --- [PCIMSI] --- |
|---[VECTOR]
device --- [IOAPIC] --- |
|--[IRQ Remapping]------
device --- [PCIMSI] ---
The important part is that this hierarchy deals with a single Linux virq
and all parts of the hierarchy are required for setup and possibly for
mask/ack/eoi.
This is different from a demultiplex interrupt
device --- [DEMUX] --- [GIC]
where the demultiplex interrupt is a different virq than the device
virq. The demux interrupt chip can have a parent relation ship, which can
be required to propagate information, e.g. wake on a device behind the
demux must keep the gic as a wake irq as well. But it's not hierarchical in
the sense of our hierarchical irq domains.
Hope that helps.
Thanks,
tglx
next prev parent reply other threads:[~2016-10-25 10:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-19 10:08 [PATCH 0/9] irqchip: meson: add support for the gpio interrupt controller Jerome Brunet
2016-10-19 10:08 ` [PATCH 1/9] irqchip: meson: add support for " Jerome Brunet
2016-10-19 10:08 ` [PATCH 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO " Jerome Brunet
2016-10-19 10:08 ` [PATCH 3/9] pinctrl: meson: update pinctrl data with gpio irq data Jerome Brunet
2016-10-19 10:08 ` [PATCH 4/9] pinctrl: meson: allow gpio to request irq Jerome Brunet
2016-10-20 19:21 ` Linus Walleij
2016-10-21 9:06 ` Jerome Brunet
2016-10-25 9:14 ` Linus Walleij
2016-10-25 10:38 ` Marc Zyngier
2016-10-25 13:08 ` Jerome Brunet
2016-10-25 13:38 ` Marc Zyngier
2016-10-25 14:22 ` Jerome Brunet
2016-10-25 14:47 ` Marc Zyngier
2016-10-25 15:31 ` Jerome Brunet
2016-10-25 18:20 ` Linus Walleij
2016-10-26 14:22 ` Jerome Brunet
2016-10-26 14:32 ` Linus Walleij
2016-10-26 15:50 ` Kevin Hilman
2016-11-04 14:40 ` Linus Walleij
2016-10-25 18:10 ` Linus Walleij
2016-10-26 14:23 ` Jerome Brunet
2016-10-26 14:44 ` Linus Walleij
2016-10-27 10:42 ` Jerome Brunet
2016-11-04 15:03 ` Linus Walleij
2016-10-25 10:39 ` Thomas Gleixner [this message]
2016-10-19 10:08 ` [PATCH 5/9] dt-bindings: pinctrl: meson: update gpio dt-bindings Jerome Brunet
2016-10-19 10:08 ` [PATCH 6/9] ARM64: meson: enable MESON_IRQ_GPIO in Kconfig Jerome Brunet
2016-10-19 10:08 ` [PATCH 7/9] ARM: meson: enable MESON_IRQ_GPIO in Kconfig for meson8 Jerome Brunet
2016-10-19 10:08 ` [PATCH 8/9] ARM64: dts: amlogic: enable gpio interrupt controller on gxbb Jerome Brunet
2016-10-19 10:08 ` [PATCH 9/9] ARM: dts: amlogic: enable gpio interrupt controller on meson8 Jerome Brunet
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=alpine.DEB.2.20.1610251137420.4990@nanos \
--to=tglx@linutronix.de \
--cc=linus-amlogic@lists.infradead.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
all inboxes | Powered by JetHome®