public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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

      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