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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

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.