Pi5: i2c1: Max clock can only reach 650kHz despite being configured for 1MHz

[JinShil]

Describe the bug

On the Pi 5, despite configuring the i2c1 device tree overlay for 1MHz, the clock can only reach 650kHz. See the following oscilloscope capture:

On the CM4, the same settings result in a true 1MHz clock signal.

Steps to reproduce the behaviour

1. Add dtoverlay=i2c1,pins_2_3,baudrate=1000000 to config.txt file and reboot
2. Write a C program using the <linux/i2c-dev.h> API
3. Observe the clock signal on an oscilloscope

Device (s)

Pi5 (By the way, the GitHub bug report template does not include the Pi 5)

System

Bookworm kernel versions 6.1.63 and 6.6.5

Logs

No response

Additional context

No response

[pelwell]

I can reproduce. Now to make sense of the datasheet.

[JinShil]

I'm not sure if this is related, but I'm also seeing this error: Dec 15 10:07:21 raspberrypi kernel: clk: couldn't set clk_pwm0 clk rate to 100000000 (-22), current rate: 30720000 in the kernel logs.

[pelwell]

The Designware I2C driver requires some configuration data from Device Tree for SCL and SDA fall times (I don't understand yet why this isn't SCL rise and fall times) - without them it uses some very pessimistic values. I have some reasonable looking values that I've tuned to give 1000kHz as expected. Unfortunately they also have the effect of raising the 400kHz speed to 466kHz (and 100kHz to 111kHz), which could break some applications. If we were using ACPI for configuration then we could specify speed-specific HCNT and LCNT values, but that's not possible for Device Tree without either hacking the driver or putting some tricksy parameter handling into the overlay.

How close to 1000kHz would be acceptable?

[JinShil]

Our solution is latency sensitive, so we really want to be able to run it as fast as possible. All of our slaves are spec's for at least 1MHz to help us reduce latency as much as possible. Our solution will be used in many use cases, so if we aren't able to fully utilize our hardware, there may be a few use cases that will need to be dropped. I think 1MHz +/- 10% would probably be OK, but I say that reluctantly.

However, we would actually prefer to use PIO for our solution, as I assume it could help us reduce jitter, thus expanding our potential use cases. Currently, due to interrupt IO in the existing i2c stack (especially due to scheduling interrupts on PREEMPT_RT), the jitter when using i2c is pretty bad. If we could use PIO w/ polling IO, along with a 1MHz SCL also programmed with PIO, I believe we could optimize for reductions in both latency and jitter.

So, what I'm trying to say is, if you can't reach 1MHz using the existing i2c stack, could you make PIO a higher priority so we could perhaps achieve our goals with that instead?

[pelwell]

See #5802 for a potential fix. Wait about 45 minutes for the auto-builds to complete, then run sudo rpi-update pulls/5802 to install a trial kernel build.

[JinShil]

When configured for 1000kHz, 400kHz, and 100kHz, I get 965kHz, 393kHz, and 100kHz respectively. I think that's good enough for our needs, and certainly an improvement for the 1MHz configuration. Thank you.