Date:	Sun, 09 Dec 2012 14:06:48 +0100
From:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
CC:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Jason Cooper <jason@...edaemon.net>,
	Arnd Bergmann <arnd@...db.de>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the
 timer

On 12/09/2012 09:30 AM, Andrew Lunn wrote:
> On Sat, Dec 08, 2012 at 07:57:48PM -0700, Jason Gunthorpe wrote:
>> On Sat, Dec 08, 2012 at 12:26:24PM +0100, Andrew Lunn wrote:
>>
>>> 1) It should have an IRQ domain, like the other IRQ chips we have.
>>> 2) It should have a DT binding, like the other IRQ chips we have.
>>
>> I was going to look at a DT binding for this as a follow on, since
>> I'll want to bind to these interrupts.
>>
>> Are you OK with keeping this patch as is and seeing DT in a follow up,
>> or as a series? It is already pretty big.
>
> Hi Jason
>
> A patch series is great. However, its not so good practice to add
> something on the first patch, and then move it somewhere else in the
> next. So i would suggest initializing the controller in
> kirkwood_irq_init(), etc as its added.

Hi Andrew, Jason,

first of all I have adjusted the Cc list a little bit: Gregory is missing,
and I removed Mike and Olof as they might not be that interested in discussing
mvebu internals. Please re-add if I am wrong.

I have an irqchip driver for orion that I wrote some weeks ago. I can
prepare a patch today. I will allow to have main irq controller by DT
and I can also add a secondary irq controller for the bridge registers
as chained irq handler.

If I dig hard enough in my branches I will also find time-orion drivers,
that are either "standalone" (i.e. orion only) or merged with time-mvebu.

The main irq controller will be required for sure, but for the secondary
irq controller we had a discussion long ago. IIRC Gregory proposed to have
shared irqs handled by timer and watchdog, I was proposing chained irqs.

For mvebu archs, IIRC, we have wrt to timer-related irqs:
- Armada 370/XP with different irq handler and timer irq handling within
   timer registers.
- Orion SoCs with Bridge irq registers for timer related stuff (timer0/1)
- Kirkwood and Dove with watchdog timers (both with wdt irq in bridge irqs)
- RTC in bridge irqs, but Dove with RTC connected to PMU irqs

I think we should have patches for irqchip-orion first and then rethink
if we want a standalone timer-orion or merge it with timer-mvebu. Having
watchdog using irqs is kind of independent from this.

> ...
>>> 3) We then pass the timer interrupt via DT to the timer driver.
>>> 3) is not so simple, because we currently don't have a timer binding
>>> for Orion SoC. However, with this cleanup, we are much closer to being
>>> able to use the 370/XP timer code.
>>
>> Interesting.. The 370/XP is a more advanced version of the same timer
>> IP, there are several registers that driver is touching that are not
>> HW supported, at least on kirkwood.
>
> Yes, the 25MHz and the divider for example. I'm not 100% sure it will
> actually work, it will need a different compatibility string, and a
> bit of configuration based on that string, but i think it goes. If you
> compare the two different drivers, they are very similar.

Back in the days when Gregory, Thomas, and I were looking into merged timer
we agreed not to have an extra check on 25MHz support. If you put the
property in the node, it will try to set the timer to fixed 25MHz. If you
use the property on Orion timer, it will just break timer handling.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists