Is suspend/resume fully supported on Sabrelite or are there known issues?
It should be supported, can you try below to test it:
echo +10 > /sys/class/rtc/rtc0/wakealarm /* set rtc alarm to 10s */
echo mem > /sys/power/state /* enter DSM mode */ or
echo standby > /sys/power/state /* enter standby mode */
Then system should be waked up by RTC after about 10s, if it is not working, I think some latest patches have broken this function, it is working before.
Is there any documentation of what power savings one can get by using suspend/resume and how this maps to the various sleep states of the imx6? Also how to change suspend/resume configuration, in terms of bringing down or up of certain power domains depending on the needs of the specific application. Question is for linux (yocto) and/or android. Thanks
You can refer to our BSP release's reference manual, there is low power mode chapter. Also, you can refer to I.mx 6q application note, you can get then from freescale website.
I can provide some basic info about suspend resume. There are two power states we implement in Linux, standby and mem. And for our SOC, there is two basic low power mode, WAIT mode and STOP mode, we map WAIT mode to Linux cpu idle. And map STOP mode to suspend(standby) mode, for Linux mem mode, we force SOC enter STOP mode + ARM core power off. And for each mode, we can use different configs for other modules, such as we can control whether to such down OSC in stop mode, whether to let ANATOP module into low power mode when SOC is in stop mode etc. each config may bring additional power consumption, but may have small resume latency. In short, we map mem mode to our lowest power mode, we call it DSM mode. But only standby mode to our SOC's STOP mode, ARM core is still powered on, no need to restore its context after resume.
To change config for suspend resume, you need to config CCM, ANATOP and GPC, the code is in system.c, pm.c and mx6_suspend.c, but you had better to know SOC hardware well enough before doing any change to this part.
I suggest you read our power related DOC first, BTW, what power domain you need to change according to your specific application?
Thanks for the explanation. If I am to use the PF0100 power mgmt chip for managing the i.MX6 and other externals (like wifi and camera), is there an equivalent suspend/resume support in linux for using this power mgmt chip? Or would I have to use an external microcontroller to interface with the PF0100 over i2c to initiate the suspend/resume operation.
Our linux BSP already supported PF0100 to manage suspend/resume power, no need to use an external microcontroller to interface with PF0100, as our i.MX6 has I2C module which has been connected to PF0100, so we only need to use internal I2C module.
HI Anson Huang,
Can you please let me know , how to set the cpu into system ideal mode, as no where it is mentioned , and even system ideal mode is not mentioned in BSP also , when I ran cat /sys/power/state . I read all the Linux reference manual and application notes , no where mentioned on system ideal ..
1. How to configure the CPU n system ideal mode ?
2. How to come out of the mode ?
Thanks in advance.
we've faced with a problem during WEC7 suspend/resume implementation: STOP mode can not be entered when SMP support is enabled (VSTBY pin is not set). Are there any issues which may prevent entering STOP mode? What minimum conditions must be done before entering STOP mode?
Thank you in advance,
As far as I know, to enter STOP/WAIT mode, you need to ensure below conditions:
1. all cores are in wfi;
2. SCU is in idle mode, you can enable its auto standby mode;
3. L2 cache is idle mode, you can enable its auto standby mode;
4. No wake-up source's interrupts are pending, that means those irqs which are not masked in GPC_IMR registers, if one of them is pending, then SOC will not enter STOP/WAIT mode.
Can you double check upper conditions first?
thank you for your help, the problem was in SCU. STOP mode works now.
However, I've got another problem with interrupts processing: suspend/resume works only once, looks like wake interrupts stop working in the resumed system. There is no such behaviour with simple WFI suspend/resume.
Retrieving data ...