> 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:
signature.asc
Description: PGP signature
