On 31/08/2016 01:28, Alexandre Belloni wrote: > Hi, > > On 25/08/2016 at 16:54:18 +0200, Gabriele Mazzotta wrote : >> Hi, >> >> were you able to verify that no other driver is affect? >> > > I had a closer look at the issue. I think what is happening is that you > don't enter the do/while loop in cmos_resume twice. That is supposed to > handle then clear the RTC_AIE bit and that is why the alarm still seems > enabled. > > Can you add some tracing there to understand why? It is probably also > useful to know the value of cmos->suspend_ctrl in cmos_suspend.
cmos->suspend_ctrl is 0x2 when no alarm is set, 0x22 otherwise. The only way to clear RTC_AIE is to set an alarm and wait for it to expire while the system is awake. > My guess is that is_intr(mask) is false and you break out of the loop at > the first pass, meaning that the RTC_AIE bit is never cleared from > RTC_CONTROL. That would also mean that your RTC is not setting RTC_AF > after waking your PC. Am I right? You are right, is_intr(mask) is false and now I see where the problem is. I thought cmos_interrupt() was taking care of everything, but I've just noticed that it's executed only when the system is awake. That's because cmos->wake_on is not NULL, so enable_irq_wake() is not called. However, not even rtc_handler() is called, so I guess the BIOS silently wakes the system when an alarm expires while suspended. This means that we can't update RTC_CONTROL from rtc_handler() and that we have to do it from cmos_resume(). There's a problem with this. We don't know whether the system is waking up because of an alarm or because the user resumed it. In both cases RTC_AIE is set. One way to solve this problem is to manually check from cmos_resume() if any alarm expired while suspended. If we find such an alarm, we don't break early out of the loop and let it clear the flags. Is this reasonable? > Regards, >
