lkml.org 
[lkml]   [2017]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC 2/5] i3c: Add core I3C infrastructure
    From
    Date
    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.
    >

    \
     
     \ /
      Last update: 2017-08-01 18:49    [W:3.306 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site