Messages in this thread | | | Date | Sun, 28 Aug 2011 12:08:11 +1000 (EST) | From | Finn Thain <> | Subject | Re: m68k: [v5] Convert to genirq (WIP) |
| |
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
| |