On 03/29/2016 01:26 PM, Tony Lindgren wrote: > Hi, > > * Michael Mrozek <EvilDragon@xxxxxxxxxxxxxxx> [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: > > 1. Disconnect USB cable(s) > > 2. Unload ehci-omap and ohci-omap3 > > 4. Configure UART timeouts > > 5. 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. -- Regards, Nishanth Menon -- 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
