I2C combined mode / repeated start after latest updates

[stefandz]

Hello all

Recently (a couple of weeks back, if memory serves) something changed in Raspbian (latest version from dist-upgrade, not the downloadable image) which has broken I2C repeated start / combined read-write operations for me. It used to be that writing a 'Y' to /sys/module/i2c_bcm2708/parameters/combined would enable this mode and all would be well. After the latest update, this no longer exists - now we have /sys/modules/i2c_bcm2835/parameters but it doesn't contain a combined path - and even with sudo, I can't create one.

Can anyone point me in the direction of what's changed and how to get it back working again?

Many thanks in advance

Stefan

[PhilE]

I'm not an I2C expert, but from reading the driver it looks as though that module parameter is specific to the i2c_bcm2708 driver. As of 4.9 we are now using the upstream i2c_bcm2835 driver. The I2C subsystem appears to have some kind of support for combined transfers - there are "quirks" controlling it - but I don't know why that mechanism isn't working in your case.

There are two things you could do:
1. Revert to the downstream driver, which is still in our trees at least up to the 4.12 branch. To do this, add the following to your config.txt and reboot:

Code: Select all

dtoverlay=i2c-bcm2708

2. Extract or write a short test program demonstrating the problem - combined on i2c_bcm2708, not combined on i2c_bcm2835 -
and make it available to me. I can then use it to see what is happening on the bus and work through the I2C stack with the new driver to try and figure out why it isn't working.

[joan]

Can you use the old module instead?

i2c_bcm2708 ?

[stefandz]

OK - loading the old driver in boot/config.txt works fine. Am doing a bit of detective work and sorting out a minimal program to send you, @PhilE (thanks as always for your assistance). Also thank you @joan for your help.

I am assuming that going back to the old driver would be a bad thing in the long run, however, as future compatibility wouldn't be guaranteed.

I'll get back to you both ASAP with results from investigations etc.

[PhilE]

The longer term goal would be to submit patches to the upstream code until it was as capable as the downstream driver - it doesn't sound like you're doing anything dodgy or undesirable.

[stefandz]

OK - dug deep into this. Looks like I jumped the gun slightly - the code causing the issue was actually due to poor error handling when trying to manipulate the non-existent device file. Getting a scope onto the SDA and SCL lines showed expected behaviour. Tidying up the error handling, the driver seems to cope with repeated starts transparently (which was your whole motivation for using the new driver - so good call!).

Am doing some edge testing now but seems like a non-issue overall. Sorry if I wasted your time - your continued patience is always appreciated!!

[PhilE]

No problem - I can cross it off the To Do list.