From: tglx@linutronix.de (Thomas Gleixner)
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 17:22:05 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.10.1408271657310.3323@nanos> (raw)
In-Reply-To: <20140827142935.GA9490@leverpostej>
On Wed, 27 Aug 2014, Mark Rutland wrote:
> On Wed, Aug 27, 2014 at 02:37:44PM +0100, Marc Zyngier wrote:
> > We need to work out how to drive the whole stacking from a DT
> > perspective: Mark, any idea?
>
> Describing the lines the magic irqchip has to its parent irqchip is
> simple, the standard interrupts property can handle that:
>
> parent: parent {
> ...
> #interrupt-cells = <1>;
> };
>
> magic {
> ...
> interrupt-parent = <&parent>;
> interrupts = <3>, <6>, <17>, <2>;
> #interrupt-cells = <1>;
> };
>
> The harder part is describing the configuration of each interrupt to the
> magic irqchip (e.g. edge vs level triggered), which is inseparable form
> the line identifier in the interrupt-specifier.
Do we really need to decribe that at the this level?
You have the parent ARMGIC and the maGIC with a specified (or even
dynamic) routing of the maGIC lines to the ARMGIC.
Now the device which uses a maGIC interrupt specifies the interrupt
type at the maGIC.
So the type setter function of the maGIC configures the maGIC hardware
in such a way that the output to the ARMGIC results in a type which
the ARMGIC can handle and calls the type setter function of the maGIC
with that type.
I don't think you need to decribe this in the magic/parent relation
ship at all. maGIC should know what kind of output it can provide to
ARMGIC so that should just work, unless I'm missing something.
> If there interrupts don't share the same configuration then I'm not sure
> how we describe that in the DT. That's especially problematic if the
> assignment of parent line is dynamic (as with the crossbar iirc).
Why is this an issue?
There are two ways to solve that:
1) You can do a fully dynamic allocation at the parent level, which of
course requires that the whole parent range is dynamically
managed. That's what we are planning for the MSI/Remap/Vector
stacking
2) You define the irq lines at the parent which are available for
dynamic stacking and let the allocation code hand one out.
3) You tell the maGIC controller which lines of the parent are
available for it, so it can only stack onto those lines and instead
of letting the parent allocate a free one, the maGIC needs to map
its stuff to one of those ARMGIC lines.
Which one to chose depends on the particular maGIC incarnation, but
its not a big issue to select one ...
Thanks,
tglx
next prev parent reply other threads:[~2014-08-27 15:22 UTC|newest]
Thread overview: 17+ 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 ` [RESEND PATCH v2 1/4] irqchip: gic: Change irq type check when extension is present Joe.C
2014-08-22 11:09 ` Marc Zyngier
2014-08-23 5:28 ` Joe.C
2014-08-27 9:55 ` Jan Lübbe
2014-08-27 10:36 ` Marc Zyngier
2014-08-27 12:23 ` Thomas Gleixner
2014-08-27 13:37 ` Marc Zyngier
2014-08-27 14:03 ` Thomas Gleixner
2014-08-27 14:29 ` Mark Rutland
2014-08-27 15:22 ` Thomas Gleixner [this message]
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 ` [RESEND PATCH v2 3/4] arm: mediatek: Add intpol in mt6589.dtsi Joe.C
2014-08-13 2:11 ` [RESEND PATCH v2 4/4] dt-bindings: add bindings for mediatek intpol Joe.C
2014-08-21 15:02 ` Matthias Brugger
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
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.10.1408271657310.3323@nanos \
--to=tglx@linutronix.de \
--cc=linux-arm-kernel@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