Re: Q: i2c block write emulation / handling of i2c message size constraints of a bus ?

["Frank Schäfer" <fschaefer.oss-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]

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.)