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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
