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

On 7/21/26 5:41 PM, Loic Poulain wrote:
> Hi Konrad,
> 
> On Tue, Jul 21, 2026 at 5:07 PM Konrad Dybcio
> <[email protected]> wrote:
>>
>> On 7/21/26 4:58 PM, 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, actively set the clock to the
>>> expected rate at probe time. Warn if the rate could not be applied so the
>>> user is informed that timings may be incorrect.
>>>
>>> Signed-off-by: Loic Poulain <[email protected]>
>>> ---

[...]

>>> +     cci_clk = devm_clk_get(dev, "cci");
>>> +     if (IS_ERR(cci_clk))
>>> +             return dev_err_probe(dev, PTR_ERR(cci_clk), "failed to get CCI clock\n");
>>> +
>>> +     clk_set_rate(cci_clk, cci->data->cci_clk_rate);
>>> +     if (clk_get_rate(cci_clk) != cci->data->cci_clk_rate)
>>> +             dev_warn(dev, "CCI clock is not at expected %lu Hz\n",
>>> +                      cci->data->cci_clk_rate);
>>
>> This needs to go through OPP.
>>
>> Feel free to take over and refresh:
>>
>> https://lore.kernel.org/linux-arm-msm/[email protected]/
> 
> Sorry for missing your series earlier. I still think we need this
> series to restore the expected clock rate information in the driver
> and enforce it at probe time, right now the timing tables are
> calibrated for a specific frequency and the driver has no way to
> verify or correct what it gets.

What I'm saying is that you need to call dev_pm_opp_set_rate()
anyway, clk_set_rate() doesn't take into account the required
OPPs for a frequency, and those are very low, but non-zero for
CCI. Unfortunately that comes with the added headache of
maintaining an OPP table for each target anyway..

Konrad