On Fri, 26 Aug 2011, Geert Uytterhoeven wrote:
- [PATCH 18/24]: m68k/mac: Optimize interrupts using chain handlers (NEW)
That patch has a mistake --
irq_set_chained_handler(IRQ_AUTO_4, psc_irq);
irq_set_handler_data(IRQ_AUTO_3, (void *)0x40);
irq_set_chained_handler(IRQ_AUTO_5, psc_irq);
irq_set_handler_data(IRQ_AUTO_3, (void *)0x50);
irq_set_chained_handler(IRQ_AUTO_6, psc_irq);
irq_set_handler_data(IRQ_AUTO_3, (void *)0x60);
should be
irq_set_chained_handler(IRQ_AUTO_4, psc_irq);
irq_set_handler_data(IRQ_AUTO_4, (void *)0x40);
irq_set_chained_handler(IRQ_AUTO_5, psc_irq);
irq_set_handler_data(IRQ_AUTO_5, (void *)0x50);
irq_set_chained_handler(IRQ_AUTO_6, psc_irq);
irq_set_handler_data(IRQ_AUTO_6, (void *)0x60);
I also found that the mac_esp driver probe (when in PIO mode) locks up the
machine. I worked around this by changing the
disable_irq(IRQ_VIA2_3)/enable_irq(IRQ_VIA2_3) calls to
local_irq_save/local_irq_restore, but this is not a good solution.
Apparently genirq doesn't permit nested disable_irq/enable_irq calls. But
I haven't found any outer disable_irq/enable_irq pair yet, so I'm only
guessing as to the cause of the problem. I'll keep looking.
On one VIA-based machine that I tested, !CONFIG_USE_GENERIC_HARDIRQS
gives:
# cat /proc/interrupts
auto 1: 2299 via1
auto 2: 3876 via2
auto 4: 562 SCC
auto 7: 0 NMI
mac 10: 590 pmu-shift
mac 12: 90 pmu-clock
mac 14: 1635 timer
mac 17: 3876 nubus
mac 56: 3879 sonic
whereas, CONFIG_USE_GENERIC_HARDIRQS=y gives:
# cat /proc/interrupts
CPU0
4: 5303 auto SCC
7: 0 auto NMI
10: 2136 mac pmu-shift
12: 607 mac pmu-clock
14: 41858 mac timer
56: 66876 mac sonic
ERR: 0
Are there no counters for chained IRQs?
Other than these issues everything looks OK. I will test OSS and Baboon
when I get the relevant hardware set up.
Finn
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
