lkml.org 
[lkml]   [2018]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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...

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-07-20 17:43    [W:0.112 / U:1.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site