The Qualcomm CCI I2C controller has an SCL clock stretch enable bit in
the MISC_CTL register. Currently the driver hardcodes this off in
per-SoC hw_params tables, with no way to enable it from the device tree
on a per-master basis.

Clock stretching is required for GMSL configurations where the
deserializer uses it to absorb the latency imposed by forwarding I2C
transactions across the serial link. Without it, the CCI master exhibits
intermittent transaction failure.

This series adds a "qcom,scl-stretch-enable" boolean DT property to
individual CCI i2c-bus sub-nodes. The property ORs with the existing
hw_params default so it is purely additive and does not affect masters
that do not set it.

Tested on sa8775p using the qcom,sm8250-cci compatible string with two
CCI buses connected to one max96724/max96717 GMSL2 pair each. Enabling
this property eliminated intermittent NACK errors during serializer
and/or deserializer probe.

Signed-off-by: Cory Keitz <ckeitz@amazon.com>
---
Cory Keitz (2):
      dt-bindings: i2c: qcom-cci: Document qcom,scl-stretch-enable property
      i2c: qcom-cci: Add DT property for SCL clock stretching

 Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml | 8 ++++++++
 drivers/i2c/busses/i2c-qcom-cci.c                       | 7 ++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)
---
base-commit: ecc64d2dc9ff9738d2a896beb68e02c2feaf9a02
change-id: 20260304-cci-scl-stretch-e20060685476

Best regards,
-- 
Cory Keitz <ckeitz@amazon.com>

Hi Cory,

On Thu, Mar 5, 2026 at 3:40 PM Cory Keitz via B4 Relay
<devnull+ckeitz.amazon.com@kernel.org> wrote:
>
> The Qualcomm CCI I2C controller has an SCL clock stretch enable bit in
> the MISC_CTL register. Currently the driver hardcodes this off in
> per-SoC hw_params tables, with no way to enable it from the device tree
> on a per-master basis.
>
> Clock stretching is required for GMSL configurations where the
> deserializer uses it to absorb the latency imposed by forwarding I2C
> transactions across the serial link. Without it, the CCI master exhibits
> intermittent transaction failure.
>
> This series adds a "qcom,scl-stretch-enable" boolean DT property to
> individual CCI i2c-bus sub-nodes. The property ORs with the existing
> hw_params default so it is purely additive and does not affect masters
> that do not set it.
>
> Tested on sa8775p using the qcom,sm8250-cci compatible string with two
> CCI buses connected to one max96724/max96717 GMSL2 pair each. Enabling
> this property eliminated intermittent NACK errors during serializer
> and/or deserializer probe.

I'm not convinced this kind of hardware behaviour belongs in
devicetree. As far as I understand, clock stretching is part of the
I2C specification, and slaves are allowed to use it whenever they need
additional time. Masters are therefore expected to tolerate
stretching. Given that, why not enable it unconditionally in the
driver? Is there any downside to doing so?

Regards,
Loic

On 3/5/26 4:16 PM, Loic Poulain wrote:
> Hi Cory,
> 
> On Thu, Mar 5, 2026 at 3:40 PM Cory Keitz via B4 Relay
> <devnull+ckeitz.amazon.com@kernel.org> wrote:
>>
>> The Qualcomm CCI I2C controller has an SCL clock stretch enable bit in
>> the MISC_CTL register. Currently the driver hardcodes this off in
>> per-SoC hw_params tables, with no way to enable it from the device tree
>> on a per-master basis.
>>
>> Clock stretching is required for GMSL configurations where the
>> deserializer uses it to absorb the latency imposed by forwarding I2C
>> transactions across the serial link. Without it, the CCI master exhibits
>> intermittent transaction failure.
>>
>> This series adds a "qcom,scl-stretch-enable" boolean DT property to
>> individual CCI i2c-bus sub-nodes. The property ORs with the existing
>> hw_params default so it is purely additive and does not affect masters
>> that do not set it.
>>
>> Tested on sa8775p using the qcom,sm8250-cci compatible string with two
>> CCI buses connected to one max96724/max96717 GMSL2 pair each. Enabling
>> this property eliminated intermittent NACK errors during serializer
>> and/or deserializer probe.
> 
> I'm not convinced this kind of hardware behaviour belongs in
> devicetree. As far as I understand, clock stretching is part of the
> I2C specification, and slaves are allowed to use it whenever they need
> additional time. Masters are therefore expected to tolerate
> stretching. Given that, why not enable it unconditionally in the
> driver? Is there any downside to doing so?

+Mukesh may be able to help

Konrad

On Thu, Mar 05, 2026 at 04:16:31PM +0100, Loic Poulain wrote:
> I'm not convinced this kind of hardware behaviour belongs in
> devicetree. As far as I understand, clock stretching is part of the
> I2C specification, and slaves are allowed to use it whenever they need
> additional time. Masters are therefore expected to tolerate
> stretching. Given that, why not enable it unconditionally in the
> driver? Is there any downside to doing so?

Fair point. I wasn't sure of implications across the platforms, so my
preference was to make the change opt-in to preserve behavior for
existing systems. This is probably an overly-cautious approach though.
I'm happy to submit a v2 that forces it on, and remove the new DT
binding.

Cory