20*C Cooler, and now with water resistance!

[pyrat]

I can also imagine going to a higher frequency can be done quickly causing a short voltage drop and freezing the system. So if it's possible to increase the voltage a second before switching the frequency, you might be able to mitigate that situation.

Can one do that by editing dts alone ?How would it be ? Or does one need to change the governor code in the kernel ?
Do you add to the dts an operating point with the same frequency as your previous point but an higher voltage and then a point with the higher voltage and the higher frequency ?
I once looked at dts definitions for operating points but I've forgotten already.

I can also imagine if you log per Pyra when it locks up at the lowest frequency, you might be able to predict the voltage curve for all other frequencies. As I imagine there will be predictable curve.

I don't understand. You should plot what against what ?

 

[TeDaDeS]

I don't understand. You should plot what against what ?

If you find the lowest voltage per frequency for the reference Pyra you have a reference voltage curve. If you do it for a few more you can see the deviation.
I would assume a Pyra that has a higher or lower voltage will show the same over the complete curve. So by doing one measurement you could predict which total curve can be configured.

 

[Askarus]

Can one do that by editing dts alone ?How would it be ? Or does one need to change the governor code in the kernel ?
Do you add to the dts an operating point with the same frequency as your previous point but an higher voltage and then a point with the higher voltage and the higher frequency ?
I once looked at dts definitions for operating points but I've forgotten already.

No, you can not do that.
However I do not think that it is a huge problem if we increase the voltages a little.

This issue mostly affects the lower frequencies. So even if we can not reduce voltages by much at the lower frequencies,we still have some room at the higher frequencies.

Anyways, from my very very limited testing I did not see a huge improvement in battery life anyways. So spending a few more days just to save 0.01mV might not be worth it.

I got it somewhat stable even when using 50 MHz steps.
It still crashed during the shutdown process but maybe that can be solved by adding 0.1 mV to all frequencies.
Since undervolting is a very personal endeavour and is different between each device, a more conservative approach might be appropriate anyways.
Do not worry, I will still release the exact numbers that did a stable boot when used in isolation.
So everyone who wants to play around with voltage values has the lower bounds.

 

[netcat]

If anyone could tell me how to test his properly, feel free to leave a comment.
Is it enough to manually set the frequency or do I need to run a stress test for a few mins to make sure each voltage is stable?

so compilation is usually a pretty good stress of the system (make -J)

i would just like compile firefox and observe voltages and temperatures. note where the values max out (or crashes)

then create a chart illustrating your findings and the sweet spot you have discovered

 

[TeDaDeS]

Anyways, from my very very limited testing I did not see a huge improvement in battery life anyways.

Did you spot any significant temperature diiferences?

 

[Askarus]

Now this is interesting:
At the default settings the system runs 250MHz at 0.75V.
However, if I add more frequencies, especially at the lower end below 250MHz, 0.75V become unstable and I need to run 0.77 mV.

It seems like the more frequencies I add, the more unstable the lower frequencies become.
250MHz runs and boots at 0.69MHz if it is the only frequency available.
Once I go up by and 125MHz steps, my Pyra does not boot any more.
If I increase 250MHz back to 0.75mV, it boots and runs stable.
Anyrthing below 0.75V causes a freeze.
Interestingly enough, if I add lower frequencies, I need to increase the voltage.

Also it seems like there is one Pyra (the one I use for testing) that is particularly unstable and has those issues. The others boot just file at lower voltages.

 

[hns]

It seems like I can reduce the voltages by a tiny bit for each frequency while maintaining a stable system.
Any idea how I can do a stress test for each frequency?
Just set the frequency manually and let it run for a bit?
Not sure if that is enough
I will do that approach with the 125 MHz steps OS.
First I'll poke around and see how low I can get.
After that I'll test the values on a bunch of Pyras. I have 36 ones here that do boot, so if I want to be serious, I can get quite a nice test sample to make sure they run stable
After that, I may or may not tweak the whole thing to run at 50 MHz steps and get the voltages by simple interpolation.
I do not expect much but maybe a little

Unfortunately I can confirm that this is a thing


I can set voltages to 750000, 740000 and 730000 for 250MHz. However, I can not do 735000. If I do those tiny steps, the frequencies are simply not available in the list and will not be utilized by the governor.
So apparently the smallest steps we can take is 50000 uV.

On the positive side, this at least makes the whole thing manageable. It's still a lot of MHz values to tweak, however there are only a couple of values viable for each step (3, maybe 4 at max I would estimate).
Further, if we want to get the values into the OS, we need to leave some buffer anyways, so probably the bigger steps won't hurt.

Anyways, we have to take what we have at hand and from my limited testing so far it seems like we can slightly tweak the voltages and reduce it for each frequency by 1000 or 2000 uV.
This process will take quite a while to finish but I am motivated

Sorry that I don't find time to dig into all these interesting discussons (this, the Pyra features&improvements and those about LetuxOS). I have just seen that they exist but it is too much material to read through and follow...

Now for this: many years ago, I created a table with results from checking voltages vs. frequencies on an early prototype (the current hardware should be more robust as we can use it with 1.5 GHz) and there is a narrow band where it works. There seem to be two contradicting effects so that not every combination works. This is what the "SmartReflex" mechanism developed by Texas Instruments should take automatically care of so that it would be sufficient to choose some frequency and "SmartReflex" would choose the best voltage. And ignore the OPP tables. This would even adapt to every individual chip (they may have production induced differences). Unfortunately this works only on OMAP3 and the OMAP4/5 drivers in Linux are incomplete/broken/deprecated/removed. And nobody has documentation how it should work.

But you can see that there is a big influence on power demand by increasing voltage and/or frequency. It turned out to be a factor 20 between 250 MHz and 1.5 GHz. Generally it shows a big - and nonlinear - conflict between battery life and processing power...

Regarding the frequency steps I think it makes not much sense to have micro-steps. And voltage steps are indeed limited by the power controller chip to 50mV (see data sheet "Palmas" and my table/graph).

About the influence of the govenor: it measures system load every now and then and then increases or decreases the frequency and the kernel adjusts the voltage. A typical scenario is if the Pyra is in idle, it sits there at 250 MHz. As soon as you press a button or touch the screen it goes up to e.g. 750 MHz or 1 GHz. After a second or so it falls down again. But if you run something more demanding it almost always increases to the maximum available value. So I think having 700, 750 and 800 MHz micro-steps won't make a noticeable difference since they are skipped in most cases. Or if you set this as the max. frequency you would only gain 5% of power demand steps - and only if the govenor uses them.

BTW: you can look into cpufreq-info which percentage of time a frequency point is active.

This table and rationale was the basis of the LetuxOS OPP points . And they include some safety margin, so that they should work everywhere out of the box (you can't modify the values manually if the device does not even boot). Hope this adds some light and facets to your discussion and experiments.

PS: for these tests I used the NEON load-test originally written by Notaz to really demand the CPU - but GPU was off.
PPS: I think I read about someone commenting that the battery is not charged to 100%. This is for purpose. Since 100% is equivalent to 4.2V but there is a 50mV voltage drop in the charging circuit and the way how the LTE modem is connected, the modem will get a too high voltage and turns its transmitter off. So an almost full battery and charging power turns off the modem. The only solution we found was to limit the carging voltage to 4.15V which is equivalent to ca. 85% as reported by the fuel gauge chip. What is missing is to multiply the fuel gauge % by 1.17 so that it is displayed as 100% and nobody would notice

 

[Askarus]

Hey, Thanks for passing by

Regarding the frequency steps I think it makes not much sense to have micro-steps.

Will it hurt? I did not notice any downsides when using 50 MHz steps.

And voltage steps are indeed limited by the power controller chip to 50mV (see data sheet "Palmas" and my table/graph).

Strange, I can set 10mV volt steps and it makes a difference in stability. This is not at voltages that are being rounded up/down to the next full 50mV.
I noticed immediate improvements (will boot vs. will not boot) if I increase voltage by 10mV.
Will it always round up to the next 50 step or will it round down to the nearest 50? Like 710 and 720mV would result in 700mV but 730 and 740mV would result in 750mV?
That would probably explain my observations.

According to EvilDragon, that lowest frequency that the OMAP5 can handle is 250MHz. Everything below, he says, are "fake frequencies". Is that true?
I can, for example, define steps of 50 MHz in the device tree starting from 50MHz (50, 100, 150, 200, 250).
If I hard lock the max frequency to 50MHz, the system becomes WAY slower than at 250MHz but is still stable.

So in the background, is the OMAP still running at 250MHz and somehow the OS is artificially limiting the perceived clock speed?

All my testing and observations are 100% done via black box testing, without knowing any of the OMAP specifications.
I will soon make a post where I publish my frequency testings and my device trees with my tweaked voltages and frequencies.
I'll ping you, so that you can check the values and verify what makes sense and what might be nonsense according to your knowledge.

 

[hns]

Hey, Thanks for passing by


Will it hurt? I did not notice any downsides when using 50 MHz steps.


Strange, I can set 10mV volt steps and it makes a difference in stability. This is not at voltages that are being rounded up/down to the next full 50mV.
I noticed immediate improvements (will boot vs. will not boot) if I increase voltage by 10mV.
Will it always round up to the next 50 step or will it round down to the nearest 50? Like 710 and 720mV would result in 700mV but 730 and 740mV would result in 750mV?
That would probably explain my observations.

According to EvilDragon, that lowest frequency that the OMAP5 can handle is 250MHz. Everything below, he says, are "fake frequencies". Is that true?
I can, for example, define steps of 50 MHz in the device tree starting from 50MHz (50, 100, 150, 200, 250).
If I hard lock the max frequency to 50MHz, the system becomes WAY slower than at 250MHz but is still stable.

So in the background, is the OMAP still running at 250MHz and somehow the OS is artificially limiting the perceived clock speed?

All my testing and observations are 100% done via black box testing, without knowing any of the OMAP specifications.
I will soon make a post where I publish my frequency testings and my device trees with my tweaked voltages and frequencies.
I'll ping you, so that you can check the values and verify what makes sense and what might be nonsense according to your knowledge.

Well, this mixes up reommended (by TI) values and experimentatlly proven values "to work". The problem is that there is a "works sometimes" range between certainly good and certainly bad values. I think the 250 MHz is what TI has said as the minimum they guarantee. It may run slower but there is no guaranee. This has its basis in how CMOS and MOS circuits and transistors work. Some are designed for a minimum (and maximum) clock speed. And no manufacturer recommends to go below to stay on the safe side. If you go below you are unsafe but it may work for you. For the next 5 months and suddenly fail. But nobody knows...

Regrding the voltage steps you are right. The DC/DC converters (SMPS) have indeed 10mV steps (I hadn't looked at the right place), but some have a wider range and 20mV steps. The LDOs are in 50mV steps.

Does it hurt: well, unnecessary complexity with marginal benefit may sometimes hurt

 

[TeDaDeS]

I think I read about someone commenting that the battery is not charged to 100%. This is for purpose. Since 100% is equivalent to 4.2V but there is a 50mV voltage drop in the charging circuit and the way how the LTE modem is connected, the modem will get a too high voltage and turns its transmitter off. So an almost full battery and charging power turns off the modem. The only solution we found was to limit the carging voltage to 4.15V which is equivalent to ca. 85% as reported by the fuel gauge chip. What is missing is to multiply the fuel gauge % by 1.17 so that it is displayed as 100% and nobody would notice

That answers the battery charging mystery

So if you don't have the LTE version you should be able to charge to the full 100% ?

 

[netcat]

BTW: you can look into cpufreq-info which percentage of time a frequency point is active.

This is very interesting! We get a sense for the governors behaviour.

My laptop running with governor=conservative (mostly) shows:

cpufreq stats:
2.40 GHz:0.00%,
2.27 GHz:0.00%,
2.13 GHz:3.38%,
2.00 GHz:0.69%,
1.87 GHz:0.64%,
1.73 GHz:1.09%,
1.60 GHz:1.2%

Unclear why the % don't sum to 100...