Re: [patch 2.6.27-rc5-omap1] rtc-twl4030 cleanup

[David Brownell <david-b@pacbell.net>]

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@ti.com>

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