Am 28.10.2012 17:11, schrieb Laurent Pinchart: > Hi Jean, > > On Sunday 28 October 2012 13:03:01 Jean Delvare wrote: >> On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote: >>> Am 27.10.2012 18:50, schrieb Jean Delvare: >>>> On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote: >>>>> the i2c interface of my device is capable of writing 2 bytes (reg + >>>>> data) and reading a single data byte only. >>>> Are you talking about an I2C master (controller) here, or a slave >>>> device? >>> It's an em2765 USB-video-bridge with an OV2640 sensor slave. >>> The i2c transfer functions I'm currently working on are not yet in the >>> em28xx driver. >>> >>> I don't know yet if it is a general bus limitation or a client >>> limitiation. >>> The procedures are based on reverse-engineering work and the OV2640 is >>> the only device we have seen so far. >>> Maybe it has something to do with the fact that the OV2640 uses SCCB. >> Yes SCCB is apparently very limited in terms of supported transaction >> types. Plus it diverges from the equivalent SMBus transactions in the >> details. Note that we do have support for SCCB since kernel v3.6 >> (commit d47726c52122d64253ae56e0fafdb7d0b954e97c by Laurent Pinchart.) >> >>> (...) >>> Yes, emulating block reads/writes internally (the em28xx driver in this >>> case) is not the problem. >>> My question was if it makes sense to export the emulation through the >>> i2c subsystem. >> If you do, you'll have to make it flexible enough that it can be used >> by other drivers, such as at24 and eeprom. > Is that really mandatory ? The EM2765 will only be connected to video sensors > in practice. > >>>>> What's the right error code to return from the drivers master_xfer >>>>> function if the message length is not supported ? -EMSGSIZE ? >>>> -EOPNOTSUPP, per Documentation/i2c/fault-codes. >>>> >>>> Note that ideally, the slave driver should check the bus functionality >>>> and not try transactions which aren't supported. So returning >>>> -EOPNOTSUPP normally never happens. >>> What are the correct functionality flags to use in this case ? >>> I2C_FUNC_I2C | I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_WORD_DATA ? >> If your controller is limited then I2C_FUNC_I2C is most certainly >> wrong. From what you described, I'd say: >> >> I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_BYTE_DATA >> >> This doesn't match what Laurent said about SCCB 4 months ago though: >> >> "The read transaction transmits 2 2-byte messages (addr/w, reg, >> followed by addr/r, data)." > The EM2765 might split reg + data write operations into two transactions > internally. We don't know yet exactly what the EM2765 does. All we can say at the moment is: - transfers are working fine with a SCCB slave device (which doesn't mean that the bus is for SCCB devices only) - when sending n bytes to the slave device, the first byte sets the register, the last byte is written to this register. All bytes inbetween are ignored - when reading n bytes from the slave device, it returns n identical bytes (beeing the value at the current register) - 0 byte transfers always succeed, too (even if there is no device with the i2c slave address !) Regards, Frank > >> You can take a look at Documentation/i2c/smbus-protocol to match >> transactions to function names (and from there to I2C_FUNC flags.) -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
