On Friday 05 September 2008, Pakaravoor, Jagadeesh wrote: > RTC generates an extra spurious interrupt for every actual periodic > interrupt. This is due to a problem with the RTC_IT bit of > REG_PWR_ISR1. It requires two writes or two reads (when COR is > enabled) to clear it. Since COR is enabled and one read of the same > register is done already (inside twl4030-pwrirq.c do_twl4030_pwrirq() > function), all we need is one more read. > > Signed-off-by: Jagadeesh Bhaskar Pakaravoor <j-pakaravoor@xxxxxx> Yes, that seems to make the 1/second update IRQs work right. Thanks! Were alarm IRQs having the same problem, just not as noticably? The two other technical issues I know about with this driver also relate to IRQs: - Is it really true that alarm and update IRQs are mutually exclusive? Unusual if so ... + if exclusive, then don't let both be enabled at the same time (the way it now does)! + else, update irq handler so the comment is correct, and so the code stops assuming it's alarm -or- update irqs ... it should be possible to report *both* events at once. - Are there any reasons alarm IRQs wouldn't be able to wake the system from sleep states (STR etc)? If not, then need to update suspend() to leave the alarm active (yes?) and do various other stuff related to driver model wakeup flags; rtc-omap.c can be an example. (Except for leaving update IRQs active...) The wakeup stuff will let programs like rtcwake work, and enable the /sys/class/rtc/rtc0/wakealarm file. It's better to have that stuff work than not, even if OMAP power management uses states like STR very differently than most other Linuxes. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html