From: heiko@sntech.de (Heiko Stübner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 7/7] irqchip: s3c24xx: add devicetree support
Date: Tue, 26 Mar 2013 08:38:42 +0100 [thread overview]
Message-ID: <201303260838.42804.heiko@sntech.de> (raw)
In-Reply-To: <201303252200.46258.arnd@arndb.de>
Hi Arnd,
thanks again for taking the time to look at the changes.
Am Montag, 25. M?rz 2013, 23:00:46 schrieb Arnd Bergmann:
> On Monday 25 March 2013, Heiko St?bner wrote:
> > Add the necessary code to initialize the interrupt controller
> > thru devicetree data using the irqchip infrastructure.
> >
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>
> The binding looks fine now. I have a few detail comments but am happy
> with the series otherwise.
>
> > +Required properties:
> > +- compatible: Compatible property value should be "samsung,s3c24xx-irq"
> > + for non s3c2416 machines and "samsung,s3c2416-irq" for s3c2416
> > machines
>
> We try to avoid wildcards in the "compatible" properties. Better use
> the name of the first SoC that had this controller, and let the other
> ones mark themselves as compatible with that one.
>
> I guess "samsung,s3c2410-irq" would be the right identifier here.
ok, sounds sensible
> > +- #interrupt-cells : Specifies the number of cells needed to encode an
> > + interrupt source. The value shall be 4 and interrupt descriptor shall
> > + have the following format:
> > + <ctrl_num ctrl_irq parent_irq type>
> > +
> > + ctrl_num contains the controller to use:
> > + - 0 ... main controller
> > + - 1 ... sub controller
> > + - 2 ... second main controller on s3c2416 and s3c2450
> > + ctrl_irq contains the interrupt bit of the controller
> > + parent_irq contains the parent bit in the main controller and will be
> > + ignored in main controllers
>
> I expected the second and third cell to be in the opposite order, so
> the meaning of the second cell is always the same.
ok, so we do <ctrl_num parent_irq ctrl_irq type>, right? ... As it only
involves exchanging the intspec values, that's easy :-)
> > + /* we're using individual domains for the non-dt case
> > + * and one big domain for the dt case where the subintc
> > + * starts at hwirq number 32.
> > + */
> > + offset = (intc->domain->of_node) ? 32 : 0;
>
> Wouldn't it be easier to always use the same setup for the domains here?
nope ... the non-dt domains are not uniform (different lengths and start-irqs)
to recreate the static irq mappings that are still needed. For the non-dt case
it also implement the handling of the external interrupts that is not part of
the interrupt-controller itself but comes from the gpio-registers and will
move to pinctrl for dt machines.
My hope is still to move to dt in a "reasonable" time, so this stuff can go
away then altogether.
Heiko
prev parent reply other threads:[~2013-03-26 7:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 21:26 [PATCH v5 0/7] move s3c24xx-irq to drivers/irqchip and add dt support Heiko Stübner
2013-03-25 21:27 ` [PATCH v5 1/7] ARM: S3C24XX: move irq driver to drivers/irqchip Heiko Stübner
2013-03-25 21:27 ` [PATCH v5 2/7] irqchip: s3c24xx: fix comments on some camera interrupts Heiko Stübner
2013-03-25 21:28 ` [PATCH v5 3/7] irqchip: s3c24xx: fix irqlist of second s3c2416 controller Heiko Stübner
2013-03-25 21:29 ` [PATCH v5 4/7] irqchip: s3c24xx: add irq_set_type callback for basic interrupt types Heiko Stübner
2013-03-25 21:31 ` [PATCH v5 5/7] irqchip: s3c24xx: globally keep track of the created intc instances Heiko Stübner
2013-03-25 21:32 ` [PATCH v5 6/7] irqchip: s3c24xx: make interrupt handling independent of irq_domain structure Heiko Stübner
2013-03-25 21:34 ` [PATCH v5 7/7] irqchip: s3c24xx: add devicetree support Heiko Stübner
2013-03-25 22:00 ` Arnd Bergmann
2013-03-26 7:38 ` Heiko Stübner [this message]
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=201303260838.42804.heiko@sntech.de \
--to=heiko@sntech.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