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

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

[Peng Fan]

Hi all,

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?

Thanks,
Peng.

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

[Cristian Marussi]

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

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

[Peng Fan]

Hi Cristian,

> Subject: Re: SCMI Clock Protocol: clk_round_rate() mismatch with
> actual get_rate() results
...
> > 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 for letting me know.  Waiting for your update on this.

At same time, we have to find a method in downstream to
address the issue.

Thanks,
Peng.

> 
> Thanks,
> Cristian