On 03/29/2016 01:26 PM, Tony Lindgren wrote:
Hi,
- Michael Mrozek EvilDragon@openpandora.org [160328 16:16]:
Hi,
as we now have the first prototypes running so far, I was able to do some testings with them.
Right now, the OMAP5 seems to eat quite a bit of power, even when basically doing nothing (a LOT more than the DM3730 or OMAP3 uses).
Having it idling around doesn't use less power than running LibreOffice and typing a text, for example.
Right now, I get about 6 - 7 hours of usage with a 6000mAh battery (and everything enabled), whereas I have about 8 hours with a 4400mAh battery (and also everything enabled) on the Pandora.
Unfortunately OMAP5 or DRA7 SoCs are no longer focussed on hand held world. Sorry, TI exited mobile business some years back - OMAP5 was one of the causalities.
I think Nikolaus mentioned at some time that power saving features for the OMAP5 are missing in the kernel (SmartReflex maybe?), so I wanted to check for the status about that and what can be improved.
Well some PM features work for omap4, so getting to the same point with omap5 should be doable. We need to check the various IDLEST registers to make sure various devices are idled, and then the hardware should start entering deeper idle states depending what support is implemented for the SoC.
The device drivers for most part already idle things using kernel PM runtime. And roughly the steps to get the device to hitting deeper idle states is:
Disconnect USB cable(s)
Unload ehci-omap and ohci-omap3
Configure UART timeouts
Blank the display
And then it's up to what is implemented for the SoC to for the idle modes, which certainly needs work for omap5.
The autoidle timeouts for UARTs can be enabled with something like:
#!/bin/bash uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms 2>&1 done uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null) for uart in $uarts; do echo enabled > $uart/wakeup 2>&1 echo auto > $uart/control 2>&1 done echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
In theory, the OMAP5 should use less power for the same tasks the DM3730 or OMAP4 can do, but use more power for more CPU usage (which sounds logical).
Not really logical - comparing A15 vs A8 and completely different process corners behaviors are not comparable.
Right now, it seems the kernel is fixed to 1GHz and 1,5GHz (or 500Mhz and 1GHz on our kernel, as we changed the settings).
I suggest to read the operating conditions Addendum (NDA) for OMAP5 to better understand what OPPs are actually "expected to be function" - going out side those discrete points are basically "You are on your own".
If I understood correctly, it only uses these settings. Does that mean it will always use at least the power it needs to run at 500Mhz? AFAIR, the DM3730 / OMAP3 can go down to around 30Mhz.
The dm3730 can do < 10 mW while running and idle with WLAN connected with the mainline kernel.. But not with libertas_sdio, that seems to have no PM support :)
Not sure what kind of numbers omap5 should be able to get, but my guess is we should reasonably easily get to 500 mW with LCD blanked and device idle as listed above. That's what omap4 pandaboard es seems to measure at with current mainline kernel, so I don't see why omap5 could not do the same.
Lets get somethings out of the way here: OMAP5 is NOT OMAP4. Other than the technologies that are completely different, there has been quiet a bit of descopes on OMAP5 Vs previous generation SoCs. Further, a ton of effort in productizing OMAP3 and 4, which is completely missing in OMAP5. Almost most of power management as has been functional during OMAP3/4 has been descoped - making it more inline with DRA7 is the best hope of moving things forward on OMAP5.
From TI's perspective, despite a few of us community involved folks,
there is very less interest in investigating all the missing features on OMAP5 at this point in time.
So the question is, how can we improve that?
- Add more voltages so it can scale better? (how low can the OMAP5 go?)
- Is SmartReflex active, can this be checked? Is that something that can be improved?
AVS Class 0 is the POR for the same.
Idling around, the Pandora can hold up to 40 hours... so the Pyra should be able to do more with a 6000mAh battery.
And at least my Smartphone with an OMAP4 can idle for over 20 hours with a 1500mAh battery, the OMAP5 can't be that much different.
What are we missing here?
I've added linux-omap, Tero and Nishanth to Cc as they may be able to provide some more info.
I suggest using e2e.ti.com for further understanding of capabilities that can be enabled on OMAP5 - mostly getting to understand what TI is willing to support. I try my best to keep OMAP5 at least on par with DRA7 where possible - but that is not really in interest to many folks though.