Faster IIC

May I propose that the default IIC speed on the RaspberryPi (and possibly the newer SoCs in general) be increased to 400kHz instead of 100kHz?

The faster speed was introduced in 1992, so it seems reasonable to assume that most devices will be compatible, twenty two years later and anyway Fast Mode predates more recent changes such as the use of 3.3V or even 1.8V as IIC signal levels.

I have hacked my Pi’s IIC driver to run at about 400kHz (binary hack, as described in the OLED docs) because the slower way was too slow and unable to send a frame within the OLED’s native refresh rate.
I can confirm that, at the faster speed, all parts of the CJE power control expansion work – the PIC for power control and status LEDs, the temperature sensor, and the RTC.

I would propose trying this in a nightly build to see “what breaks”. The CJE hardware on a 256MB issue 2 Model B Pi works, but that is all that I am able to test. If no reports of IIC problems arise, it should pave to way for running IIC faster “as standard” on modern devices.

Is there a legal way to set the I2C bus speed other that hack the IIC driver?

All Pi’s suffer from a hardware bug in the Broadcom SoC that causes issues with I2C devices that use clock stretching. One workaround is to use the i2c-gpio overlay which bitbangs I2C, the other is to slow the I2C bus down.

Is there a legal way to set the I2C bus speed other that hack the IIC driver?

No.

All Pi’s suffer from a hardware bug in the Broadcom SoC that causes issues with I2C devices that use clock stretching.

Possibly that’s the bug that we’ve worked around by having the Pi IIC driver run in a completely blocking manner, with interrupts disabled? (Dave Higton should be able to confirm)

One workaround is to use the i2c-gpio overlay which bitbangs I2C

Yeah, I did realise a couple of weeks ago that we could probably just switch to using bit-banged IIC in order to avoid needing to perform transfers with interrupts disabled (the kernel does all the hard work, the HAL just needs a couple of calls to read & write the control lines). And if this is a different bug, it’s all the more reason to switch.

having the Pi IIC driver run in a completely blocking manner, with interrupts disabled? (Dave Higton should be able to confirm)

I’m not aware of any bug.

I wrote the IIC driver like that because I discovered that it would generate the repeated start condition under those circumstances – IIRC (it’s a long time ago that I wrote the driver!) the transfer for the data part had to be initiated before the peripheral had a chance to issue the stop condition. The repeated start condition seems to be not well understood. It is part of the standard, but many people seem to just generate a stop followed by a start. My understanding is that the Acorn drivers used to do it. Once you do that instead of repeated start, you’re working outside the IIC specification.

It only occurred to me long afterwards that it might be possible to re-enable interrupts after the repeated start has been generated, but I never went back to try.

May I propose that the default IIC speed on the RaspberryPi (and possibly the newer SoCs in general) be increased to 400kHz instead of 100kHz?

Is there a legal way to set the I2C bus speed other that hack the IIC driver?

I had a look at the PCF8583 recently; it’s still in production, and the data sheet still shows it as a 100kHz device. This was the RTC/CMOS in lots of Acorn computers.

I would recommend that a call be added to change the IIC bus speed. I think it would probably have to call into the HAL, as I don’t think you can do it in a hardware-independent way. I also don’t know what happens if the CPU clock is changed – does the IIC peripheral come off a constant or variable clock? Dunno.

I’m not aware of any bug.

I presume you’ve now read the bug report I linked too and understand the issue. The only real workaround is the bitbang approach, which looks like the route Linux probably took.

what happens if the CPU clock is changed

From what I understand the I2C clock is derived from the CPU clock, so will possibly change as the CPU clock changes. ie. it’s only running at the set clock speed when the CPU is at its full set clock speed. See this post from one of the Pi engineers that explains things.

As the firmware blob also alters the CPU speed when undervolt and thermal limit are detected, you probably don’t get much say it what speed it’s actually running at, only the max speed it can run at.