SCCB support

I made some research on this subject (AM3517 device):

1)  I2C controller doesn't generate XRDY interrupt in the SCCB mode, but TRM says that it should generate. When transmitting you need write data to DATA register immediately after writing STT into CON register.

2) While receiving a slave SCCB device (in my case OV7670 camera)  drives SDA low for some time after "don't care bit" transmitted by master after data byte received. This brings I2C controller in the inoperable state with SDA line driven low, "stop condition" is not generated and I2C controller hangs.

Conclusion - SCCB mode in the AM3517 device is too crude and inoperable with some devices. Use I2C mode (with STOP generation after send before receice while reseiving - search patch with google by "I2C_M_STOP" tag).

Sergey,

SCCB in fact is exactly same as I2C and it will send ACK also. This is just a different naming by Omnivision instead of using I2C directly. I'm not sure why they've done this. 

Sorry, but not absolutely exactly. The main difference is that while reading SCCB needs STOP after address phase, and each read phase, while I2C - not. Thus, this patch is important  (аnd really works with OV7670 on AM3517): http://comments.gmane.org/gmane.linux.ports.arm.omap/79483

Sergey,

I have got SCCB working without any changes in kernel, without any of these patches. Basically it was done almost 10 months before with 7640 sensor. We got the sensor working on Android kernel on DM3730. That's why I really started thinking, why OV has implemented SCCB. 

Maybe you don't use reading from OV Sensor registers? The SCCB specification not contains definition of  "repeated start" condition, therefore a STOP condition must be generated after address phase of reading cycle before data read phase to avoid generation of "repeated START" condition. This patch provides such behavior to comply with the SCCB specification.

Sergey,

We did read from the sensor registers also. But what about acknowledgement? Will it work without ACK?

No, it doesn't work without ACK. AM3517's hardware controller in I2C mode stops transaction automatically when NAK - there is no way to ignore NAK in this mode. In the native SCCB mode of the AM3517 I2C controller a write transfer is performed without ACK successfully. But a read transfer brings the I2C controller operating in SCCB mode into an inoperable state (He simply hangs and not generates STOP condition after read due to some extra zero level on SIO_D line, that generates SCCB slave after read phase). Thus I didn't find a way of an exchange with the SCCB device which doesn't generate ACK's.

I think that such behavior of I2C controller in SCCB mode is a hardware issue - incorrect handling of zero level on SIO_D line. While controller expects high level (STOP generation), he gets low level (SCCB slave drives extra bit of zero level), and hangs. When SCCB slave not generates this extra zero level, a read cycle is performed successfully. For example, when reading from a device with incorrect address it doesn't responds and controller reads 0xFF code from the bus correctly without ACK.

Generally because of this problem it appeared it is impossible to use a native SCCB mode of the controler with OV SCCB slaves to perform reading from such devices.

Sergey,

I think SCCB is a good topic for a big discussion. Please go through the following posts.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/120548.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/6092.aspx