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

[Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>]

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