Re: i2c-designware: not possible to write to different i2c addresses in one transfer?

[Hans Verkuil <hverkuil+cisco@kernel.org>]

+CC kernel-list@raspberrypi.com since I wonder if the RPi devs are aware of this.

On 20/10/2025 13:59, Mika Westerberg wrote:
> Hi,
> 
> On Wed, Oct 15, 2025 at 01:25:02PM +0200, Hans Verkuil wrote:
>> Hi,
>>
>> I have this code in a driver (writing display EDID data into an EDID EEPROM):
>>
>>         struct i2c_msg msg[] = {
>>                 {
>>                         .addr = state->seg_client->addr,        // 0x30
>>                         .buf = &seg,
>>                         .len = 1,
>>                         .flags = 0,
>>                 },
>>                 {
>>                         .addr = state->data_client->addr,       // 0x50
>>                         .buf = data,
>>                         .len = len,
>>                         .flags = 0,
>>                 },
>>         };
>>
>>         err = i2c_transfer(state->dev_client->adapter, msg, ARRAY_SIZE(msg));
>>
>> This worked fine for the Raspberry Pi 4B using the broadcom i2c driver, but for
>> the Raspberry Pi 5 using the designware driver it fails with -EINVAL and these
>> kernel messages:
>>
>> [  272.284689] i2c_designware 1f00074000.i2c: i2c_dw_xfer_msg: invalid target address
>> [  272.305788] i2c_designware 1f00074000.i2c: controller active
>>
>> Looking in i2c-designware-master.c it seems it cannot handle consecutive messages for
>> different addresses.
>>
>> The i2c device I'm using is this one:
>>
>> https://www.onsemi.com/pdf/datasheet/cat24c208-d.pdf
>>
>> Is this a hardware limitation? Or is this a corner case that was never implemented?
>> Or just simply a bug?
> 
> I'm catching up what has happened to this driver since I last did something
> for it so please excuse me if I'm stating obvious things ;-) Also was on
> vacation last week, sorry for the delay.
> 
> The Intel I2C DW datasheets say that the I2C_TAR register must be
> programmed only when the controller is disabled (I2C_ENABLE=0) or no
> initiator mode operations are active.
> 
> I think this explains why the driver does what it does.
> 
> Since this is I2C EEPROM, pretty standard I guess. I wonder if you have
> tried the at24.c driver instead? If I read it right it splits the chip into
> multiple "clients" per segments thus avoiding limitations like this. IIRC
> this works fine with Intel controllers at least.

It's not a standard EEPROM, it's an EEPROM specifically meant for storing
display EDIDs. The host (in my case a Raspberry Pi 5) can write an EDID to it
over i2c, and it is also connected to the HDMI DDC lines so a video source can
read the EDID using the E-DDC standard. So the cat24c208 has two i2c ports,
one towards the host, one towards the HDMI connector. We use the cat24c208 to
emulate a display so we can easily debug various EDID issues.

It all worked fine with the RPi 4 and the Broadcom i2c driver, but not with
the RPi 5 designware i2c driver. It took a while before I noticed this since
most EDIDs are <= 256 bytes, and you don't need the segment address for that.

So is this a hardware limitation? I.e., there is no workaround and this simply
can't be supported?

If it is, then I will have to look for alternatives.

Regards,

	Hans