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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
