DM3730 Spurious resuming from suspend

Hi Andrew,

I'm still checking the registers but it should be helpful for investigation of the issue to post a kernel log with dmesg after suspend and resume has been done.

BR

Tsvetolin Shulev

Hi Tsvetolin,

In the attachment below I provided dmesg log after suspend and resume has been done.

5238.dmesg.doc

Hi Andrew,

Unfortunately the attached kernel log doesn't give exact information about the reason for the immediate wake-up after suspend but I see that the system seems does not work in proper conditions because some processes have been terminated with various (non zero) status.

init: ureadahead main process (46) terminated with status 5
init: mounted-proc main process (65) terminated with status 1
systemd-udevd[168]: starting version 204
init: plymouth main process (53) killed by ABRT signal
init: plymouth-splash main process (220) terminated with status 2
init: plymouth-log main process (243) terminated with status 1
init: plymouth-upstart-bridge main process (313) terminated with status 1
...

I'm not sure whether this has some relation with the immediate wake-up. Also it is possible some periphery to sends wake-up events.
I suggest you to try to sleep the system by the following test with debugging purpose:
First check the wakeup_count:

cat /sys/power/wakeup_count

echo mem > /sys/power/state

After waiting some time and checking whether the system wakes-up immediately or not and check the wakeup_count again.
I would like to see the console log of this test.

BR

Tsvetolin Shulev

Thanks for you're answers.

I tried to execute these commands. The result was:

1) Before suspending and resuming: 

root@arm:~# cat /sys/power/wakeup_count
0

2) After suspending and immediately resume: 

root@arm:~# cat /sys/power/wakeup_count
0

It is interesting that there is no wake-ups.

According PRM_RSTST_domain registers snapshot CORE, PER, EMU, NEON, USBHOST domains has been reset following a CORE power domain wake-up. This corresponds with TRM's (rev. R) 246 page CM logic is reset on "A CORE power domain transition from off to on".

RM_RSTST_domain registers before suspending

RM_RSTST_IVA2: 00000000
RM_RSTST_MPU: 00000000
RM_RSTST_CORE: 00000300
RM_RSTST_SGX: 00000000
RM_RSTST_DSS: 00000000
RM_RSTST_CAM: 00000001
RM_RSTST_PER: 00000000
RM_RSTST_EMU: 00000000
RM_RSTST_NEON: 00000000
RM_RSTST_USBHOST: 00000000

RM_RSTST_domain registers after suspending and immediately resume

RM_RSTST_MPU: 0000000c
RM_RSTST_CORE: 00000304
RM_RSTST_SGX: 00000000
RM_RSTST_DSS: 00000000
RM_RSTST_CAM: 00000001
RM_RSTST_PER: 0000000c
RM_RSTST_EMU: 00000004
RM_RSTST_NEON: 0000000c
RM_RSTST_USBHOST: 00000008

Also according /arch/arm/mach-omap2/sleep34xx.S source file (Linux Kernel v.3.0.87) for off & non-off modes Linux Kernel has different resume paths. For off mode the restore functions are called by the ROM code, so dm3730 resets on wake-up.

So maybe we should look for sources of reset instead wake-ups?

Maybe the reason of spurios wake-up is that described in http://www.makelinux.net/lib/ti/DM3730_DM3725_Silicon_Errata/doc-74?

Also can you comment information presented in  http://processors.wiki.ti.com/index.php/AM35x-OMAP35x-PSP_03.00.00.05_Release_Notes about SDOCM00067652 known issue for AM/DM37x:  "Suspend/resume doesn't succeed for 37x when off mode is enabled."?

Hi Andrew,

After I analyzed your configuration I find that the most possible reason for the wake-up is enabled off mode as described in the SDOCM00067652 and Advisory 1.70.

BR

Tsvetolin Shulev

Hi Tsvetolin,

So, according SDOCM00067652 and Advisory 1.70 off mode is NOT supported at this time for DM3730?