Re: [PATCH v6 00/10] Add the I3C subsystem

[Wolfram Sang <wsa@the-dreams.de>]

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


> I don't have an actual example for I2C, maybe Wolfram does? But I can
> invent a case. E.g. the speedy DMA-enabled master cannot generate
> RESTART, which is a must for (re-)configuration, but not for passing
> data to the device.

DMA capable controllers may also not react adequate to the slave doing
clock stretching (which is forbidden in I3C).

Renesas R-Car Gen2 has two I2C IP cores. One can do DMA and automatic
transfers to the PMIC, the other has I2C slave functionality. One cannot
do I2C_SMBUS_QUICK, the other can. And some more kind of quirks.
Sometimes you can mux the pins to GPIO, so you have a third option.

This setup is the reason the demux driver exists.

> Also consider some future HW that has several I3C blocks, but they
> are not identical. There's one beefy kind and one slim kind (I'm sure
> you can find HW with different flavors of I2C blocks). Even if the
> HW designers intended for one type of block to be superior in every
> aspect, they might have made a mistake? This HW also has a pinmux, so
> the SW is free to route different I3C blocks to the actual I3C bus.

So, basically this is what happened with R-Car. Now, I tend to think
that I3C is much more complex and noone would put two I3C IP cores into
on SoC. But it was not too long ago that I wouldn't believe someone put
two different I2C IP cores into a SoC. Then again, it happened when I2C
was around for 35 years...


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