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

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

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