From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Thomas Abraham <thomas.abraham-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: devicetree-discuss
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
linux-samsung-soc
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: Device node for a controller with two interrupt parents
Date: Sat, 24 Mar 2012 19:07:49 +0000 [thread overview]
Message-ID: <20120324190749.CA6F73E0AE2@localhost> (raw)
In-Reply-To: <CAJuYYwQapeMthSxSgpaJ5fQNQnyvducgGyi-75WrjZut6akh+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5490 bytes --]
On Fri, 23 Mar 2012 16:18:09 +0530, Thomas Abraham <thomas.abraham-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Grant,
>
> On 21 March 2012 20:43, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> > Okay, so you're saying there are three important aspects to this
> > device:
> > 1) it terminates interrupts from other devices (therefore needs an
> > Â interrupt controller driver)
> > 2) it passes some interrupts through untouched (interrupt controller
> > Â driver doesn't need to touch them; it directly raises an irq on the
> > Â gic or combiner)
> > 3) It is able generate interrupt signals on it's own (independent of
> > Â any attached devices)
> >
> > Do I understand correctly?
>
> #1 is applicable but not #2 and #3 (if I have interpreted the above
> correctly). The wakeup interrupt controller looks for an edge or level
> on pins (which are connected to external devices) and generates a
> interrupt (to gic or combiner) when the set condition on that pin is
> found (edge or level).
>
> >
> > Your patch above solves the problem for #2 above, but it breaks #1
> > because interrupts from external devices can no longer be terminated
> > on the wakeup controller node (they'll always get passed through).
>
> Ok.
>
> >
> > --- Possible solution 1 ---
> > If other devices *don't* use the wakeup node as their interrupt
> > parent, then you should be able to simply drop the
> > interrupt-controller property and make the other devices directly
> > reference the gic and combiner.
>
> Other devices use wakeup node as interrupt controller. The wakeup
> interrupt controller supports masking, unmasking and prioritization of
> the wakeup interrupts. The interrupt-controller property can be
> dropped but then of_irq_init() function cannot be used.
>
> >
> > --- Possible solution 2 ---
> > Split the interrupt map into a separate node:
> >
> >
> > Â Â Â Â wakeup_eint: interrupt-controller@11000000 {
> > Â Â Â Â Â Â Â Â compatible = "samsung,exynos4210-wakeup-eint";
> > Â Â Â Â Â Â Â Â reg = <0x11000000 0x1000>;
> > Â Â Â Â Â Â Â Â interrupt-controller;
> > Â Â Â Â Â Â Â Â #interrupt-cells = <1>;
> > Â Â Â Â Â Â Â Â interrupt-parent = <&wakeup_map>;
> > Â Â Â Â Â Â Â Â interrupts = <0 1 2 3 f 5 6 7 8 9 10 11 12 13 14 15 16>;
> >
> > Â Â Â Â Â Â Â Â wakeup_map: interrupt-map {
> > Â Â Â Â Â Â Â Â Â Â Â Â #interrupt-cells = <1>;
> > Â Â Â Â Â Â Â Â Â Â Â Â #address-cells = <0>;
> > Â Â Â Â Â Â Â Â Â Â Â Â interrupt-map = <0 &gic 0 16 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <1 &gic 0 17 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <2 &gic 0 18 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <3 &gic 0 19 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <4 &gic 0 20 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <5 &gic 0 21 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <6 &gic 0 22 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <7 &gic 0 23 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <8 &gic 0 24 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <9 &gic 0 25 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <10 &gic 0 26 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <11 &gic 0 27 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <12 &gic 0 28 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <13 &gic 0 29 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <14 &gic 0 30 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <15 &gic 0 31 0>,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <16 &combiner 2 4>;
> > Â Â Â Â Â Â Â Â };
> > Â Â Â Â };
>
> I have tested with this and it works but of_irq_init() function cannot
> be used because 'wakeup_map' is set as interrupt parent and
> 'wakeup_map' is not a interrupt-controller. So of_irq_init() does not
> invoke the initialization function for the wakeup node. If the machine
> init code explicitly looks for this node and calls the corresponding
> initialization function, it works fine.
That's a bug in of_irq_init() then. It should be fixed.
>
> >
> > --- possible solution 3 ---
> > 'interrupts' just isn't sufficient for some devices; add a binding for
> > a 'interrupts-multiparent' that can be used instead of 'interrupts'
> > and uses the format <phandle> <specifier> [<phandle> <specifier> [...]].
>
> This would be the ideal case. In addition to this, the
> interrupt-parent property handling should be modified to support
> multiple parent phandles like <&parent1 [&parent2] [&parent3] ....>.
> This will be useful to extend the capability of of_irq_init() to
> handle interrupt-controller node with multiple interrupt parents.
>
> >
> > I'm not opposed to this solution since it is a more natural binding
> > for multiparented interrupt controllers, but I won't commit to it
> > without feedback and agreement from Mitch, Ben, David Gibson, etc.
>
> Ok. For now, I will go ahead and use solution #2 which you and David
> have suggested. And correspondingly add explicit lookup of wakeup node
> and call to its initialization function in the machine init code.
I'd really prefer a fix to of_irq_init() instead of hacking around it.
g.
[-- Attachment #2: Type: text/plain, Size: 192 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
next prev parent reply other threads:[~2012-03-24 19:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-21 2:25 Device node for a controller with two interrupt parents Thomas Abraham
2012-03-21 3:41 ` David Gibson
2012-03-21 13:35 ` Thomas Abraham
2012-03-21 15:13 ` Grant Likely
2012-03-23 10:48 ` Thomas Abraham
[not found] ` <CAJuYYwQapeMthSxSgpaJ5fQNQnyvducgGyi-75WrjZut6akh+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-24 19:07 ` Grant Likely [this message]
2012-03-25 12:17 ` Thomas Abraham
2012-03-25 12:38 ` [PATCH] of/irq: of_irq_init: Call initialization function for all controllers Thomas Abraham
2012-03-25 15:20 ` Rob Herring
2012-03-25 16:16 ` Thomas Abraham
2012-03-26 13:04 ` Rob Herring
2012-03-26 15:36 ` Thomas Abraham
2012-03-28 6:02 ` Thomas Abraham
2012-03-22 1:05 ` Device node for a controller with two interrupt parents David Gibson
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=20120324190749.CA6F73E0AE2@localhost \
--to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=thomas.abraham-QSEj5FYQhm4dnm+yROfE0A@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 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).