Raspberry Pi Forums

I've had my Pi for a while now, but there are still some aspects which I can find little, and often contradictory, information about:

Overclocking:
With 'force_turbo=0', does the SoC scale up and down linearly between *_freq_min and *_freq, or is it a step-change from one value to the other? Linux has the ability (via cpufreq) to control the CPU frequency, but not (unless RPi-specific kenel-changes handle this) the GPU or RAM frequencies or the Voltage supplied. So what's the relationship between the SoC's frequency-control and the OS' frequency-control? Can either override the other, or is one counted only as an advisory value to the other?
Additionally, does the SoC have any logic which would allow it to fine-tune the frequencies to hit maximum performance (by whatever metric this is measured) - if the maximum frequencies are all turned up to 11, will the Pi stop at a safe maximum, or will the system crash?

CMA:
What is the relationship, if any, between the kernel's CMA system (for providing contiguous memory to devices for DMA purposes) and the RPi CMA feature (to relocate memory between ARM and GPU)? Should the amount of CMA memory specified in the kernel configuration be equal to or a multiple of the CMA setting in config.txt or the 'coherent_pool' setting on the command-line. It seems that 'cma=2M coherent_pool=2M' is a deprecated set of arguments, whilst 'coherent_pool=6M' is the current recommendation - why is this? What are the effects of lowering or increasing the coherent_pool figure? Is this a fixed amount, or should it scale with the amount of memory left to CMA.
Is there a deterministic way to calculate 'cma_offline_start'? With the fixup_x and start_x files in-use, the Pi crashes during early boot if 'cma_offline_start' is less than 26 (with lwm 16 & hvm 32).

The example given during this topic has 'cma=2M coherent_pool=2M' and 'gpu_mem_256=160', then states that:

ARM has 96M always. GPU has 20M always

The 96M figure is 256 - 160 = 96, but the 20M figure is 16M (hard-coded minimum) + 2M (cma) + 2M (coherent_pool)? Does this mean that with gnu_mem_256=192 and coherent_pool=6M, the GPU always gets 22M? Or, is the (deprecated?) 'cma' value now fixed (at 2M?) and so the GPU gets more? Does this relate to the cma_offline_start value required? Are there any other tricks which allow CMA to be used, but which minimise the amount of memory reserved for the GPU for what will generally be a headless system?

config.txt parameters:
I've already had to use the undocumented (at http://elinux.org/RPiconfig, at least) 'cma_offline_start' parameter - what others exist? Is there a better resource than elinux.org with a canonical list? I'm also aware that it's possible to add 'start_file=start_x.elf'
and 'fixup_file=fixup_x.dat' to gain (in the former case, at least) additional firmware codecs - at the expense of requiring more dedicated GPU memory to boot. Are the differences between (and memory requirements of) the various fixup* and start* files documented anywhere? What do the *_cd* files do?

Thanks in advance,

Stuart

Please - does no-one have any information on any of the queries above?

Overclocking part:
Linux indeed has cpufreq mechanism for manipulating the frequency. It can't do this by magic, however. It has to have a driver. In case of a RaspberryPi, it's bcm2835-cpufreq driver (you can see the sources in drivers/cpufreq/bcm2835-cpufreq.c) in RaspberryPi specific kernel. If your kernel lacks this driver, it can't scale the clock.

Now if you look at the sources, you can find that the driver works by sending clock changes request (with a specific value that should be set) to GPU (by mailbox messaging model) which handles all the required operations. You can also check that min, max and cur values of the clock are get from GPU. And GPU gets those values from /boot/config.txt file.

I believe that all force_turbo=1 does is to force GPU to report min frequency as the same value as max frequency preventing cpufreq from changing to lower values, but I haven't checked that.

Conclusion: Linux driver is responsible for choosing the frequency that should be set (between min and max set in /boot/config.txt). So changing system CPU frequency governor rules will affect frequencies that are being requested. But it's the GPU firmware that really sets the clocks, not Linux. I hope this answers at least some of your questions about overclocking.