dms75 wrote:the arm_freq goes up to 950 as it should, the core_freq goes to 374, still as expected, but the h264_freq is set to 224.4 instead of 280.5
If i understood the calculations correct the PLL should run at 374*6=2244 and if i divide 2244 by 250 i get 8.976. when rounded to the nearest even integer i should get a divisor of 8, not 10. so the resulting h264_freq should be 280.5 instead of 224.4, since i don't use avoid_pwm_pll.
Am i missing something?
Does it perhaps pick the resulting frequency which is nearer to 250 MHz instead? If so the documentation might need an (minor) update.
No, it rounds divisor up, and so frequency down. This means v3d/h264 may go down a little with overclock. However they are almost never a bottleneck, so it's unlikely to have an effect.
Currently the v3d/h264 doesn't increase when core increases, as it's usually not necessary, and ARM busy does not correlate closely with v3d/h264 busy.
However that is something I may tweak in a further update, to allow what you describe with gpu_freq=281 (but gpe_freq_min left at 250).