2012/6/26 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>:
> 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.
>
I have been using omnivision sensor without being aware of this issue,
and without any i2c reliability issue either.
Here is typical code I use :
/* This function is used to read value from register for i2c client */
static int ov2710_read(struct i2c_client *client, unsigned short reg,
unsigned char *val)
{
int err = 0;
unsigned char outbuf[] = {(reg>>8)&0xff, reg&0xff};
unsigned char inbuf[1];
struct i2c_msg msg[] = {
{ .addr = client->addr, .flags = 0, .buf = outbuf, .len = 2 },
{ .addr = client->addr, .flags = I2C_M_RD, .buf = inbuf, .len = 1 },
};
err = i2c_transfer(client->adapter, msg, 2);
/* error handling and pass by ref handling */
....
}
Is the point of this patch to avoid writing such functions again and
again in every ov driver ?
What is solved in practice by this patch that is not solved by a
regular i2c transfer ?
Regards,
Jean-Philippe François
> 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
--
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
