[PATCH] i2c: qcom-cci: skip core clock rates the clock cannot provide

[PATCH] i2c: qcom-cci: skip core clock rates the clock cannot provide

[Oleg Keri]

cci_get_required_rate() picks the lowest rate that has timings for every
active master, but never checks that the CCI clock can run at it. On
glymur, sm8750 and kaanapali the CCI clock table has no 19.2 MHz entry,
so the request rounds up to 30 MHz or 37.5 MHz, the timing lookup for
the running rate fails and the controller does not probe:

  i2c-qcom-cci ac16000.cci: CCI clock is not at expected 19200000 Hz
  i2c-qcom-cci ac16000.cci: no timing for mode 1 at CCI clock 30000000 Hz
  i2c-qcom-cci ac16000.cci: probe with driver i2c-qcom-cci failed with error -95

Only consider rates clk_round_rate() can deliver exactly. Glymur then
runs its CCI at 37.5 MHz, which has timings for every mode.

Fixes: fa1eb3af12fa ("i2c: qcom-cci: Enforce the required CCI clock rate")
Signed-off-by: Oleg Keri <okerixx@gmail.com>
---
 drivers/i2c/busses/i2c-qcom-cci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/i2c/busses/i2c-qcom-cci.c b/drivers/i2c/busses/i2c-qcom-cci.c
index 6d8be7b8b79d..289368c00fe4 100644
--- a/drivers/i2c/busses/i2c-qcom-cci.c
+++ b/drivers/i2c/busses/i2c-qcom-cci.c
@@ -586,6 +586,9 @@ static int cci_get_required_rate(struct cci *cci, unsigned long *rate)
 	for (int ri = 0; ri < NUM_CCI_CLK_RATES; ri++) {
 		bool supported = true;
 
+		if (clk_round_rate(cci->cci_clk, cci_clk_rates[ri]) != cci_clk_rates[ri])
+			continue;
+
 		for (int i = 0; i < cci->data->num_masters; i++) {
 			int mode = cci->master[i].mode;
 
-- 
2.55.0

Re: [PATCH] i2c: qcom-cci: skip core clock rates the clock cannot provide

[Loic Poulain]

On Fri, Oct 9, 2026 at 1:07 AM Oleg Keri <okerixx@gmail.com> wrote:
>
> cci_get_required_rate() picks the lowest rate that has timings for every
> active master, but never checks that the CCI clock can run at it. On
> glymur, sm8750 and kaanapali the CCI clock table has no 19.2 MHz entry,
> so the request rounds up to 30 MHz or 37.5 MHz, the timing lookup for
> the running rate fails and the controller does not probe:
>
>   i2c-qcom-cci ac16000.cci: CCI clock is not at expected 19200000 Hz
>   i2c-qcom-cci ac16000.cci: no timing for mode 1 at CCI clock 30000000 Hz
>   i2c-qcom-cci ac16000.cci: probe with driver i2c-qcom-cci failed with error -95

sm8750 and kaanapali have a single 37.5Mhz frequency point which
should not cause a probe failure.

>
> Only consider rates clk_round_rate() can deliver exactly. Glymur then
> runs its CCI at 37.5 MHz, which has timings for every mode.
>
> Fixes: fa1eb3af12fa ("i2c: qcom-cci: Enforce the required CCI clock rate")

Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>


> Signed-off-by: Oleg Keri <okerixx@gmail.com>
> ---
>  drivers/i2c/busses/i2c-qcom-cci.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-cci.c b/drivers/i2c/busses/i2c-qcom-cci.c
> index 6d8be7b8b79d..289368c00fe4 100644
> --- a/drivers/i2c/busses/i2c-qcom-cci.c
> +++ b/drivers/i2c/busses/i2c-qcom-cci.c
> @@ -586,6 +586,9 @@ static int cci_get_required_rate(struct cci *cci, unsigned long *rate)
>         for (int ri = 0; ri < NUM_CCI_CLK_RATES; ri++) {
>                 bool supported = true;
>
> +               if (clk_round_rate(cci->cci_clk, cci_clk_rates[ri]) != cci_clk_rates[ri])
> +                       continue;
> +
>                 for (int i = 0; i < cci->data->num_masters; i++) {
>                         int mode = cci->master[i].mode;
>
> --
> 2.55.0
>