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

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

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


> I have not read much of the I3C spec. I'm just coming from the
> current situation with I2C and the i2c-demux-pinctrl driver which
> tries to retrofit this into the I2C world and is not doing a grand
> job. And how could it?
> 
> If you can acknowledge that i2c-demux-pinctrl is needed for I2C
> but for some reason is not needed for I3C because of something
> that differs between I2C and I3C, then fine, by all means ditch
> the explicit bus object.
> 
> But in my mind splitting up the devices on the same bus between
> several of our own masters and then not have a single object for
> the bus is going to cause headaches down the line. Be it address
> clashes or trouble with master ping-pong or whatever.
> 
> I think the reason for i2c-demux-pinctrl is that some (most?) I2C
> hardware suffers from quirks and one way to work around it is to
> make selected accesses from a different master. I expect I3C HW
> to also suffer from quirks...
> 
> Maybe a bit-bang I3C master isn't feasible for some fundamental
> reason? But if it is, then I'd say that it's just a matter of time
> until someone finds a situation where such a thing could be used to
> work around some I3C quirk. And then it might be too expensive to
> always use the bit-bang master for the affected device.
> 
> But what do I know? Don't let me hold this series back...

Thanks, Peter. You nailed it, the I2C use case (and its limits). From
what I know about I3C, bit-banging doesn't sound very feasible to me, so
the situation might be a bit different. Still, no one knows about future
I3C use cases and HW quirks. This is why I encouraged the seperate bus
object because back then it was said it was easy to do and implement. If
this now becomes a show-stopper, we can surely re-decide. I am not
strong on this point, it was just something which would have helped I2C.
(And for that matter, we (= the Renesas Upstream Kernel Team) was
discussing something similar to the i2c demuxer for SPI, too. We have
multiple IP cores which can do SPI on R-Car, all with their pros and
cons)


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