Sometimes failed to wakeup OMAP3630 through TPS65920 INT1

Hi Gavin,

Is this scenario like this

Scenario 1

1. Trying to suspend the device
2. Immediately press TWL button
3. System does not woke up

Or

Scenario 2

1. The system is already suspended
2. Press TWL button
3. System does not wake up

I think the issue you are observing may occur in Scenario 1 only. Otherwise see the console output with "no_console_supend" in the boot args

Isnt the power/wakelock driver suspend_late routine executed last?

Hi Arun,

You are right. We can duplicate the issue using Scenario 1. I don't know what you mean of "Isnt the power/wakelock driver suspend_late routine executed last?". However, when the issue happen the last part of dmesg like this:

[ 881.167999] Successfully put all powerdomains to target state
[ 881.174468] PM: early resume of devices complete after 0.305 msecs
[ 881.181243] restarting OHCI controller
[ 881.235992] wakeup wake lock: event0-1262
[ 881.263824] usb usb1: root hub lost power or was reset
[ 881.269226] ohci-omap3 ohci-omap3.0: ohci_omap3_resume: exit
[ 881.275177] d7800_bt_resume
[ 881.278137] mcspi1 attached
[ 881.281066] omap_hdq omap_hdq.0: omap_hdq_resume
[ 881.291503] twl_resume, exit
[ 881.673553] d7800_kp_resume: wakeup by Other Event.
[ 881.678710] twl_rtc_resume, exit
[ 881.683105] mma7660 3-004c: mma7660_resume: exit
[ 881.790496] soc-audio soc-audio: resume work item may be lost
[ 881.796539] smartreflex smartreflex.0: omap_sr_resume
[ 881.801879] smartreflex smartreflex.1: omap_sr_resume
[ 881.807464] honeywell_d7800_resume restoring power to the audio codec
[ 881.814727] rt5630_resume restoring audio codec registers
[ 881.820465] usb 1-3: reset full speed USB device using ohci-omap3 and address 3
[ 882.074707] PM: resume of devices complete after 893.585 msecs
[ 882.081634] Restarting tasks ...
[ 882.093383] request_suspend_state: wakeup (3->0) at 606553070136 (2012-06-27 02:59:11.631958003 UTC)
[ 882.102935] request_suspend_state: old_sleep=1, new_state=0
[ 882.110046] done.
[ 882.112335] suspend: exit suspend, ret = 0 (2012-06-27 02:59:11.650939937 UTC)
[ 882.120239] d7800_kp_late_resume
[ 882.133453] mma7660: mma7660_enable 1
[ 882.184936] tsc2007_late_resume
[ 883.472717] request_suspend_state: sleep (0->3) at 607932403633 (2012-06-27 02:59:13.011291500 UTC)
[ 883.482238] request_suspend_state: old_sleep=0, new_state=3
[ 883.490631] tsc2007_early_suspend
[ 883.495971] mma7660: mma7660_enable 0
[ 883.609832] d7800_kp_early_suspend
[ 883.730224] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 883.754516] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[ 883.786682] smartreflex smartreflex.1: omap_sr_suspend
[ 883.792266] smartreflex smartreflex.0: omap_sr_suspend
[ 883.799987] set_audio_hp_pop_on onoff: 0
[ 883.811035] mma7660 3-004c: mma7660_suspend: exit
[ 883.816162] twl_rtc_suspend, exit
[ 883.819885] d7800_kp_suspend: exit
[ 883.931640] twl_suspend, exit
[ 883.940521] omap_hdq omap_hdq.0: omap_hdq_suspend
[ 883.945465] mcspi1 detached
[ 883.948455] d7800_bt_suspend
[ 883.951507] ohci-omap3 ohci-omap3.0: ohci_omap3_suspend: exit
[ 883.957733] PM: suspend of devices complete after 171.295 msecs
[ 883.964416] PM: late suspend of devices complete after 0.457 msecs

Gavin,

The wakelock driver itself has a suspend_late/suspend_noirq callback which checks if a wake_lock still exist.

Hi Arun,

The system is suspended successfully. The power/wakelock driver suspend_late routine executed last and there is no wakelock.

BRs,

Gavin

Gavin,

Can you acquire a wakelock on top-half of twl interrupt routine and release it at the end of the bottom-half?

This way the system would be able to process twl interrupt if it was called before power/wakelock driver suspend-late.

Hi Arun,

You are right. This way the system would be able to process twl interrupt if it was called before power/wakelock driver suspend-late. We have tried it but we still can duplicate the issue since the interrupt can be asserted during suspend_late stage. As you know, acquire a wakelock would not abort suspend flow in suspend_late stage. 

Gavin

Gavin,

If an interrupt occurs after wakelock driver suspend_late, do not acknowledge/process it.

Let the system go to WFI and then H/W would wake the system detecting the interrupt.

Can you try this?

Hi Arun,

We also try this. We do not set IRQF_NO_SUSPEND. So the interrupt will be mask during suspend. In the trial, we also print the interrupt setting before entering suspend:

INTCPS_MIR0=0x1fffffff

INTCPS_ITR0=0x482

Bit7 is sys_nirq, it shows that the interrupt is asserted but masked. But in this case, the system can not be wakeup through TWL. BTW, in the case we still can wakeup system through anther ARM GPIO intterrupt.

How to make the system go to WFI?

BRs,

Gavin

Gavin,

By default, at the end of suspend sequence WFI is executed.

Can you check the SYSNIRQ mux settings in the above method?

It must be WAKEUP enabled as well as OFFMODE WAKEUP enabled.

Hi Arun,

We do config SYSNIRQ mux setting as wakeup enabled and offmode wakeup enabled. Here is value of CONTROL_PADCONF_SYS_NIRQ we got:0x7718.

BRs,

Gavin