Inability to dynamically set core clock with recent firmware

Start with the clock-setting code in RGBtoHDMI's src/rgb_to_hdmi.c around line 306 and compare behavior before and after firmware commit 7fdcd00e. Use the linked previous firmware binary and a minimal reproduction, if available, to verify whether TAG_SET_CLOCK_RATE still changes CORE_CLK_ID. Done means identifying the regression or a documented workaround for dynamic core-clock changes.

Dom suggested I created an issue for this. It was originally a forum post

First a little bit of background... I'm working on a project called RGBtoHDMI that uses a Pi Zero as a video format converter to convert RGB Video (from the Acorn BBC Micro) to HDMI:

The project is at a fairly advanced stage and about 10 working prototypes exist.

You can find more information here:
https://github.com/hoglet67/RGBtoHDMI/wiki

This is a bare metal project, mostly C with a bit of assembler.

We need to generate a very accurate pixel sampling clock from the Pi that is at the same frequency as the BBC micro's video clock, and with minimal jitter. Actually, it's slightly more complicated than that, as the BBC Micro has 12MHz and 16MHz video modes, so we end up wanting a nominal 96MHz clock.

This clock needs to deal with any variations in the BBC micro's video clock. So if that is 700ppm faster, then we need a clock of 96.0672MHz. We calculate the required sampling clock by measuring the interval between two VSync pulses, and from this determine the clock error (in ppm) between the Beeb and the Pi.

We then use the mailbox interface to set the core core clocks to 384MHz +/- this error:

   // Switch to new core clock speed
   RPI_PropertyInit();
   RPI_PropertyAddTag( TAG_SET_CLOCK_RATE, CORE_CLK_ID, new_clock, 1);
   RPI_PropertyProcess();

We then use the Core Clock (PLLC) as a clock source with one of the GPClocks, which gives us a pixel sampling clock of ~96MHz.

The code is in github here:
https://github.com/hoglet67/RGBtoHDMI/blob/master/src/rgb_to_hdmi.c#L306

So finally to the point of this post....

It seems that the ability to change the Core clock dynamically in this manner stopped working with this (and all subsequent) version of firmware: 7fdcd00e

(The comment says "Rework the frequency/voltage scaling logic")

The issue is that clock remains unchanged, at it's original value of 400MHz (or whatever is set in config.txt)

Can anyone help me understand what's going on here and whether there is a workaround?

There is a binary release here, including the previous version of the firmware that works. Unfortunately, this isn't going to be much use for testing as it will hang before the clock setting stuff if it doesn't detect a valid video sync signal.

I'll try to work up a small example that exhibits the problem....