Re: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of thetimer

[Sebastian Hesselbarth]

On 06/04/13 19:26, Jason Gunthorpe wrote:
> 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.

Jason,

I have irqchip and clocksource drivers done for Orion, just need to
find some time to rebase them.

> > 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 suggest not to merge clocksource for Orion and Armada 370/XP. They
are different enough to justify separate drivers. IIRC Armada 370/XP
acks timer interrupts by clearing timer register bits that are not
implemented in Orion SoCs.

> 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

I'd rather have irqchip and clocksource mainlined and enable both
drivers when they have surfaced. I try to sent patches by end of this week.

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

We could have a single clocksource driver but as said above,
clocksource is a tiny driver compared to others. Separate drivers will
save us from checking SoC on every timer event or have a callback for 
Armada 370/XP clearing timer irqs.

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