[PATCH] i2c: qcom-geni: restore tSCL with 32MHz I2C fast-mode

[PATCH] i2c: qcom-geni: restore tSCL with 32MHz I2C fast-mode

[Daniel J Blueman]

Commit cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
SE_GENI_CLK_SEL") allowed GENI to use 32MHz clock. This changed I2C
timing, making the Yoga Slim 7x keyboard (ITE 048D:8987) unusable
on all boots, and touchpad unusable on some boots, resulting in:

  i2c_hid_of 1-003a: unexpected HID descriptor bcdVersion (0x0000)
  i2c_hid_of 1-002c: failed to fetch HID descriptor: -110

With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
versus the previous default of 521ns, however the I2C spec has a
minimum tSCL of 600ns.

Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
verified on Lenovo Yoga Slim 7x X1E-80100.

Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock")
Cc: <stable@vger.kernel.org>
Signed-off-by: Daniel J Blueman <daniel@quora.org>
---
 drivers/i2c/busses/i2c-qcom-geni.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index 6a39e21d5ed4..1336a09ca183 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -193,7 +193,7 @@ static const struct geni_i2c_clk_fld geni_i2c_clk_map_19p2mhz[] = {
 /* source_clock = 32 MHz */
 static const struct geni_i2c_clk_fld geni_i2c_clk_map_32mhz[] = {
 	{ I2C_MAX_STANDARD_MODE_FREQ, 12, 9, 10, 26 },
-	{ I2C_MAX_FAST_MODE_FREQ, 4, 3, 9, 19 },
+	{ I2C_MAX_FAST_MODE_FREQ, 4, 5, 9, 19 },
 	{ I2C_MAX_FAST_MODE_PLUS_FREQ, 2, 3, 5, 15 },
 	{}
 };
-- 
2.53.0

Re: [PATCH] i2c: qcom-geni: restore tSCL with 32MHz I2C fast-mode

[Mukesh Savaliya]

Thanks Daniel !

On 9/29/2026 9:44 AM, Daniel J Blueman wrote:
> Commit cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
> SE_GENI_CLK_SEL") allowed GENI to use 32MHz clock. This changed I2C
> timing, making the Yoga Slim 7x keyboard (ITE 048D:8987) unusable
> on all boots, and touchpad unusable on some boots, resulting in:
> 
>    i2c_hid_of 1-003a: unexpected HID descriptor bcdVersion (0x0000)
>    i2c_hid_of 1-002c: failed to fetch HID descriptor: -110
> 
> With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
> versus the previous default of 521ns, however the I2C spec has a
> minimum tSCL of 600ns.
> 
> Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
> verified on Lenovo Yoga Slim 7x X1E-80100.
> 

There might be a final count which i should get and update back.
Since this fix is working though not suggested per hardware guidance, 
should we consider as temporary fix and move ahead to prevent failing 
usecase ?

Any thought @andi ?

> Fixes: 506bb2ab0075 ("i2c: qcom-geni: Support systems with 32MHz serial engine clock")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> ---
>   drivers/i2c/busses/i2c-qcom-geni.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
> index 6a39e21d5ed4..1336a09ca183 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -193,7 +193,7 @@ static const struct geni_i2c_clk_fld geni_i2c_clk_map_19p2mhz[] = {
>   /* source_clock = 32 MHz */
>   static const struct geni_i2c_clk_fld geni_i2c_clk_map_32mhz[] = {
>   	{ I2C_MAX_STANDARD_MODE_FREQ, 12, 9, 10, 26 },
> -	{ I2C_MAX_FAST_MODE_FREQ, 4, 3, 9, 19 },
> +	{ I2C_MAX_FAST_MODE_FREQ, 4, 5, 9, 19 },

Exact change to come from hardware experts, till that i am hoping this 
revert should be fine.

>   	{ I2C_MAX_FAST_MODE_PLUS_FREQ, 2, 3, 5, 15 },
>   	{}
>   };

Re: [PATCH] i2c: qcom-geni: restore tSCL with 32MHz I2C fast-mode

[Daniel J Blueman]

On Wed, 30 Sept 2026 at 15:19, Mukesh Savaliya
<mukesh.savaliya@oss.qualcomm.com> wrote:
>
> Thanks Daniel !
>
> On 9/29/2026 9:44 AM, Daniel J Blueman wrote:
> > Commit cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
> > SE_GENI_CLK_SEL") allowed GENI to use 32MHz clock. This changed I2C
> > timing, making the Yoga Slim 7x keyboard (ITE 048D:8987) unusable
> > on all boots, and touchpad unusable on some boots, resulting in:
> >
> >    i2c_hid_of 1-003a: unexpected HID descriptor bcdVersion (0x0000)
> >    i2c_hid_of 1-002c: failed to fetch HID descriptor: -110
> >
> > With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
> > versus the previous default of 521ns, however the I2C spec has a
> > minimum tSCL of 600ns.
> >
> > Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
> > verified on Lenovo Yoga Slim 7x X1E-80100.
> >
>
> There might be a final count which i should get and update back.
> Since this fix is working though not suggested per hardware guidance,
> should we consider as temporary fix and move ahead to prevent failing
> usecase ?

If you can get the final values into a patch for the next -rc instead
of my fix here, that would be the minimal path for everyone. You or
the hardware team can cross-check against the I2C standard as I did
[1, p44].

I would revert the original patch if there is hardware that uses the
I2C 1MHz fast-mode, since the current timings aren't to spec, but also
weren't before.

Thanks,
  Dan

-- [1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf
-- 
Daniel J Blueman

Re: [PATCH] i2c: qcom-geni: restore tSCL with 32MHz I2C fast-mode

[Mukesh Savaliya]

Thanks Dan !

On 9/30/2026 3:01 PM, Daniel J Blueman wrote:
> On Wed, 30 Sept 2026 at 15:19, Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com> wrote:
>>
>> Thanks Daniel !
>>
>> On 9/29/2026 9:44 AM, Daniel J Blueman wrote:
>>> Commit cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
>>> SE_GENI_CLK_SEL") allowed GENI to use 32MHz clock. This changed I2C
>>> timing, making the Yoga Slim 7x keyboard (ITE 048D:8987) unusable
>>> on all boots, and touchpad unusable on some boots, resulting in:
>>>
>>>     i2c_hid_of 1-003a: unexpected HID descriptor bcdVersion (0x0000)
>>>     i2c_hid_of 1-002c: failed to fetch HID descriptor: -110
>>>
>>> With this change, t_high_cnt 3 and clk_div 4 gave a tSCL of 375ns
>>> versus the previous default of 521ns, however the I2C spec has a
>>> minimum tSCL of 600ns.
>>>
>>> Restore tSCL to the spec with t_high_cnt 5 giving a 625ns tSCL,
>>> verified on Lenovo Yoga Slim 7x X1E-80100.
>>>
>>
>> There might be a final count which i should get and update back.
>> Since this fix is working though not suggested per hardware guidance,
>> should we consider as temporary fix and move ahead to prevent failing
>> usecase ?
> 
> If you can get the final values into a patch for the next -rc instead
> of my fix here, that would be the minimal path for everyone. You or
> the hardware team can cross-check against the I2C standard as I did
> [1, p44].
> 

Yes, Agree Dan ! That would be quick and fast way.
I am in discussion to get more details on correct configuration meeting 
the specs.

> I would revert the original patch if there is hardware that uses the
> I2C 1MHz fast-mode, since the current timings aren't to spec, but also
> weren't before.
> 
Agree, after having last change thought that would meet the spec.


> Thanks,
>    Dan
> 
> -- [1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Re: [PATCH] i2c: qcom-geni: restore tSCL with 32MHz I2C fast-mode

[Sasha Levin]

> On 9/30/2026 3:01 PM, Daniel J Blueman wrote:
> > I would revert the original patch if there is hardware that uses the
> > I2C 1MHz fast-mode, since the current timings aren't to spec, but also
> > weren't before.

For stable: cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in
SE_GENI_CLK_SEL") has already shipped in 7.2.9, 6.18.55 and 6.12.112, and is
queued for 6.6, 6.1, 5.15 and 5.10.

The 32 MHz clock map (506bb2ab0075, v6.13+) does not exist in 6.12.y and older.
The backports there pick only the 19.2 MHz entry, so the Yoga Slim 7x /
X1E80100 timing regression cannot occur on 6.12.y or older, and I'm keeping the
6.6 and older queues as they are.

7.2.y and 6.18.y do have the 32 MHz table and are affected. Once the fix lands
in mainline, I'll pick it up for 7.2 and 6.18.

-- 
Thanks,
Sasha