[PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer

Jason Gunthorpe jgunthorpe at obsidianresearch.com
Tue Jun 4 13:26:38 EDT 2013


On Sun, Dec 09, 2012 at 02:06:48PM +0100, Sebastian Hesselbarth wrote:

> 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.

+1 on decoded IRQs for bridge. I've been running that configuration
now since this patch set was first posted.

There is too much HW variance, the timer, watchdog, etc drivers should
not have to poke into SOC specific registers just to get an interrupt.

The bridge decode can either be via a chained handler, or by incorporating
the bridge decode into the main kirkwood handler - the latter having
lower overhead for timer ticks.

> 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.

I would think the logical progression is:
- irq-chip orion combined with work to keep the existing timer working
- Patch to add the bridge irq-chip
- Patches to support orion/kirkwood/dove/etc in the existing timer drivers
- Patch to update the DT to switch to the bridge and updated timer
- Patch to remove the old timer

When I last looked briefly, it seems like merging with timer-mvebu was
fairly straightforward..

> 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.

As for the mveth case we should have a compatible tag for each SOC,
the driver can ignore it, but it should be in the DT for future use..

Jason



More information about the linux-arm-kernel mailing list