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.
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.
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).
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).
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.
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?
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?
Am Tue, 29 Mar 2016 01:15:13 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Ah, one thing I forgot to mention: I was testing this using Nikolaus' testing card. The CPU was set to 500MHz, but X was using 7 - 8% CPU power when idling (probably because the X.Org driver he uses is "omap").
X on the Pandora uses 0,1 - 0,7% CPU power when idling, and that CPU has a lot less power, so that's quite a huge difference.
So I guess that's more a fotware thig.
Also, there are some other CPU hungry things running:
irq/298-4807200 (about 3,3%) kworker/0:1 (about 2%) kworker/0:4 (about 2%) irq/301-4807c00 (about 1,3%) kworker/1:3 (about 0,7%) kworker/0:5 (about 0,7%) kworker/1:1 (about 0,7%) kworker/1:2 (about 0,7%)
What are those? On the Pandora, only X is using a bit of CPU, all the irq and kworker stay at 0%.
On 29/03/16 03:26, Michael Mrozek wrote:
Am Tue, 29 Mar 2016 01:15:13 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Ah, one thing I forgot to mention: I was testing this using Nikolaus' testing card. The CPU was set to 500MHz, but X was using 7 - 8% CPU power when idling (probably because the X.Org driver he uses is "omap").
X on the Pandora uses 0,1 - 0,7% CPU power when idling, and that CPU has a lot less power, so that's quite a huge difference.
So I guess that's more a fotware thig.
Also, there are some other CPU hungry things running:
irq/298-4807200 (about 3,3%) kworker/0:1 (about 2%) kworker/0:4 (about 2%) irq/301-4807c00 (about 1,3%) kworker/1:3 (about 0,7%) kworker/0:5 (about 0,7%) kworker/1:1 (about 0,7%) kworker/1:2 (about 0,7%)
What are those? On the Pandora, only X is using a bit of CPU, all the irq and kworker stay at 0%.
See "cat /proc/interrupts" for the irq numbers. If I'm not mistaken, those irq processes are for i2c2 and i2c5.
Tomi
Am 31.03.2016 um 13:58 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 29/03/16 03:26, Michael Mrozek wrote:
Am Tue, 29 Mar 2016 01:15:13 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Ah, one thing I forgot to mention: I was testing this using Nikolaus' testing card. The CPU was set to 500MHz, but X was using 7 - 8% CPU power when idling (probably because the X.Org driver he uses is "omap").
X on the Pandora uses 0,1 - 0,7% CPU power when idling, and that CPU has a lot less power, so that's quite a huge difference.
So I guess that's more a fotware thig.
Also, there are some other CPU hungry things running:
irq/298-4807200 (about 3,3%) kworker/0:1 (about 2%) kworker/0:4 (about 2%) irq/301-4807c00 (about 1,3%) kworker/1:3 (about 0,7%) kworker/0:5 (about 0,7%) kworker/1:1 (about 0,7%) kworker/1:2 (about 0,7%)
What are those? On the Pandora, only X is using a bit of CPU, all the irq and kworker stay at 0%.
See "cat /proc/interrupts" for the irq numbers. If I'm not mistaken, those irq processes are for i2c2 and i2c5.
that is what I just wanted to check but was interrupted by a broken PC...
Now I can test again. Yes, they are
298: 724 0 WUGEN 57 Level 48072000.i2c 301: 43384 0 WUGEN 60 Level 4807c000.i2c
This is indeed i2c2 and i2c5,
i2c2 activity is most likely from the Nubs. AFAIK we still use polling for the as5013 chips:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
Patches (and cleanup) are welcome.
i2c5 may be the polling activity by my ts3a225e driver hack which just allows to poll the chip and report plug/unplug events and status:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn...
We will replace this chip with a ts3227e in the final hardware, which already has a better driver. AFAIK it can be operated interrupt driven.
BR, Nikolaus
Am Wed, 6 Apr 2016 10:28:30 +0200 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
irq/298-4807200 (about 3,3%) kworker/0:1 (about 2%) kworker/0:4 (about 2%) irq/301-4807c00 (about 1,3%) kworker/1:3 (about 0,7%) kworker/0:5 (about 0,7%) kworker/1:1 (about 0,7%) kworker/1:2 (about 0,7%) What are those? On the Pandora, only X is using a bit of CPU, all the irq and kworker stay at 0%.
See "cat /proc/interrupts" for the irq numbers. If I'm not mistaken, those irq processes are for i2c2 and i2c5.
i2c2 activity is most likely from the Nubs. AFAIK we still use polling for the as5013 chips: http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn... Patches (and cleanup) are welcome.
Just a quick question: The as5013 can operate interrupt driven as well, right? It's just the driver that needs to be updated?
i2c5 may be the polling activity by my ts3a225e driver hack which just allows to poll the chip and report plug/unplug events and status: http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn... We will replace this chip with a ts3227e in the final hardware, which already has a better driver. AFAIK it can be operated interrupt driven.
Okay, good to know.
I'll try to find out with perf what the kworkers are here. Something is keeping the kernel busy :)
Hi,
Am 07.04.2016 um 13:07 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Wed, 6 Apr 2016 10:28:30 +0200 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
irq/298-4807200 (about 3,3%) kworker/0:1 (about 2%) kworker/0:4 (about 2%) irq/301-4807c00 (about 1,3%) kworker/1:3 (about 0,7%) kworker/0:5 (about 0,7%) kworker/1:1 (about 0,7%) kworker/1:2 (about 0,7%) What are those? On the Pandora, only X is using a bit of CPU, all the irq and kworker stay at 0%.
See "cat /proc/interrupts" for the irq numbers. If I'm not mistaken, those irq processes are for i2c2 and i2c5.
i2c2 activity is most likely from the Nubs. AFAIK we still use polling for the as5013 chips: http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn... Patches (and cleanup) are welcome.
Just a quick question: The as5013 can operate interrupt driven as well, right?
yes. We have hooked up the interrupt outputs to gpio input pins.
It's just the driver that needs to be updated?
the latest device tree already contains the interrupt definition
http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=arch/arm/boot/dts/...
but I don't know if the driver code (see link above) is really using it.
i2c5 may be the polling activity by my ts3a225e driver hack which just allows to poll the chip and report plug/unplug events and status: http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hn... We will replace this chip with a ts3227e in the final hardware, which already has a better driver. AFAIK it can be operated interrupt driven.
Okay, good to know.
I'll try to find out with perf what the kworkers are here. Something is keeping the kernel busy :)
BR, Nikolaus
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.
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).
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).
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.
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?
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.
Cheers,
Tony
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.
Hi,
* Nishanth Menon nm@ti.com [160329 16:36]:
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.
Yeah well, like you say, there is still quite a bit of PM related synergy between am57xx and omap5. Many of the devices are the same and are using same PM runtime for clock gating also on am57xx.
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.
Right, so for omap5 PM, it's mostly the omap5 PRCM related parts that are missing. And am57xx is not using PRCM which explains the TI perspective.
So nothing stopping the community people from adding PM support for omap5 as needed and as long as there is interest.
Cheers,
Tony
Am Tue, 29 Mar 2016 17:41:04 -0700 hat Tony Lindgren tony@atomide.com geschrieben:
Hi,
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.
Yeah well, like you say, there is still quite a bit of PM related synergy between am57xx and omap5. Many of the devices are the same and are using same PM runtime for clock gating also on am57xx.
If that's the case, then we should follow the am57xx development and see if we can grab some stuff here.
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.
Right, so for omap5 PM, it's mostly the omap5 PRCM related parts that are missing. And am57xx is not using PRCM which explains the TI perspective. So nothing stopping the community people from adding PM support for omap5 as needed and as long as there is interest.
Well, are all the PRCM available to the public? We probably have them in our datasheets, but can the community add the support?
On 03/29/2016 08:21 PM, Michael Mrozek wrote:
Am Tue, 29 Mar 2016 17:41:04 -0700 hat Tony Lindgren tony@atomide.com geschrieben:
Hi,
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.
Yeah well, like you say, there is still quite a bit of PM related synergy between am57xx and omap5. Many of the devices are the same and are using same PM runtime for clock gating also on am57xx.
If that's the case, then we should follow the am57xx development and see if we can grab some stuff here.
AM57 and DRA7 are more or less the same thing from a s/w view of the world. I do have a few more descope patches to send upstream, but I am holding off on that since the promised TRM and data sheet update that was supposed to happen in March seems to have skipped that update, and I dont plan on posting code not backed by TI official documentation.
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.
Right, so for omap5 PM, it's mostly the omap5 PRCM related parts that are missing. And am57xx is not using PRCM which explains the TI perspective. So nothing stopping the community people from adding PM support for omap5 as needed and as long as there is interest.
Well, are all the PRCM available to the public?
Yes, it should be. PRCM is a module inside the SoC that is responsible for Power Reset and Clock Management (hence PRCM).. all TI public TRMs based on SoCs using PRCM have it already.
We probably have them in our datasheets, but can the community add the support?
It is all there.
On 03/29/2016 07:41 PM, Tony Lindgren wrote:
Hi,
- Nishanth Menon nm@ti.com [160329 16:36]:
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.
Yeah well, like you say, there is still quite a bit of PM related synergy between am57xx and omap5. Many of the devices are the same and are using same PM runtime for clock gating also on am57xx.
yes, overall principles are similar, but there are lot of broken handshaking, issues that were identified, but decided to be descoped rather than be dug into etc. when people try to enable all dynamic dependencies and some IP fails.. well.. yes, it was descoped... there are lots of interesting stories there..
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.
Right, so for omap5 PM, it's mostly the omap5 PRCM related parts that are missing. And am57xx is not using PRCM which explains the TI perspective.
That is not accurate. AM57xx/DRA7 use PRCM. it is Keystone generation SoCs that dont use PRCM.
So nothing stopping the community people from adding PM support for omap5 as needed and as long as there is interest.
As long as people follow what the latest TRM and TI documentation states, there is nothing to prevent us from going ahead. The trouble is when we try to enable things like "Smart reflex AVS", or "OFF mode" or similar stuff -> those are gone by long ago. there are lot of assumptions that people who actually test every sample make when certain things get "descoped" - enabling things and just because it works on one sample and posting "it works" patches is just pure headache to deal with for the rest of us. as long as we all are in agreement to stay within the constraints of TI documentation, we are all good.. any issues there of will be something to deal over e2e.ti.com - though I must warn ahead of time that certain domains might not get attention that might be desired for things to move ahead.
* Nishanth Menon nm@ti.com [160329 19:33]:
On 03/29/2016 07:41 PM, Tony Lindgren wrote:
Right, so for omap5 PM, it's mostly the omap5 PRCM related parts that are missing. And am57xx is not using PRCM which explains the TI perspective.
That is not accurate. AM57xx/DRA7 use PRCM. it is Keystone generation SoCs that dont use PRCM.
I guess I consider ti81xx, am33xx, am43xx and am57xx not using PRCM because of the limited PM functionality :)
Tony
On 03/30/2016 10:09 AM, Tony Lindgren wrote:
- Nishanth Menon nm@ti.com [160329 19:33]:
On 03/29/2016 07:41 PM, Tony Lindgren wrote:
Right, so for omap5 PM, it's mostly the omap5 PRCM related parts that are missing. And am57xx is not using PRCM which explains the TI perspective.
That is not accurate. AM57xx/DRA7 use PRCM. it is Keystone generation SoCs that dont use PRCM.
I guess I consider ti81xx, am33xx, am43xx and am57xx not using PRCM because of the limited PM functionality :)
Hehe.. I agree, we could say that it probably does not use PRCM to the extent that PRCM has potential for. Unfortunately, we might as well add OMAP5 to the list as well.
Am Tue, 29 Mar 2016 18:35:20 -0500 hat Nishanth Menon nm@ti.com geschrieben:
Hi,
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.
Well, yes, I fully agree with the DRA7, but wasn't the OMAP5 originally planned as mobile processor?
When we started, the OMAP5430 was still announced, and AFAIR, it was meant for mobile devices, wasn't it?
Sadly it never was released, but the OMAP5432 shouldn't be THAT much worse...
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.
Yes, I know - but still, the A15 (especially with 28nm) should use less power for the same CPU power as an A8, shouldn't it?
Unless something really power hungry is going on in there, but as it was originally planned as mobile CPU... hmm.
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".
Well, trying out lower voltages shouldn't damage the system, I guess, it would probably simply crash.
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.
True, I know that the software is not as optimized as it was with older systems. That's not something I am too afraid of (unless the software cannot be optimized by others because internal knowledge is required)
I would be more afraid if the hardware would be an issue here, but I guess hardwarewise the possibilities to save power should be there (as the OMAP5 was developed BEFORE the complete mobile department basically was shut down)
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.
That's nothing new and nothing unexpected for us.
I just wanted to find out what the general status is and what could be done to improve it.
That said, it might not even be as bad as I thought - I've been using the current Pyra for over 8 hours without a charge now. I didn't do anything demanding (typed some text, created the keyboard layout, etc.), but it was with that unoptimized X server that constantly eats 8% CPU power and with all other stuff (USB Ports, 4G Modem, etc.) still enabled (interrupts also added up to about 8% more CPU power).
So we had 16% constant CPU load, everything enabled (also the keyboard LEDs) and the battery worked for over 8 hours. I don't know how long it will still work, as it's not yet calibrated, but that doesn't sound too bad.
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.
Thanks, every little bit of help really is appreciated!
Once the system is released, I'd gladly pay someone who would work on that - but persons capable of doing that are hard to find, and the question is: Is everything that's needed for an improvement available in the hardware documentation?
BTW: How similar is the DRA7 to the OMAP5? I know it SOUNDS very similar on the paper, but is the hardware similar as well?
On 03/29/2016 08:18 PM, Michael Mrozek wrote:
Am Tue, 29 Mar 2016 18:35:20 -0500 hat Nishanth Menon nm@ti.com geschrieben:
[...]
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.
Well, yes, I fully agree with the DRA7, but wasn't the OMAP5 originally planned as mobile processor?
I am sorry, I am not permitted to talk about TI SoC internal plans on a public forum. I suggest asking your TI representative about the same.
When we started, the OMAP5430 was still announced, and AFAIR, it was meant for mobile devices, wasn't it?
Sadly it never was released, but the OMAP5432 shouldn't be THAT much worse...
For people who have worked with previous generation SoCs, there is a difference.
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.
Yes, I know - but still, the A15 (especially with 28nm) should use less power for the same CPU power as an A8, shouldn't it?
Unless something really power hungry is going on in there, but as it was originally planned as mobile CPU... hmm.
Not complete accurate here: a) there is always power hungry (and thermal generators) in an SoC, else we'd be talking microcontrollers ;) b) we are assuming the very first version of SoC works "as designed". it never does. then it becomes a matter of priority to fix things that is of interest to the current market target.. that is where things change. In case of OMAP5: Original architecture targets != what end result SoC that is in production.
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".
Well, trying out lower voltages shouldn't damage the system, I guess, it would probably simply crash.
Not necessarily. again, doing something like a hackish project with a single board - sure you can push the limits and see how far you can go.. but the side effects of insufficient voltage can manifest itself in very very confusing ways (having seen people spend months debugging mobile device issues where voltage was not sufficient for a freq thanks to a s/w sequencing bugs).. anyways.. there is no way I will agree to patches that wont meet TI specs, at the end of the day.
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.
True, I know that the software is not as optimized as it was with older systems. That's not something I am too afraid of (unless the software cannot be optimized by others because internal knowledge is required)
I would be more afraid if the hardware would be an issue here, but I guess hardwarewise the possibilities to save power should be there (as the OMAP5 was developed BEFORE the complete mobile department basically was shut down)
again, yes it was architected in a era when power was of significant concern and the major market that was targetted needed it. the point I hope I am conveying is that as time changed, what was architected is NOT the same SoC that is actually being produced.
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.
That's nothing new and nothing unexpected for us.
I just wanted to find out what the general status is and what could be done to improve it.
That said, it might not even be as bad as I thought - I've been using the current Pyra for over 8 hours without a charge now. I didn't do anything demanding (typed some text, created the keyboard layout, etc.), but it was with that unoptimized X server that constantly eats 8% CPU power and with all other stuff (USB Ports, 4G Modem, etc.) still enabled (interrupts also added up to about 8% more CPU power).
So we had 16% constant CPU load, everything enabled (also the keyboard LEDs) and the battery worked for over 8 hours. I don't know how long it will still work, as it's not yet calibrated, but that doesn't sound too bad.
I dont even know what a pyra is.. but anyways.. I do have a wish list of things to do where I can take some help ofcourse.. I am hoping that we can fix DVFS first -> ABB and AVS class 0, class1.5, class 2 for various TI SoCs will benefit everyone - But, this involves a lot of OPP framework and common work that needs to be done.
cpuidle attempt to put CPUx into CSWR ended into a pure debacle with dynamic dependency breakage all over.. we were told to not do that and there was no interest in debugging issues related to that.. so (as upstream today does), it is enabled as part of suspend path..
Suspend path: core INA is descoped as well -> core can only stay in ON state.. long story, but it is a culmination of a bunch of bugs -> i am waiting on documentation update before I post patches descoping those as well :(
Then we go into runtime pm optimization -> there again (with few exceptions) we might be able to get some optimizations done.
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.
Thanks, every little bit of help really is appreciated!
I am open to knowing what we would like to enable given the details that the hardware documentation provides.
Once the system is released, I'd gladly pay someone who would work on that - but persons capable of doing that are hard to find, and the question is: Is everything that's needed for an improvement available in the hardware documentation?
I hope so. I have'nt been paying too close an attention to OMAP5 documentation in recent years. but where we run into issues, using e2e.ti.com might provide answers.
BTW: How similar is the DRA7 to the OMAP5? I know it SOUNDS very similar on the paper, but is the hardware similar as well?
After falling in to that trap of assuming DRA7 and OMAP5 are related two years back, I have come to the conclusion after some interesting experience that it really is not - I will stop there :). No matter how much I like the idea, having known the realities, I just hope that folks dont have too high hopes there.