Hi everybody, While trying to use an OV7725 camera sensor with an OMAP3 system I ran into a couple of issues related to the sensor communication protocol. Instead of using the obiquitous I2C protocol, Omnivision invited the SCCB communication bus, very similar to I2C but different enough not to be compatible. SCCB documentation is available at http://www.ovt.com/download_document.php?type=document&DID=63. SCCB exists in two flavors, 3-wire and 2-wire. The 3-wire version is too different from I2C to be of interest here. SCCB is very close to SMBus. It supports two transactions, an 8-bit register read and an 8-bit register write. The write transaction transmits a 3-byte message (addr/w, reg, data). The read transaction transmits 2 2-byte messages (addr/w, reg, followed by addr/r, data). The two majors differences between I2C and SCCB are in the acknowledgment bit and in the stop bit. SCCB devices generate no ack bit and don't take the ack bit generated by the master into account. The ack bit is thus an unspecified bit, present in the transfer but whose value must be ignored. However, in practice, the SCCB components I've seen implement the ack bit in write transactions. The stop bit is handled as in I2C, except that a stop bit needs to be generated between the two messages that make the read transaction (as opposed to SMBus, where no stop bit must be present between the two messages). I need SCCB support in the I2C core and in the OMAP3 I2C driver and have two options. The OMAP3 I2C controller support SCCB natively. The interface exposed by the hardware is at the transaction level (smbus_xfer), while the i2c-omap driver exposes a message level interface (master_xfer). To use the native SCCB support, we would thus have to either allow i2c_smbus_xfer() to choose between smbus_xfer and i2c_smbus_xfer_emulated based on the client type (I2C or SCCB), or export i2c_smbus_xfer_emulated() to use it as a fallback in the i2c-omap driver for I2C clients. Another option is not to use the hardware SCCB support, but to emulate it through I2C. In that case the i2c-omap driver must generate a stop bit after the first message of a read transaction, and ignore the ack bit. Two flags would then be necessary, one in the message to force the stop bit, and one in the i2c_client to mark the device as using SCCB. Implementing support for the second option is required for I2C masters that have no hardware SCCB support. As the first option won't bring much benefits, I've decided to skip it for now. The following three patches thus implement emulated SCCB support in the I2C core, with a small change in the i2c-omap driver to support the new I2C_M_STOP flag. Laurent Pinchart (3): i2c: Add SCCB support i2c: Fall back to emulated SMBus if the operation isn't supported natively i2c: omap: Add support for I2C_M_STOP message flag drivers/i2c/busses/i2c-omap.c | 2 ++ drivers/i2c/i2c-core.c | 22 +++++++++++++++++++--- include/linux/i2c.h | 2 ++ 3 files changed, 23 insertions(+), 3 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
