I2C clock-stretching bug

Start with the /boot/config.txt I2C settings and reproduce the failures using the Python smbus example at 100000 baud, then compare with the 10000-baud behavior. Read the BCM2711 peripherals datasheet section cited in the issue and investigate the I2C hardware behavior against the software I2C overlay. Done means clock-stretched reads from the UCD9081 complete reliably without communication errors.

Describe the bug

I'm having intermittent problems with the RPi4 when it performs I2C reads on devices (like UCD9081 texas) that use clock stretch.

This apparently affects the Raspberry Pi and was documented in a lot of detail, back in 2013 by someone at Advamation. Here is that post.

Also have an open issue #3064 for RPi3 which apparently has not been resolved. Everything indicates that the SoCs (BCM2835, BCM2836 e BCM2837) do not have hardware support for clock stretch, but some interventions were made to stabilize the software i2c.

Although I found evidence on the datasheet BCM2711 on the chapter 3 that it had been fixed on the hardware RPi4, this is apparently not the case as it was a RPi4 I was getting the problem on.

By setting a baud rate of 10,000 the readings are more stable but still occur in smaller amounts.
dtparam=i2c_baudrate=10000

An alternative solution would be to use the software I2C dtoverlay=i2c-gpio,bus=3, however with the UCD9081 device this is not an option as it implements a maximum time for a byte transition and is something that cannot be ensure with software I2C that it can be interrupted for brief moments to process other interruptions.

Steps to reproduce the behaviour

1. Configure a I2C de hardware by editing /boot/config.txt:
   dtparam=i2c=on,i2c_baudrate=100000
2. Send an I2C request using python:
   python import smbus import time bus = smbus.SMBus(1) time.sleep(1) read = bus.read_i2c_block_data(0x65, 0x0, 16)
3. Sometimes we get the return without errors but many times we get errors as shown in the image:
   
   We can see that there was a stretch and soon after the RPi4 did not guarantee the adequate clock width, resulting in a chain error.
   In the image below we can see the correct communication where the clock at the same moment is with its correct width, probably because there was no stretch request by the device.
   

Device (s)

Raspberry Pi 4 Mod. B

System

OS: Raspberry Pi reference 2021-10-30 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 88b21fc27e128ea6b330777aca68e0061ebf4fe, stage4
Firmware: Jan 20 2022 13:56:48 Copyright (c) 2012 Broadcom version bd88f66f8952d34e4e0613a85c7a6d3da49e13e2
Kernel: Linux JigaBrise 5.10.92-v7l+ #1514 SMP Mon Jan 17 17:38:03 GMT 2022 armv7l GNU/Linux
Soc: BCM2711 b03112

Logs

No response

Additional context

No response