[RFC] Handle targets with different speed by the same I2C master

[RFC] Handle targets with different speed by the same I2C master

[Vladimir Kondratiev]

We have a design where several I2C targets with different maximum speed capability
connected to the same I2C bus managed by one I2C master.
We want to communicate with each target with its speed. However there is no way to
specify the bus speed for the I2C message.

I want to propose the following solution:

let's say there's master represented by /dev/i2c-0 with the configured speed
1MHz (I2C_MAX_FAST_MODE_PLUS_FREQ) and most of the targets supports this speed,
but there's also a target capable of 400KHz (I2C_MAX_FAST_MODE_FREQ) at max.

Create virtual I2C adapter (say, /dev/i2c-0-fast) that refers to the real I2C adapter while
have its bus speed set. Software talking with the 400KHz target will communicate with the
/dev/i2c-0-fast. In its message transfer, it will ask real I2C adapter to configure bus speed.
Regular communication can be continued using /dev/i2c-0. This design require no user-space
changes (only device name should be adjusted)

Bus speed can be cached and hardware reconfigured only when needed

Adapters handle i2c_timings in an adapter-specific manner, so I want to implement this as
a modification to the particular I2C adapter (designware), providing OF bindings for the
sub-device

Does it looks like right direction for development? Any other ideas?

Re: [RFC] Handle targets with different speed by the same I2C master

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]


> We have a design where several I2C targets with different maximum speed capability
> connected to the same I2C bus managed by one I2C master.
> We want to communicate with each target with its speed. However there is no way to
> specify the bus speed for the I2C message.

Rightfully so. Devices with a lower max_freq may get confused and block
the bus if you operate at a higher freq. You have to live with the
lowest max_freq. Or put the slow devices to another adapter. Or behind a
mux. Something like this.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC] Handle targets with different speed by the same I2C master

[Vladimir Kondratiev]

>> We have a design where several I2C targets with different maximum speed capability
>> connected to the same I2C bus managed by one I2C master.
>> We want to communicate with each target with its speed. However there is no way to
>> specify the bus speed for the I2C message.

>Rightfully so. Devices with a lower max_freq may get confused and block
>the bus if you operate at a higher freq. You have to live with the
>lowest max_freq. Or put the slow devices to another adapter. Or behind a
>mux. Something like this.

In general - yes, lower frequency devices may get confused. However, there are cases where
device is not FM+ capable because it can't provide enough current, meaning it can't drive
bus at this speed; but it is still capable to listen and properly interpret bus activity. So such
device will not be confused, and will not interfere with other activity on the FM+.

This is exactly the situation I want to handle: FM+ bus in general, but there's a device that
can accept only FM transaction, at the same time being capable to not interfere with FM+

In my case it is bus powered by 1.8V VCC with lots of FM+ targets and this EEPROM:
https://www.onsemi.com/download/data-sheet/pdf/nv24m01muw-d.pdf
This EEPROM supports 1MHz at VCC >= 2.5v and 400 KHz at VCC >= 1.8v.
Our experiments confirm it can stay silent when bus is clocked at 1MHz

This is the case I want to address. However, it is possible to do more complex design where
slower mode virtual I2C sub-device, when switching bus to the required speed, will also perform
other custom actions like connecting slow segment, and disconnecting it when switching back
to faster speed. This is not my case, but this design allows such things

Re: [RFC] Handle targets with different speed by the same I2C master

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]


> In my case it is bus powered by 1.8V VCC with lots of FM+ targets and this EEPROM:
> https://www.onsemi.com/download/data-sheet/pdf/nv24m01muw-d.pdf
> This EEPROM supports 1MHz at VCC >= 2.5v and 400 KHz at VCC >= 1.8v.
> Our experiments confirm it can stay silent when bus is clocked at 1MHz

Okay, I get the picture, thanks. Still, this is a corner case which is
furthermore based only on experiments, not on specifications. This is
way too vague to have this added to a generic OS. For most people, it
won't work. And this will add some complexity to the code base which I
don't want to maintain. Because the underlying principle is unreliable
itself.

Sorry that the HW design is flawed on your device. If you can still
influence the process, you could get the EERPOM replaced. If you still
want your software solution in your device (I don't recommend it), you
have to carry it out-of-tree, I am afraid.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]