i.MX6 locks up during suspend to RAM sequence

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6 locks up during suspend to RAM sequence

929 Views
pastrana
Contributor III

Hi everyone!

Firstly, I describe my platform environment:

  • Processor: i.MX6ul
  • Kernel version:  4.1.38
  • Suspend to RAM mode: "echo standby > /sys/power/state"

I have noticed that sometimes the system does not wake up from a standby state. It does not complete the suspend sequence, it becomes blocked before suspend. Therefore, it does not matter if it is happening the wake up interrupts, it is not been handling. In order to wake up the system from standby status, I have configured a GPIO as wake up source.

I have enabled the debugging out during the sequence and It is like this:

PM: Entering standby sleep
calling input4+ @ 24897, parent: gpio-keys
call input4+ returned 0 after 145 usecs
calling 2000000.aips-bus:tempmon+ @ 24897, parent: 2000000.aips-bus
call 2000000.aips-bus:tempmon+ returned 0 after 21 usecs
calling imx6q-cpufreq+ @ 24897, parent: platform
call imx6q-cpufreq+ returned 0 after 2 usecs
calling snd-soc-dummy+ @ 24897, parent: platform
call snd-soc-dummy+ returned 0 after 1 usecs
calling snd_virmidi.0+ @ 24897, parent: platform
call snd_virmidi.0+ returned 0 after 1 usecs
calling snd_aloop.0+ @ 24897, parent: platform
call snd_aloop.0+ returned 0 after 10 usecs
calling snd_dummy.0+ @ 24897, parent: platform
call snd_dummy.0+ returned 0 after 6 usecs
calling caam_sm+ @ 24897, parent: 2140000.caam
call caam_sm+ returned 0 after 0 usecs
calling mmc0:0001+ @ 24897, parent: mmc0
call mmc0:0001+ returned 0 after 116316 usecs
calling 2143000.jr2+ @ 24897, parent: 2140000.caam
call 2143000.jr2+ returned 0 after 1 usecs
calling 2142000.jr1+ @ 24897, parent: 2140000.caam
call 2142000.jr1+ returned 0 after 2 usecs
calling 2141000.jr0+ @ 24897, parent: 2140000.caam
call 2141000.jr0+ returned 0 after 0 usecs
calling mmc0::+ @ 24897, parent: 2194000.usdhc
call mmc0::+ returned 0 after 2 usecs
calling rtc0+ @ 24897, parent: 20cc000.snvs:snvs-rtc-lp
call rtc0+ returned 0 after 33 usecs
calling input3+ @ 24897, parent: 0-006a
call input3+ returned 0 after 3 usecs
calling input2+ @ 24897, parent: 0-006a
call input2+ returned 0 after 1 usecs
calling input1+ @ 24897, parent: 0-001c
call input1+ returned 0 after 2 usecs
calling input0+ @ 24897, parent: 20cc000.snvs:snvs-powerkey
call input0+ returned 0 after 160 usecs
calling usb1+ @ 24897, parent: ci_hdrc.1
call usb1+ returned 0 after 17659 usecs
calling ci_hdrc.1+ @ 24897, parent: 2184200.usb
call ci_hdrc.1+ returned 0 after 30 usecs
calling ci_hdrc.0+ @ 24897, parent: 2184000.usb
call ci_hdrc.0+ returned 0 after 35 usecs
calling card0+ @ 24897, parent: Vivante GCCore
call card0+ returned 0 after 3 usecs
calling Vivante GCCore+ @ 24897, parent: platform
call Vivante GCCore+ returned 0 after 1 usecs
calling alarmtimer+ @ 24897, parent: platform
call alarmtimer+ returned 0 after 6 usecs
calling regulatory.0+ @ 24897, parent: platform
call regulatory.0+ returned 0 after 1 usecs
calling 1-0008+ @ 24897, parent: i2c-1
call 1-0008+ returned 0 after 1 usecs
calling 0-001c+ @ 24897, parent: i2c-0
call 0-001c+ returned 0 after 476 usecs
calling onewire+ @ 24897, parent: platform
call onewire+ returned 0 after 2 usecs
calling gpio-keys+ @ 24897, parent: platform
call gpio-keys+ returned 0 after 13 usecs
calling userspace-consumer+ @ 24897, parent: platform
call userspace-consumer+ returned 0 after 2 usecs
calling regulators:regulator@1+ @ 24897, parent: regulators
call regulators:regulator@1+ returned 0 after 1 usecs
calling regulators:regulator@0+ @ 24897, parent: regulators
call regulators:regulator@0+ returned 0 after 2 usecs
calling regulators+ @ 24897, parent: platform
call regulators+ returned 0 after 2 usecs
calling 21fc000.serial+ @ 24897, parent: 2100000.aips-bus
call 21fc000.serial+ returned 0 after 170 usecs
calling 21f4000.serial+ @ 24897, parent: 2100000.aips-bus
call 21f4000.serial+ returned 0 after 307 usecs
calling 21f0000.serial+ @ 24897, parent: 2100000.aips-bus

It always stops in the same point. 

In case of complete the suspend sequence, the output continue with the following lines:

call 21ec000.serial+ returned 0 after 19 usecs
calling 21e8000.serial+ @ 4001, parent: 2100000.aips-bus
call 21e8000.serial+ returned 0 after 20 usecs
calling 21bc000.ocotp-ctrl+ @ 4001, parent: 2100000.aips-bus
call 21bc000.ocotp-ctrl+ returned 0 after 1 usecs
calling 21b8000.weim+ @ 4001, parent: 2100000.aips-bus
call 21b8000.weim+ returned 0 after 2 usecs
calling 21b0000.mmdc+ @ 4001, parent: 2100000.aips-bus
call 21b0000.mmdc+ returned 0 after 2 usecs
calling 21ac000.romcp+ @ 4001, parent: 2100000.aips-bus
call 21ac000.romcp+ returned 0 after 2 usecs
calling 21a4000.i2c+ @ 4001, parent: 2100000.aips-bus
call 21a4000.i2c+ returned 0 after 3 usecs
calling 21a0000.i2c+ @ 4001, parent: 2100000.aips-bus
call 21a0000.i2c+ returned 0 after 1 usecs
calling 2198000.adc+ @ 4001, parent: 2100000.aips-bus
call 2198000.adc+ returned 0 after 10 usecs
calling 2194000.usdhc+ @ 4001, parent: 2100000.aips-bus
call 2194000.usdhc+ returned 0 after 12 usecs
calling 2184800.usbmisc+ @ 4001, parent: 2100000.aips-bus
call 2184800.usbmisc+ returned 0 after 2 usecs
calling 2184200.usb+ @ 4001, parent: 2100000.aips-bus
call 2184200.usb+ returned 0 after 9 usecs
calling 2184000.usb+ @ 4001, parent: 2100000.aips-bus
call 2184000.usb+ returned 0 after 8 usecs
calling 2140000.caam+ @ 4001, parent: 2100000.aips-bus
call 2140000.caam+ returned 0 after 1 usecs
calling 2100000.aips-bus+ @ 4001, parent: soc
call 2100000.aips-bus+ returned 0 after 2 usecs
calling 20fc000.pwm+ @ 4001, parent: 2000000.aips-bus
call 20fc000.pwm+ returned 0 after 2 usecs
calling 20f8000.pwm+ @ 4001, parent: 2000000.aips-bus
call 20f8000.pwm+ returned 0 after 1 usecs
calling 20f4000.pwm+ @ 4001, parent: 2000000.aips-bus
call 20f4000.pwm+ returned 0 after 0 usecs
calling 20f0000.pwm+ @ 4001, parent: 2000000.aips-bus
call 20f0000.pwm+ returned 0 after 0 usecs
calling 20ec000.sdma+ @ 4001, parent: 2000000.aips-bus
call 20ec000.sdma+ returned 0 after 2 usecs
calling 20e8000.gpt+ @ 4001, parent: 2000000.aips-bus
call 20e8000.gpt+ returned 0 after 0 usecs
calling 20e4000.iomuxc-gpr+ @ 4001, parent: 2000000.aips-bus
call 20e4000.iomuxc-gpr+ returned 0 after 2 usecs
calling 20e0000.iomuxc+ @ 4001, parent: 2000000.aips-bus
call 20e0000.iomuxc+ returned 0 after 1 usecs
calling 20dc000.gpc+ @ 4001, parent: 2000000.aips-bus
call 20dc000.gpc+ returned 0 after 1 usecs
calling 20d8000.src+ @ 4001, parent: 2000000.aips-bus
call 20d8000.src+ returned 0 after 1 usecs
calling 20cc000.snvs:snvs-powerkey+ @ 4001, parent: 20cc000.snvs
call 20cc000.snvs:snvs-powerkey+ returned 0 after 7 usecs
calling 20cc000.snvs:snvs-poweroff+ @ 4001, parent: 20cc000.snvs
call 20cc000.snvs:snvs-poweroff+ returned 0 after 2 usecs
calling 20cc000.snvs:snvs-rtc-lp+ @ 4001, parent: 20cc000.snvs
call 20cc000.snvs:snvs-rtc-lp+ returned 0 after 4 usecs
calling 20cc000.snvs+ @ 4001, parent: 2000000.aips-bus
call 20cc000.snvs+ returned 0 after 0 usecs
calling 20cc000.caam-snvs+ @ 4001, parent: 2000000.aips-bus
call 20cc000.caam-snvs+ returned 0 after 1 usecs
calling 20ca000.usbphy+ @ 4001, parent: 2000000.aips-bus
call 20ca000.usbphy+ returned 0 after 1 usecs
calling 20c9000.usbphy+ @ 4001, parent: 2000000.aips-bus
call 20c9000.usbphy+ returned 0 after 1 usecs
calling 20c8000.anatop:regulator-vddsoc@140+ @ 4001, parent: 20c8000.anatop
call 20c8000.anatop:regulator-vddsoc@140+ returned 0 after 2 usecs
calling 20c8000.anatop:regulator-vddcore@140+ @ 4001, parent: 20c8000.anatop
call 20c8000.anatop:regulator-vddcore@140+ returned 0 after 1 usecs
calling 20c8000.anatop:regulator-3p0@120+ @ 4001, parent: 20c8000.anatop
call 20c8000.anatop:regulator-3p0@120+ returned 0 after 0 usecs
calling 20c8000.anatop+ @ 4001, parent: 2000000.aips-bus
call 20c8000.anatop+ returned 0 after 0 usecs
calling 20c4000.ccm+ @ 4001, parent: 2000000.aips-bus
call 20c4000.ccm+ returned 0 after 0 usecs
calling 20bc000.wdog+ @ 4001, parent: 2000000.aips-bus
call 20bc000.wdog+ returned 0 after 19 usecs
calling 20b0000.snvs+ @ 4001, parent: 2000000.aips-bus
call 20b0000.snvs+ returned 0 after 0 usecs
calling 20ac000.gpio+ @ 4001, parent: 2000000.aips-bus
call 20ac000.gpio+ returned 0 after 1 usecs
calling 20a8000.gpio+ @ 4001, parent: 2000000.aips-bus
call 20a8000.gpio+ returned 0 after 1 usecs
calling 20a4000.gpio+ @ 4001, parent: 2000000.aips-bus
call 20a4000.gpio+ returned 0 after 0 usecs
calling 20a0000.gpio+ @ 4001, parent: 2000000.aips-bus
call 20a0000.gpio+ returned 0 after 0 usecs
calling 209c000.gpio+ @ 4001, parent: 2000000.aips-bus
call 209c000.gpio+ returned 0 after 0 usecs
calling 2098000.gpt+ @ 4001, parent: 2000000.aips-bus
call 2098000.gpt+ returned 0 after 2 usecs
calling 2094000.can+ @ 4001, parent: 2000000.aips-bus
call 2094000.can+ returned 0 after 4 usecs
calling 208c000.pwm+ @ 4001, parent: 2000000.aips-bus
call 208c000.pwm+ returned 0 after 1 usecs
calling 2088000.pwm+ @ 4001, parent: 2000000.aips-bus
call 2088000.pwm+ returned 0 after 0 usecs
calling 2084000.pwm+ @ 4001, parent: 2000000.aips-bus
call 2084000.pwm+ returned 0 after 2 usecs
calling 2080000.pwm+ @ 4001, parent: 2000000.aips-bus
call 2080000.pwm+ returned 0 after 0 usecs
calling 2034000.asrc+ @ 4001, parent: 2000000.spba-bus
call 2034000.asrc+ returned 0 after 23 usecs
calling 2024000.serial+ @ 4001, parent: 2000000.spba-bus
call 2024000.serial+ returned 0 after 205 usecs
calling 2020000.serial+ @ 4001, parent: 2000000.spba-bus
call 2020000.serial+ returned 0 after 17 usecs
calling 2000000.spba-bus+ @ 4001, parent: 2000000.aips-bus
call 2000000.spba-bus+ returned 0 after 2 usecs
calling 2000000.aips-bus+ @ 4001, parent: soc
call 2000000.aips-bus+ returned 0 after 0 usecs
calling 1804000.dma-apbh+ @ 4001, parent: soc
call 1804000.dma-apbh+ returned 0 after 2 usecs
calling 905000.sram+ @ 4001, parent: soc
call 905000.sram+ returned 0 after 1 usecs
calling 904000.sram+ @ 4001, parent: soc
call 904000.sram+ returned 0 after 0 usecs
calling 900000.sram+ @ 4001, parent: soc
call 900000.sram+ returned 0 after 1 usecs
calling soc:caam_secvio+ @ 4001, parent: soc
call soc:caam_secvio+ returned 0 after 1 usecs
calling 100000.caam-sm+ @ 4001, parent: soc
call 100000.caam-sm+ returned 0 after 0 usecs
calling soc:busfreq+ @ 4001, parent: soc
call soc:busfreq+ returned 0 after 2 usecs
calling soc+ @ 4001, parent: platform
call soc+ returned 0 after 1 usecs
calling a01000.interrupt-controller+ @ 4001, parent: platform
call a01000.interrupt-controller+ returned 0 after 1 usecs
calling reg-dummy+ @ 4001, parent: platform
call reg-dummy+ returned 0 after 1 usecs
PM: suspend of devices complete after 1042.535 msecs
PM: suspend devices took 1.050 seconds
calling 20ec000.sdma+ @ 4001, parent: 2000000.aips-bus
call 20ec000.sdma+ returned 0 after 104 usecs
PM: late suspend of devices complete after 11.953 msecs
calling 20cc000.snvs:snvs-rtc-lp+ @ 4001, parent: 20cc000.snvs
call 20cc000.snvs:snvs-rtc-lp+ returned 0 after 2 usecs
PM: noirq suspend of devices complete after 13.116 msecs
Disabling non-boot CPUs ...
PM: Calling sched_clock_suspend+0x0/0x40
PM: Calling timekeeping_suspend+0x0/0x258
PM: Calling irq_gc_suspend+0x0/0x68
PM: Calling fw_suspend+0x0/0x2c
PM: Calling cpu_pm_suspend+0x0/0x28

Moreover, the interrupts that I have configured on my device are:

pastedImage_13.png

Moreover, I try removing (via dts) the serial port which corresponds to 21f0000.serial, to know if the system get blocked at the same point. And, it finishs the standby sequence, but it also locked up.

Furthermore, t does not matter which state is introduced, “echo standby” or “echo mem”, it has the same behaviour as before.

Also, We have try using “systemctl suspend”. However, we have discovered other misbehaviour.  The most of times after finish the suspend sequence, the system reboots. The exceptions are instead of taking one suspend sequence, it takes 2, 3 or 4 times. Mostly the same…

Any idea?? Any other way to debug the behaviour?

Thanks!

Javi F.P.

Labels (2)
0 Kudos
1 Reply

745 Views
igorpadykov
NXP Employee
NXP Employee

Hi Javi

4.1.38 kernel is not supported by nxp, one can look at i.MX6UL L4.1.15 sources related to low power

modes in nxp codeaurora.org/external/imx repository

imx6ul_low_power_idle.S,cpuidle-imx6ul.c, pm-imx6.c in

mach-imx\arm\arch - linux-imx - i.MX Linux kernel 

Low power modes drivers description can be found in nxp linux documentation on

i.MX Software|NXP 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos