From: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>,
Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
"open list:ARM/Amlogic Meson..."
<linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Subject: Re: [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-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 25 Oct 2016, Linus Walleij wrote:
> On Fri, Oct 21, 2016 at 11:06 AM, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Jerome Brunet <jbrunet@baylibre.com>,
Carlo Caione <carlo@caione.org>,
Kevin Hilman <khilman@baylibre.com>,
"open list:ARM/Amlogic Meson..."
<linux-amlogic@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Jason Cooper <jason@lakedaemon.net>,
Marc Zyngier <marc.zyngier@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Russell King <linux@armlinux.org.uk>
Subject: Re: [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
WARNING: multiple messages have this Message-ID (diff)
From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@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
WARNING: multiple messages have this Message-ID (diff)
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: 120+ 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 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` [PATCH 1/9] irqchip: meson: add support for " Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` 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 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` 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 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` [PATCH 4/9] pinctrl: meson: allow gpio to request irq Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-20 19:21 ` Linus Walleij
2016-10-20 19:21 ` Linus Walleij
2016-10-20 19:21 ` Linus Walleij
2016-10-20 19:21 ` Linus Walleij
2016-10-21 9:06 ` Jerome Brunet
2016-10-21 9:06 ` Jerome Brunet
2016-10-21 9:06 ` Jerome Brunet
2016-10-21 9:06 ` Jerome Brunet
2016-10-25 9:14 ` Linus Walleij
2016-10-25 9:14 ` Linus Walleij
2016-10-25 9:14 ` Linus Walleij
2016-10-25 9:14 ` Linus Walleij
2016-10-25 10:38 ` Marc Zyngier
2016-10-25 10:38 ` Marc Zyngier
2016-10-25 10:38 ` Marc Zyngier
2016-10-25 10:38 ` Marc Zyngier
2016-10-25 13:08 ` Jerome Brunet
2016-10-25 13:08 ` Jerome Brunet
2016-10-25 13:08 ` Jerome Brunet
2016-10-25 13:08 ` Jerome Brunet
[not found] ` <1477400900.2482.51.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-10-25 13:38 ` Marc Zyngier
2016-10-25 13:38 ` Marc Zyngier
2016-10-25 13:38 ` Marc Zyngier
2016-10-25 13:38 ` Marc Zyngier
2016-10-25 14:22 ` Jerome Brunet
2016-10-25 14:22 ` Jerome Brunet
2016-10-25 14:22 ` Jerome Brunet
2016-10-25 14:22 ` Jerome Brunet
[not found] ` <1477405332.2482.87.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-10-25 14:47 ` Marc Zyngier
2016-10-25 14:47 ` Marc Zyngier
2016-10-25 14:47 ` Marc Zyngier
2016-10-25 14:47 ` Marc Zyngier
2016-10-25 15:31 ` Jerome Brunet
2016-10-25 15:31 ` Jerome Brunet
2016-10-25 15:31 ` Jerome Brunet
2016-10-25 15:31 ` Jerome Brunet
2016-10-25 18:20 ` Linus Walleij
2016-10-25 18:20 ` Linus Walleij
2016-10-25 18:20 ` Linus Walleij
2016-10-25 18:20 ` Linus Walleij
[not found] ` <CACRpkdbGo4BJOdzkgBrE9jT-rKodd4zssCnOtOuGS+OqV-Uc6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-26 14:22 ` Jerome Brunet
2016-10-26 14:22 ` Jerome Brunet
2016-10-26 14:22 ` Jerome Brunet
2016-10-26 14:22 ` Jerome Brunet
[not found] ` <1477491766.2482.159.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-10-26 14:32 ` Linus Walleij
2016-10-26 14:32 ` Linus Walleij
2016-10-26 14:32 ` Linus Walleij
2016-10-26 14:32 ` Linus Walleij
2016-10-26 15:50 ` Kevin Hilman
2016-10-26 15:50 ` Kevin Hilman
2016-10-26 15:50 ` Kevin Hilman
2016-10-26 15:50 ` Kevin Hilman
2016-11-04 14:40 ` Linus Walleij
2016-11-04 14:40 ` Linus Walleij
2016-11-04 14:40 ` Linus Walleij
2016-11-04 14:40 ` Linus Walleij
2016-10-25 18:10 ` Linus Walleij
2016-10-25 18:10 ` Linus Walleij
2016-10-25 18:10 ` Linus Walleij
2016-10-25 18:10 ` Linus Walleij
2016-10-26 14:23 ` Jerome Brunet
2016-10-26 14:23 ` Jerome Brunet
2016-10-26 14:23 ` Jerome Brunet
2016-10-26 14:23 ` Jerome Brunet
[not found] ` <1477491816.2482.160.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2016-10-26 14:44 ` Linus Walleij
2016-10-26 14:44 ` Linus Walleij
2016-10-26 14:44 ` Linus Walleij
2016-10-26 14:44 ` Linus Walleij
2016-10-27 10:42 ` Jerome Brunet
2016-10-27 10:42 ` Jerome Brunet
2016-10-27 10:42 ` Jerome Brunet
2016-10-27 10:42 ` Jerome Brunet
2016-11-04 15:03 ` Linus Walleij
2016-11-04 15:03 ` Linus Walleij
2016-11-04 15:03 ` Linus Walleij
2016-11-04 15:03 ` Linus Walleij
[not found] ` <CACRpkdYUVXny57AC9rKX3VRAyooEk_2XLvqe9jOuT3rOaE75rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-25 10:39 ` Thomas Gleixner [this message]
2016-10-25 10:39 ` Thomas Gleixner
2016-10-25 10:39 ` Thomas Gleixner
2016-10-25 10:39 ` Thomas Gleixner
2016-10-19 10:08 ` [PATCH 5/9] dt-bindings: pinctrl: meson: update gpio dt-bindings Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` 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 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` 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 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` 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 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` [PATCH 9/9] ARM: dts: amlogic: enable gpio interrupt controller on meson8 Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` Jerome Brunet
2016-10-19 10:08 ` 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-hfztesqfncyowbw4kg4ksq@public.gmane.org \
--cc=carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
--cc=jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
--cc=khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
--cc=linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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.