Board
=======
imx6sx
Command used to put A9 in sleep:
==============
echo mem > /sys/power/state.
A9 wake up once M4 send RPMSG.
Logs A9- Wakeup
====================
Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.005 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 150.832 msecs
PM: late suspend of devices complete after 0.896 msecs
PM: noirq suspend of devices complete after 0.836 msecs
Disabling non-boot CPUs ...
In imx6q_pm_enter
M4 is busy, enter WAIT mode instead of STOP!
PM: noirq resume of devices complete after 0.406 msecs
PM: early resume of devices complete after 0.473 msecs
PM: resume of devices complete after 166.394 msecs
Restarting tasks ... done.
Issue
=======
M4 performance gets degraded in wakeup time = 166.394 msec(Sleep to wakeup time). After 166msec, M4 performs as expected like wakeup.
What can be the reason here?
Note: Out application on the M4 side is using just some GPIO read/write and RAM write + rpmsg operations only.
Hi rakesh_patel
I am afraid it is not possible to exclude some modules from the
suspend-resume flow. Probably one can disable them before entering low power
mode, then reenable again.
Best regards
igor
I found culprit module that affect M4 performance.
Module= mmc3:0001
I have bypassed(ignored) this module from device_pm_add API("drivers/base/power/main.c") then M4 application is working fine.
But, this is not ideal solution. I am not getting, why mmc3 is affecting M4 performance.
Hi rakesh_patel
probably mmc3 is performing some operations during low power mode
sequence, what device is attached to mmc3 . One can try to tweak some dts settings:
Best regards
igor
I tried the above-mentioned dts setting. But it is not working.
We are using "MTFC32GAPALBH" Emmc.
Any clue for why "mmc3:0001" is creating an issue with M4 performance?
We also have an EPIT timer in the M4 application which uses a peripheral clock.
And as per the imx6sx reference manual,
=======
"Any change of the periph_clk_sel and periph2_clk_sel sync
mux select will involve handshake with the MMDC. Refer to
the CCDR and CDHIPR registers for the handshake bypass and
busy bits
"
I also bypassed the MMDC handshake. Still, M4 performance is impacted.
Just for more information:
===========
Our M4 application uses the following things:
1) RPMSG
2) EPIT timer
3) read/write GPIO
4) read and write RAM - physical memory
>Any clue for why "mmc3:0001" is creating an issue with M4 performance?
this may be due to handshake when changing certain root clock dividers that require
handshake, handshake with GPC during power-down and power-up sequencing
of individual subsystems.
Best regards
igor
Any idea, how to debug out and fix this further?
Hi rakesh_patel
for performance issues NXP has special service:
https://contact.nxp.com/new-prof-svcs-sw-tech
Suggest to proceed with it.
Best regards
igor
Thanks a lot for giving pointers for the debugging.
But this issue is automatically resolved in the new BSP code.
Hi rakesh_patel
from log: "PM: resume of devices complete after 166.394 msecs"
seems 166msec is necessary for processor to exit from low power mode:
restore pmic voltages, restart PLLs, details can be found in sect.19.5.3.3.2 Exiting STOP mode
i.MX 6SoloX Applications Processor Reference Manual
Best regards
igor
I also believe the same. But my purpose is to exclude modules from the suspend-resume flow that affect M4 performance.
I have attached list of module using custom debugging prints(Please find attached)
Query:
1) Which modules affect M4 performance?
2) How to exclude those modules from suspend-resume?