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

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...