All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Mark Rutland" <Mark.Rutland@arm.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"yingjoe.chen@gmail.com" <yingjoe.chen@gmail.com>,
	"Jason Cooper" <jason@lakedaemon.net>,
	"Russell King" <linux@arm.linux.org.uk>,
	"Pawel Moll" <Pawel.Moll@arm.com>,
	"Joe.C" <srv_yingjoe.chen@mediatek.com>,
	"yh.chen@mediatek.com" <yh.chen@mediatek.com>,
	"nathan.chung@mediatek.com" <nathan.chung@mediatek.com>
Subject: Re: [RESEND PATCH v2 1/4] irqchip: gic: Change irq type check when extension is present
Date: Wed, 27 Aug 2014 14:37:44 +0100	[thread overview]
Message-ID: <87ppfmoxxz.fsf@approximate.cambridge.arm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1408271347210.3323@nanos> (Thomas Gleixner's message of "Wed, 27 Aug 2014 13:23:48 +0100")

[Adding Jiang Liu to the spam-fest]

Hi Thomas,

On Wed, Aug 27 2014 at  1:23:48 pm BST, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 27 Aug 2014, Marc Zyngier wrote:
>> > As in the DT the actual IRQ polarity should be used, simply configuring
>> > the HW IRQ polarity in the bootloader is not enough without telling the
>> > GIC driver which polarity is supported on which IRQ, right?
>> 
>> Looking a bit closer at things, what you describe in DT is the IRQ
>> polarity the interrupt controller sees. Nothing else should interpret
>> that field.
>> 
>> So it is legal (IMO) to have a device with an interrupt specifier
>> describing a rising edge interrupt, and yet have the device generating a
>> falling edge, with Mediatek's special sauce doing the conversion in between.
>> 
>> Something will have to configure the polarity widget though, but that
>> can be left outside of the GIC.
>
> This seems to become a popular topic and it looks like the whole GIC
> extension thing is going to explode sooner than later.
>
> We are currently discussing hierarchical irq domains to solve a
> different issue in x86 land. See the related discussion here:
>
> 	  https://lkml.org/lkml/2014/8/1/67

Ah, very interesting. Thanks for pointing that out.

> Now looking at these GIC plus extra sauce problems, I wonder whether
> this wouldn't be solvable in a similar way. If you look at it from the
> HW perspective you have:
>
>    ---------      ---------
> ---| MAGIC |------|ARM GIC|
> ---|       |------|       |
> ---|       |------|       |
> ---|       |------|       |
> ---|       |------|       |
>    ---------      ---------
>
> The MAGIC interrupt controller only provides functionality which is
> not available from the ARM architected GIC but maps 1:1 to the ARM GIC
> interrupt lines. So it looks like a variation to the more dynamic
> mapping of MSI -> Remap -> CPU-Vector problem we need to solve on x86.
>
> The idea is to have two irq domains: magic_domain and armgic_domain.
>
> The magic_domain is the frontend facing the devices and the
> armgic_domain is the parent domain. This is also reflected in
> hierarchical data structures, i.e. irq_desc->irq_data will get a new
> field parent_data, which points to the irq_data of the parent
> interrupt controller, which is allocated separately when the interrupt
> line is instantiated.
>
> So in the above case the hotpath ack/eoi functions of the irq chip
> associated to the device interrupt, i.e. magic_chip, would do:
>
> irq_ack(struct irq_data *d)
> {
> 	struct irq_data *pd = d->parent_data;
>
> 	pd->chip->irq_ack(pd);
> }
>
> Granted, that's another level of indirection, but this is going to be
> more efficient than a boatload of conditional hooks in the GIC code
> proper. Not to talk about the maintainability of the whole maze.
>
> The irq_set_type() function would do:
>
> irq_set_type(struct irq_data *d, int type)
> {
> 	struct irq_data *pd = d->parent_data;
>
> 	gic_type = set_magic_chip_type(d, type);
>
> 	return pd->chip->irq_set_type(d, gic_type);
> }
>
> Switching to this allows to completely avoid the gazillion of hooks in
> the gic code and should work nicely with multiplatform kernels by
> simpling hooking up the domain parent relation ship to the proper
> magic domain or leave the armgic as the direct device interface in
> case the SoC does not have the magic chip in front of the arm gic.
>
> Thoughts?

I very much like that kind of approach. Stacking domains seems to solve
a number of issues at once:

- NVIDIA's gic extension
- TI's crossbar
- ARM's GICv2m
- Mediatek's glorified line inverter
- ... and probably the next madness that's going to land tomorrow

I haven't completly groked the way we're going to allocate domains and
irq_data structures, but this is definitely something worth
investigating. I'm not too worried about the indirection either - at
least we end up with maintainable code.

We need to work out how to drive the whole stacking from a DT
perspective: Mark, any idea?

Jiang, would you mind keeping us ARM folks posted when you resend your
patch series? That'd be much appreciated.

In the meantime, I'll furbish an axe and aim it squarely at the GIC
code... ;-)

Thanks again,

	M.
-- 
Jazz is not dead. It just smells funny.

WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH v2 1/4] irqchip: gic: Change irq type check when extension is present
Date: Wed, 27 Aug 2014 14:37:44 +0100	[thread overview]
Message-ID: <87ppfmoxxz.fsf@approximate.cambridge.arm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1408271347210.3323@nanos> (Thomas Gleixner's message of "Wed, 27 Aug 2014 13:23:48 +0100")

[Adding Jiang Liu to the spam-fest]

Hi Thomas,

On Wed, Aug 27 2014 at  1:23:48 pm BST, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 27 Aug 2014, Marc Zyngier wrote:
>> > As in the DT the actual IRQ polarity should be used, simply configuring
>> > the HW IRQ polarity in the bootloader is not enough without telling the
>> > GIC driver which polarity is supported on which IRQ, right?
>> 
>> Looking a bit closer at things, what you describe in DT is the IRQ
>> polarity the interrupt controller sees. Nothing else should interpret
>> that field.
>> 
>> So it is legal (IMO) to have a device with an interrupt specifier
>> describing a rising edge interrupt, and yet have the device generating a
>> falling edge, with Mediatek's special sauce doing the conversion in between.
>> 
>> Something will have to configure the polarity widget though, but that
>> can be left outside of the GIC.
>
> This seems to become a popular topic and it looks like the whole GIC
> extension thing is going to explode sooner than later.
>
> We are currently discussing hierarchical irq domains to solve a
> different issue in x86 land. See the related discussion here:
>
> 	  https://lkml.org/lkml/2014/8/1/67

Ah, very interesting. Thanks for pointing that out.

> Now looking at these GIC plus extra sauce problems, I wonder whether
> this wouldn't be solvable in a similar way. If you look at it from the
> HW perspective you have:
>
>    ---------      ---------
> ---| MAGIC |------|ARM GIC|
> ---|       |------|       |
> ---|       |------|       |
> ---|       |------|       |
> ---|       |------|       |
>    ---------      ---------
>
> The MAGIC interrupt controller only provides functionality which is
> not available from the ARM architected GIC but maps 1:1 to the ARM GIC
> interrupt lines. So it looks like a variation to the more dynamic
> mapping of MSI -> Remap -> CPU-Vector problem we need to solve on x86.
>
> The idea is to have two irq domains: magic_domain and armgic_domain.
>
> The magic_domain is the frontend facing the devices and the
> armgic_domain is the parent domain. This is also reflected in
> hierarchical data structures, i.e. irq_desc->irq_data will get a new
> field parent_data, which points to the irq_data of the parent
> interrupt controller, which is allocated separately when the interrupt
> line is instantiated.
>
> So in the above case the hotpath ack/eoi functions of the irq chip
> associated to the device interrupt, i.e. magic_chip, would do:
>
> irq_ack(struct irq_data *d)
> {
> 	struct irq_data *pd = d->parent_data;
>
> 	pd->chip->irq_ack(pd);
> }
>
> Granted, that's another level of indirection, but this is going to be
> more efficient than a boatload of conditional hooks in the GIC code
> proper. Not to talk about the maintainability of the whole maze.
>
> The irq_set_type() function would do:
>
> irq_set_type(struct irq_data *d, int type)
> {
> 	struct irq_data *pd = d->parent_data;
>
> 	gic_type = set_magic_chip_type(d, type);
>
> 	return pd->chip->irq_set_type(d, gic_type);
> }
>
> Switching to this allows to completely avoid the gazillion of hooks in
> the gic code and should work nicely with multiplatform kernels by
> simpling hooking up the domain parent relation ship to the proper
> magic domain or leave the armgic as the direct device interface in
> case the SoC does not have the magic chip in front of the arm gic.
>
> Thoughts?

I very much like that kind of approach. Stacking domains seems to solve
a number of issues at once:

- NVIDIA's gic extension
- TI's crossbar
- ARM's GICv2m
- Mediatek's glorified line inverter
- ... and probably the next madness that's going to land tomorrow

I haven't completly groked the way we're going to allocate domains and
irq_data structures, but this is definitely something worth
investigating. I'm not too worried about the indirection either - at
least we end up with maintainable code.

We need to work out how to drive the whole stacking from a DT
perspective: Mark, any idea?

Jiang, would you mind keeping us ARM folks posted when you resend your
patch series? That'd be much appreciated.

In the meantime, I'll furbish an axe and aim it squarely at the GIC
code... ;-)

Thanks again,

	M.
-- 
Jazz is not dead. It just smells funny.

  reply	other threads:[~2014-08-27 13:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13  2:11 [RESEND PATCH v2 0/4] arm: mediatek: Add support for GIC interrupt polarity extension Joe.C
2014-08-13  2:11 ` Joe.C
2014-08-13  2:11 ` [RESEND PATCH v2 1/4] irqchip: gic: Change irq type check when extension is present Joe.C
2014-08-13  2:11   ` Joe.C
2014-08-22 11:09   ` Marc Zyngier
2014-08-22 11:09     ` Marc Zyngier
2014-08-22 11:09     ` Marc Zyngier
2014-08-23  5:28     ` Joe.C
2014-08-23  5:28       ` Joe.C
2014-08-27  9:55     ` Jan Lübbe
2014-08-27  9:55       ` Jan Lübbe
2014-08-27  9:55       ` Jan Lübbe
2014-08-27 10:36       ` Marc Zyngier
2014-08-27 10:36         ` Marc Zyngier
2014-08-27 10:36         ` Marc Zyngier
2014-08-27 12:23         ` Thomas Gleixner
2014-08-27 12:23           ` Thomas Gleixner
2014-08-27 12:23           ` Thomas Gleixner
2014-08-27 13:37           ` Marc Zyngier [this message]
2014-08-27 13:37             ` Marc Zyngier
2014-08-27 14:03             ` Thomas Gleixner
2014-08-27 14:03               ` Thomas Gleixner
2014-08-27 14:03               ` Thomas Gleixner
2014-08-27 14:29             ` Mark Rutland
2014-08-27 14:29               ` Mark Rutland
2014-08-27 14:29               ` Mark Rutland
2014-08-27 15:22               ` Thomas Gleixner
2014-08-27 15:22                 ` Thomas Gleixner
2014-08-27 15:22                 ` Thomas Gleixner
2014-08-13  2:11 ` [RESEND PATCH v2 2/4] arm: mediatek: Add support for GIC interrupt polarity extension Joe.C
2014-08-13  2:11   ` Joe.C
2014-08-13  2:11 ` [RESEND PATCH v2 3/4] arm: mediatek: Add intpol in mt6589.dtsi Joe.C
2014-08-13  2:11   ` Joe.C
2014-08-13  2:11 ` [RESEND PATCH v2 4/4] dt-bindings: add bindings for mediatek intpol Joe.C
2014-08-13  2:11   ` Joe.C
2014-08-21 15:02   ` Matthias Brugger
2014-08-21 15:02     ` Matthias Brugger
2014-08-21 15:02     ` Matthias Brugger
2014-08-22  8:39     ` Joe.C
2014-08-22  8:39       ` Joe.C
2014-08-22  9:23 ` [RESEND PATCH v2 0/4] arm: mediatek: Add support for GIC interrupt polarity extension Joe.C
2014-08-22  9:23   ` Joe.C

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=87ppfmoxxz.fsf@approximate.cambridge.arm.com \
    --to=marc.zyngier@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Pawel.Moll@arm.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nathan.chung@mediatek.com \
    --cc=srv_yingjoe.chen@mediatek.com \
    --cc=tglx@linutronix.de \
    --cc=yh.chen@mediatek.com \
    --cc=yingjoe.chen@gmail.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.