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

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

[Hans Verkuil]

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?

Regards,

	Hans

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

[Wolfram Sang]

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

Hi Hans,

lucky you, I happen to have a board with that controller on the table
currently :)

> 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

Confirmed.

> Looking in i2c-designware-master.c it seems it cannot handle consecutive messages for
> different addresses.

I agree. I leave the final judgement to the experts (Andy, Mika), but I
already anticipate that I need to extend the existing
I2C_AQ_COMB_SAME_ADDR quirk into a more generic one. And set the quirk
in this driver.

Thanks for the report,

   Wolfram


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

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

[Andy Shevchenko]

On Wed, Oct 15, 2025 at 01:51:20PM +0200, Wolfram Sang wrote:
> Hi Hans,
> 
> lucky you, I happen to have a board with that controller on the table
> currently :)
> 
> > 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
> 
> Confirmed.
> 
> > Looking in i2c-designware-master.c it seems it cannot handle consecutive messages for
> > different addresses.
> 
> I agree. I leave the final judgement to the experts (Andy, Mika), but I
> already anticipate that I need to extend the existing
> I2C_AQ_COMB_SAME_ADDR quirk into a more generic one. And set the quirk
> in this driver.

May I ask a dumb question? Why do we need such an awkward transaction
to begin with?

-- 
With Best Regards,
Andy Shevchenko

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

[Hans Verkuil]

On 15/10/2025 15:40, Andy Shevchenko wrote:
> On Wed, Oct 15, 2025 at 01:51:20PM +0200, Wolfram Sang wrote:
>> Hi Hans,
>>
>> lucky you, I happen to have a board with that controller on the table
>> currently :)
>>
>>> 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
>>
>> Confirmed.
>>
>>> Looking in i2c-designware-master.c it seems it cannot handle consecutive messages for
>>> different addresses.
>>
>> I agree. I leave the final judgement to the experts (Andy, Mika), but I
>> already anticipate that I need to extend the existing
>> I2C_AQ_COMB_SAME_ADDR quirk into a more generic one. And set the quirk
>> in this driver.
> 
> May I ask a dumb question? Why do we need such an awkward transaction
> to begin with?
> 

That's how the datasheet defines the transfer. And in turn it is based on the VESA
E-DDC standard for reading display EDIDs. By doing it in a single transaction you
ensure that the bytes are written to (or read from) the correct EEPROM segment. If
it was split in two commands, then someone could change the segment inadvertently.
I.e., you set the segment to 1, then someone writes to it as well and sets it to 2,
then you write the EDID data to the EEPROM, which has now selected the wrong segment.

For now I have split up the transaction into two independent transfers in my driver,
one to the segment address, one writing to the EEPROM. This works, but it is not really
how it is supposed to be done. And I was actually surprised that it worked, since a
write to the EEPROM without writing to the segment pointer first in the same transaction
should write to segment 0, according to the cat24c208 datasheet.

I couldn't tell from the designware driver code whether this was 1) impossible (HW limitation),
2) possible, but not implemented, or 3) a bug. The comment in the code before the
"invalid target address" error was rather vague.

Regards,

	Hans

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

[Andy Shevchenko]

On Sat, Oct 18, 2025 at 08:17:36PM +0200, Hans Verkuil wrote:
> On 15/10/2025 15:40, Andy Shevchenko wrote:
> > On Wed, Oct 15, 2025 at 01:51:20PM +0200, Wolfram Sang wrote:
> >>
> >> lucky you, I happen to have a board with that controller on the table
> >> currently :)
> >>
> >>> 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
> >>
> >> Confirmed.
> >>
> >>> Looking in i2c-designware-master.c it seems it cannot handle consecutive messages for
> >>> different addresses.
> >>
> >> I agree. I leave the final judgement to the experts (Andy, Mika), but I
> >> already anticipate that I need to extend the existing
> >> I2C_AQ_COMB_SAME_ADDR quirk into a more generic one. And set the quirk
> >> in this driver.
> > 
> > May I ask a dumb question? Why do we need such an awkward transaction
> > to begin with?
> 
> That's how the datasheet defines the transfer. And in turn it is based on the VESA
> E-DDC standard for reading display EDIDs. By doing it in a single transaction you
> ensure that the bytes are written to (or read from) the correct EEPROM segment. If
> it was split in two commands, then someone could change the segment inadvertently.
> I.e., you set the segment to 1, then someone writes to it as well and sets it to 2,
> then you write the EDID data to the EEPROM, which has now selected the wrong segment.
> 
> For now I have split up the transaction into two independent transfers in my driver,
> one to the segment address, one writing to the EEPROM. This works, but it is not really
> how it is supposed to be done. And I was actually surprised that it worked, since a
> write to the EEPROM without writing to the segment pointer first in the same transaction
> should write to segment 0, according to the cat24c208 datasheet.
> 
> I couldn't tell from the designware driver code whether this was 1) impossible (HW limitation),
> 2) possible, but not implemented, or 3) a bug. The comment in the code before the
> "invalid target address" error was rather vague.

Thanks for a comprehensive reply. I see now where it comes from and I have no
objections on the proposed direction to fix the issue.

-- 
With Best Regards,
Andy Shevchenko

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

[Wolfram Sang]

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


> May I ask a dumb question? Why do we need such an awkward transaction
> to begin with?

Because it is allowed per I2C specs? So people will use it.

Interestingly, a patch has just now been proposed which I haven't looked
at but I wanted to let you guys already know:

[PATCH 2/3] i2c: designware: Enable transfer with different target addresses
https://lore.kernel.org/r/20251017-i2c-dw-v1-2-7b85b71c7a87@bootlin.com

Maybe you guys can have a look at it?


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

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

[Hans Verkuil]

On 19/10/2025 19:53, Wolfram Sang wrote:
> 
>> May I ask a dumb question? Why do we need such an awkward transaction
>> to begin with?
> 
> Because it is allowed per I2C specs? So people will use it.
> 
> Interestingly, a patch has just now been proposed which I haven't looked
> at but I wanted to let you guys already know:
> 
> [PATCH 2/3] i2c: designware: Enable transfer with different target addresses
> https://lore.kernel.org/r/20251017-i2c-dw-v1-2-7b85b71c7a87@bootlin.com
> 
> Maybe you guys can have a look at it?
> 

I'll give it a spin today.

Regards,

	Hans

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

[Hans Verkuil]

On 18/10/2025 20:17, Hans Verkuil wrote:
> On 15/10/2025 15:40, Andy Shevchenko wrote:
>> On Wed, Oct 15, 2025 at 01:51:20PM +0200, Wolfram Sang wrote:
>>> Hi Hans,
>>>
>>> lucky you, I happen to have a board with that controller on the table
>>> currently :)
>>>
>>>> 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
>>>
>>> Confirmed.
>>>
>>>> Looking in i2c-designware-master.c it seems it cannot handle consecutive messages for
>>>> different addresses.
>>>
>>> I agree. I leave the final judgement to the experts (Andy, Mika), but I
>>> already anticipate that I need to extend the existing
>>> I2C_AQ_COMB_SAME_ADDR quirk into a more generic one. And set the quirk
>>> in this driver.
>>
>> May I ask a dumb question? Why do we need such an awkward transaction
>> to begin with?
>>
> 
> That's how the datasheet defines the transfer. And in turn it is based on the VESA
> E-DDC standard for reading display EDIDs. By doing it in a single transaction you
> ensure that the bytes are written to (or read from) the correct EEPROM segment. If
> it was split in two commands, then someone could change the segment inadvertently.
> I.e., you set the segment to 1, then someone writes to it as well and sets it to 2,
> then you write the EDID data to the EEPROM, which has now selected the wrong segment.
> 
> For now I have split up the transaction into two independent transfers in my driver,
> one to the segment address, one writing to the EEPROM. This works, but it is not really
> how it is supposed to be done. And I was actually surprised that it worked, since a
> write to the EEPROM without writing to the segment pointer first in the same transaction
> should write to segment 0, according to the cat24c208 datasheet.

Actually, my hack didn't work. It behaved exactly as the datasheet describes: if it is
done as two separate transactions, then when writing to the EEPROM will actually write
to segment 0, not 1.

My test was buggy, and after fixing it I could clearly see that the segment write and
EEPROM write must be part of the same transaction.

Regards,

	Hans

> 
> I couldn't tell from the designware driver code whether this was 1) impossible (HW limitation),
> 2) possible, but not implemented, or 3) a bug. The comment in the code before the
> "invalid target address" error was rather vague.
> 
> Regards,
> 
> 	Hans

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

[Mika Westerberg]

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.

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

[Hans Verkuil]

+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

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

[Mika Westerberg]

Hi,

On Mon, Oct 20, 2025 at 02:29:31PM +0200, Hans Verkuil wrote:
> > 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?

This is hardware limitation. That said, there is a way to update IC_TAR
(target address register) dynamically too but it first requires that the
feature is enabled when the controller was integrated (I2C_DYNAMIC_TAR_UPDATE == 1),
and then certain conditions match. Figuring out some of these parameters is
not possible through the register interface unfortunately, so there needs
to be some sort of indication (e.g device ID or firmware property) that it is
supported. I think this is what the other patch series is trying to do but
I have not yet looked at it.

You cannot work this around by doing the same as at24.c and split the
EEPROM part into multiple I2C clients per segment?