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