Here are some basic OMAP test results for Linux v3.16-rc4. Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc4/20140706150051/
Test summary ------------
Build: uImage+dtb: Pass (10/10): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap5-uevm
Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only
Build: zImage: Pass (16/16): multi_v7_defconfig, omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_am43xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_dra7xx_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig
Boot to userspace: FAIL ( 1/14): 2430sdp skip ( 1/14): 5912osk Pass (12/14): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom, 5430es2uevm
PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes
PM: chip retention via dynamic idle: FAIL ( 7/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom
PM: chip off except CORE via suspend: FAIL ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm
PM: chip off via suspend: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom
PM: chip off via dynamic idle: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom
vmlinux object size (delta in bytes from test_v3.16-rc3 (4c834452aad01531db949414f94f817a86348d59)): text data bss total kernel +208 +96 0 +304 omap1_defconfig +176 +96 0 +272 omap1_defconfig_1510innovator_only +208 +96 0 +304 omap1_defconfig_5912osk_only +1648 +776 0 +2424 multi_v7_defconfig +4936 +512 0 +5448 omap2plus_defconfig +872 +112 0 +984 omap2plus_defconfig_2430sdp_only +1036 +128 0 +1164 omap2plus_defconfig_am33xx_only +3336 +248 0 +3584 omap2plus_defconfig_am43xx_only +840 +576 0 +1416 omap2plus_defconfig_cpupm +876 +120 0 +996 omap2plus_defconfig_dra7xx_only +336 +80 0 +416 omap2plus_defconfig_n800_multi_omap2xxx +368 +88 0 +456 omap2plus_defconfig_n800_only_a +840 +448 0 +1288 omap2plus_defconfig_no_pm +868 +56 0 +924 omap2plus_defconfig_omap2_4_only +932 +56 0 +988 omap2plus_defconfig_omap3_4_only +876 +560 0 +1436 omap2plus_defconfig_omap5_only +380 +24 -72 +332 rmk_omap3430_ldp_allnoconfig +380 +64 0 +444 rmk_omap3430_ldp_oldconfig +80 +4 +20 +104 rmk_omap4430_sdp_allnoconfig +180 +80 0 +260 rmk_omap4430_sdp_oldconfig
Boot-time memory difference (delta in bytes from test_v3.16-rc3 (4c834452aad01531db949414f94f817a86348d59)) avail rsrvd high freed board kconfig -4k 4k . 404k 4460varsomom omap2plus_defconfig
After some troubleshooting, it turns out that the reason that the 4460 VAR-SOM-OM-DVK wasn't booting was that I was missing 'rootwait' on the kernel command line.
* Paul Walmsley paul@pwsan.com [140706 16:43]:
Here are some basic OMAP test results for Linux v3.16-rc4. Logs and other details at:
...
PM: chip retention via dynamic idle: FAIL ( 7/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom
PM: chip off except CORE via suspend: FAIL ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm
PM: chip off via suspend: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom
PM: chip off via dynamic idle: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom
With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work.
Maybe you are using legacy booting path to idle the UARTs still?
FYI, I'm doing this to find the UART entries:
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done
echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
Regards,
Tony
On Mon, 7 Jul 2014, Tony Lindgren wrote:
With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work.
Maybe you are using legacy booting path to idle the UARTs still?
FYI, I'm doing this to find the UART entries:
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done
echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
OK thanks, I'll take a close look at it. It's not using the legacy paths, but based on a glance at the 37xxevm logs, it looks like the bus address of the UART isn't right.
- Paul
* Paul Walmsley paul@pwsan.com [140714 10:32]:
On Mon, 7 Jul 2014, Tony Lindgren wrote:
With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work.
Maybe you are using legacy booting path to idle the UARTs still?
FYI, I'm doing this to find the UART entries:
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done
echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
OK thanks, I'll take a close look at it. It's not using the legacy paths, but based on a glance at the 37xxevm logs, it looks like the bus address of the UART isn't right.
Hmm for which UART? I'm using ttyO2 on my 37xxevm FYI, it can be selected on the board based on some switch settings. I may have patched my u-boot for that too but don't remember for sure.
Regards,
Tony
On Mon, 14 Jul 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140714 10:32]:
On Mon, 7 Jul 2014, Tony Lindgren wrote:
With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work.
Maybe you are using legacy booting path to idle the UARTs still?
FYI, I'm doing this to find the UART entries:
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done
echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
OK thanks, I'll take a close look at it. It's not using the legacy paths, but based on a glance at the 37xxevm logs, it looks like the bus address of the UART isn't right.
Hmm for which UART? I'm using ttyO2 on my 37xxevm FYI, it can be selected on the board based on some switch settings. I may have patched my u-boot for that too but don't remember for sure.
Sorry, I should have been more specific. The path name that the script here was using to write to the 'wakeup' file contained the base address. It's probably just best to set them via /sys/class/tty as you do.
- Paul
On Mon, 7 Jul 2014, Tony Lindgren wrote:
With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work.
Just to follow up briefly on this: there was indeed a bug in the OMAP3 test scripts here that resulted in the UART wakeup not being enabled.
Once that was fixed, system suspend-based chip-retention and chip-off modes work.
However, scheduler-idle based chip-retention and chip-off still are not working. Looking at the logs, it appears that some domains are not dynamically going idle. For example, looking at:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc6/20140724142225/pm/37xxevm/...
it can be seen that core_pwrdm's retention count doesn't increase between the two PM debug dumps. The important lines are:
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
and
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
That's why the test reports mark the dynamic PM modes as failing.
...
Here's an example where things worked:
http://www.pwsan.com/omap/testlogs/test_v3.10/20130717134228/pm/3530es3beagl...
In this one, it can be seen that the CORE counts transitioned from:
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
to
core_pwrdm (ON),OFF:0,RET:10,INA:0,ON:11,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
between the retention suspend/resume test ending and the dynamic retention idle test ending.
- Paul
# # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:333,INA:0,ON:334,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:333,INA:0,ON:334,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:297,INA:36,ON:334,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:297,INA:36,ON:334,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (1) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (15) cam_clkdm->cam_pwrdm (0) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (22) core_l3_clkdm->core_pwrdm (1) neon_clkdm->neon_pwrdm (0) # # # # ./test_rootfs_access_nonexistent_file__ret_susp
/bin/sh: 32: ./test_rootfs_access_nonexistent_file__ret_susp: not found # # %% End retention double suspend/resume UART wakeup test
%% Start retention dynamic idle UART wakeup test
for u in `ls -1d /sys/bus/platform/drivers/omap_uart/*.serial | paste -s -d' '`; do echo 3000 > $u/power/autosuspend_delay_ms; done
# #
# #
# # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:433,INA:0,ON:434,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:23,INA:0,ON:24,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:0,RET:433,INA:0,ON:434,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:0,RET:393,INA:40,ON:434,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:0,RET:393,INA:40,ON:434,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (1) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (13) cam_clkdm->cam_pwrdm (0) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (21) core_l3_clkdm->core_pwrdm (1) neon_clkdm->neon_pwrdm (0) # #
# # ./test_rootfs_access_nonexistent_file__ret_dyn
/bin/sh: 44: ./test_rootfs_access_nonexistent_file__ret_dyn: not found # # for u in `ls -1d /sys/bus/platform/drivers/omap_uart/*.serial | paste -s -d' '`; do echo -1 > $u/power/autosuspend_delay_ms; done
# # %% End retention dynamic idle UART wakeup test
* Paul Walmsley paul@pwsan.com [140725 12:16]:
On Mon, 7 Jul 2014, Tony Lindgren wrote:
With v3.16-rc4 the PM features for omap3 should be working finally for device tree based booting. At lest beaglexm and 3xxevm should work.
Just to follow up briefly on this: there was indeed a bug in the OMAP3 test scripts here that resulted in the UART wakeup not being enabled.
Once that was fixed, system suspend-based chip-retention and chip-off modes work.
OK
However, scheduler-idle based chip-retention and chip-off still are not working. Looking at the logs, it appears that some domains are not dynamically going idle. For example, looking at:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc6/20140724142225/pm/37xxevm/...
it can be seen that core_pwrdm's retention count doesn't increase between the two PM debug dumps. The important lines are:
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
and
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
That's why the test reports mark the dynamic PM modes as failing.
...
Here's an example where things worked:
http://www.pwsan.com/omap/testlogs/test_v3.10/20130717134228/pm/3530es3beagl...
In this one, it can be seen that the CORE counts transitioned from:
core_pwrdm (ON),OFF:0,RET:2,INA:0,ON:3,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
to
core_pwrdm (ON),OFF:0,RET:10,INA:0,ON:11,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
between the retention suspend/resume test ending and the dynamic retention idle test ending.
Hmm I think the difference with the working v3.10 one is that you have root=/dev/mmcblk0p2 instead of root=/dev/nfs. As the Ethernet on beagle is on the USB EHCI, this is still blocking the deeper idle states AFAIK.
Care to test -rc7 with root=/dev/mmcblk0p2 to see if that works?
On the am37xx-evm nfsroot will work as it's on the GPMC bus.
Regards,
Tony
On Mon, 28 Jul 2014, Tony Lindgren wrote:
Hmm I think the difference with the working v3.10 one is that you have root=/dev/mmcblk0p2 instead of root=/dev/nfs. As the Ethernet on beagle is on the USB EHCI, this is still blocking the deeper idle states AFAIK.
Hmm? There's no Ethernet on the 3530 Beagle.
The hardware configuration on those two boards - the 37xxevm and the 3530es3beagle - hasn't changed between the two test runs, AFAIK.
Just to take the Beagle out of the equation, here's a test with the 37xxevm on 3.11 where it passes the dynamic idle tests:
http://www.pwsan.com/omap/testlogs/test_v3.11/20130902150604/pm/37xxevm/37xx...
And here's one on the 37xxevm on 3.16-rc7 where it fails:
http://www.pwsan.com/omap/testlogs/test_v3.11/20130902150604/pm/37xxevm/37xx...
I should probably read back those writes to autosuspend_delay_ms, just to make sure they are reaching the right destinations. But you might want to confirm that you can see the CORE RET count increasing during dynamic idle on your 37xxevm.
- Paul
* Paul Walmsley paul@pwsan.com [140729 01:27]:
On Mon, 28 Jul 2014, Tony Lindgren wrote:
Hmm I think the difference with the working v3.10 one is that you have root=/dev/mmcblk0p2 instead of root=/dev/nfs. As the Ethernet on beagle is on the USB EHCI, this is still blocking the deeper idle states AFAIK.
Hmm? There's no Ethernet on the 3530 Beagle.
The hardware configuration on those two boards - the 37xxevm and the 3530es3beagle - hasn't changed between the two test runs, AFAIK.
Oh it's the original beagle, sorry. In that case the uart wake interrupts need to be enabled for the serial wake to work. I did not do that as I don't have one. I guess that might explain why it fails? Or are you using RTC wake for your test?
Just to take the Beagle out of the equation, here's a test with the 37xxevm on 3.11 where it passes the dynamic idle tests:
http://www.pwsan.com/omap/testlogs/test_v3.11/20130902150604/pm/37xxevm/37xx...
And here's one on the 37xxevm on 3.16-rc7 where it fails:
http://www.pwsan.com/omap/testlogs/test_v3.11/20130902150604/pm/37xxevm/37xx...
Wrong link here :) It should be:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc7/20140727174803/pm/37xxevm/...
I should probably read back those writes to autosuspend_delay_ms, just to make sure they are reaching the right destinations. But you might want to confirm that you can see the CORE RET count increasing during dynamic idle on your 37xxevm.
Hmm seems to work on 37xxevm for me with my retention test script:
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done
echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode
Which produces:
core_pwrdm (ON),OFF:0,RET:7,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
And then setting enable_off_mode:
core_pwrdm (ON),OFF:15,RET:100,INA:8,ON:124,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
And I'm using UART3 like I mentioned earlier, but I doubt that makes a difference.
Are you maybe missing "echo auto > $uart/control"?
Regards,
Tony
On Tue, 29 Jul 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140729 01:27]:
On Mon, 28 Jul 2014, Tony Lindgren wrote:
Hmm I think the difference with the working v3.10 one is that you have root=/dev/mmcblk0p2 instead of root=/dev/nfs. As the Ethernet on beagle is on the USB EHCI, this is still blocking the deeper idle states AFAIK.
Hmm? There's no Ethernet on the 3530 Beagle.
The hardware configuration on those two boards - the 37xxevm and the 3530es3beagle - hasn't changed between the two test runs, AFAIK.
Oh it's the original beagle, sorry. In that case the uart wake interrupts need to be enabled for the serial wake to work. I did not do that as I don't have one. I guess that might explain why it fails? Or are you using RTC wake for your test?
Serial wake works fine. But the chip never enters dynamic retention idle as measured by the pm_debug/count differential for CORE powerdomain. Works OK with static suspend.
Wrong link here :) It should be:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc7/20140727174803/pm/37xxevm/...
Oops indeed :-)
I should probably read back those writes to autosuspend_delay_ms, just to make sure they are reaching the right destinations. But you might want to confirm that you can see the CORE RET count increasing during dynamic idle on your 37xxevm.
Hmm seems to work on 37xxevm for me with my retention test script:
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done
echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode
Which produces:
core_pwrdm (ON),OFF:0,RET:7,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
And then setting enable_off_mode:
core_pwrdm (ON),OFF:15,RET:100,INA:8,ON:124,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
OK thanks for the point of comparison.
And I'm using UART3 like I mentioned earlier, but I doubt that makes a difference.
Are you maybe missing "echo auto > $uart/control"?
It should be doing both of those things, according to the logs:
-------- # # for u in `ls -1d /sys/class/tty/ttyO* | paste -s -d' '`; do echo enabled > $u/power/wakeup; done
# %% Start retention double suspend/resume UART wakeup test
# for u in `ls -1d /sys/class/tty/ttyO* | paste -s -d' '`; do echo auto > $u/power/control; done --------
I will add code to read back the values from the sysfs files, just to make sure they are being set.
- Paul
* Paul Walmsley paul@pwsan.com [140729 06:00]:
On Tue, 29 Jul 2014, Paul Walmsley wrote:
I will add code to read back the values from the sysfs files, just to make sure they are being set.
Confirmed that they are.
Hmm maybe different u-boot version then? I'm using 2014.04-00001-g5f09f5b.
Are you using NFS root on 37xxevm or MMC root?
Using nfsroot and omap2plus_defconfig. My dmesg attached in case it provides some clues. I don't have console=ttyO here, but I've verified that it works with that too.
Regards,
Tony
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.16.0-rc7 (tmlind@muffinssi) (gcc version 4.7.2 (Debian 4.7.2-5) ) #291 SMP Tue Jul 29 07:37:49 PDT 2014 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: TI OMAP37XX EVM (TMDSEVM3730) [ 0.000000] cma: CMA: reserved 16 MiB at 8e800000 [ 0.000000] Memory policy: Data cache writeback [ 0.000000] On node 0 totalpages: 65280 [ 0.000000] free_area_init_node: node 0, pgdat c08c0c00, node_mem_map cfcf1000 [ 0.000000] Normal zone: 512 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 65280 pages, LIFO batch:15 [ 0.000000] HighMem zone: 1048574 pages exceeds freesize 0 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [ 0.000000] PERCPU: Embedded 9 pages/cpu @cfc7d000 s14336 r8192 d14336 u36864 [ 0.000000] pcpu-alloc: s14336 r8192 d14336 u36864 alloc=9*4096 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [ 0.000000] Kernel command line: root=/dev/nfs ip=dhcp debug earlyprintk omapfb.vram=0:2M,1:5M omapfb.rotate=0 init=/root/init [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 224728K/261120K available (5659K kernel code, 681K rwdata, 2200K rodata, 402K init, 8209K bss, 36392K reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xffe00000 (2048 kB) [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc07b51dc (7861 kB) [ 0.000000] .init : 0xc07b6000 - 0xc081a800 ( 402 kB) [ 0.000000] .data : 0xc081c000 - 0xc08c6570 ( 682 kB) [ 0.000000] .bss : 0xc08c6570 - 0xc10caa60 (8210 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts [ 0.000000] Total of 96 interrupts on 1 active controller [ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000030] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65536000000000ns [ 0.000030] OMAP clocksource: 32k_counter at 32768 Hz [ 0.001159] Console: colour dummy device 80x30 [ 0.004669] console [tty0] enabled [ 0.004699] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.004760] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.004791] ... MAX_LOCK_DEPTH: 48 [ 0.004791] ... MAX_LOCKDEP_KEYS: 8191 [ 0.004821] ... CLASSHASH_SIZE: 4096 [ 0.004852] ... MAX_LOCKDEP_ENTRIES: 32768 [ 0.004882] ... MAX_LOCKDEP_CHAINS: 65536 [ 0.004913] ... CHAINHASH_SIZE: 32768 [ 0.004943] memory used by lock dependency info: 5167 kB [ 0.004974] per task-struct memory footprint: 1152 bytes [ 0.005065] Calibrating delay loop... 594.73 BogoMIPS (lpj=2973696) [ 0.097656] pid_max: default: 32768 minimum: 301 [ 0.098236] Security Framework initialized [ 0.098449] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.098510] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.101837] CPU: Testing write buffer coherency: ok [ 0.103424] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [ 0.103576] Setting up static identity map for 0x8055d2c0 - 0x8055d330 [ 0.108398] Brought up 1 CPUs [ 0.108459] SMP: Total of 1 processors activated. [ 0.108489] CPU: All CPU(s) started in SVC mode. [ 0.112365] devtmpfs: initialized [ 0.123168] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 [ 0.205596] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp [ 0.208068] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp [ 0.302490] omap_hwmod: mcbsp2: cannot be enabled for reset (3) [ 0.320434] pinctrl core: initialized pinctrl subsystem [ 0.324096] regulator-dummy: no parameters [ 0.420104] NET: Registered protocol family 16 [ 0.429107] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.432617] cpuidle: using governor ladder [ 0.432678] cpuidle: using governor menu [ 0.441406] Reprogramming SDRC clock to 400000000 Hz [ 0.454162] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [ 0.455535] OMAP GPIO hardware version 2.5 [ 0.457519] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [ 0.460296] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [ 0.463012] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [ 0.465698] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [ 0.468414] gpiochip_add: registered GPIOs 160 to 191 on device: gpio [ 0.469879] irq: no irq domain found for /ocp/pinmux@48002030 ! [ 0.470733] irq: no irq domain found for /ocp/pinmux@48002030 ! [ 0.471557] irq: no irq domain found for /ocp/pinmux@48002030 ! [ 0.494659] omap-gpmc 6e000000.gpmc: GPMC revision 5.0 [ 0.496246] gpmc_probe_nand_child: ti,elm-id property not found [ 0.496459] gpmc_cs_program_settings: invalid width 0! [ 0.498962] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' [ 0.507354] No ATAGs? [ 0.507415] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.511108] OMAP DMA hardware revision 5.0 [ 0.551330] edma-dma-engine edma-dma-engine.0: Can't allocate PaRAM dummy slot [ 0.551483] edma-dma-engine: probe of edma-dma-engine.0 failed with error -5 [ 0.605987] omap-dma-engine 48056000.dma-controller: OMAP DMA engine driver [ 0.607360] of_get_named_gpiod_flags: can't parse gpios property of node '/regulator-vddvario[0]' [ 0.608215] vddvario: no parameters [ 0.608886] of_get_named_gpiod_flags: can't parse gpios property of node '/regulator-vdd33a[0]' [ 0.609466] vdd33a: no parameters [ 0.610137] reg-fixed-voltage wl12xx_vmmc: could not find pctldev for node /ocp/pinmux@48002030/pinmux_wl12xx_gpio, deferring probe [ 0.610229] platform wl12xx_vmmc: Driver reg-fixed-voltage requests probe deferral [ 0.610504] of_get_named_gpiod_flags exited with status 0 [ 0.611389] lcd_3v3: 3300 mV [ 0.617828] SCSI subsystem initialized [ 0.619049] usbcore: registered new interface driver usbfs [ 0.619354] usbcore: registered new interface driver hub [ 0.619964] usbcore: registered new device driver usb [ 0.773498] omap_i2c 48070000.i2c: bus 0 rev4.4 at 2600 kHz [ 0.775390] omap_i2c 48072000.i2c: bus 1 rev4.4 at 400 kHz [ 0.780242] omap_i2c 48060000.i2c: bus 2 rev4.4 at 400 kHz [ 0.787780] Switched to clocksource 32k_counter [ 1.009338] NET: Registered protocol family 2 [ 1.011840] TCP established hash table entries: 2048 (order: 1, 8192 bytes) [ 1.012115] TCP bind hash table entries: 2048 (order: 4, 73728 bytes) [ 1.013275] TCP: Hash tables configured (established 2048 bind 2048) [ 1.013488] TCP: reno registered [ 1.013549] UDP hash table entries: 256 (order: 2, 20480 bytes) [ 1.013885] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) [ 1.015533] NET: Registered protocol family 1 [ 1.018127] RPC: Registered named UNIX socket transport module. [ 1.018188] RPC: Registered udp transport module. [ 1.018218] RPC: Registered tcp transport module. [ 1.018249] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 1.020080] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available [ 1.028137] futex hash table entries: 256 (order: 2, 16384 bytes) [ 1.034179] VFS: Disk quotas dquot_6.5.2 [ 1.034423] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.038482] NFS: Registering the id_resolver key type [ 1.039031] Key type id_resolver registered [ 1.039062] Key type id_legacy registered [ 1.039276] jffs2: version 2.2. (NAND) (SUMMARY) \xffffffc2\xffffffa9\xffffffa9 2001-2006 Red Hat, Inc. [ 1.039947] msgmni has been set to 470 [ 1.046936] io scheduler noop registered [ 1.047119] io scheduler deadline registered [ 1.047271] io scheduler cfq registered (default) [ 1.051239] pinctrl-single 48002030.pinmux: 284 pins at pa fa002030 size 568 [ 1.052062] pinctrl-single 48002a00.pinmux: 46 pins at pa fa002a00 size 92 [ 1.053161] pinctrl-single 480025a0.pinmux: 46 pins at pa fa0025a0 size 92 [ 1.056640] pbias_mmc_omap2430: 1800 <--> 3000 mV at 3000 mV [ 1.059082] abb_mpu_iva: 1012 <--> 1375 mV [ 1.060546] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.070648] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@4806a000[0]' [ 1.071319] 4806a000.serial: ttyO0 at MMIO 0x4806a000 (irq = 88, base_baud = 3000000) is a OMAP UART0 [ 1.075195] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@4806c000[0]' [ 1.075653] 4806c000.serial: ttyO1 at MMIO 0x4806c000 (irq = 89, base_baud = 3000000) is a OMAP UART1 [ 1.079376] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@49020000[0]' [ 1.079833] 49020000.serial: ttyO2 at MMIO 0x49020000 (irq = 90, base_baud = 3000000) is a OMAP UART2 [ 1.081939] omap_uart 49042000.serial: no wakeirq for uart0 [ 1.082031] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/serial@49042000[0]' [ 1.082427] 49042000.serial: ttyO3 at MMIO 0x49042000 (irq = 96, base_baud = 3000000) is a OMAP UART3 [ 1.120300] brd: module loaded [ 1.142852] loop: module loaded [ 1.163208] twl 0-0048: PIH (irq 23) chaining IRQs 341..349 [ 1.163818] twl 0-0048: power (irq 346) chaining IRQs 349..356 [ 1.171874] VAUX1: at 3000 mV [ 1.176086] VAUX2_4030: at 1800 mV [ 1.180084] VAUX3: at 2800 mV [ 1.184020] VAUX4: at 2800 mV [ 1.188049] VDD1: 600 <--> 1450 mV at 1200 mV [ 1.191833] VDAC: 1800 mV [ 1.198486] VIO: at 1800 mV [ 1.203399] VINTANA1: 1500 mV [ 1.208038] VINTANA2: at 2750 mV [ 1.211364] VINTDIG: 1500 mV [ 1.214691] VMMC1: 1850 <--> 3150 mV at 3000 mV [ 1.218872] VMMC2: 1850 <--> 3150 mV at 2600 mV [ 1.222015] VUSB1V5: 1500 mV [ 1.224121] VUSB1V8: 1800 mV [ 1.226165] VUSB3V1: 3100 mV [ 1.234100] VPLL1: at 1800 mV [ 1.240905] VPLL2: 1800 mV [ 1.244842] VSIM: 1800 <--> 3000 mV at 1800 mV [ 1.248443] twl4030_gpio twl4030-gpio: gpio (irq 341) chaining IRQs 357..374 [ 1.249481] gpiochip_find_base: found new base at 492 [ 1.250457] gpiochip_add: registered GPIOs 492 to 511 on device: twl4030 [ 1.351745] mtdoops: mtd device (mtddev=name/number) must be supplied [ 1.383422] libphy: smsc911x-mdio: probed [ 1.457794] smsc911x 2c000000.ethernet eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=2c000000.etherne:01, irq=-1) [ 1.458160] smsc911x 2c000000.ethernet eth0: MAC Address: 00:12:34:56:78:90 [ 1.460418] usbcore: registered new interface driver asix [ 1.460693] usbcore: registered new interface driver ax88179_178a [ 1.460906] usbcore: registered new interface driver cdc_ether [ 1.461212] usbcore: registered new interface driver smsc95xx [ 1.461425] usbcore: registered new interface driver net1080 [ 1.461639] usbcore: registered new interface driver cdc_subset [ 1.461883] usbcore: registered new interface driver zaurus [ 1.462219] usbcore: registered new interface driver cdc_ncm [ 1.463928] usbcore: registered new interface driver cdc_wdm [ 1.464294] usbcore: registered new interface driver usb-storage [ 1.464599] usbcore: registered new interface driver usbtest [ 1.468109] mousedev: PS/2 mouse device common for all mice [ 1.469604] twl4030_keypad 48070000.i2c:twl@48:keypad: OF: linux,keymap property not defined in /ocp/i2c@48070000/twl@48/keypad [ 1.469665] twl4030_keypad 48070000.i2c:twl@48:keypad: Failed to build keymap [ 1.469818] twl4030_keypad: probe of 48070000.i2c:twl@48:keypad failed with error -2 [ 1.471496] of_get_named_gpiod_flags exited with status 0 [ 1.548706] ads7846 spi1.0: touchscreen, irq 287 [ 1.551727] input: ADS7846 Touchscreen as /devices/68000000.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input1 [ 1.559204] input: twl4030_pwrbutton as /devices/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:pwrbutton/input/input2 [ 1.562530] twl_rtc 48070000.i2c:twl@48:rtc: Power up reset detected. [ 1.563171] twl_rtc 48070000.i2c:twl@48:rtc: Enabling TWL-RTC [ 1.570068] twl_rtc 48070000.i2c:twl@48:rtc: rtc core: registered 48070000.i2c:twl@48 as rtc0 [ 1.571868] i2c /dev entries driver [ 1.575744] Driver for 1-wire Dallas network protocol. [ 1.580627] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec [ 1.585296] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@4809c000[0]' [ 1.585357] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@4809c000[0]' [ 1.637634] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@480b4000[0]' [ 1.637725] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@480b4000[0]' [ 1.638488] omap_hsmmc 480b4000.mmc: unable to get vmmc regulator -517 [ 1.639190] platform 480b4000.mmc: Driver omap_hsmmc requests probe deferral [ 1.640533] of_get_named_gpiod_flags exited with status 0 [ 1.640624] of_get_named_gpiod_flags exited with status 0 [ 1.648895] ledtrig-cpu: registered to indicate activity on CPUs [ 1.650207] usbcore: registered new interface driver usbhid [ 1.650268] usbhid: USB HID core driver [ 1.652954] oprofile: using arm/armv7 [ 1.653808] TCP: cubic registered [ 1.653869] Initializing XFRM netlink socket [ 1.654052] NET: Registered protocol family 17 [ 1.654174] NET: Registered protocol family 15 [ 1.654693] Key type dns_resolver registered [ 1.655090] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva [ 1.655151] omap2_set_init_voltage: unable to set vdd_mpu_iva [ 1.655212] omap2_set_init_voltage: unable to find boot up OPP for vdd_core [ 1.655242] omap2_set_init_voltage: unable to set vdd_core [ 1.660217] ThumbEE CPU extension supported. [ 1.660339] Registering SWP/SWPB emulation handler [ 1.660369] SmartReflex Class3 initialized [ 1.670257] of_get_named_gpiod_flags exited with status 0 [ 1.671325] vwl1271: 1800 mV [ 1.671600] vwl1271: supplied by VMMC2 [ 1.673278] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@480b4000[0]' [ 1.673339] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc@480b4000[0]' [ 1.802642] twl_rtc 48070000.i2c:twl@48:rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [ 1.802734] sr_init: No PMIC hook to init smartreflex [ 1.803344] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [ 1.804321] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [ 1.981872] smsc911x 2c000000.ethernet eth0: SMSC911x/921x identified at 0xd087c000, IRQ: 288 [ 4.477233] Sending DHCP requests ., OK [ 4.497253] IP-Config: Got DHCP answer from 192.168.111.1, my address is 192.168.111.253 [ 4.497711] IP-Config: Complete: [ 4.497772] device=eth0, hwaddr=00:50:c2:7e:99:47, ipaddr=192.168.111.253, mask=255.255.255.0, gw=192.168.111.1 [ 4.497833] host=omap3evm, domain=muru.com, nis-domain=(none) [ 4.497863] bootserver=192.168.111.8, rootserver=192.168.111.8, rootpath=/srv/nfs3/armhf,v3 [ 4.497894] nameserver0=192.168.1.254 [ 4.498321] vwl1271: disabling [ 4.499664] VUSB3V1: disabling [ 4.532409] VFS: Mounted root (nfs filesystem) readonly on device 0:13. [ 4.534545] devtmpfs: mounted [ 4.535583] Freeing unused kernel memory: 400K (c07b6000 - c081a000) [ 6.771423] random: sshd urandom read with 46 bits of entropy available
On Tue, 29 Jul 2014, Tony Lindgren wrote:
Hmm maybe different u-boot version then? I'm using 2014.04-00001-g5f09f5b.
Are you using NFS root on 37xxevm or MMC root?
Using nfsroot and omap2plus_defconfig. My dmesg attached in case it provides some clues. I don't have console=ttyO here, but I've verified that it works with that too.
Walked through the PM test script by hand, and the proximal cause of the problem became obvious...
Turns out a five-second delay for a three-second autosuspend_delay_ms is no longer sufficient time for kernels to enter idle. A ten-second sleep seems to be long enough.
Not sure what exactly is causing that weirdness yet, or when that started happening. Am suspecting it could be some of the RCU changes over the past couple of years. We don't have RCU_FAST_NO_HZ enabled in omap2plus_defconfig; we should probably switch that on.
Now 37xxevm and the 3730beaglexm are entering idle as they should be. Test report below; logs etc. have been uploaded. Thanks for the debug discussion,
- Paul
OMAP baseline test results for v3.16-rc7
Here are some basic OMAP test results for Linux v3.16-rc7. Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc7/20140729083516/
Test summary ------------
Build: zImage: Pass (16/16): multi_v7_defconfig, omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_am43xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_dra7xx_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig
Build: uImage+dtb: Pass (10/10): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap5-uevm
Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only
Boot to userspace: FAIL ( 1/14): 2430sdp skip ( 1/14): 5912osk Pass (12/14): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom, 5430es2uevm
PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes
PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3730beaglexm, 37xxevm
PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm
PM: chip off via dynamic idle: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm
vmlinux object size (delta in bytes from test_v3.16-rc6 (9a3c4145af32125c5ee39c0272662b47307a8323)): text data bss total kernel +380 +24 0 +404 omap1_defconfig +380 0 0 +380 omap1_defconfig_1510innovator_only +348 -8 0 +340 omap1_defconfig_5912osk_only +412 +16 0 +428 multi_v7_defconfig +96 -16 0 +80 omap2plus_defconfig +704 -16 +32 +720 omap2plus_defconfig_2430sdp_only +96 -16 0 +80 omap2plus_defconfig_am33xx_only +96 +16 0 +112 omap2plus_defconfig_am43xx_only +96 +16 0 +112 omap2plus_defconfig_cpupm +96 +16 0 +112 omap2plus_defconfig_dra7xx_only +232 -8 0 +224 omap2plus_defconfig_n800_multi_omap2xxx +232 0 0 +232 omap2plus_defconfig_n800_only_a +96 +48 0 +144 omap2plus_defconfig_no_pm +160 +16 0 +176 omap2plus_defconfig_omap2_4_only +96 -16 0 +80 omap2plus_defconfig_omap3_4_only +160 -16 0 +144 omap2plus_defconfig_omap5_only +40 0 +12 +52 rmk_omap3430_ldp_allnoconfig +256 0 0 +256 rmk_omap3430_ldp_oldconfig +24 0 +28 +52 rmk_omap4430_sdp_allnoconfig +288 0 +64 +352 rmk_omap4430_sdp_oldconfig
Boot-time memory difference (delta in bytes from test_v3.16-rc6 (9a3c4145af32125c5ee39c0272662b47307a8323)) avail rsrvd high freed board kconfig (no differences)
* Paul Walmsley paul@pwsan.com [140729 12:39]:
On Tue, 29 Jul 2014, Tony Lindgren wrote:
Hmm maybe different u-boot version then? I'm using 2014.04-00001-g5f09f5b.
Are you using NFS root on 37xxevm or MMC root?
Using nfsroot and omap2plus_defconfig. My dmesg attached in case it provides some clues. I don't have console=ttyO here, but I've verified that it works with that too.
Walked through the PM test script by hand, and the proximal cause of the problem became obvious...
Turns out a five-second delay for a three-second autosuspend_delay_ms is no longer sufficient time for kernels to enter idle. A ten-second sleep seems to be long enough.
Oh OK.
Not sure what exactly is causing that weirdness yet, or when that started happening. Am suspecting it could be some of the RCU changes over the past couple of years. We don't have RCU_FAST_NO_HZ enabled in omap2plus_defconfig; we should probably switch that on.
OK
Now 37xxevm and the 3730beaglexm are entering idle as they should be. Test report below; logs etc. have been uploaded. Thanks for the debug discussion,
Great, good to hear you found what caused it :)
PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3730beaglexm, 37xxevm
PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm
PM: chip off via dynamic idle: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
Regards,
Tony
8< ----------------------------------- From: Tony Lindgren tony@atomide.com Date: Tue, 29 Jul 2014 22:36:59 -0700 Subject: [PATCH] ARM: dts: Enable UART wake-up events for beagleboard
For device tree based booting, we need to use wake-up interrupts like we already do for some omaps. This fixes a PM regression on beagleboard compared to legacy booting.
Signed-off-by: Tony Lindgren tony@atomide.com
--- a/arch/arm/boot/dts/omap3-beagle.dts +++ b/arch/arm/boot/dts/omap3-beagle.dts @@ -292,6 +292,7 @@ &uart3 { pinctrl-names = "default"; pinctrl-0 = <&uart3_pins>; + interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>; };
&gpio1 {
On Tue, 29 Jul 2014, Tony Lindgren wrote:
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others).
http://www.pwsan.com/omap/testlogs/next_20140729/20140730010841/pm/3530es3be...
Adding the patch you sent doesn't change that, but now some extra warning messages appear ("PRM: I/O chain clock line assertion timed out"):
http://www.pwsan.com/omap/testlogs/next_20140729_beagle_pm/20140730004856/pm...
- Paul
* Paul Walmsley paul@pwsan.com [140730 00:55]:
On Tue, 29 Jul 2014, Tony Lindgren wrote:
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others).
I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm.
http://www.pwsan.com/omap/testlogs/next_20140729/20140730010841/pm/3530es3be...
Adding the patch you sent doesn't change that, but now some extra warning messages appear ("PRM: I/O chain clock line assertion timed out"):
http://www.pwsan.com/omap/testlogs/next_20140729_beagle_pm/20140730004856/pm...
Weird it should just work. I don't know why the "PRM: I/O chain clock line assertion timed out" happens for you, I have not seen that. So far I've tested it on n900, beagle xm and 37xx-evm. None of those are 3530 though, but it should behave the same way as on n900.
Regards,
Tony
On Thu, 31 Jul 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140730 00:55]:
On Tue, 29 Jul 2014, Tony Lindgren wrote:
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others).
I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm.
I ran the full set of tests across all boards. The only board that passed the dynamic idle testing on next-20140729 was the 3730beaglexm.
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/README.txt
37xxevm hangs on the first suspend entry:
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/pm/37xxevm/3...
If I find some extra time, I'll set up a bisection run.
- Paul
* Paul Walmsley paul@pwsan.com [140731 12:29]:
On Thu, 31 Jul 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140730 00:55]:
On Tue, 29 Jul 2014, Tony Lindgren wrote:
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others).
I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm.
I ran the full set of tests across all boards. The only board that passed the dynamic idle testing on next-20140729 was the 3730beaglexm.
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/README.txt
37xxevm hangs on the first suspend entry:
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/pm/37xxevm/3...
If I find some extra time, I'll set up a bisection run.
OK that sounds like some driver suspend regression that needs to be tracked down. I'm seeing it on my 37xx evm also with linux next too.
Regards,
Tony
* Tony Lindgren tony@atomide.com [140801 00:14]:
- Paul Walmsley paul@pwsan.com [140731 12:29]:
On Thu, 31 Jul 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140730 00:55]:
On Tue, 29 Jul 2014, Tony Lindgren wrote:
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others).
I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm.
I ran the full set of tests across all boards. The only board that passed the dynamic idle testing on next-20140729 was the 3730beaglexm.
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/README.txt
37xxevm hangs on the first suspend entry:
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/pm/37xxevm/3...
If I find some extra time, I'll set up a bisection run.
OK that sounds like some driver suspend regression that needs to be tracked down. I'm seeing it on my 37xx evm also with linux next too.
With no_console_suspend I'm seeing the following for smsc911x. This does not happen with v3.16-rc, and there have been no changes to smsc911x.c, so sounds like a good candidate for an automated bisect and boot test.
Regards,
Tony
[ 47.804443] PM: Syncing filesystems ... done. [ 47.807342] PM: Preparing system for mem sleep [ 47.817871] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 47.821258] Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done. [ 47.825073] PM: Entering mem sleep [ 47.838897] random: nonblocking pool is initialized [ 47.839630] Unable to handle kernel NULL pointer dereference at virtual address 00000698 [ 47. *pte=00000000, *ppte=00000000 [ 47.840423] Internal error: Oops: 17 [#1] SMP ARM [ 47.840545] Modules linked in: [ 47.840728] CPU: 0 PID: 882 Comm: bash Not tainted 3.16.0-rc7-next-20140731-10331-ge9fab93 #303 [ 47.840942] task: ce4dd140 ti: ce508000 task.ti: ce508000 [ 47.841125] PC is at __lock_acquire+0x128/0xb78 [ 47.841247] LR is at lock_acquire+0xa4/0x10c [ 47.841369] pc : [<c0088524>] lr : [<c00894d8>] psr: 20010093 [ 47.841369] sp : ce509c68 ip : ce508000 fp : ce509cc4 [ 47.841583] r10: 00000000 r9 : 00000000 r8 : ce4dd140 [ 47.841766] r7 : 00000698 r6 : c097d068 r5 : c1165764 r4 : 00000001 [ 47.841888] r3 : c09676f0 r2 : 00000001 r1 : 00000000 r0 : 00000698 [ 47.842071] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 47.842254] Control: 10c5387d Table: 8e534019 DAC: 00000015 [ 47.842376] Process bash (pid: 882, stack limit = 0xce508248) [ 47.842559] Stack: (0xce509c68 to 0xce50a000) [ 47.842681] 9c60: ce4dd700 00000000 00000000 00000000 00011e89 f8316096 [ 47.842895] 9c80: 0000000 [ 47.843017] 9ca0: 00000698 00000000 00000000 00000000 ce508000 c0436c94 ce509d14 ce509cc8 [ 47.843231] 9cc0: c00894d8 c0088408 00000001 00000080 00000000 c0436c94 00000000 00000006 [ 47.843444] 9ce0: ce4dd140 60010093 ce593cac 00000688 60010013 c0436c94 00000002 00000002 [ 47.843658] 9d00: c07a83e8 c0436c6c ce509d44 ce509d18 c05db420 c0089440 00000001 00000000 [ 47.843811] 9d20: c0436c94 60010013 c1165764 00000000 00000688 ce593c78 ce509d64 ce509d48 [ 47.844024] 9d40: c0436c94 c05db3dc c09b43b0 00000000 00000000 ce593c78 ce509da4 ce509d68 [ 47.844238] 9d60: c03bbc88 c0436c78 ce509d8c ce509d78 00000000 00000000 00000000 ce593c78 [ 47.844451] 9d80: 00000000 c11aa6d8 000000 da0: c03bce3c c03bbc40 ce593c78 009886cc c11aa6d8 ce593c78 c09886cc c11aa6d8 [ 47.844787] 9dc0: 00000000 00000002 ce509e14 ce5 05dbf74 0000000b 00000000 00000002 00000000 00000003 c09b6550 c1164e64 [ 47.845153] 9e00: 0000000c c077086c ce509e2c ce509e18 c03bea04 c03be2dc c1164e78 c1164e58 [ 47.845367] 9e20: ce509e7c ce509e30 c008f0c8 c03be9a8 c09b6550 c1164e64 0000000c c077086c [ 47.845550] 9e40: ce509e6c ce509e50 c05d158c c0092104 c07707d8 00000003 00000000 c0770848 [ 47.845764] 9e60: c09b6550 c1164e64 0000000c c077086c ce509eb4 ce509e80 c008f920 c008f03c [ 47.845916] 9e80: ce4dd140 c077086c ce509eb4 00000003 c076b6d4 c1164e68 00000003 ce377140 [ 47.846130] 9ea0: ce6a2e4c 00000004 ce509edc ce509eb8 c008e00c c008f534 ce6a2e40 00000004 [ 47.846343] 9ec0: ce377140 ce509f78 00000004 ce6a2e40 ce509eec ce509ee0 c032699c c008dfa0 [ 47.846557] 9ee0: ce509f0c ce509ef0 c01b109c c032698c c01b1040 00000000 00000000 ce377140 [ 47.846679] 9f00: ce509f44 ce509f10 c01b0328 c01b104c 00000000 00000000 ce509f4c ce4cae00 [ 47.846893] 9f20: 00000004 000bcc08 ce509f78 00000004 ce508000 000bcc08 ce509f74 ce509f48 [ 47.847106] 9f40: c014406c c01b0250 c01604b4 c0160424 00000000 00000000 ce4cae00 ce4cae00 [ 47.847259] 9f60: 00000004 000bcc08 ce509fa4 ce509f78 c01444b4 c0143fc4 00000000 00000000 [ 47.847473] 9f80: 00000004 000bcc08 b6e94b50 00000004 c000f1c4 00000000 00000000 ce509fa8 [ 47.847686] 9fa0: c000ef40 c0144474 00000004 000bcc08 0000000 c08 b6e94b50 00000004 00000004 00000000 000b5174 00000000 [ 47.848052] 9fe0: 00000000 be94b92c b6e01671 b6e3a7c6 40010030 00000001 fffe7fff ffffffff [ 47.848266] [<c0088524>] (__lock_acquire) from [<c00894d8>] (lock_acquire+0xa4/0x10c) [ 47.848510] [<c00894d8>] (lock_acquire) from [<c05db420>] (_raw_spin_lock_irqsave+0x50/0x64) [ 47.848754] [<c05db420>] (_raw_spin_lock_irqsave) from [<c0436c94>] (smsc911x_suspend+0x28/0x5c) [ 47.848907] [<c0436c94>] (smsc911x_suspend) from [<c03bbc88>] (dpm_run_callback+0x54/0x108) [ 47.849121] [<c03bbc88>] (dpm_run_callback) from [<c03bce3c>] (__device_suspend+0x13c/0x388) [ 47.849334] [<c03bce3c>] (__device_suspend) from [<c03be340>] (dpm_suspend+0x70/0x2d0) [ 47.849548] [<c03be340>] (dpm_suspend) from [<c03bea04>] (dpm_suspend_start+0x68/0x70) [ 47.849670] [<c03bea04>] (dpm_suspend_start) from [<c008f0c8>] (suspend_devices_and_enter+0x98/0x4f8) [ 47.849914] [<c008f0c8>] (suspend_devices_and_enter) from [<c008f920>] (pm_suspend+0x3f8/0x470) [ 47.850128] [<c008f920>] (pm_suspend) from [<c008e00c>] (state_store+0x78/0xc8) [ 47.850250] [<c008e00c>] (state_store) from [<c032699c>] (kobj_attr_store+0x1c/0x28) [ 47.850463] [<c032699c>] (kobj_attr_store) from [<c01b109c>] (sysfs_kf_write+0x5c/0x60) [ 47.850677] [<c01b109c>] (sysfs_kf_write) from [<c01b0328>] (kernfs_fop_write+0xe4/0x198) [ 47.850891] [<c01b0328>] (kernfs_fop_wr 014406c>] (vfs_write) from [<c01444b4>] (SyS_write+0x4c/0x98) [ 47.851257] [<c01444b4>] (SyS_write) from [<c000ef40>] (ret_fast_syscall+0x0/0x48) [ 47.851470] Code: 1a00000e e3a00000 e24bd028 e89daff0 (e5971000) [ 47.851593] ---[ end trace c6b1f330200fefe5 ]---
On Fri, 1 Aug 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140731 12:29]:
On Thu, 31 Jul 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140730 00:55]:
On Tue, 29 Jul 2014, Tony Lindgren wrote:
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others).
I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm.
I ran the full set of tests across all boards. The only board that passed the dynamic idle testing on next-20140729 was the 3730beaglexm.
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/README.txt
37xxevm hangs on the first suspend entry:
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/pm/37xxevm/3...
If I find some extra time, I'll set up a bisection run.
OK that sounds like some driver suspend regression that needs to be tracked down. I'm seeing it on my 37xx evm also with linux next too.
It's commit a71e3c37960ce5f9c6a519bc1215e3ba9fa83e75:
Author: Ezequiel Garcia ezequiel.garcia@free-electrons.com Date: Wed Jul 23 16:47:31 2014 -0300
net: phy: Set the driver when registering an MDIO bus device
mdiobus_register() registers a device which is already bound to a driver. Hence, the driver pointer should be set properly in order to track down the driver associated to the MDIO bus.
This will be used to allow ethernet driver to pin down a MDIO bus driver, preventing it from being unloaded while the PHY device is running.
Reviewed-by: Florian Fainelli f.fainelli@gmail.com Tested-by: Florian Fainelli f.fainelli@gmail.com Signed-off-by: Ezequiel Garcia ezequiel.garcia@free-electrons.com Signed-off-by: David S. Miller davem@davemloft.net
What's bad is that this went in late during v3.16-rc fixes. So now v3.16 itself is broken, and there's no way to fix it.
As far as I can tell, this patch doesn't fix a regression. So no way it should have gone in during late -rc kernels.
- Paul
Hi,
On Thu, Aug 07, 2014 at 10:21:23PM +0000, Paul Walmsley wrote:
On Fri, 1 Aug 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140731 12:29]:
On Thu, 31 Jul 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140730 00:55]:
On Tue, 29 Jul 2014, Tony Lindgren wrote:
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others).
I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm.
I ran the full set of tests across all boards. The only board that passed the dynamic idle testing on next-20140729 was the 3730beaglexm.
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/README.txt
37xxevm hangs on the first suspend entry:
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/pm/37xxevm/3...
If I find some extra time, I'll set up a bisection run.
OK that sounds like some driver suspend regression that needs to be tracked down. I'm seeing it on my 37xx evm also with linux next too.
It's commit a71e3c37960ce5f9c6a519bc1215e3ba9fa83e75:
Author: Ezequiel Garcia ezequiel.garcia@free-electrons.com Date: Wed Jul 23 16:47:31 2014 -0300
net: phy: Set the driver when registering an MDIO bus devicemdiobus_register() registers a device which is already bound to a driver. Hence, the driver pointer should be set properly in order to track down the driver associated to the MDIO bus. This will be used to allow ethernet driver to pin down a MDIO bus driver, preventing it from being unloaded while the PHY device is running. Reviewed-by: Florian Fainelli f.fainelli@gmail.com Tested-by: Florian Fainelli f.fainelli@gmail.com Signed-off-by: Ezequiel Garcia ezequiel.garcia@free-electrons.com Signed-off-by: David S. Miller davem@davemloft.net
What's bad is that this went in late during v3.16-rc fixes. So now v3.16 itself is broken, and there's no way to fix it.
we have stable releases for that.
On Fri, Aug 08, 2014 at 06:11:54AM +0000, Paul Walmsley wrote:
On Thu, 7 Aug 2014, Felipe Balbi wrote:
we have stable releases for that.
Stable releases aren't a fix for process failures.
of course not, but your claim that there's no way to fix v3.16 is nonsense. And mistakes occur as well.
On Fri, 8 Aug 2014, Felipe Balbi wrote:
On Fri, Aug 08, 2014 at 06:11:54AM +0000, Paul Walmsley wrote:
On Thu, 7 Aug 2014, Felipe Balbi wrote:
we have stable releases for that.
Stable releases aren't a fix for process failures.
of course not, but your claim that there's no way to fix v3.16 is nonsense. And mistakes occur as well.
There is no way to fix v3.16.
The point of the -rc cycle is to stabilize the final, non-rc releases.
- Paul
Hi,
On Fri, Aug 08, 2014 at 11:39:08PM +0000, Paul Walmsley wrote:
On Fri, 8 Aug 2014, Felipe Balbi wrote:
On Fri, Aug 08, 2014 at 06:11:54AM +0000, Paul Walmsley wrote:
On Thu, 7 Aug 2014, Felipe Balbi wrote:
we have stable releases for that.
Stable releases aren't a fix for process failures.
of course not, but your claim that there's no way to fix v3.16 is nonsense. And mistakes occur as well.
There is no way to fix v3.16.
There is no way to fix *any* commit.
We can go back a few major releases and we will hit a point when ARM multiplatform was enabled and the tree doesn't even build. There is no way to fix that either, but I'm sure the patches fixing the build breaks have been back ported to stable.
The point of the -rc cycle is to stabilize the final, non-rc releases.
Well, stable release are *not* -rc releases and they exist in order to fix bugs that were found after the final release has been tagged; otherwise what would be the point of even having -stable ?
On Thu, Aug 7, 2014 at 7:21 PM, Paul Walmsley paul@pwsan.com wrote:
It's commit a71e3c37960ce5f9c6a519bc1215e3ba9fa83e75:
Author: Ezequiel Garcia ezequiel.garcia@free-electrons.com Date: Wed Jul 23 16:47:31 2014 -0300
net: phy: Set the driver when registering an MDIO bus device mdiobus_register() registers a device which is already bound to a driver. Hence, the driver pointer should be set properly in order to track down the driver associated to the MDIO bus. This will be used to allow ethernet driver to pin down a MDIO bus driver, preventing it from being unloaded while the PHY device is running. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>What's bad is that this went in late during v3.16-rc fixes. So now v3.16 itself is broken, and there's no way to fix it.
I have sent a patch reverting this commit and it is in mainline now. It will reach 3.16.1:
commit ce7991e8198b80eb6b4441b6f6114bea4a665d66 Author: Fabio Estevam fabio.estevam@freescale.com Date: Tue Aug 5 08:13:42 2014 -0300
Revert "net: phy: Set the driver when registering an MDIO bus device"
Commit a71e3c37960ce5f9 ("net: phy: Set the driver when registering an MDIO bus device") caused the following regression on the fec driver:
root@imx6qsabresd:~# echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.003 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. Unable to handle kernel NULL pointer dereference at virtual address 0000002c pgd = bcd14000 [0000002c] *pgd=4d9e0831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 0 PID: 617 Comm: sh Not tainted 3.16.0 #17 task: bc0c4e00 ti: bceb6000 task.ti: bceb6000 PC is at fec_suspend+0x10/0x70 LR is at dpm_run_callback.isra.7+0x34/0x6c pc : [<803f8a98>] lr : [<80361f44>] psr: 600f0013 sp : bceb7d70 ip : bceb7d88 fp : bceb7d84 r10: 8091523c r9 : 00000000 r8 : bd88f478 r7 : 803f8a88 r6 : 81165988 r5 : 00000000 r4 : 00000000 r3 : 00000000 r2 : 00000000 r1 : bd88f478 r0 : bd88f478 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 4cd1404a DAC: 00000015 Process sh (pid: 617, stack limit = 0xbceb6240) Stack: (0xbceb7d70 to 0xbceb8000) ....
The problem with the original commit is explained by Russell King:
"It has the effect (as can be seen from the oops) of attaching the MDIO bus device (itself is a bus-less device) to the platform driver, which means that if the platform driver supports power management, it will be called to power manage the MDIO bus device.
Moreover, drivers do not expect to be called for power management operations for devices which they haven't probed, and certainly not for devices which aren't part of the same bus that the driver is registered against."
This reverts commit a71e3c37960ce5f9c6a519bc1215e3ba9fa83e75.
Cc: stable@vger.kernel.org #3.16 Signed-off-by: Fabio Estevam fabio.estevam@freescale.com Signed-off-by: David S. Miller davem@davemloft.net
On Thu, 7 Aug 2014, Fabio Estevam wrote:
On Thu, Aug 7, 2014 at 7:21 PM, Paul Walmsley paul@pwsan.com wrote:
It's commit a71e3c37960ce5f9c6a519bc1215e3ba9fa83e75:
Author: Ezequiel Garcia ezequiel.garcia@free-electrons.com Date: Wed Jul 23 16:47:31 2014 -0300
net: phy: Set the driver when registering an MDIO bus device mdiobus_register() registers a device which is already bound to a driver. Hence, the driver pointer should be set properly in order to track down the driver associated to the MDIO bus. This will be used to allow ethernet driver to pin down a MDIO bus driver, preventing it from being unloaded while the PHY device is running. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>What's bad is that this went in late during v3.16-rc fixes. So now v3.16 itself is broken, and there's no way to fix it.
I have sent a patch reverting this commit and it is in mainline now.
That's great; thanks for letting us know.
The problem with the original commit is explained by Russell King: "It has the effect (as can be seen from the oops) of attaching the MDIO bus device (itself is a bus-less device) to the platform driver, which means that if the platform driver supports power management, it will be called to power manage the MDIO bus device. Moreover, drivers do not expect to be called for power management operations for devices which they haven't probed, and certainly not for devices which aren't part of the same bus that the driver is registered against."
Makes sense to me.
- Paul
On 07 Aug 10:21 PM, Paul Walmsley wrote:
On Fri, 1 Aug 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140731 12:29]:
On Thu, 31 Jul 2014, Tony Lindgren wrote:
- Paul Walmsley paul@pwsan.com [140730 00:55]:
On Tue, 29 Jul 2014, Tony Lindgren wrote:
The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one?
3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others).
I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm.
I ran the full set of tests across all boards. The only board that passed the dynamic idle testing on next-20140729 was the 3730beaglexm.
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/README.txt
37xxevm hangs on the first suspend entry:
http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/pm/37xxevm/3...
If I find some extra time, I'll set up a bisection run.
OK that sounds like some driver suspend regression that needs to be tracked down. I'm seeing it on my 37xx evm also with linux next too.
It's commit a71e3c37960ce5f9c6a519bc1215e3ba9fa83e75:
Author: Ezequiel Garcia ezequiel.garcia@free-electrons.com Date: Wed Jul 23 16:47:31 2014 -0300
net: phy: Set the driver when registering an MDIO bus devicemdiobus_register() registers a device which is already bound to a driver. Hence, the driver pointer should be set properly in order to track down the driver associated to the MDIO bus. This will be used to allow ethernet driver to pin down a MDIO bus driver, preventing it from being unloaded while the PHY device is running. Reviewed-by: Florian Fainelli f.fainelli@gmail.com Tested-by: Florian Fainelli f.fainelli@gmail.com Signed-off-by: Ezequiel Garcia ezequiel.garcia@free-electrons.com Signed-off-by: David S. Miller davem@davemloft.net
What's bad is that this went in late during v3.16-rc fixes. So now v3.16 itself is broken, and there's no way to fix it.
As far as I can tell, this patch doesn't fix a regression. So no way it should have gone in during late -rc kernels.
Indeed, the commit shouldn't have landed as a v3.16-rc fix. FWIW, it was originally intended for v3.17, but I wasn't clear enough about this when it was submitted.
On 07/30/2014 08:39 AM, Tony Lindgren wrote:
8< ----------------------------------- From: Tony Lindgrentony@atomide.com Date: Tue, 29 Jul 2014 22:36:59 -0700 Subject: [PATCH] ARM: dts: Enable UART wake-up events for beagleboard
For device tree based booting, we need to use wake-up interrupts like we already do for some omaps. This fixes a PM regression on beagleboard compared to legacy booting.
Signed-off-by: Tony Lindgrentony@atomide.com
--- a/arch/arm/boot/dts/omap3-beagle.dts +++ b/arch/arm/boot/dts/omap3-beagle.dts @@ -292,6 +292,7 @@ &uart3 { pinctrl-names = "default"; pinctrl-0 = <&uart3_pins>;
interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>; };
&gpio1 {
--
The above patch works for me with ret/off-idle on beagle rev C4 on top of 3.16-rc5. Without it, the board just seems to hang with ret, and with off, it just doesn't respond to anything on uart but seems alive otherwise.
Tested-by: Tero Kristo t-kristo@ti.com
On Tue, 29 Jul 2014, Paul Walmsley wrote:
I should probably read back those writes to autosuspend_delay_ms, just to make sure they are reaching the right destinations.
Just took a whack at that, looks like the autosuspend_delay_ms files are being set correctly:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc7/20140729023831/pm/37xxevm/...
By the way, it's not obvious from the logs, but there's a 'sleep 5' on the host between the autosuspend_delay_ms writes and the read of the pm_debug/count file...
- Paul
kernel-build-reports@lists.linaro.org
-
Ezequiel Garcia -
Fabio Estevam -
Felipe Balbi -
Paul Walmsley -
Tero Kristo -
Tony Lindgren