OMAP baseline test results for v3.9-rc3

OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/


Test summary
------------

Build:
    FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
		  omap2plus_defconfig_2430sdp_only
    Pass (13/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
		  omap1_defconfig_1510innovator_only, 
		  omap2plus_defconfig, omap2plus_defconfig_cpupm,
		  omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig
		  rmk_omap4430_sdp_oldconfig

Boot to userspace:
    FAIL ( 1/11): am335xbone
    Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
  	   	  3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
		  5912osk, cmt3517

PM ret, suspend:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM ret, dynamic idle:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM off, suspend:
    FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 5): 3530es3beagle, 3730beaglexm

PM off, dynamic idle:
    FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 5): 3530es3beagle, 3730beaglexm


Failing tests: fixed by posted patches
--------------------------------------

Build:

* omap1_defconfig_5912osk_only: implicit declaration of function 'cpu_is_omap15xx'
  - Fixed by Aaro: http://www.spinics.net/lists/linux-omap/msg87523.html

PM:

* 4460pandaes: CORE, L3INIT didn't enter target state
  - Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
    (ARM: OMAP4: clock/hwmod data: start to remove some IP block control
     "clocks")
  - Fixed by "ARM: OMAP4: PM: fix PM regression introduced by recent clock
    cleanup"
    - http://www.spinics.net/lists/arm-kernel/msg224419.html

Failing tests: needing investigation
------------------------------------

Build:

* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link errors

Boot tests:

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug

Boot warnings:

* 2430sdp & 37xxevm: nasty lock warning due to NFS root
  - Cause unknown
  - Breaks most remaining tests

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
  - Longstanding issue; does not occur on the 3517EVM

PM tests:

* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
  - need to doublecheck wakeup dependencies
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 2430sdp: power domains not entering retention
  - Cause unknown
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE

* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
    per discussion with Tero Kristo
  - Likely dependent on the bootloader version
    - fails with 2012.07-00136-g755de79

* 4460pandaes: chip not entering retention in dynamic idle
  - Presumably 4430es2panda also fails this
  - Suspend-to-RAM enters full chip retention

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock-gate ("debug ignore_loglevel")
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:
    http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
    in hwmod code
  - Jon Hunter reports this does not appear with the same X-loader/bootloader
    on his 4430ES2.3 Panda, so could be ES-level dependent


vmlinux object size
(delta in bytes from test_v3.9-rc2 
(f6161aa153581da4a3867a2d1a7caf4be19b6ec9)):
   text     data      bss    total  kernel
    +72      -64        0       +8  n800_multi_omap2xxx
    +56      -64        0       -8  n800_only_a
+5606576  +359420  +121728  +6087724  omap1_defconfig
   +108    +2592        0    +2700  omap1_defconfig_1510innovator_only
   +640    +2568        0    +3208  omap2plus_defconfig
   +704    +2560        0    +3264  omap2plus_defconfig_cpupm
   +704    +2560        0    +3264  omap2plus_defconfig_no_pm
   +640    +2560        0    +3200  omap2plus_defconfig_omap2_4_only
   +628    +2576        0    +3204  omap2plus_defconfig_omap3_4_only
 -20852     -460    +1732   -19580  rmk_omap3430_ldp_allnoconfig
  +4352      -64        0    +4288  rmk_omap3430_ldp_oldconfig
 -20740     -460    +1620   -19580  rmk_omap4430_sdp_allnoconfig
   +168       -8        0     +160  rmk_omap4430_sdp_oldconfig

omap1_defconfig is building again.

OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/


Test summary
------------

Build:
    FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
		  omap2plus_defconfig_2430sdp_only
    Pass (13/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
		  omap1_defconfig_1510innovator_only, 
		  omap2plus_defconfig, omap2plus_defconfig_cpupm,
		  omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig
		  rmk_omap4430_sdp_oldconfig

Boot to userspace:
    FAIL ( 1/11): am335xbone
    Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
  	   	  3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
		  5912osk, cmt3517

PM ret, suspend:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM ret, dynamic idle:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM off, suspend:
    FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 5): 3530es3beagle, 3730beaglexm

PM off, dynamic idle:
    FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 5): 3530es3beagle, 3730beaglexm


Failing tests: fixed by posted patches
--------------------------------------

Build:

* omap1_defconfig_5912osk_only: implicit declaration of function 'cpu_is_omap15xx'
  - Fixed by Aaro: http://www.spinics.net/lists/linux-omap/msg87523.html

PM:

* 4460pandaes: CORE, L3INIT didn't enter target state
  - Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
    (ARM: OMAP4: clock/hwmod data: start to remove some IP block control
     "clocks")
  - Fixed by "ARM: OMAP4: PM: fix PM regression introduced by recent clock
    cleanup"
    - http://www.spinics.net/lists/arm-kernel/msg224419.html

Failing tests: needing investigation
------------------------------------

Build:

* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link errors

Boot tests:

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug

Boot warnings:

* 2430sdp & 37xxevm: nasty lock warning due to NFS root
  - Cause unknown
  - Breaks most remaining tests

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
  - Longstanding issue; does not occur on the 3517EVM

PM tests:

* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
  - need to doublecheck wakeup dependencies
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 2430sdp: power domains not entering retention
  - Cause unknown
  - (am assuming it's still there; userspace problems prevent the test
     from running, probably due to the lock warning)

* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE

* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
    per discussion with Tero Kristo
  - Likely dependent on the bootloader version
    - fails with 2012.07-00136-g755de79

* 4460pandaes: chip not entering retention in dynamic idle
  - Presumably 4430es2panda also fails this
  - Suspend-to-RAM enters full chip retention

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock-gate ("debug ignore_loglevel")
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:
    http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
    in hwmod code
  - Jon Hunter reports this does not appear with the same X-loader/bootloader
    on his 4430ES2.3 Panda, so could be ES-level dependent


vmlinux object size
(delta in bytes from test_v3.9-rc2 
(f6161aa153581da4a3867a2d1a7caf4be19b6ec9)):
   text     data      bss    total  kernel
    +72      -64        0       +8  n800_multi_omap2xxx
    +56      -64        0       -8  n800_only_a
+5606576  +359420  +121728  +6087724  omap1_defconfig
   +108    +2592        0    +2700  omap1_defconfig_1510innovator_only
   +640    +2568        0    +3208  omap2plus_defconfig
   +704    +2560        0    +3264  omap2plus_defconfig_cpupm
   +704    +2560        0    +3264  omap2plus_defconfig_no_pm
   +640    +2560        0    +3200  omap2plus_defconfig_omap2_4_only
   +628    +2576        0    +3204  omap2plus_defconfig_omap3_4_only
 -20852     -460    +1732   -19580  rmk_omap3430_ldp_allnoconfig
  +4352      -64        0    +4288  rmk_omap3430_ldp_oldconfig
 -20740     -460    +1620   -19580  rmk_omap4430_sdp_allnoconfig
   +168       -8        0     +160  rmk_omap4430_sdp_oldconfig

omap1_defconfig is building again.

Re: OMAP baseline test results for v3.9-rc3

[Anca Emanuel]

You are not planning any resources to solve this ?
You are listing this for a number of months now. It is time to solve them.

On Mon, Mar 18, 2013 at 5:38 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Here are some basic OMAP test results for Linux v3.9-rc3.
> Logs and other details at:
>
>     http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
>
>
> Test summary
> ------------
>
> Build:
>     FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
>                   omap2plus_defconfig_2430sdp_only
>     Pass (13/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
>                   omap1_defconfig_1510innovator_only,
>                   omap2plus_defconfig, omap2plus_defconfig_cpupm,
>                   omap2plus_defconfig_no_pm,
>                   omap2plus_defconfig_omap2_4_only,
>                   omap2plus_defconfig_omap3_4_only,
>                   rmk_omap3430_ldp_allnoconfig,
>                   rmk_omap3430_ldp_oldconfig,
>                   rmk_omap4430_sdp_allnoconfig
>                   rmk_omap4430_sdp_oldconfig
>
> Boot to userspace:
>     FAIL ( 1/11): am335xbone
>     Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
>                   3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
>                   5912osk, cmt3517
>
> PM ret, suspend:
>     FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
>     Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
>
> PM ret, dynamic idle:
>     FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
>     Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
>
> PM off, suspend:
>     FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
>     Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
>
> PM off, dynamic idle:
>     FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
>     Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
>
>
> Failing tests: fixed by posted patches
> --------------------------------------
>
> Build:
>
> * omap1_defconfig_5912osk_only: implicit declaration of function 'cpu_is_omap15xx'
>   - Fixed by Aaro: http://www.spinics.net/lists/linux-omap/msg87523.html
>
> PM:
>
> * 4460pandaes: CORE, L3INIT didn't enter target state
>   - Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
>     (ARM: OMAP4: clock/hwmod data: start to remove some IP block control
>      "clocks")
>   - Fixed by "ARM: OMAP4: PM: fix PM regression introduced by recent clock
>     cleanup"
>     - http://www.spinics.net/lists/arm-kernel/msg224419.html
>
> Failing tests: needing investigation
> ------------------------------------
>
> Build:
>
> * am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link errors
>
> Boot tests:
>
> * 3517EVM & CM-T3517: boot hangs with NFS root
>   - Likely some Kconfig, board file, and PM issues with EMAC
>   - Longstanding bug
>
> Boot warnings:
>
> * 2430sdp & 37xxevm: nasty lock warning due to NFS root
>   - Cause unknown
>   - Breaks most remaining tests
>
> * CM-T3517: L3 in-band error with IPSS during boot
>   - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
>   - Longstanding issue; does not occur on the 3517EVM
>
> PM tests:
>
> * 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
>   - need to doublecheck wakeup dependencies
>   - (am assuming it's still there; userspace problems prevent the test
>      from running, probably due to the lock warning)
>
> * 2430sdp: power domains not entering retention
>   - Cause unknown
>   - (am assuming it's still there; userspace problems prevent the test
>      from running, probably due to the lock warning)
>
> * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
>
> * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
>
> * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
>   - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
>     per discussion with Tero Kristo
>   - Likely dependent on the bootloader version
>     - fails with 2012.07-00136-g755de79
>
> * 4460pandaes: chip not entering retention in dynamic idle
>   - Presumably 4430es2panda also fails this
>   - Suspend-to-RAM enters full chip retention
>
> * 3730 Beagle XM: does not serial wake from off-idle suspend when console
>   UART doesn't clock-gate ("debug ignore_loglevel")
>   - Cause unknown
>   - Not yet part of the automated test suite
>   - Re-tested at v3.7; still failing:
>     http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
>
> Other:
>
> * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
>   - Unknown cause; could be due to the lack of hierarchical enable/disable
>     in hwmod code
>   - Jon Hunter reports this does not appear with the same X-loader/bootloader
>     on his 4430ES2.3 Panda, so could be ES-level dependent
>
>
> vmlinux object size
> (delta in bytes from test_v3.9-rc2
> (f6161aa153581da4a3867a2d1a7caf4be19b6ec9)):
>    text     data      bss    total  kernel
>     +72      -64        0       +8  n800_multi_omap2xxx
>     +56      -64        0       -8  n800_only_a
> +5606576  +359420  +121728  +6087724  omap1_defconfig
>    +108    +2592        0    +2700  omap1_defconfig_1510innovator_only
>    +640    +2568        0    +3208  omap2plus_defconfig
>    +704    +2560        0    +3264  omap2plus_defconfig_cpupm
>    +704    +2560        0    +3264  omap2plus_defconfig_no_pm
>    +640    +2560        0    +3200  omap2plus_defconfig_omap2_4_only
>    +628    +2576        0    +3204  omap2plus_defconfig_omap3_4_only
>  -20852     -460    +1732   -19580  rmk_omap3430_ldp_allnoconfig
>   +4352      -64        0    +4288  rmk_omap3430_ldp_oldconfig
>  -20740     -460    +1620   -19580  rmk_omap4430_sdp_allnoconfig
>    +168       -8        0     +160  rmk_omap4430_sdp_oldconfig
>
> omap1_defconfig is building again.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

OMAP baseline test results for v3.9-rc3

[Anca Emanuel]

You are not planning any resources to solve this ?
You are listing this for a number of months now. It is time to solve them.

On Mon, Mar 18, 2013 at 5:38 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Here are some basic OMAP test results for Linux v3.9-rc3.
> Logs and other details at:
>
>     http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
>
>
> Test summary
> ------------
>
> Build:
>     FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
>                   omap2plus_defconfig_2430sdp_only
>     Pass (13/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
>                   omap1_defconfig_1510innovator_only,
>                   omap2plus_defconfig, omap2plus_defconfig_cpupm,
>                   omap2plus_defconfig_no_pm,
>                   omap2plus_defconfig_omap2_4_only,
>                   omap2plus_defconfig_omap3_4_only,
>                   rmk_omap3430_ldp_allnoconfig,
>                   rmk_omap3430_ldp_oldconfig,
>                   rmk_omap4430_sdp_allnoconfig
>                   rmk_omap4430_sdp_oldconfig
>
> Boot to userspace:
>     FAIL ( 1/11): am335xbone
>     Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
>                   3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
>                   5912osk, cmt3517
>
> PM ret, suspend:
>     FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
>     Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
>
> PM ret, dynamic idle:
>     FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
>     Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
>
> PM off, suspend:
>     FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
>     Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
>
> PM off, dynamic idle:
>     FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
>     Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
>
>
> Failing tests: fixed by posted patches
> --------------------------------------
>
> Build:
>
> * omap1_defconfig_5912osk_only: implicit declaration of function 'cpu_is_omap15xx'
>   - Fixed by Aaro: http://www.spinics.net/lists/linux-omap/msg87523.html
>
> PM:
>
> * 4460pandaes: CORE, L3INIT didn't enter target state
>   - Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
>     (ARM: OMAP4: clock/hwmod data: start to remove some IP block control
>      "clocks")
>   - Fixed by "ARM: OMAP4: PM: fix PM regression introduced by recent clock
>     cleanup"
>     - http://www.spinics.net/lists/arm-kernel/msg224419.html
>
> Failing tests: needing investigation
> ------------------------------------
>
> Build:
>
> * am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link errors
>
> Boot tests:
>
> * 3517EVM & CM-T3517: boot hangs with NFS root
>   - Likely some Kconfig, board file, and PM issues with EMAC
>   - Longstanding bug
>
> Boot warnings:
>
> * 2430sdp & 37xxevm: nasty lock warning due to NFS root
>   - Cause unknown
>   - Breaks most remaining tests
>
> * CM-T3517: L3 in-band error with IPSS during boot
>   - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
>   - Longstanding issue; does not occur on the 3517EVM
>
> PM tests:
>
> * 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
>   - need to doublecheck wakeup dependencies
>   - (am assuming it's still there; userspace problems prevent the test
>      from running, probably due to the lock warning)
>
> * 2430sdp: power domains not entering retention
>   - Cause unknown
>   - (am assuming it's still there; userspace problems prevent the test
>      from running, probably due to the lock warning)
>
> * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
>
> * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
>
> * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
>   - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
>     per discussion with Tero Kristo
>   - Likely dependent on the bootloader version
>     - fails with 2012.07-00136-g755de79
>
> * 4460pandaes: chip not entering retention in dynamic idle
>   - Presumably 4430es2panda also fails this
>   - Suspend-to-RAM enters full chip retention
>
> * 3730 Beagle XM: does not serial wake from off-idle suspend when console
>   UART doesn't clock-gate ("debug ignore_loglevel")
>   - Cause unknown
>   - Not yet part of the automated test suite
>   - Re-tested at v3.7; still failing:
>     http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
>
> Other:
>
> * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
>   - Unknown cause; could be due to the lack of hierarchical enable/disable
>     in hwmod code
>   - Jon Hunter reports this does not appear with the same X-loader/bootloader
>     on his 4430ES2.3 Panda, so could be ES-level dependent
>
>
> vmlinux object size
> (delta in bytes from test_v3.9-rc2
> (f6161aa153581da4a3867a2d1a7caf4be19b6ec9)):
>    text     data      bss    total  kernel
>     +72      -64        0       +8  n800_multi_omap2xxx
>     +56      -64        0       -8  n800_only_a
> +5606576  +359420  +121728  +6087724  omap1_defconfig
>    +108    +2592        0    +2700  omap1_defconfig_1510innovator_only
>    +640    +2568        0    +3208  omap2plus_defconfig
>    +704    +2560        0    +3264  omap2plus_defconfig_cpupm
>    +704    +2560        0    +3264  omap2plus_defconfig_no_pm
>    +640    +2560        0    +3200  omap2plus_defconfig_omap2_4_only
>    +628    +2576        0    +3204  omap2plus_defconfig_omap3_4_only
>  -20852     -460    +1732   -19580  rmk_omap3430_ldp_allnoconfig
>   +4352      -64        0    +4288  rmk_omap3430_ldp_oldconfig
>  -20740     -460    +1620   -19580  rmk_omap4430_sdp_allnoconfig
>    +168       -8        0     +160  rmk_omap4430_sdp_oldconfig
>
> omap1_defconfig is building again.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

On Mon, 18 Mar 2013, Anca Emanuel wrote:

> You are not planning any resources to solve this ?
> You are listing this for a number of months now. It is time to solve them.

Absolutely, thanks for volunteering!  Patches welcome.


- Paul

OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

On Mon, 18 Mar 2013, Anca Emanuel wrote:

> You are not planning any resources to solve this ?
> You are listing this for a number of months now. It is time to solve them.

Absolutely, thanks for volunteering!  Patches welcome.


- Paul

Re: OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

On Mon, 18 Mar 2013, Paul Walmsley wrote:

> On Mon, 18 Mar 2013, Anca Emanuel wrote:
> 
> > You are not planning any resources to solve this ?
> > You are listing this for a number of months now. It is time to solve them.
> 
> Absolutely, thanks for volunteering!  Patches welcome.

Also, if you are a TI customer, you can probably contact your TI rep and 
put pressure on them to put more resources into their upstream kernel 
support.


- Paul

OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

On Mon, 18 Mar 2013, Paul Walmsley wrote:

> On Mon, 18 Mar 2013, Anca Emanuel wrote:
> 
> > You are not planning any resources to solve this ?
> > You are listing this for a number of months now. It is time to solve them.
> 
> Absolutely, thanks for volunteering!  Patches welcome.

Also, if you are a TI customer, you can probably contact your TI rep and 
put pressure on them to put more resources into their upstream kernel 
support.


- Paul

Re: OMAP baseline test results for v3.9-rc3

[Santosh Shilimkar]

+ Tero,

On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
> 
> Here are some basic OMAP test results for Linux v3.9-rc3.
> Logs and other details at:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
> 
> 
> Test summary
> ------------
> 
Thanks for the summary Paul. A usual, it is quite exhaustive. Few
questions and comments below.

[..]

> Failing tests: needing investigation
> ------------------------------------
> 

[..]

> PM tests:
> 
[..]

> 
> * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
> 
I thought we discussed about boot-loader dependency already. 

> * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 
> 
Same here.

> * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
>   - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
>     per discussion with Tero Kristo
>   - Likely dependent on the bootloader version
>     - fails with 2012.07-00136-g755de79
> 
Do you still see the issue after upgrading the boot-loader version ?

> * 4460pandaes: chip not entering retention in dynamic idle
>   - Presumably 4430es2panda also fails this
>   - Suspend-to-RAM enters full chip retention
> 
Assuming dynmic idle is CPUIdle, core retention isn't supported
in CPUDILE so it is expected

> 
> Other:
> 
> * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
>   - Unknown cause; could be due to the lack of hierarchical enable/disable
>     in hwmod code
>   - Jon Hunter reports this does not appear with the same X-loader/bootloader
>     on his 4430ES2.3 Panda, so could be ES-level dependent
I confirm Jon's observation even on my OMAP4430 ES2.3 SDP.

Regards,
Santosh

OMAP baseline test results for v3.9-rc3

[Santosh Shilimkar]

+ Tero,

On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
> 
> Here are some basic OMAP test results for Linux v3.9-rc3.
> Logs and other details at:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
> 
> 
> Test summary
> ------------
> 
Thanks for the summary Paul. A usual, it is quite exhaustive. Few
questions and comments below.

[..]

> Failing tests: needing investigation
> ------------------------------------
> 

[..]

> PM tests:
> 
[..]

> 
> * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
> 
I thought we discussed about boot-loader dependency already. 

> * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 
> 
Same here.

> * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
>   - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
>     per discussion with Tero Kristo
>   - Likely dependent on the bootloader version
>     - fails with 2012.07-00136-g755de79
> 
Do you still see the issue after upgrading the boot-loader version ?

> * 4460pandaes: chip not entering retention in dynamic idle
>   - Presumably 4430es2panda also fails this
>   - Suspend-to-RAM enters full chip retention
> 
Assuming dynmic idle is CPUIdle, core retention isn't supported
in CPUDILE so it is expected

> 
> Other:
> 
> * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
>   - Unknown cause; could be due to the lack of hierarchical enable/disable
>     in hwmod code
>   - Jon Hunter reports this does not appear with the same X-loader/bootloader
>     on his 4430ES2.3 Panda, so could be ES-level dependent
I confirm Jon's observation even on my OMAP4430 ES2.3 SDP.

Regards,
Santosh

Re: OMAP baseline test results for v3.9-rc3

[Tero Kristo]

On Tue, 2013-03-19 at 14:21 +0530, Santosh Shilimkar wrote:
> + Tero,
> 
> On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
> > 
> > Here are some basic OMAP test results for Linux v3.9-rc3.
> > Logs and other details at:
> > 
> >     http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
> > 
> > 
> > Test summary
> > ------------
> > 
> Thanks for the summary Paul. A usual, it is quite exhaustive. Few
> questions and comments below.
> 
> [..]
> 
> > Failing tests: needing investigation
> > ------------------------------------
> > 
> 
> [..]
> 
> > PM tests:
> > 
> [..]
> 
> > 
> > * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
> > 
> I thought we discussed about boot-loader dependency already. 
> 
> > * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 
> > 
> Same here.
> 
> > * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
> >   - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
> >     per discussion with Tero Kristo
> >   - Likely dependent on the bootloader version
> >     - fails with 2012.07-00136-g755de79
> > 
> Do you still see the issue after upgrading the boot-loader version ?

I think you should definitely upgrade your bootloader, the old one you
are using is prone to cause trouble due to bugs it has, and we have no
simple way to workaround the issues it causes on kernel side.

-Tero

OMAP baseline test results for v3.9-rc3

[Tero Kristo]

On Tue, 2013-03-19 at 14:21 +0530, Santosh Shilimkar wrote:
> + Tero,
> 
> On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
> > 
> > Here are some basic OMAP test results for Linux v3.9-rc3.
> > Logs and other details at:
> > 
> >     http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
> > 
> > 
> > Test summary
> > ------------
> > 
> Thanks for the summary Paul. A usual, it is quite exhaustive. Few
> questions and comments below.
> 
> [..]
> 
> > Failing tests: needing investigation
> > ------------------------------------
> > 
> 
> [..]
> 
> > PM tests:
> > 
> [..]
> 
> > 
> > * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
> > 
> I thought we discussed about boot-loader dependency already. 
> 
> > * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 
> > 
> Same here.
> 
> > * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
> >   - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
> >     per discussion with Tero Kristo
> >   - Likely dependent on the bootloader version
> >     - fails with 2012.07-00136-g755de79
> > 
> Do you still see the issue after upgrading the boot-loader version ?

I think you should definitely upgrade your bootloader, the old one you
are using is prone to cause trouble due to bugs it has, and we have no
simple way to workaround the issues it causes on kernel side.

-Tero

Re: OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

Hi

On Tue, 19 Mar 2013, Santosh Shilimkar wrote:

> On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
>
> > Test summary
> > ------------
> > 
> Thanks for the summary Paul. A usual, it is quite exhaustive.

Would that it were true.  These tests are really only very superficial.  
Here are some major missing areas:

- other devices (audio, video, etc.)
- stability testing - does the board hang or freeze across 24 hours to 
  a week of uptime?
- CPU DVFS
- current consumption during active, ret idle, off idle
- multiple bootloaders
- multiple rootfs originations (across boards that support several) -- 
  e.g., NFS, MMC, etc.

If I were basing anything off the mainline kernel, that's the minimum I'd 
like to see.

> > 
> > * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
> > 
> I thought we discussed about boot-loader dependency already. 
> 
> > * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 
> > 
> Same here.

Have these issues been confirmed to be bootloader-related?

If so, then we can mark these as cases where the kernel isn't resetting 
devices properly.

> > * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
> >   - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
> >     per discussion with Tero Kristo
> >   - Likely dependent on the bootloader version
> >     - fails with 2012.07-00136-g755de79
> > 
> Do you still see the issue after upgrading the boot-loader version ?

Haven't tried yet.

> > * 4460pandaes: chip not entering retention in dynamic idle
> >   - Presumably 4430es2panda also fails this
> >   - Suspend-to-RAM enters full chip retention
> > 
> Assuming dynmic idle is CPUIdle, core retention isn't supported
> in CPUDILE so it is expected

No, it's not CPUIdle.  It's simply echoing a power management timeout to 
the UART autosuspend sysfs entries.  You can see exactly what's done by 
checking the pm/ directory in the test logs, for example:

http://www.pwsan.com/omap/testlogs/test_v3.9-rc4/20130324120244/pm/

OMAP4 should be able to enter full-chip retention idle without CPUIdle, as 
OMAP3 does.  If the current kernel depends on CPUIdle to do this on OMAP4, 
that's a bug.

> > Other:
> > 
> > * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
> >   - Unknown cause; could be due to the lack of hierarchical enable/disable
> >     in hwmod code
> >   - Jon Hunter reports this does not appear with the same X-loader/bootloader
> >     on his 4430ES2.3 Panda, so could be ES-level dependent
> I confirm Jon's observation even on my OMAP4430 ES2.3 SDP.

Thanks, I put this in the v3.9-rc4 README.


- Paul

OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

Hi

On Tue, 19 Mar 2013, Santosh Shilimkar wrote:

> On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
>
> > Test summary
> > ------------
> > 
> Thanks for the summary Paul. A usual, it is quite exhaustive.

Would that it were true.  These tests are really only very superficial.  
Here are some major missing areas:

- other devices (audio, video, etc.)
- stability testing - does the board hang or freeze across 24 hours to 
  a week of uptime?
- CPU DVFS
- current consumption during active, ret idle, off idle
- multiple bootloaders
- multiple rootfs originations (across boards that support several) -- 
  e.g., NFS, MMC, etc.

If I were basing anything off the mainline kernel, that's the minimum I'd 
like to see.

> > 
> > * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
> > 
> I thought we discussed about boot-loader dependency already. 
> 
> > * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA 
> > 
> Same here.

Have these issues been confirmed to be bootloader-related?

If so, then we can mark these as cases where the kernel isn't resetting 
devices properly.

> > * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
> >   - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
> >     per discussion with Tero Kristo
> >   - Likely dependent on the bootloader version
> >     - fails with 2012.07-00136-g755de79
> > 
> Do you still see the issue after upgrading the boot-loader version ?

Haven't tried yet.

> > * 4460pandaes: chip not entering retention in dynamic idle
> >   - Presumably 4430es2panda also fails this
> >   - Suspend-to-RAM enters full chip retention
> > 
> Assuming dynmic idle is CPUIdle, core retention isn't supported
> in CPUDILE so it is expected

No, it's not CPUIdle.  It's simply echoing a power management timeout to 
the UART autosuspend sysfs entries.  You can see exactly what's done by 
checking the pm/ directory in the test logs, for example:

http://www.pwsan.com/omap/testlogs/test_v3.9-rc4/20130324120244/pm/

OMAP4 should be able to enter full-chip retention idle without CPUIdle, as 
OMAP3 does.  If the current kernel depends on CPUIdle to do this on OMAP4, 
that's a bug.

> > Other:
> > 
> > * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
> >   - Unknown cause; could be due to the lack of hierarchical enable/disable
> >     in hwmod code
> >   - Jon Hunter reports this does not appear with the same X-loader/bootloader
> >     on his 4430ES2.3 Panda, so could be ES-level dependent
> I confirm Jon's observation even on my OMAP4430 ES2.3 SDP.

Thanks, I put this in the v3.9-rc4 README.


- Paul

Re: OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

Hi.

On Tue, 19 Mar 2013, Tero Kristo wrote:

> I think you should definitely upgrade your bootloader, the old one you
> are using is prone to cause trouble due to bugs it has, and we have no
> simple way to workaround the issues it causes on kernel side.

So, the kernel should be independent of the bootloader that's used.  Many 
of the rest of us have taken great care to ensure that devices get reset 
to do this.  We've got pretty good coverage on OMAP3 and most of the other 
OMAP4 IP blocks.

You mention that there's no simple way to do it, but as far as I know, no 
one has assessed what's needed to reset the remaining devices.  Or if 
someone has this information, it hasn't been shared here - please do so.

So what I'd like you to do is:

1. Determine what devices are remaining to be reset and idled on OMAP4 
   with the bootloader that I use.  As far as I know, there are only four 
   that block full-chip idle: M3, DSP, SL2IF, FSUSB

2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
   I'd assume this involves pointing the reset vector for those 
   processors at a few lines of code that basically enter WFI or the C64x 
   equivalent.

3. At this point, we can determine the difficulty level of the task.

4. Then, assuming it's of the level described in step 2, that reset/idle 
   code should be implemented.

This process will ensure both that users with "old" OMAP4 bootloaders -- 
really, u-boot versions distributed less than a year ago, so not very old 
at all -- will be able to successfully enter chip low power states.  It 
will also ensure that users who boot to new kernels with kexec will be 
able to do so successfully, with a minimum of interference from other 
devices.


- Paul

OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

Hi.

On Tue, 19 Mar 2013, Tero Kristo wrote:

> I think you should definitely upgrade your bootloader, the old one you
> are using is prone to cause trouble due to bugs it has, and we have no
> simple way to workaround the issues it causes on kernel side.

So, the kernel should be independent of the bootloader that's used.  Many 
of the rest of us have taken great care to ensure that devices get reset 
to do this.  We've got pretty good coverage on OMAP3 and most of the other 
OMAP4 IP blocks.

You mention that there's no simple way to do it, but as far as I know, no 
one has assessed what's needed to reset the remaining devices.  Or if 
someone has this information, it hasn't been shared here - please do so.

So what I'd like you to do is:

1. Determine what devices are remaining to be reset and idled on OMAP4 
   with the bootloader that I use.  As far as I know, there are only four 
   that block full-chip idle: M3, DSP, SL2IF, FSUSB

2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
   I'd assume this involves pointing the reset vector for those 
   processors at a few lines of code that basically enter WFI or the C64x 
   equivalent.

3. At this point, we can determine the difficulty level of the task.

4. Then, assuming it's of the level described in step 2, that reset/idle 
   code should be implemented.

This process will ensure both that users with "old" OMAP4 bootloaders -- 
really, u-boot versions distributed less than a year ago, so not very old 
at all -- will be able to successfully enter chip low power states.  It 
will also ensure that users who boot to new kernels with kexec will be 
able to do so successfully, with a minimum of interference from other 
devices.


- Paul

Re: OMAP baseline test results for v3.9-rc3

[Tero Kristo]

On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
> Hi.
> 
> On Tue, 19 Mar 2013, Tero Kristo wrote:
> 
> > I think you should definitely upgrade your bootloader, the old one you
> > are using is prone to cause trouble due to bugs it has, and we have no
> > simple way to workaround the issues it causes on kernel side.
> 
> So, the kernel should be independent of the bootloader that's used.  Many 
> of the rest of us have taken great care to ensure that devices get reset 
> to do this.  We've got pretty good coverage on OMAP3 and most of the other 
> OMAP4 IP blocks.
> 
> You mention that there's no simple way to do it, but as far as I know, no 
> one has assessed what's needed to reset the remaining devices.  Or if 
> someone has this information, it hasn't been shared here - please do so.
> 
> So what I'd like you to do is:
> 
> 1. Determine what devices are remaining to be reset and idled on OMAP4 
>    with the bootloader that I use.  As far as I know, there are only four 
>    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> 
> 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
>    I'd assume this involves pointing the reset vector for those 
>    processors at a few lines of code that basically enter WFI or the C64x 
>    equivalent.

This is the nasty part. We need firmware support for the blocks to do
this, and this is imo a complete overkill for the task at hand, as it
will duplicate the DSP + M3 firmware and drivers at least partially. On
OMAP3, it was easy as you could just setup the boot mode for IVA and get
over with it. We don't have similar luxury on OMAP4.

If there was a simple way to do this, don't you think this would have
been done already a year back when we started to discuss this first
time? And, a year old bootloader is ancient seeing we didn't have any
kind of support for OMAP4 core idle in mainline back then and this
feature was essentially completely untested.... nobody cared about the
upstream u-boot PM compatibility before that.

-Tero

> 
> 3. At this point, we can determine the difficulty level of the task.
> 
> 4. Then, assuming it's of the level described in step 2, that reset/idle 
>    code should be implemented.
> 
> This process will ensure both that users with "old" OMAP4 bootloaders -- 
> really, u-boot versions distributed less than a year ago, so not very old 
> at all -- will be able to successfully enter chip low power states.  It 
> will also ensure that users who boot to new kernels with kexec will be 
> able to do so successfully, with a minimum of interference from other 
> devices.
> 
> 
> - Paul
> --
> 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.9-rc3

[Tero Kristo]

On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
> Hi.
> 
> On Tue, 19 Mar 2013, Tero Kristo wrote:
> 
> > I think you should definitely upgrade your bootloader, the old one you
> > are using is prone to cause trouble due to bugs it has, and we have no
> > simple way to workaround the issues it causes on kernel side.
> 
> So, the kernel should be independent of the bootloader that's used.  Many 
> of the rest of us have taken great care to ensure that devices get reset 
> to do this.  We've got pretty good coverage on OMAP3 and most of the other 
> OMAP4 IP blocks.
> 
> You mention that there's no simple way to do it, but as far as I know, no 
> one has assessed what's needed to reset the remaining devices.  Or if 
> someone has this information, it hasn't been shared here - please do so.
> 
> So what I'd like you to do is:
> 
> 1. Determine what devices are remaining to be reset and idled on OMAP4 
>    with the bootloader that I use.  As far as I know, there are only four 
>    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> 
> 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
>    I'd assume this involves pointing the reset vector for those 
>    processors at a few lines of code that basically enter WFI or the C64x 
>    equivalent.

This is the nasty part. We need firmware support for the blocks to do
this, and this is imo a complete overkill for the task at hand, as it
will duplicate the DSP + M3 firmware and drivers at least partially. On
OMAP3, it was easy as you could just setup the boot mode for IVA and get
over with it. We don't have similar luxury on OMAP4.

If there was a simple way to do this, don't you think this would have
been done already a year back when we started to discuss this first
time? And, a year old bootloader is ancient seeing we didn't have any
kind of support for OMAP4 core idle in mainline back then and this
feature was essentially completely untested.... nobody cared about the
upstream u-boot PM compatibility before that.

-Tero

> 
> 3. At this point, we can determine the difficulty level of the task.
> 
> 4. Then, assuming it's of the level described in step 2, that reset/idle 
>    code should be implemented.
> 
> This process will ensure both that users with "old" OMAP4 bootloaders -- 
> really, u-boot versions distributed less than a year ago, so not very old 
> at all -- will be able to successfully enter chip low power states.  It 
> will also ensure that users who boot to new kernels with kexec will be 
> able to do so successfully, with a minimum of interference from other 
> devices.
> 
> 
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.9-rc3

[Tony Lindgren]

* Tero Kristo <t-kristo@ti.com> [130327 02:15]:
> On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
> > 
> > So what I'd like you to do is:
> > 
> > 1. Determine what devices are remaining to be reset and idled on OMAP4 
> >    with the bootloader that I use.  As far as I know, there are only four 
> >    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> > 
> > 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
> >    I'd assume this involves pointing the reset vector for those 
> >    processors at a few lines of code that basically enter WFI or the C64x 
> >    equivalent.
> 
> This is the nasty part. We need firmware support for the blocks to do
> this, and this is imo a complete overkill for the task at hand, as it
> will duplicate the DSP + M3 firmware and drivers at least partially. On
> OMAP3, it was easy as you could just setup the boot mode for IVA and get
> over with it. We don't have similar luxury on OMAP4.
> 
> If there was a simple way to do this, don't you think this would have
> been done already a year back when we started to discuss this first
> time? And, a year old bootloader is ancient seeing we didn't have any
> kind of support for OMAP4 core idle in mainline back then and this
> feature was essentially completely untested.... nobody cared about the
> upstream u-boot PM compatibility before that.

You may be able to have an inline function in the DSP and M3 headers
that idles those modules that can also be called from the reset and idle
function in the hwmod code. That way the driver related code stays in
the driver, but can be called from hwmod reset if the driver is not
compiled in.

Of course if the reset and idle of DSP and M3 gets more complex than
just a few lines of code, then we should just determine that the PM is
broken without those drivers and print out a warning.

Regards,

Tony

OMAP baseline test results for v3.9-rc3

[Tony Lindgren]

* Tero Kristo <t-kristo@ti.com> [130327 02:15]:
> On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
> > 
> > So what I'd like you to do is:
> > 
> > 1. Determine what devices are remaining to be reset and idled on OMAP4 
> >    with the bootloader that I use.  As far as I know, there are only four 
> >    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> > 
> > 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
> >    I'd assume this involves pointing the reset vector for those 
> >    processors at a few lines of code that basically enter WFI or the C64x 
> >    equivalent.
> 
> This is the nasty part. We need firmware support for the blocks to do
> this, and this is imo a complete overkill for the task at hand, as it
> will duplicate the DSP + M3 firmware and drivers at least partially. On
> OMAP3, it was easy as you could just setup the boot mode for IVA and get
> over with it. We don't have similar luxury on OMAP4.
> 
> If there was a simple way to do this, don't you think this would have
> been done already a year back when we started to discuss this first
> time? And, a year old bootloader is ancient seeing we didn't have any
> kind of support for OMAP4 core idle in mainline back then and this
> feature was essentially completely untested.... nobody cared about the
> upstream u-boot PM compatibility before that.

You may be able to have an inline function in the DSP and M3 headers
that idles those modules that can also be called from the reset and idle
function in the hwmod code. That way the driver related code stays in
the driver, but can be called from hwmod reset if the driver is not
compiled in.

Of course if the reset and idle of DSP and M3 gets more complex than
just a few lines of code, then we should just determine that the PM is
broken without those drivers and print out a warning.

Regards,

Tony

Re: OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

Hi

On Wed, 27 Mar 2013, Tero Kristo wrote:

> On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
>
> > So what I'd like you to do is:
> > 
> > 1. Determine what devices are remaining to be reset and idled on OMAP4 
> >    with the bootloader that I use.  As far as I know, there are only four 
> >    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> > 
> > 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
> >    I'd assume this involves pointing the reset vector for those 
> >    processors at a few lines of code that basically enter WFI or the C64x 
> >    equivalent.
> 
> This is the nasty part. We need firmware support for the blocks to do
> this, and this is imo a complete overkill for the task at hand, as it
> will duplicate the DSP + M3 firmware and drivers at least partially.

Why can't the DSP & M3 go straight from the reset vector to WFI (or the 
C64x equivalent?)  The M3s might need a couple of additional instructions 
to program DEEPSLEEP mode.  What other significant additional code is 
needed for those processors?

> If there was a simple way to do this, don't you think this would have
> been done already a year back when we started to discuss this first
> time? 

No, I don't think it has anything to do with the simplicity of the task.  
My sense is that no one at TI wants to work on it.  I can sympathize, but 
all of us who work on upstream Linux do things that we'd rather not do, 
for a more stable or more maintainable kernel.

So the first thing that should be done is to figure out whether the 
situation is really as bad as was suggested above.  Doesn't it seem 
unlikely that it would be necessary to "duplicate the firmware" -- which 
does much more than just idle the DSP & M3 -- just to put those subsystems 
into idle?

There's also the reset of the FSUSB IP block, which shouldn't need any 
firmware.  Who's going to work on that one?


- Paul

OMAP baseline test results for v3.9-rc3

[Paul Walmsley]

Hi

On Wed, 27 Mar 2013, Tero Kristo wrote:

> On Tue, 2013-03-26 at 18:43 +0000, Paul Walmsley wrote:
>
> > So what I'd like you to do is:
> > 
> > 1. Determine what devices are remaining to be reset and idled on OMAP4 
> >    with the bootloader that I use.  As far as I know, there are only four 
> >    that block full-chip idle: M3, DSP, SL2IF, FSUSB
> > 
> > 2. Determine what's needed to reset and idle them.  For the M3 and DSP, 
> >    I'd assume this involves pointing the reset vector for those 
> >    processors at a few lines of code that basically enter WFI or the C64x 
> >    equivalent.
> 
> This is the nasty part. We need firmware support for the blocks to do
> this, and this is imo a complete overkill for the task at hand, as it
> will duplicate the DSP + M3 firmware and drivers at least partially.

Why can't the DSP & M3 go straight from the reset vector to WFI (or the 
C64x equivalent?)  The M3s might need a couple of additional instructions 
to program DEEPSLEEP mode.  What other significant additional code is 
needed for those processors?

> If there was a simple way to do this, don't you think this would have
> been done already a year back when we started to discuss this first
> time? 

No, I don't think it has anything to do with the simplicity of the task.  
My sense is that no one at TI wants to work on it.  I can sympathize, but 
all of us who work on upstream Linux do things that we'd rather not do, 
for a more stable or more maintainable kernel.

So the first thing that should be done is to figure out whether the 
situation is really as bad as was suggested above.  Doesn't it seem 
unlikely that it would be necessary to "duplicate the firmware" -- which 
does much more than just idle the DSP & M3 -- just to put those subsystems 
into idle?

There's also the reset of the FSUSB IP block, which shouldn't need any 
firmware.  Who's going to work on that one?


- Paul