OMAP baseline test results for v3.16-rc4

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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. 

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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. 

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

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/3530es3beagle/3530es3beagle_log.txt

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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

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/3530es3beagle/3530es3beagle_log.txt

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

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/37xxevm_log.txt
> 
> 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/3530es3beagle/3530es3beagle_log.txt
> 
> 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

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/37xxevm_log.txt
> 
> 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/3530es3beagle/3530es3beagle_log.txt
> 
> 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

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

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/37xxevm_log.txt

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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

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/37xxevm_log.txt

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

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/37xxevm_log.txt
> 
> 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/37xxevm_log.txt

Wrong link here :) It should be:

http://www.pwsan.com/omap/testlogs/test_v3.16-rc7/20140727174803/pm/37xxevm/37xxevm_log.txt
 
> 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

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/37xxevm_log.txt
> 
> 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/37xxevm_log.txt

Wrong link here :) It should be:

http://www.pwsan.com/omap/testlogs/test_v3.16-rc7/20140727174803/pm/37xxevm/37xxevm_log.txt
 
> 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

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

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

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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.

Are you using NFS root on 37xxevm or MMC root?


- Paul

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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.

Are you using NFS root on 37xxevm or MMC root?


- Paul

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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 at 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 at 48002030 !
[    0.470733] irq: no irq domain found for /ocp/pinmux at 48002030 !
[    0.471557] irq: no irq domain found for /ocp/pinmux at 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 at 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 at 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 at 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 at 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 at 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 at 48:keypad: OF: linux,keymap property not defined in /ocp/i2c at 48070000/twl at 48/keypad
[    1.469665] twl4030_keypad 48070000.i2c:twl at 48:keypad: Failed to build keymap
[    1.469818] twl4030_keypad: probe of 48070000.i2c:twl at 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 at 48:pwrbutton/input/input2
[    1.562530] twl_rtc 48070000.i2c:twl at 48:rtc: Power up reset detected.
[    1.563171] twl_rtc 48070000.i2c:twl at 48:rtc: Enabling TWL-RTC
[    1.570068] twl_rtc 48070000.i2c:twl at 48:rtc: rtc core: registered 48070000.i2c:twl at 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 at 4809c000[0]'
[    1.585357] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc at 4809c000[0]'
[    1.637634] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc at 480b4000[0]'
[    1.637725] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc at 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 at 480b4000[0]'
[    1.673339] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc at 480b4000[0]'
[    1.802642] twl_rtc 48070000.i2c:twl at 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

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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)

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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)

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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 {

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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 {

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/3530es3beagle/3530es3beagle_log.txt

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/3530es3beagle/3530es3beagle_log.txt


- Paul

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/3530es3beagle/3530es3beagle_log.txt

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/3530es3beagle/3530es3beagle_log.txt


- Paul

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/3530es3beagle/3530es3beagle_log.txt
> 
> 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/3530es3beagle/3530es3beagle_log.txt

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

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/3530es3beagle/3530es3beagle_log.txt
> 
> 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/3530es3beagle/3530es3beagle_log.txt

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

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

If I find some extra time, I'll set up a bisection run.


- Paul

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

If I find some extra time, I'll set up a bisection run.


- Paul

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/37xxevm_log.txt
> 
> 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

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/37xxevm_log.txt
> 
> 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

Re: OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/37xxevm_log.txt
> > 
> > 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 ]---

OMAP baseline test results for v3.16-rc4

[Tony Lindgren]

* 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/37xxevm_log.txt
> > 
> > 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 ]---

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt
> > 
> > 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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt
> > 
> > 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

Re: OMAP baseline test results for v3.16-rc4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

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/37xxevm_log.txt
> > > 
> > > 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.

we have stable releases for that.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

OMAP baseline test results for v3.16-rc4

[Felipe Balbi]

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/37xxevm_log.txt
> > > 
> > > 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.

we have stable releases for that.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140807/828d02d0/attachment.sig>

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

On Thu, 7 Aug 2014, Felipe Balbi wrote:

> we have stable releases for that.

Stable releases aren't a fix for process failures.


- Paul

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

On Thu, 7 Aug 2014, Felipe Balbi wrote:

> we have stable releases for that.

Stable releases aren't a fix for process failures.


- Paul

Re: OMAP baseline test results for v3.16-rc4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

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.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

OMAP baseline test results for v3.16-rc4

[Felipe Balbi]

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.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140808/0a12a47a/attachment-0001.sig>

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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

Re: OMAP baseline test results for v3.16-rc4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

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 ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

OMAP baseline test results for v3.16-rc4

[Felipe Balbi]

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 ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140808/7197b5e8/attachment.sig>

Re: OMAP baseline test results for v3.16-rc4

[Fabio Estevam]

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>

OMAP baseline test results for v3.16-rc4

[Fabio Estevam]

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 at 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>

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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

Re: OMAP baseline test results for v3.16-rc4

[Ezequiel Garcia]

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/37xxevm_log.txt
> > > 
> > > 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.
> 

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.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

OMAP baseline test results for v3.16-rc4

[Ezequiel Garcia]

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/37xxevm_log.txt
> > > 
> > > 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.
> 

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.
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: OMAP baseline test results for v3.16-rc4

[Tero Kristo]

On 07/30/2014 08:39 AM, Tony Lindgren wrote:
> 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 {
> --

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>

OMAP baseline test results for v3.16-rc4

[Tero Kristo]

On 07/30/2014 08:39 AM, Tony Lindgren wrote:
> 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 {
> --

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>

Re: OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

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

OMAP baseline test results for v3.16-rc4

[Paul Walmsley]

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/37xxevm_log.txt

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