Re: [PATCH v2 3/3] i2c: qcom-cci: Fix CCI clock rate enforcement

Hi Loic.

On 7/27/26 12:21, Loic Poulain wrote:
> The hw_params timing values (thigh, tlow, etc.) are in CCI clock ticks
> and were calibrated for a specific clock rate per hardware variant. If
> the clock is running at a different rate the I2C timings will be wrong,
> potentially violating the I2C specification.
> 
> Rather than just warning about a mismatch like before, actively set
> the clock to the expected rate, using the OPP framework so that boards
> which (will) describe an opp table also get the required power-domain and
> regulator votes for that rate. The OPP table is optional, boards without
> one simply fall back to a plain clk_set_rate() behavior, so existing DTs
> keep working.
> 

Can you please share any deficiencies you see, if a regular mechanism
of 'assigned-clock-rates' is used in dt descriptions instead of setting
a supported clock rate from the driver? Or is opps mechanism supposed to
substitute it?

For instance qcom,i2c-cci.yaml example uses 'assigned-clock-rates'
properly, in many .dtsi files (NB, but not all, which means for a number
of platforms CCI hw programming is done incorrectly today) CCI clock
rate is set this way.

It seems to be sufficient to get the clock rate in probe, compare it
against the supported clock rate associated with a wanted mode, return
-EOPNOTSUPP if there is no match.

To get a better idea of my proposal please check this simple commit:

* https://github.com/torvalds/linux/compare/master...vzapolskiy:linux-lpc32xx:cci-speed-modes

> Tested-by: Wenmeng Liu <[email protected]>
> Suggested-by: Konrad Dybcio <[email protected]>
> Signed-off-by: Loic Poulain <[email protected]>

-- 
Best wishes,
Vladimir