> > Ah, didn't notice that so far. Can't find it in drivers/i2c/busses. > > Where are those? > > IIRC the OMAP I2C adapter supports SCCB natively. I'm not sure the driver > implements that though. It doesn't currently. And seeing how long it sits in HW without a driver for it, I don't have much expectations. > > > we need to forward native SCCB calls all the way down the stack in that > > > case. > > > > And how is it done currently? > > Currently we go down to .master_xfer(), and adapters can then decide to use > the hardware SCCB support. Again, it might not be implemented :-) To sum it up: hardware-driven SCCB support is a very rare exception not implemented anywhere in all those years. From a pragmatic point of view, I'd say: we should be open for it, but we don't need to design around it. > I'm fine with SCCB helpers. Please note, however, that SCCB differs from SMBus > in two ways: NACKs shall be ignored by the master (even though most SCCB > devices generate an ack, so we could likely ignore this), and write-read > sequences shouldn't use a repeated start. Apart from that register reads and Especially the latter is a huge difference to SMBus, and so I think it will be much safer to not abuse SMBus calls for SCCB. > register writes are identical to SMBus, which prompted the reuse (or abuse) of > the SMBus API. If we end up implementing SCCB helpers, they will likely look > very, very similar to the SMBus implementation, including the SMBus emulated > transfer helper. I don't think so. SCCB has much less transaction types than SMBus. Also, the fallback as sketched in this patch (one master write, then a master read) would be impossible on SMBus. I have an idea in my mind. Maybe it is better to implement an RFC first, so we can talk over code (even if only in prototype stage). I already found this in ov7670.c, so I am proven wrong on this one already: 472 * Note that there are two versions of these. On the XO 1, the 473 * i2c controller only does SMBUS, so that's what we use. The 474 * ov7670 is not really an SMBUS device, though, so the communication 475 * is not always entirely reliable. Sigh...
Attachment:
signature.asc
Description: PGP signature
