Am Wed, 12 Feb 2014 16:11:52 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
Hmm, but it doesn't really seem to clock down when doing nothing. I'll try what it does when X is not running, just at the CPU core. Do you know what happens when you use both cores? Do they run at the same clockspeed or can one run with 1,5GHz and the other with 0,5GHz?
According to the manual, there is only single clock generator, so both cores always run at the same clock. Some forum posters claim that Snapdragon has a feature to clock cores independently, supposedly unique feature. No idea about other SoCs..
Okay... well, then it totally makes sense to include a single-core mode into the OS. Should be enough for most stuff (as it should be about twice as fast as 1GHz Pandora), and even a sleeping core eats a bit of power.
Question is whether that can be changed on-the-fly or not.
Running PSX emulation uses 70% on one core, the other core doesn't do much (though Linux sometimes seems to move the tasks around, so the 70% are sometimes on one then on the other core). So if both cores are clocked higher even though just one core is being used actually, that would also increas power usage.
Probably, unless the other one can go to sleep. but even if there are small tasks for the other core, it has to do them at full power..
And as our Debian currently moves tasks between both cores around, the second one probably never really sleeps at all.
That's why big.Little thing was developed, and OMAP lacks it. But still I think the other core should end up spending most of it's time sleeping and ignoring the fast clock, otherwise you wouldn't see power usage difference between fully loading just one core and both of them.
Well, I've never loaded one CPU full. I played PSX, but that used between 60 - 75% on one core and I used stress to put stress on both CPUs.
I'll see if I can do more tests tonight. Is there a way in userspace to disable cpufreq and set the cpuspeed manually?
Working with fixed speeds should make measuring easier ;)
FYI we also currently have it like that on pandora, only the video overlay is accelerated on pandora and not on OMAP5. I wouldn't put too many expectetions here..
Hmm... but even on lower resolutions moving X Windows around seems a lot slower than on the Pandora, so something is different here
I forgot that there's NEON-optimized pixman library (which is responsible for window redrawing) on pandora, and all Debian packages are compiled without NEON because of that stupid Tegra2 SoC (Tegra2 had no NEON but was popular at it's time). So that's the disadvantage of Debian.. OTOH I don't know if those pixman optimizations were even ever merged to mainline pixman project, it might be only available as patches on Angstrom/OE only.
Oh... okay... so that means we really need to recompile the basic Debian packages ourselves and put them in our own repositories.
I can imagine that pixman using NEON uses less power as well, compared to having X do all the stuff without any optimizations.
For stuff like LibreOffice or FireFox it probably isn't much different compiling them with NEON or without, the powerusage shouldn't be too high anyways.
But at least for the basic libraries that are being used all the time.
Maybe enabling power management is something we should look into soon, so we can do some real life tests with power management enabled.
Powersaving on OMAPs is extremely complicated, you know yourself how long it took to get it working on pandora..
Yes - is it that much different on the OMAP5 than on the OMAP3? I thought TI stuff is pretty similar, so we might be able to use it on the OMAP5 with minor changes.
Yes it's different, it needs it's own code, even though a bit of it is shared on all newer OMAPs..
Okay, thanks for the information. Should we ask at the TI EVM boards if someone is working on power management features in the kernel?