Hi Jarkko, On 08/10/2012 04:00 PM, Jarkko Nikula wrote: > I got some odd current consumption results from Beagle to really compare > different kernel versions but I was able get sensible results from N900. I still use my n900 as a main phone so I can not really hack on it :( > I tested your set on top of 196973c of sound.git. > > First consumption when using threshold based transfer has remained the > same between 2.6.38-3.6.0-rc1 (wau!). Cool! > Active sidetone under "arecord -f > dat >/dev/null |aplay -f dat /dev/zero" test increases consumption from > plain playback about 17 mA in 3.4 and 3.6.0-rc1. > > With your set applied consumption increases 28 mA when the sidetone is > active (i.e. +11 mA higher than on top of 196973c). Plain threshold > based playback remains still the same. Oh. 11mA is huge... Really strange. I would expected smaller (actually zero) difference since in essence both workaround should be doing the same. Only if the OMAP pm core making different decisions runtime when it see that the no-idle is selected in the SYSCONFIG register of McBSP2. But the autogating of clocks should work without SW. So it seams that we need to do this down at PRCM level? >> I'm doing the same test on BeagleBoard, but this thing does not want to hit >> retention despite all the effort :( >> > Could it be display subsystem which keeps it active? At least on N900 I > need to get DSS drivers activated in order to be able to blank the > display after bootloader and thus be able to reach the retention idle. I tried that as well, but nothing helps. It must be something else which I have overlooked... -- Péter -- 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
