tree be2c4d4d9d779dd25ac3edf55963e6ed956c6e2c
parent d1dcf7d75d4e761c1e51e50ff40f5fe9c6bd486e
author Jan Kundrát <jan.kundrat@cesnet.cz> 1729696480 +0200
committer Jan Kundrát <jan.kundrat@cesnet.cz> 1729774829 +0200

clearfog: faster bit-banged I2C bus access

There was a typo in the DT property name, and therefore this option has
always been a no-op, since the very beginning. That means that the
kernel's default of 5µs has always been in effect.

I made some measurements on kernel 6.6.56-10-g683b4dee50cd, with
CONFIG_PREEMPT. The scope (Agilent U1604B) was connected to SCL and SDA
signals at the connector at the PCB's edge, the frequency was measured
by the scope's built-in math functions with the measurement performed at
the resolution of 5µs/div. The machine was otherwise idle. Here's the
actual measured SCL frequency based on different delay values:

- 1: ~150-175kHz
- 2: ~112-128kHz
- 3: ~96-102kHz
- 4: ~78-85kHz
- 5: ~70-75kHz

Value "5" was in effect because it's the default. "0" gets interpreted
as "no value", so it's the same as "5" (or no value, or a typo as we had
before).

Using just "3" is, however, not enough because the t_LOW requirement of
a minimal duration of the SCL being at logical 0 was not always met
(I've seen traces with just 4µs while the standard requires 4.7µs for a
100kHz bus). Using a custom delay of 4µs does the trick.

I'm not happy with two more things, though:

- The SCL is consistently "too low", measuring around 3.1V. That's
because the MPP24 (which we use as SCL) has a built-in pull-down
resistor (the CPU's datasheet says that these are anywhere between 20
and 70kΩ). As far as I can tell the result is still OK from the SMBus'
perspective (2.1V is the threshold there), but it isn't pretty --
especially when the SDA is at the usual level of 3.3V.

- There's "some" rise time. Without an active component for managing the
slew rate, this might be hard to fix on a rather (physically) long I2C
bus (which is partially implemented over a wire bundle). However, SMBus
defines the low threshold to be at 0.8V, and the high threshold at 2.1V,
and as far as I can see, the signal always raises "a bit quicker" than
the required 1'000ns. (This is *very* painful to measure on a scope
which can only place triggers at a div boundary.)

TL;DR: with these settings we're always in spec AFAICT.

Fixes: 7f2ff837 clearfog: Add a SW bit-bang I2C bus for PMBus
Change-Id: I8bff086330aa8d8a15b4ba8bd2f5c8e261e4fe59