SmartReflex on Pyra (and Pandora?)


Exophase

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,307
Age
41
Location
Cleveland OH
SmartReflex refers to a bunch of TI technologies, in particular it includes voltage tweaking based on dynamic measured values like temperature.

According to notaz, it was not enabled on Pandora: https://pyra-handheld.com/boards/th...oming-from-the-pyra.77152/page-3#post-1370927 The expectation was that the performance improvement might be minimal.

It is also currently not yet enabled on Pyra.

I was curious to see if anyone had done any tests to see what kind of effect it could have. It's hard to find very concrete information, but it looks like it can have a significant effect on some devices:

https://wiki.maemo.org/Smartreflex
http://talk.maemo.org/showthread.php?t=81580
http://forum.xda-developers.com/galaxy-nexus/general/smartreflex-undervolting-t2211675
https://talk.maemo.org/showpost.php?p=1005782&postcount=2

I don't know if it's worth implementing in Pandora at this point, but I think it should definitely be a priority to implement in Pyra. Even saving an average of a few percent in power consumption at peak loads would be very important.
 
So this isn't just about dropping OPP and clock speed when the system starts to cook itself, I assume. How could a Pandora running this outperform a Pandora running at maxium OPP and a tuned clock speed?
 
So this isn't just about dropping OPP and clock speed when the system starts to cook itself, I assume. How could a Pandora running this outperform a Pandora running at maxium OPP and a tuned clock speed?

AFAIK, when you set an OPP it programs the PMIC to output some voltage which is fixed and static. This value has to work under all possible conditions for all possible hardware, so it has to be conservative.

The point of the adaptive voltage scaling feature in SmartReflex is to allow for a lower voltage based on dynamic conditions. For example, if the chip temperature is 40C it maybe won't need the same voltage it'd need if it were 80C. And if the chip is not of poor yield. Or if the chip is not as old/aged as possible.

Another possibility is that it corrects for inaccuracy and dynamic fluctuations of the voltage regulator itself. For example, if the regulator is specified for a maximum error of 5% a value of +5% has to always be given as a safety bound. But that 5% error might not be usual (especially under normal operating conditions). Another condition is that under certain loads or transients the voltage may droop, so margin has to be provided to prevent the voltage from ever dropping by too much. If the voltage is measured with a reasonably accurate sensor closed loop control can be performed to dynamically ensure the voltage keeps up as necessary, instead of providing static margins that you always pay for.

I don't know to precise detail what it does and doesn't do, I just know that it lowers typical voltages (and therefore power consumption) and that users of other OMAP-based hardware have reported significant power savings.
 
For some reason, after what went about with the kernel mailing list, I wouldn't be surprised if the SmartReflex stuff was eventually descoped for OMAP5 :p
 
Well, according to my information, SmartReflex hasn't been added properly to the OMAP5 drivers yet (and TI doesn't plan to do that), but it CAN be implemented by anyone with the information we can access.
I'm not really knowledgable about that stuff, but if you want to take a look at it, I would be happy to get you in contact with persons who know what you need to know to implement it (and I'd be happy if it would work :D)
 
Well, according to my information, SmartReflex hasn't been added properly to the OMAP5 drivers yet (and TI doesn't plan to do that), but it CAN be implemented by anyone with the information we can access.
I'm not really knowledgable about that stuff, but if you want to take a look at it, I would be happy to get you in contact with persons who know what you need to know to implement it (and I'd be happy if it would work :D)

Sorry, but I can't possibly take on something like this now :(

But maybe other people here can, and development discussion can happen here. I don't really know...
 
Well, according to my information, SmartReflex hasn't been added properly to the OMAP5 drivers yet (and TI doesn't plan to do that), but it CAN be implemented by anyone with the information we can access.
I'm not really knowledgable about that stuff, but if you want to take a look at it, I would be happy to get you in contact with persons who know what you need to know to implement it (and I'd be happy if it would work :D)
I don't understand. If the chip supports this, why on earth wouldn't they have drivers for it?
 
Because they moved away from the mobile market and don't want to spend more ressources on that.
 
This is only the generic driver, AFAIK the registers for the OMAP5 aren't defined for it yet.
 
According to notaz, it was not enabled on Pandora: https://pyra-handheld.com/boards/th...oming-from-the-pyra.77152/page-3#post-1370927 The expectation was that the performance improvement might be minimal.
It's not functional in 3.2, but out of the interest, I've picked some smartreflex patches from newer kernels and it seems to work now.

Here is a quick test on my 1GHz running @1GHz, results from the battery monitoring chip:
+ ~20mW while idle with screen off
- ~12mW while idle with screen on
- ~140mW while bash is spinning a loop @1GHz
- ~180mW while bash is spinning a loop @1.2GHz

The power draw improvement while overclocking is not bad, ~10% I believe, but I really hate the negative effect on idle, as that's what my pandora is doing the most. No idea what effect does it have on stability though.
Edit: my unit crashed shortly after these tests, even if it's known to be stable @1.2GHz, so SR probably can't be used while overclocking.

For those who want to try smartreflex on pandora themselves:
  • install all OS updates and reboot
  • copy http://notaz.gp2x.de/tmp/uImage_sr to /boot/uImage-3 and reboot EDIT: no longer needed, the driver now comes with OS updates
  • Code:
    sudo su
    mkdir /debug
    mount -t debugfs none /debug
    echo 1 > /debug/smartreflex/sr_mpu_iva/autocomp
 
Last edited:
Thanks notaz, that's really helpful. I didn't think it'd be something that could be enabled with patches.

Other people wrote that the SR drivers for different devices (I think some OMAP4 ones..) have hard voltage caps which interfere with overclocking, but that they were able to modify them to remove them. I think they also mentioned lower end hard caps which could explain the increase in idle consumption. If I remember right, the solution was just to disable SR outside of certain frequeny ranges.

I would say -140mW at 1GHz is a very nice improvement. For Pyra, even something like 5% could be extremely welcome.

I guess I'll at least try to look at the SR driver and the OMAP5 TRM and see if the same functionality that applies to OMAP3 and 4 maps here... my first concern is that a driver could require documentation of the PMIC which is not public.
 
when dreams come true... thanks notaz&exo guru-team! :)
 
It's not functional in 3.2, but out of the interest, I've picked some smartreflex patches from newer kernels and it seems to work now.

Here is a quick test on my 1GHz running @1GHz, results from the battery monitoring chip:
+ ~20mW while idle with screen off
- ~12mW while idle with screen on
- ~140mW while bash is spinning a loop @1GHz
- ~180mW while bash is spinning a loop @1.2GHz

The power draw improvement while overclocking is not bad, ~10% I believe, but I really hate the negative effect on idle, as that's what my pandora is doing the most. No idea what effect does it have on stability though.
Edit: my unit crashed shortly after these tests, even if it's known to be stable @1.2GHz, so SR probably can't be used while overclocking.

For those who want to try smartreflex on pandora themselves:
  • install all OS updates
  • copy http://notaz.gp2x.de/tmp/uImage_sr to /boot/uImage-3 and reboot
  • Code:
    sudo su
    mkdir /debug
    mount -t debugfs none /debug
    echo 1 > /debug/smartreflex/sr_mpu_iva/autocomp
This kernel is missing squashfs support, I can't mount any PNDs! Where's the default kernel located? I can't find it in the repos, I need it.
 
This kernel is missing squashfs support
No it's not, you're probably just missing the kernel modules for it.

Yesterday I've pushed an OS update which has the newest stable 3.2 kernel, that probably made the modules incompatible. The package with latest kernel+modules is this one:
https://openpandora.org/feeds/unsta...a-kernel2_3.2-pandora-r30.5_omap3-pandora.ipk

Anyway the kernel that comes from OS update now has the SmartReflex driver, I've updated my post to reflect it.
 
No it's not, you're probably just missing the kernel modules for it.

Yesterday I've pushed an OS update which has the newest stable 3.2 kernel, that probably made the modules incompatible. The package with latest kernel+modules is this one:
https://openpandora.org/feeds/unsta...a-kernel2_3.2-pandora-r30.5_omap3-pandora.ipk

Anyway the kernel that comes from OS update now has the SmartReflex driver, I've updated my post to reflect it.
Oh oops! So if I use opkg to install that package it should fix it? Sorry for accusing you of stuff.
 
Yes, but in case you already installed it through OS upgrade you'll need to use --force-reinstall , which doesn't work correctly because of some opkg bug. Workaround is to run it it twice, be careful to not reboot between those opkg runs.
 
Back
Top