Suspend and Resume traces

[Sean McNeil]

Hi Andy,

I just thought of something....

If there are critical things that need to get turned on when a resume 
interrupt happens, then why not do them in the interrupt handler? I am 
not all that familiar with how the system wakes up on resume but the 
pcf50633 handles the interrupt that causes the system to wake up, right? 
Use the resume call for things that can be deferred, but do critical 
parts in the irq itself.

Andy Green wrote:
> Somebody in the thread at some point said:
> | Am I missing something in pcf50633.c as I can't see where the interrupt
> | mask is restored on resume. I only see the resumers gettting set in
> | suspend:
> |
> |    __reg_write(pcf, PCF50633_REG_INT1M, ~pcf->pdata->resumers[0]);
> |    __reg_write(pcf, PCF50633_REG_INT2M, ~pcf->pdata->resumers[1]);
> |    __reg_write(pcf, PCF50633_REG_INT3M, ~pcf->pdata->resumers[2]);
> |    __reg_write(pcf, PCF50633_REG_INT4M, ~pcf->pdata->resumers[3]);
> |    __reg_write(pcf, PCF50633_REG_INT5M, ~pcf->pdata->resumers[4]);
>
> Hi Sean -
>
> The reset interrupt masks of "everything unmasked" is what we wanted, so
> I removed it as an optimization to speed resume.  But now I check the
> datasheet I see it only gets reset on NoPower state, so this was a
> mistake on my part :-(
>
> I have several patches not up on andy yet that further reduce resume
> time a bit (optimize RTC code) but now I am dead stuck with trying to
> explain why deferring the interrupt service until pcf50633 is resumed
> kills resume stone dead, but letting it get serviced before then gives
> us a clean resume.  Clearly this is the heart of the various config /
> power-related resume races but I didn't figure it out yet, hard to debug
> stuff in early resume.
>
> -Andy