Fix over_voltage description

[MichaIng]

The default over_voltage value equals 0 on all RPi models.
This equates to a maximum voltage of 1.35V (1.2V on RPi 1).
Changing over_voltage only affects the upper voltage limit by 25mA with each integer step.

over_voltage_min affects the minimum voltage which defaults to 0.
This equates to a minimum voltage of 1.2V.
Changing over_voltage_min affects the lower voltage limit by 25mA with each integer step.

Additional minor clarification with this commit:

1. The default CPU scaling governor on RPi is powersave. A SysV service, shipped with raspi-config, changes it to ondemand during boot.
   The link to CPUFreq documentation is now pointing to an up-to-date official Linux documentation, since the previous reference is outdated and includes lots of information which does not apply on RPi.

2. The ondemand governor has an effect even without overclocking settings, scaling the frequency between arm_freq and arm_freq_min.
   Only on RPi 1, these two settings are equal by default, practically disabling dynamic frequency scaling.

3. The safest option to disable dynamic clocking is to apply a static scaling governor like powersave or performance, since this does not involve the risk to void warranty.

[lurch]

More questions for @popcornmix ? 😉

[MichaIng]

Jep, sorry for being a bid noisy today, one test lead to the next and one question to the next 😄.

[MichaIng]

Okay, I think I got it now right. over_voltage and over_voltage_min basically behave like arm_freq and arm_freq_min, only without the intermediate steps and max voltage being applied as fast as ARM frequency does not equal arm_freq_min. The AVS description gives a different impression, but lets keep it like that.

The voltages ranges in the description are true for RPi 1 (upper limit = 1.2V => static voltage with default over_voltage=0) but 1.35V on all other models.

There is still one thing incorrect: vcgencmd measure_volts sdram_p reports 1.225V on all tested RPi models (Zero, 1, 2) and over_voltage_sdram_p setting has no effect on this, at least not on my RPi 2 within a tested range of -2 and 1. But probably this is a separate issue to investigate.

[JamesH65]

@popcornmix When you have a few seconds free, could you double check this for accuracy? Ta.

[ghost]

Only on RPi 1, these two settings are equal by default, practically disabling dynamic frequency scaling.

I'm not sure if Pi 1 can do dynamic frequency scaling - I had always assumed it can't.

[MichaIng]

I'm not sure if Pi 1 can do dynamic frequency scaling - I had always assumed it can't.

It can, but as mentioned does not do with defaults: arm_freq_min=arm_freq=700
I think this is the reason for the docs statement prior to this PR:

It has no effect if you have no overclock settings, but if you overclock, the CPU frequency will vary with processor load.

While it is true for RPi1, for all other models it is wrong and should hence be clarified 🙂.

[aallan]

I'd encourage you to wrap this PR up in the next week or so as we're in the process of transitioning the documentation from the current Markdown-based source format to Asciidoc. At some point soon — probably around the end of June, beginning of July — we will freeze the current documentation repo. After that time contributions and PRs based on the Markdown source will not be accepted, and any PRs that are still open will be closed.

See #1911 for full details.

[MichaIng]

I rebased this commit onto the current master branch, no changes required. Ready from my side.