Power State Wakeup accepted interrupts and wakeup times for IMX6 SoloLite?

[chrisloental]

All,

Hello, and apologies if my questions are silly, it is my first time here and I am new to the IMX6.

I am designing a system with an IMX6 SoloLite and have some questions about the low power modes:

1) For Standby/DeepSleep mode what allowed interrupts will bring the IMX6 back to RUN? Can you exit this power state based on UART or SDIO?

2) For each of the following modes (WAIT, STOP, STNBY/DSM) what are some ballpark "exit times" from power-down to RUN?

Basically, I want to figure out the following:

Can I be in DSM and wake up the IMX6 via WiFi or BT interrupt (routed to IMX SDIO and UART, respectively) and after wakeup has occured, what is the approximate time it will take for the IMX6 to be "ready".

Assuming I cannot use DSM as I've described above, what are the approximate wake times from WAIT and STOP?

Thanks!

-Chris Loental

[AnsonHuang · Accepted solution]

Hi, Chris

     Let me try to answer your questions as below:

     1. Yes, in Standby/DSM mode, you can use UART or SDIO to wake up system, actually our default BSP has supported UART wake up, you need to enable its wake up first via: "echo enabled > /sys/devices/platform/imx-uart.X/tty/ttymxcX/power/wakeup", here "X" is your console's index. Then when you enter standby/DSM, you can input anything from your console, then system should resume; And for SDIO, our BSP is not supporting it by default, but the hardware should support it, just need to enable SDIO's wakeup before suspend, normally, you need to enable two levels, first one is to enable the eSDHC module's interrupt in its driver before suspend, the other is to unmask the wake up logic in GPC module, then SDIO should be able to wake up system.

     2. Latency of exiting from WAIT and STOP mode, there are something we need to figure out first. For WAIT mode, the latency is very small, I think it should be less than 1us from hardware perspective. For STOP mode, we only use it in standby/DSM mode, and its latency depend on many config of our CCM. If you set the CCM to disable OSC 24M in STOP mode, it will take about 2mS to make OSC re-enabled after resume; Also, there are some timing setting in GPC, take DSM for example, we power down ARM core during DSM, so after system resume, we need to wait for this timing(timer count down) finish then ARM core reset to resume; In a word, for exiting from DSM, the analog will take < 1mS to prepare normal working power(voltage up from standby mode to normal mode), then waiting timer to count down, about 0.5mS before re-power OSC, then OSC takes about 2mS to lock, but we wait for about 8ms to make sure OSC is enabled, then PLL takes about 0.45mS to re-lock, then wait for another 2mS to re-power the ARM core and another 2mS to reset ARM core. So it takes about 14mS to exit from STOP mode, here exit means ARM core restart to run. But, if you didn't care about power, you can use STANDBY mode and keep analog module and OSC enabled, then you only need to wait for PLL relock time, it should be less than 1mS for you to exit from STOP mode.  This is all from hardware perspective, from software, kernel has its suspend/resume flow, some modules may need several ms to resume, so if you want to know the whole kernel suspend/resume latency, it will be very long mainly depend on modules' resume latency, we have saw it takes more than 100ms to resume kernel.

     Hope you can get some useful info from my upper answer.