Linux/AM3352: Stand-by issue

Angel Falcon

Part Number: AM3352

Tool/software: Linux

Hello,

We have our own HW design using am3352 and we got linux 4.4.19 from TI SDK.

We need that our system is able to enter stand-by mode to save power, and we configured our .dts file to allow system to wake up with gpio0_3. Then, we call "echo standby > /sys/power/state" when we need the system to enter stand-bye mode.

System works fine most of the times, enter/resume stand-by mode as expected with gpio0_3. But sometimes we see that system resumes immediatly from stand-by, and we have checked that gpio0_3 is not changing its value.

The kernel log is the same when the system works fine and when it does not:

[ 1903.641236] PM: Syncing filesystems ... done.
[ 1903.651957] PM: Preparing system for sleep (standby)
[ 1903.653121] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 1903.655212] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 1903.656729] PM: Suspending system (standby)
[ 1903.656771] Suspending console(s) (use no_console_suspend to debug)
[ 1904.869578] PM: suspend of devices complete after 1210.777 msecs
[ 1904.871908] PM: late suspend of devices complete after 2.293 msecs
[ 1904.874375] PM: noirq suspend of devices complete after 2.437 msecs
[ 1904.874383] PM: Successfully put all powerdomains to target state
[ 1904.890296] PM: noirq resume of devices complete after 15.794 msecs
[ 1904.892387] PM: early resume of devices complete after 1.942 msecs
[ 1904.894941] net can1: c_can_hw_raminit_wait_syscon: time out
[ 1904.895001] c_can_platform 481cc000.can can1: setting BTR=1c05 BRPE=0000
[ 1904.895163] net eth0: initializing cpsw version 1.12 (0)
[ 1904.895171] net eth0: initialized cpsw ale version 1.4
[ 1904.895178] net eth0: ALE Table size 1024
[ 1904.896866] libphy: PHY not found
[ 1904.896873] net eth0: phy "" not found on slave 0, err -19
[ 1904.897660] net eth0: phy found : id is : 0x7c0f1
[ 1905.009357] PM: resume of devices complete after 116.880 msecs
[ 1905.010830] PM: Finishing wakeup.
[ 1905.010842] Restarting tasks ... done.

How coulkd we know why the system is waking up if gpio0_3 did not change?

Is it possible to know the wake-up reason?

Thank you for your help

Best regards

Angel

over 7 years ago

0 Nick Saulnier over 7 years ago

TI__Guru** 109730 points

Hello Angel,

Please take a look at the Power Management documentation, section "Power Management on AM335 and AM437". The bottom of the section lists additional resources that might be helpful, such as Debugging AM335x Suspend-Resume Issues.

Regards,

Nick

0 Nick Saulnier over 7 years ago in reply to Nick Saulnier

TI__Guru** 109730 points

Hello Angel,

I am going to mark this thread resolved. Feel free to comment if you need to continue the discussion.

Regards,
Nick

0 Angel Falcon over 7 years ago in reply to Nick Saulnier

Expert 1160 points

Hello Nick,

Sorry If I did not send feedback before, I was doing some tests.
I checked the documents but I do not know how find the wake-up reason.

As I mentioned before, the system settings and configuration seem to be fine, because it works as supposed most of the times. And even when there is an unexpected wake-up there is no error. Probably, in that situation there is something in the system that does not allow to remain in stand-by mode, and we would like to know this reason to avoid it.

Remember we use "echo standby > /sys/power/state" to enter this power save mode.

Best regards
Angel

0 Nick Saulnier over 7 years ago in reply to Angel Falcon

TI__Guru** 109730 points

Hello Angel,

When I look at the "Debugging AM335x Suspend-Resume Issues" wiki page, it shows an example of a "successful suspend/resume sequence". That output includes a line "PM: Wakeup source UART".

I do not support Linux 4.4 on these forums because it is too old, but that line of output has been on that wiki page since 2015. So I would have expected that you would see that line of output if you were using a TI SDK. When I check SDK 4.3 (Linux 4.9.69), drivers/soc/ti/pm33xx.c, function am33xx_pm_suspend, it does not look like there should be a way to get through wakeup with a "PM: Successfully put all powerdomains to target state" without also going through "PM: Wakeup source X".

So I am wondering if something is missing from the output you posted, or if there are some changes to that function in your SDK?

Regards,
Nick

0 Nick Saulnier over 7 years ago in reply to Nick Saulnier

TI__Guru** 109730 points

A bit more background:

When I run that test on a beaglebone black running Linux SDK 4.3, here is my console output if I type into the UART:

root@am335x-evm:~# uname -a
Linux am335x-evm 4.9.69-g9ce43c71ae #1 PREEMPT Wed Jan 9 11:04:31 CST 2019 armv7l GNU/Linux
root@am335x-evm:~# echo standby > /sys/power/state
[   65.143896] PM: Syncing filesystems ... done.
[   65.182782] Freezing user space processes ... [   65.202800] Freezing remaining freezable tasks ...
[   65.208296] (elapsed 0.005 seconds) done.[   65.208363] Suspending console(s) (use no_console_suspend to debug)
(elapsed 0.019 seconds) done.
[   65.344569] PM: suspend of devices complete after 123.852 msecs
[   65.348579] PM: late suspend of devices complete after 3.962 msecs
[   65.352942] PM: noirq suspend of devices complete after 4.314 msecs
[   65.352958] PM: Successfully put all powerdomains to target state
[   65.352958] PM: Wakeup source UART
[   65.371421] PM: noirq resume of devices complete after 18.267 msecs
[   65.375326] PM: early resume of devices complete after 3.564 msecs
[   65.376870] net eth0: initializing cpsw version 1.12 (0)
[   65.376896] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[   65.376912] cpsw 4a100000.ethernet: ALE Table size 1024
[   65.472903] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=-1)
[   65.477326] cpts ptp bc clkid 0
[   65.482931] Suspended for 9.124 seconds
[   65.602386] PM: resume of devices complete after 227.017 msecs
[   65.692840] Restarting tasks ... done.
root@am335x-evm:~# [   67.523355] cpsw 4a100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

root@am335x-evm:~#

Have you been able to run tests on a TI board that get the same behavior?

Regards,

Nick

0 Angel Falcon over 7 years ago in reply to Nick Saulnier

Expert 1160 points

Hello Nick,

Thank you very much for your help.
I know that kernel 4.4.14 is old and we are moving to kernel 4.14.67 from TI SDK, but we have customers using 4.4 version and we have to support them. Anyway I think the situation is the same with both versions.

In version 4.4.14 I do not see log trace "PM: Wakeup source GPIO0" because in this version this trace is only shown when you call "echo mem > /sys/power/state". It is not shown when using "echo standby > /sys/power/state".

Anyway I changed function am33xx_pm_suspend() and now I can see this trace.

I have checked that wake up reason is UART
May 16 09:14:35 A06DXX1 kernel: [ 723.744000] PM: Syncing filesystems ... done.
May 16 09:14:35 A06DXX1 kernel: [ 723.807030] PM: Preparing system for sleep (standby)
May 16 09:14:35 A06DXX1 kernel: [ 723.808237] Freezing user space processes ... (elapsed 0.002 seconds) done.
May 16 09:14:35 A06DXX1 kernel: [ 723.810917] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
May 16 09:14:35 A06DXX1 kernel: [ 723.812274] PM: Suspending system (standby)
May 16 09:14:35 A06DXX1 kernel: [ 723.812327] Suspending console(s) (use no_console_suspend to debug)
May 16 09:14:35 A06DXX1 kernel: [ 725.026562] PM: suspend of devices complete after 1212.698 msecs
May 16 09:14:35 A06DXX1 kernel: [ 725.028931] PM: late suspend of devices complete after 2.334 msecs
May 16 09:14:35 A06DXX1 kernel: [ 725.031394] PM: noirq suspend of devices complete after 2.438 msecs
May 16 09:14:35 A06DXX1 kernel: [ 725.031403] PM: Successfully put all powerdomains to target state
May 16 09:14:35 A06DXX1 kernel: [ 725.031403] PM: Wakeup source UART
May 16 09:14:35 A06DXX1 kernel: [ 725.047318] PM: noirq resume of devices complete after 15.811 msecs
May 16 09:14:35 A06DXX1 kernel: [ 725.049423] PM: early resume of devices complete after 1.962 msecs

But UART wake up seems to be disabled

cd /sys/devices/platform/ocp

root@A06DXX1:/sys/devices/platform/ocp# cat 44e09000.serial/tty/ttyO0/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 48022000.serial/tty/ttyO1/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 48024000.serial/tty/ttyO2/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 481a6000.serial/tty/ttyO3/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 481a8000.serial/tty/ttyO4/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 481aa000.serial/tty/ttyO5/power/wakeup
disabled

root@A06DXX1:/sys/devices/platform/ocp# cat 44e09000.serial/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 48022000.serial/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 48024000.serial/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 481a6000.serial/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 481a8000.serial/power/wakeup
disabled
root@A06DXX1:/sys/devices/platform/ocp# cat 481aa000.serial/power/wakeup
disabled

Also checking wakeup_sources file I see only 5 wake up events on gpio_buttons@0, but real situation is that have been 8 wake up events, 5 on gpio_buttons@0 and 3 on UART.

root@A06DXX1:/sys/devices/platform/ocp# cat /sys/kernel/debug/wakeup_sources
name active_count event_count wakeup_count expire_count active_since total_time max_time last_change prevent_suspend_time
musb-hdrc.1.auto 0 0 0 0 0 0 0 21637 0
musb-hdrc.0.auto 0 0 0 0 0 0 0 21517 0
gpio_buttons@0 5 5 0 0 0 0 0 750911 0
481d8000.mmc 0 0 0 0 0 0 0 1320 0
48060000.mmc 0 0 0 0 0 0 0 1286 0
alarmtimer 0 0 0 0 0 0 0 315 0
deleted 0 0 0 0 0 0 0 0 0

What else do I need to do to disable UART as a wake up source?

Best regards
Angel

0 Nick Saulnier over 7 years ago in reply to Angel Falcon

TI__Guru** 109730 points

Hello Angel,

Take a look at the UART0 WER Register (offset = 5Ch) (Wake Up Enable) and the SYSC Register (offset = 54h). There may be options in the Linux drivers to set those values or you may need to set the registers directly, I am not sure.

Regards,
Nick

0 Angel Falcon over 7 years ago in reply to Nick Saulnier

Expert 1160 points

Hello Nick,

Finally I found a solution yesterday, I have tested the last night and it worked fine.
We are using omap-serial driver instead of 8250_serial driver (this one does not support 485 features in kernel version 4.4.14). omap-serial driver does not check if uarts are configured to wake up the system, so suspend functions do not change value of WER register.

What I did is check this setting when suspending uarts and set WER register to the correct value.

Thank you very much for your help
Angel

Processors

Processors forum

Linux/AM3352: Stand-by issue