Re: SCMI Clock Protocol: clk_round_rate() mismatch with actual get_rate() results

[Cristian Marussi <cristian.marussi@arm.com>]

On Thu, Oct 30, 2025 at 02:36:14AM +0000, Peng Fan wrote:
> Hi all,
> 
Hi Peng,

> I'm encountering an issue with the SCMI Clock Protocol implementation in
> Linux where clk_round_rate() returns a value that matches the expected
> rate, but after calling clk_set_rate(), the actual rate retrieved via
> clk_get_rate() differs significantly. This discrepancy is causing problems
> for video modes that require precise pixel clock frequencies.
> 
> Here are some examples:
> 1) Expected: 148500000, Rounded: 148500000, Set: 148500000, Get: 148444444
> 2) Expected: 148352000, Rounded: 148352000, Set: 148352000, Get: 111333333
> 3) Expected: 74250000,  Rounded: 74250000,  Set: 74250000,  Get: 74222222
> 4) Expected: 74176000,  Rounded: 74176000,  Set: 74176000,  Get: 63619047
> 
> From what I understand, SCMI does not support a dedicated round_rate
> protocol operation. The Linux SCMI clk driver uses the initial clock attributes
> (either a discrete rate list or a min/max range) to implement clk_round_rate(),
> but this does not reflect the actual rate that will be set by the firmware. As a
> result, clk_round_rate() often returns the expected value, but clk_get_rate()
> shows a different result after clk_set_rate().
> 
> This behavior breaks video drivers that rely on precise clock rates for mode
> validation and setup.
> 
> SCMI supports clock parent relationships, and the Linux SCMI clk driver
> correctly builds the clock tree using this information. But when set rate,
> it will not propagate to parent, because determine_rate() is there
> for all scmi clks.
> 
> Questions:
> 
> Is there any plan to enhance SCMI to support accurate rate
> rounding or feedback?
> Would it be feasible for the SCMI clk driver to verify the
> actual rate after set_rate() and adjust accordingly?
> Are there recommended workarounds for drivers that
> require precise clock rates?
> Could SCMI protocol be extended to support parent-aware
> rate negotiation and rate propagation?
> 

A quick reply, there have been other reports/requests around this and an
internal discussion thread has been started with ATG, and this report of
yours too is being considered.

Once we have something concrete to discuss we'll get back in touch.

Thanks,
Cristian