Messages in this thread | | | Subject | Re: [RFC 2/5] i3c: Add core I3C infrastructure | From | "Andrew F. Davis" <> | Date | Tue, 1 Aug 2017 11:47:15 -0500 |
| |
On 07/31/2017 04:42 PM, Wolfram Sang wrote: > >> Actually, that's the first option I considered, but I3C and I2C are >> really different. I'm not talking about the physical layer here, but >> the way the bus has to be handled by the software layer. Actually, I >> thing the I3C bus is philosophically closer to auto-discoverable busses >> like USB than I2C or SPI. > > Acked-by: Wolfram Sang <wsa@the-dreams.de> > >> Of course, I can move all the code in drivers/i2c/, but that won't >> change the fact that I3C and I2C busses are completely different >> with little to share between them. > > That wouldn't make sense. > >> To me, the I2C backward compatibility is just a nice feature that was >> added to help people smoothly transition from mixed I3C busses with >> both I2C and I3C devices connected to it (I2C devices being here >> when no (affordable) equivalent exist in the I3C world) to pure I3C >> busses with only I3C devices connected to it. > > Yeah, and it is still to be seen how good this really works. Devices > which do clock stretching are out of the question. Probably everything > which needs an interrupt as well? >
I'm surprised they didn't allow for slave clock stretching when communicating with a legacy i2c device, it will prohibit use of a rather large class of devices. :(
As for interrupts you are always free to wire up an out-of-band interrupt like before. :)
>> This being said, I'd be happy if you prove me wrong and propose a >> solution that allows us to extend the I2C framework to support I3C >> without to much pain ;-). > > From all I know, I don't see that coming. >
| |