All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	machael-QKn5cuLxLXY@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 1/9] ARM: Kirkwood: Add interrupt controller support for DT boards
Date: Thu, 14 Jun 2012 11:55:56 +0000	[thread overview]
Message-ID: <201206141155.56289.arnd@arndb.de> (raw)
In-Reply-To: <20120614091858.GD4799-g2DYL2Zd6BY@public.gmane.org>

On Thursday 14 June 2012, Andrew Lunn wrote:
> > I think if you compute the number of interrupts in the domain from the number of
> > registers that are described in the device tree, call orion_irq_init()
> > based on those registers, and use irq domains for the gpio stuff as Rob suggested,
> > this init_irq function can become completely generic to all orion platforms.
> 
> I'm reworking the GPIO stuff at the moment, moving it to use IRQ
> domains for its interrupts. That code will be generic to all Orion
> platforms. I'm modeling the code on the AT91 GPIO handler, since that
> has a similar structure, one hardware interrupt for a number of GPIO
> lines, which is in software demultiplexed and triggers secondary level
> interrupts. The major difference is that AT91 has one hardware
> interrupt for a GPIO chip with 32 lines, where as Orion has 4 hardware
> interrupt lines, so maybe four interrupt domains, for one GPIO chip
> with 32 lines.

My guess is that you're still better off with a single interrupt domain
for 32 lines, or even for all the gpio lines, but I'm sure you can
find a solution that works best for you.

> Non-GPIO interrupts are more of a problem. Underneath it uses the
> generic-chip interrupt code. The patchset to add _domain versions of
> these calls is stalled. So i think for the moment, we need to stay
> with the domain bolted on top, until generic-chip gets domain
> support. I would also expect that generic-chip also gets a common DT
> binding which any SoC can use.

I suggested that before, and the comments I got back then were that
we should treat the generic irq chip more like a library and keep
the device tree binding at a higher level. If I understood things right,
that means we would just have one plat-orion (or mach-mvebu later)
irq chip abstraction that handles the DT binding and the irq domains
itself but uses the generic irq chip code to implement the actual
irq handling.

> My aim at the moment is to get something which works well enough that
> we can add DT support to other drivers. Without interrupts, we are not
> going to get very far. We can later rip it out what i create now and
> replace it once generic-chip becomes domain and DT aware, and there
> should be no effect on other drivers.

Right. I just want to ensure that we don't need to change the bindings
in incompatible ways.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/9] ARM: Kirkwood: Add interrupt controller support for DT boards
Date: Thu, 14 Jun 2012 11:55:56 +0000	[thread overview]
Message-ID: <201206141155.56289.arnd@arndb.de> (raw)
In-Reply-To: <20120614091858.GD4799@lunn.ch>

On Thursday 14 June 2012, Andrew Lunn wrote:
> > I think if you compute the number of interrupts in the domain from the number of
> > registers that are described in the device tree, call orion_irq_init()
> > based on those registers, and use irq domains for the gpio stuff as Rob suggested,
> > this init_irq function can become completely generic to all orion platforms.
> 
> I'm reworking the GPIO stuff at the moment, moving it to use IRQ
> domains for its interrupts. That code will be generic to all Orion
> platforms. I'm modeling the code on the AT91 GPIO handler, since that
> has a similar structure, one hardware interrupt for a number of GPIO
> lines, which is in software demultiplexed and triggers secondary level
> interrupts. The major difference is that AT91 has one hardware
> interrupt for a GPIO chip with 32 lines, where as Orion has 4 hardware
> interrupt lines, so maybe four interrupt domains, for one GPIO chip
> with 32 lines.

My guess is that you're still better off with a single interrupt domain
for 32 lines, or even for all the gpio lines, but I'm sure you can
find a solution that works best for you.

> Non-GPIO interrupts are more of a problem. Underneath it uses the
> generic-chip interrupt code. The patchset to add _domain versions of
> these calls is stalled. So i think for the moment, we need to stay
> with the domain bolted on top, until generic-chip gets domain
> support. I would also expect that generic-chip also gets a common DT
> binding which any SoC can use.

I suggested that before, and the comments I got back then were that
we should treat the generic irq chip more like a library and keep
the device tree binding at a higher level. If I understood things right,
that means we would just have one plat-orion (or mach-mvebu later)
irq chip abstraction that handles the DT binding and the irq domains
itself but uses the generic irq chip code to implement the actual
irq handling.

> My aim at the moment is to get something which works well enough that
> we can add DT support to other drivers. Without interrupts, we are not
> going to get very far. We can later rip it out what i create now and
> replace it once generic-chip becomes domain and DT aware, and there
> should be no effect on other drivers.

Right. I just want to ensure that we don't need to change the bindings
in incompatible ways.

	Arnd

  parent reply	other threads:[~2012-06-14 11:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-10 10:31 [PATCH 1/9] ARM: Kirkwood: Add interrupt controller support for DT boards Andrew Lunn
2012-06-10 10:31 ` Andrew Lunn
     [not found] ` <1339324322-29388-2-git-send-email-andrew-g2DYL2Zd6BY@public.gmane.org>
2012-06-10 16:48   ` Jason Cooper
2012-06-10 16:48     ` Jason Cooper
2012-06-10 21:21   ` Michael Walle
2012-06-10 21:21     ` Michael Walle
2012-06-11 12:49   ` Rob Herring
2012-06-11 12:49     ` Rob Herring
2012-06-14  8:12   ` Arnd Bergmann
2012-06-14  8:12     ` Arnd Bergmann
     [not found]     ` <201206140812.34399.arnd-r2nGTMty4D4@public.gmane.org>
2012-06-14  9:18       ` Andrew Lunn
2012-06-14  9:18         ` Andrew Lunn
     [not found]         ` <20120614091858.GD4799-g2DYL2Zd6BY@public.gmane.org>
2012-06-14 11:55           ` Arnd Bergmann [this message]
2012-06-14 11:55             ` Arnd Bergmann

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=201206141155.56289.arnd@arndb.de \
    --to=arnd-r2ngtmty4d4@public.gmane.org \
    --cc=andrew-g2DYL2Zd6BY@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=machael-QKn5cuLxLXY@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@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 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.