Dear Kevin,
Happy New Year! HA!
After testing several
times, we can find the following conclusions:
1.
“RTC alarm cannot wake-up” might be hardware issue. It is disappeared
after changing another board.
2.
We are focusing on UART2 RX PIN source wake-up. In order to write
APR, ER, RSR registers, we add some code into suspend.S. In most cases, it is
worked, but sometimes cannot wake-up.
For example:
@
Climax: setup wake-up bits
mov
WORK2_REG, #0x00000000
str
WORK2_REG, [CLKPWRBASE_REG, #0x20] @INT_ER
mov
WORK2_REG, #CLIMAX_STANDBY_WAKE_PIN
str
WORK2_REG, [CLKPWRBASE_REG, #0x30] @PIN_ER
mov
WORK2_REG, #CLIMAX_STANDBY_WAKE_TRIGGER
str
WORK2_REG, [CLKPWRBASE_REG, #0x3C] @PIN_APR
ldr
WORK2_REG, [CLKPWRBASE_REG, #0x34] @PIN_RS
str
WORK2_REG, [CLKPWRBASE_REG, #0x34] @PIN_RS
ldr
WORK2_REG, [CLKPWRBASE_REG, #0x24] @INT_RS
str
WORK2_REG, [CLKPWRBASE_REG, #0x24] @INT_RS
ldr
WORK2_REG, [CLKPWRBASE_REG, #0x30] @PIN_ER
cmp
WORK2_REG, #0
beq
skip
ldr
WORK2_REG, [CLKPWRBASE_REG, #0x38] @PIN_SR
cmp
WORK2_REG, #0
bne
skip
3.
We observe the Ethernet LED, it seems to take some time (1 or 2
seconds?) to shutdown and startup completely. So we add 3 seconds delay into lpc_net_drv_suspend()
and lpc_net_drv_resume(), and the system can be wake-up by UART2 RX PIN source
every times.
For example:
static int
lpc_net_drv_suspend(struct platform_device *pdev,
pm_message_t
state)
{
struct
net_device *ndev = platform_get_drvdata(pdev);
struct
netdata_local *pldat = netdev_priv(ndev);
if
(ndev) {
if
(netif_running(ndev)) {
netif_device_detach(ndev);
__lpc_net_shutdown(pldat);
clk_disable(pldat->clk);
//climax: to solve
"suspend cannot wake-up" issue
mdelay(3000);
}
}
return
0;
}
static int
lpc_net_drv_resume(struct platform_device *pdev)
{
struct
net_device *ndev = platform_get_drvdata(pdev);
struct
netdata_local *pldat;
if
(ndev) {
if
(netif_running(ndev)) {
pldat
= netdev_priv(ndev);
/*
Enable interface clock */
clk_enable(pldat->clk);
/*
Reset and initialize */
__lpc_eth_reset(pldat);
__lpc_eth_init(pldat);
netif_device_attach(ndev);
//climax: to solve
"suspend cannot wake-up" issue
mdelay(3000);
}
}
return
0;
}
Would you please give me
some suggestions for these?
Thanks a lot!
Best Regards,
Engin Lee 李英準
Climax Technology Co., Ltd.
TEL: +886-2-2794-0001 ext. 234
From:
engin [mailto:address@hidden
Sent: Thursday, December 30, 2010
2:39 PM
To: 'Li Yuan-Lung'; 'Kevin Wells'
Cc: 'address@hidden'; 'yk.chen'
Subject: RE: [Ltib] LPC3250 low
power mode?
Dear Kevin,
I modified your testing
program about waking up LPC3250 from suspend mode.
Alarm time has been
changed to 3 seconds and repeat testing. (Please see the attachment file)
And the execution result
shows there is a chance cannot be wake up.
For example:
Suspend: retry:13
Current RTC
date/time is 1-1-1970,
22:59:35.
Alarm will trigger
in 3 seconds
PM: Syncing
filesystems ... done.
Freezing user
space processes ... (elapsed 0.01 seconds) done.
Freezing remaining
freezable tasks ... (elapsed 0.01 seconds) done.
Suspending
console(s) (use no_console_suspend to debug)
PM: suspend of
devices complete after 2.764 msecs
PM: late suspend
of devices complete after 0.917 msecs
PM: early resume
of devices complete after 0.852 msecs
PM: resume of
devices complete after 126.496 msecs
Restarting tasks
... done.
Alarm has
triggered
Current RTC
date/time is 1-1-1970,
22:59:38.
Suspend: retry:14
Current RTC
date/time is 1-1-1970,
22:59:38.
Alarm will trigger
in 3 seconds
PM: Syncing
filesystems ... done.
Freezing user
space processes ... (elapsed 0.01 seconds) done.
Freezing remaining
freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s)
(use no_console_suspend to debug)
And never be wake-up.
So is there any
limitations or rules we are missing?
BTW, is there any
connection about this patch?
http://www.lpclinux.com/Forums/LPC32xxLinuxPatch0010
Thanks a lot!
Best Regards,
Engin Lee 李英準
Climax Technology Co., Ltd.
TEL: +886-2-2794-0001 ext. 234
From:
address@hidden [mailto:address@hidden On Behalf Of Li Yuan-Lung
Sent: Thursday, December 30, 2010
11:49 AM
To: Kevin Wells
Cc: address@hidden; engin;
yk.chen
Subject: Re: [Ltib] LPC3250 low
power mode?
Dear Kevin,
Just few minutes ago we have success test the suspend of rtc alarm, but there
are some limitation we have to follow.
Here we summerized the settings, some limitations may be the issues needing
your help to fix or fine tune.
1. In kernel config, DISBALE the CONFIG_VFP config as below
====Floating point emulation in .config file===
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
# CONFIG_VFP is not set
====Floating point emulation setting end====
This is the issue you just said that there will be a fix in next version.
2. In kernel config, DISBALE the CONFIG_PM_DEBUG config as below
====Power Management option in .config file====
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_APM_EMULATION is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM_OPS=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y
====Power Management option end==========
We guess the CONFIG_PM_DEBUG or its subset may corrupt the suspend operation of
LPC3250, would you fix it or hiding this menu for platform Phytec LPC3250?
3. Remove the "no_console_suspend" in kernel parameter.
Althought it is OK for us to remove it, but this will make
us unable to see the debug messages during suspend. There should be a note of
LPC3250 about this parameter settings.
Here is the result:
=========Result Start. ======
# ./rtc_tst &
# Current RTC date/time is 29-12-2010, 13:08:15.
Alarm will trigger in 60 seconds
# cat /proc/driver/rtc
rtc_time : 13:08:23
rtc_date : 2010-12-29
alrm_time : 13:09:15
alrm_date : 2010-12-29
alarm_IRQ : yes
alrm_pending : no
24hr : yes
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 3.176 msecs
PM: late suspend of devices complete after 0.915 msecs
PM: early resume of devices complete after 0.869 msecs
PM: resume of devices complete after 126.144 msecs
Restarting tasks ... Alarm has triggered
Current RTC date/time is 29-12-2010, 13:09:15.
done.
#
[1] +
Done
./rtc_tst
#
=========Result End.========
Now we are trying to use some other UART ports as the trigger source for resume
work. After referencing the LPC3250 user manual, seems we should config the
masks for these sources. Please kindly tell us some suggestions for
implementation. (START_ER_PIN, START_RSR_PIN and START_APR_PIN) It is weird the
START_ER_PIN register sometimes be cleared to 0 and we can not trigger the
resume.
Thank you.
Henry
2010/12/30 Li Yuan-Lung <henry.li@climax.com.tw>
Dear Kevin,
Thank you for your suggestion.
We have test with the VFP disabled, now we have go further more. The resume
work die in another place.
Belows are two kinds of kernel, one is disabling all FP emulations, the other
is keeping the "NWFPE math emulation".
Both of them return the "early resume" messages to console and stock
with no prompt. Is there any more kernel feature we should turn off?
=============Result1: Kernel with NO FP emulation option========
# ./rtc_tst &
# Current RTC date/time is 29-12-2010, 12:06:24.
Alarm will trigger in 60 seconds
# cat /proc/driver/rtc
rtc_time : 12:06:32
rtc_date : 2010-12-29
alrm_time : 12:07:24
alrm_date : 2010-12-29
alarm_IRQ : yes
alrm_pending : no
24hr : yes
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.03
seconds) done.
PM: suspend of devices complete after 3.306 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 1.084 msecs
PM: early resume of devices complete after 0.994 msecs
=============Result1 End===============================
=============Result2: Kernel with "NWFPE math emulation" >
#./rtc_tst &
# Current RTC date/time is 29-12-2010, 12:53:36.
Alarm will trigger in 60 seconds
# cat /proc/driver/rtc
rtc_time : 12:53:41
rtc_date : 2010-12-29
alrm_time : 12:54:36
alrm_date : 2010-12-29
alarm_IRQ : yes
alrm_pending : no
24hr : yes
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: suspend of
devices complete after 3.237 msecs
PM: late suspend of devices complete after 1.060 msecs
PM: early resume of devices complete after 0.967 msecs
=============Result2 End===============================
Thank you for any thought about this issue.
Henry
2010/12/30 Kevin Wells <address@hidden>
Hi Henry,
>
vfp_pm_resume
I’ve seen this issue before. There
appears to be an issue in the ARM VFP suspend code.
Are you using any applications that use
VFP? If not, disable the VFP context switcher support in the kernel (in the
floating point format kernel menu).
I believe this has been fixed in a later
kernel version, but won’t be able to check it in the next week..
Kevin
Dear
Kevin,
We tried the alarm test for suspend as you mentioned in web page. The alarm
program works well but still stock with suspend running.
Then we use the no_console_suspend as teh code suggested, here is the result
after suspend command:
=========================Result area====================
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: suspend of devices complete after 3.285 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 1.075 msecs
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
last sysfs file: /sys/power/state
Modules linked in:
CPU: 0 Not tainted (2.6.34 #54)
PC is at vfp_pm_resume+0xc/0x2c
LR is at __sysdev_resume+0x24/0xe4
pc : [<c0036684>] lr :
[<c01bc970>] psr: a0000093
sp : c3e11e58 ip : c3e11e68 fp : c3e11e64
r10: 00000004 r9 : c3dd45b8 r8 : c0314100
r7 : c03e88bc r6 : 00000003 r5 : c03e8870 r4 : c03e88bc
r3 : c0036678 r2 : 00000000 r1 : 00009cdc r0 : c03e88bc
Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment user
Control: 0005317f Table: 83e98000 DAC: 00000015
Process echo (pid: 446, stack limit = 0xc3e10270)
Stack: (0xc3e11e58 to 0xc3e12000)
1e40:
c3e11e84 c3e11e68
1e60: c01bc970 c0036688 c03e88bc c03e8870 00000003 003fffff c3e11e9c c3e11e88
1e80: c01bd31c c01bc95c 00000000 c042ef44 c3e11ebc c3e11ea0 c0070d38 c01bd2b0
1ea0: 00000000 c038ef60 00000003 00000003 c3e11edc c3e11ec0 c0070ecc c0070c04
1ec0: 00000000 c038ef60 00000003 c3e2a000 c3e11f04 c3e11ee0 c0070488 c0070e1c
1ee0: c3c0fcc8 c3dd45a0 00000004 c3c28ca0 c032912c c3e11f78 c3e11f14 c3e11f08
1f00: c01869b0 c00703ec c3e11f44 c3e11f18 c00f0d34 c01869a0 c3e171e0 c3e27ee0
1f20: 40000000 c3e11f78 00000000 00000004 c3e10000 00000000 c3e11f74 c3e11f48
1f40: c00a3924 c00f0c24 00000000 40000000 00000000 c3e27ee0 fffffff7 00000000
1f60: 00000000 c0024068 c3e11fa4 c3e11f78 c00a3f34 c00a387c 00000000 00000000
1f80: ffffffff 00000000 00000004 40000000 0012fbd8 00000004 00000000 c3e11fa8
1fa0: c0023ec0 c00a3f00 00000004 40000000 00000001 40000000 00000004 00000000
1fc0: 00000004 40000000 0012fbd8 00000004 00000004 00000020 00000001 00000002
1fe0: 00000004 bef2e938 000241fc 00008f1c 60000010 00000001 00000000 00000000
Backtrace:
[<c0036678>] (vfp_pm_resume+0x0/0x2c) from [<c01bc970>]
(__sysdev_resume+0x24/0xe4)
[<c01bc94c>] (__sysdev_resume+0x0/0xe4) from [<c01bd31c>]
(sysdev_resume+0x7c/0xec)
r7:003fffff r6:00000003 r5:c03e8870 r4:c03e88bc
[<c01bd2a0>] (sysdev_resume+0x0/0xec) from [<c0070d38>]
(suspend_devices_and_enter+0x144/0x218)
r5:c042ef44 r4:00000000
[<c0070bf4>] (suspend_devices_and_enter+0x0/0x218) from
[<c0070ecc>] (enter_state+0xc0/0x130)
r7:00000003 r6:00000003 r5:c038ef60 r4:00000000
[<c0070e0c>] (enter_state+0x0/0x130) from [<c0070488>]
(state_store+0xac/0xc0)
r6:c3e2a000 r5:00000003 r4:c038ef60
[<c00703dc>] (state_store+0x0/0xc0) from [<c01869b0>]
(kobj_attr_store+0x20/0x2c)
[<c0186990>] (kobj_attr_store+0x0/0x2c) from [<c00f0d34>]
(sysfs_write_file+0x120/0x178)
[<c00f0c14>] (sysfs_write_file+0x0/0x178) from [<c00a3924>]
(vfs_write+0xb8/0x164)
[<c00a386c>] (vfs_write+0x0/0x164) from [<c00a3f34>]
(sys_write+0x44/0x70)
r8:c0024068 r7:00000000 r6:00000000 r5:fffffff7 r4:c3e27ee0
[<c00a3ef0>] (sys_write+0x0/0x70) from [<c0023ec0>]
(ret_fast_syscall+0x0/0x2c)
r7:00000004 r6:0012fbd8 r5:40000000 r4:00000004
Code: c040beb0 e1a0c00d e92dd800 e24cb004 (ee113f50)
---[ end trace 59ae93e8f6834865 ]---
=========================Result end=====================
Seems the program counter may go the wrong place and got the bad data as
undefined instruction in "vfp_pm_resume". Please help us to dig more.
Thank you very much!
In the earlier mail, we said that we comment the "sysdev_suspend"; in
fact, we comment the "sysdev_suspend" and "sysdev_resume"
as a pair, then the resume works well.
The related code is just like below in kernel/power/suspend.c:
===
...
arch_suspend_disable_irqs();
//sysdev_suspend(PMSG_SUSPEND);
suspend_ops->enter(state);
//sysdev_resume();
arch_suspend_enable_irqs();
enable_nonboot_cpus();
...
===
Henry
2010/12/29
Li Yuan-Lung <henry.li@climax.com.tw>
Dear
Kevin,
Sorry, forgot to tell you one more thing. We use the kernel version 2.6.34.
Henry
2010/12/29
Li Yuan-Lung <henry.li@climax.com.tw>
Dear Kevin,
We are using our custom board base on "Phytec 3250 development
board", so in kernel config we still using the "Phytec 3250
development board" for LPC32XX SoC based board implementations.
Due to the hardware issue, we did not use the DDR menory.
After deeper tracing, we found we are stocking at "sysdev_suspend(PMSG_SUSPEND)" function under kernel/power/suspend.c.
If we comment the fucntion and test, the suspending works!
But we think it is not a good way to comment the function to prevent this
problem. Now we just trying to trace into the "sysdev_suspend()"
function. Do you have any direction for us?
Thank you very much!
Henry
2010/12/29
Kevin Wells <address@hidden>
Hi Henry,
Which board and kernel version are you
using? If you are using a custom board, are you using DDR memory?
thanks,
Kevin
Dear
Kevin,
Thank you for replying. We have tried the suspend function as the link said,
but we got stock after the system suspending. The kernel did not come back
after showing the suspending message.
Is there any other settings or tunning we should take care?
Say, after trace the suspend source code, we found the 'lpc32xx_sys_suspend()'
will be moved to IRAM(0x8000000) and execute for suspending. The only related
issue is: we have enabled the "CONFIG_ARCH_LPC32XX_IRAM_FOR_NET=y" in
kernel config. Should we have to disable the option for the suspend function
running?
Henry
2010/12/28
Kevin Wells <address@hidden>
Hi Henry,
The CPU and system clocks speeds are
changed with the boot loader (S1L or kick start).
You may need to build a new version of
the boot loader with your desired setup.
The Linux kernel has built-in power
management and you should be able to enter the
suspend-to-mem state on the LPC32x0 and
then wakeup on a specific event (ie, gpio,
SD card insertion, RTC alarm, etc.)
A basic write-up using the RTC alarm is
here:
http://www.lpclinux.com/Forums/ForumLPC32xx0005
I know this works for the Phytec board,
but it hasn’t been tested on the EA and FDI
boards with DDR memory, although the
code should be complete.
Kevin
Dear
NXP members,
Now we have a new question, does the ltib have the ability to control the
LPC3250 board to slow down the CPU frequency or any function to make the power
saving(or power management?) with portable device requirement?
Merry Christmas!
Henry
--
Best Regards,
Henry Li
SW Engineer of Climax Co.
TEL: +886-2-2794-0001 ext.231
FAX: +886-2-2792-6618
--
Best Regards,
Henry Li
SW Engineer of Climax Co.
TEL: +886-2-2794-0001 ext.231
FAX: +886-2-2792-6618
--
Best Regards,
Henry Li
SW Engineer of Climax Co.
TEL: +886-2-2794-0001 ext.231
FAX: +886-2-2792-6618
--
Best Regards,
Henry Li
SW Engineer of Climax Co.
TEL: +886-2-2794-0001 ext.231
FAX: +886-2-2792-6618
--
Best Regards,
Henry Li
SW Engineer of Climax Co.
TEL: +886-2-2794-0001 ext.231
FAX: +886-2-2792-6618
--
Best Regards,
Henry Li
SW Engineer of Climax Co.
TEL: +886-2-2794-0001 ext.231
FAX: +886-2-2792-6618