How to put Juno into Sleep-state

What exactly do you mean by Sleep-state ?

It could be cpu, device or system level sleep state.

On juno, CPU sleep states are available and must be enabled by default in Linaro releases.

Can you check if you see the sysfs files:

/sys/devices/system/cpu/cpu*/cpuidle/state*/usage

/sys/devices/system/cpu/cpu*/cpuidle/state*/time

Reading them gives the residency count and time.

System state is supported but only rtc wakeup sources is tested.

You can try:

     echo mem > /sys/power/state

Thank you for your response.

I mean that Sleep-state is System level sleep state.

For more information, please refer to the following link. ARM Information Center

When I pushed the Soft Reset button briefly, Juno did not sleep but rebooted.

So I contributed this question about it.

Might Linaro kernel not support System sleep state on Juno ?

I could check CPU sleep state is available by reading sysfs files.

But System sleep state is not going well.

     # echo mem > /sys/power/state

     -sh: echo: write error: Invalid argument

And, there was no sleep states though I tried the following command.

     # cat /sys/power/state

Thank you.

Hi,

Since this feature was added in the mainline kernelquite recently, there's possibility that it's not supported

in LSK. However I think the 15.12 firmware should have the

necessary support.

Regards,

Sudeep

Hi,

Thank you for your reply.

I added the system suspend support to 15.12 LSK by reference to mainline kernel.

Juno seemed to be into the suspend state after running "echo mem > /sys/power/state".

But Juno did not wake-up although I set the RTC alarm before entering the suspend state.

     # date

     Mon Jan 18 08:12:28 UTC 2016

     # echo +10 > /sys/class/rtc/rtc0/wakealarm

     # echo mem > /sys/power/state

     [  398.468280] PM: suspend entry 2016-01-18 08:12:28.253471540 UTC

     [  398.474147] PM: Syncing filesystems ... done.

     [  398.507730] Freezing user space processes ... (elapsed 0.004 seconds) done.

     [  398.515211] Freezing remaining freezable tasks ... (elapsed 0.007 seconds) done.

     [  398.515214] Suspending console(s) (use no_console_suspend to debug)

How can I wake-up Juno being in the suspend state ?

Could you tell me more if you know about this.

Thank you again for your help.

Hi,

That's cool.

Can you confirm the RTC being used is not rtc-efi ?

$ cat /sys/class/rtc/rtc*/name

You must use the pl031 RTC. You can first check if it's working by:

$ echo +10 > /sys/class/rtc/rtc1/wakealarm && sleep 10 && cat /proc/interrupts | grep pl031

You must get interrupts. If not it can't work as wakeup source.

If you are getting interrupts then it could be firmware issue.

I have not tried this with v3.10/v3.18 kernel, I may be missing

some config in Linux kernel too.

Regards,

Sudeep

Hi,

Thanks for giving me a information.

Yes, I am using pl031 RTC.

And I could confirm getting a interrupt from pl031 RTC after running the command.

     # echo +10 > /sys/class/rtc/rtc0/wakealarm && sleep 10

Does this mean it might be a firmware issue ?

What should I check about source code ?

Thank you for your time.

That's good that RTC is working.

Also you mentioned it's 15.12 release so I think it does support

system suspend though I have never tried that.

It could be Linux issue, but if you can run v4.4 just to check once

that will confirm firmware is fine and you can look at Linux suspend

path in detail to debug that.

Thanks for your reply.

But I am afraid I don't have a ARMv8 board on which v4.4 kernel is running on hand.

Though I tried the same thing on Juno with v4.3 kernel, it also did not wake up.

In this connection, there is something I am bothering about a little.

There is the following comments in the ARM Trusted Firmware source code.

     ===================================================================================

     On Juno, when the system power domain is suspended, the GIC is also powered down.
     The SCP resumes the final core to be suspend when an external wake-up event is received.
     But the other cores cannot be woken up by a targeted interrupt, because GIC doesn't forward these interrupts to the SCP.
     Due to this hardware limitation, we down-grade PSCI CPU SUSPEND requests targeted to the system power domain level to cluster power domain level.

     The system power domain suspend on Juno is only supported only via PSCI SYSTEM SUSPEND API.

     ===================================================================================

Does not the above hardware limitation influence a wake-up from System Suspend ?

I'd be grateful if you could tell me what you think.

Thank you for your help.

Hi,

Running v4.4 on Juno is quite simple. Just build for defconfig.

Anyways as I mentioned earlier I have tested Juno wakeup on

RTC alarm atleast. There are other interrupts like GPIO keys

which can ideally be used but for reasons yet to root-caused

they are not working when GIC is powered-down which is the

case when the system suspend is executed.

Hope that helps.

Regards,

Sudeep

Hi,

Thank you for letting me know !

Thanks to your advice, I could run v4.4 kernel building for defconfig + CONFIG_RTC_DRV_PL031 on Juno.
Also, I could confirm Juno resumes from System-Suspend by the RTC alarm though there were some warning messages.
However, to succeed in resuming is only one out of several times. How about when you tested it ?

I'm using the following software on Juno R1 board.

     Linux kernel + juno-r1.dtb  : v4.4 kernel.org
     Others ( including u-boot ) : Linaro Release 15.12 Latest
     Filesystem       : OpenEmbedded Minimal 15.10

Once again, thank you for your time.

Hi,

It always resumes on my Juno board.

Also you can ignore the warnings. One of them is from GPIO which is

fixed now  in v4.5-rc1 and another is CPUFreq which I need to look at

but postponing it as it's not harmful.

You can add "no_console_suspend" to see if you get any more logs in

failure case so that it helps to debug.

Regards,

Sudeep

Hello.

Thank you for the information.

I wonder if any firmware are different from the firmware you tested.

First I will try to debug kernel with "no_console_suspend".

Thank you very much.

Hi Sudeep,

Regarding that Juno does not always resume, it could be PCIe driver issue. Since it always resumes if I delete "pcie-controller" from DTB.

Isn't the board you tested Juno-r0 which does not support PCIe ?

Thank you.

Hi,

Right, since you mentioned PCIe, I now look your original query

and I missed the fact that it's R1 board. I always assumed it was

R0 board, sorry for that.

Yes I have R2 board and it has issue with PCIe resume path

especially if you are using sky2 ethernet port. However if you

remove that module, you will just see warning in the resume path.

It's issue with PCIe power management, I will follow up on this

once I have more info.

Regards

Hi,

I appreciate your reply.

I am glad I could clarify the cause of the issue.

I would be grateful if you could share anything about the issue with me.

Thank you.