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>]

Hi,

Am 28.10.2012 17:33, schrieb Jean Delvare:
> Hi Frank,
>
> On Sun, 28 Oct 2012 15:32:16 +0200, Frank Schäfer wrote:
>> Am 28.10.2012 14:03, schrieb Jean Delvare:
>>> On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
>>>> 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)."
>>>
>>> You can take a look at Documentation/i2c/smbus-protocol to match
>>> transactions to function names (and from there to I2C_FUNC flags.)
>> Ok, I've been digging deeper into this but still don't understand the
>> meaning of the functionality flags I2C_FUNC_*** with regards to the
>> capabilites of an master_xfer implemetation in struct i2c_algortihm...
>> Are they supposed to describe the smbus operations/methods that can be
>> successfully emulated by the smbus layer using i2c_xfer or do they
>> describe the actual capabilities of function master_xfer / the i2c adapter ?
> Most I2C_FUNC_* flags actual refer to the smbus_xfer method. A driver
> implementing master_xfer is typically fully I2C capable and can thus
> run almost any I2C or SMBus transaction. Such a driver will set
> functionality flags to I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL. The rest of
> the flags are for SMBus-only controllers. Each flag basically
> corresponds to an i2c_smbus_*() function, which in turn corresponds to
> the combination of an SMBus transaction type or size and a direction
> (read or write).
>
> The mapping between i2c_smbus_*() functions and functionality flags is
> rather obvious, but for clarity I'll update
> Documentation/i2c/smbus-protocol to mention it. Patch follows.
>
> Also see Documentation/i2c/functionality for a detailed explanation of
> how functionality flags work both on the I2C/SMBus adapter driver and
> the I2C device driver sides.

Ok, so the functionality flags describe whats possible when using the
smbus functions.
That's a bit confusing/misleading if the adapter driver doesn't
implement the smbus_xfer function in struct i2c_algorithm.
And if the i2c adapter / master_xfer fcn has some restrictions (e.g.
data length), things are getting complicated.

I2C_FUNC_SMBUS functionality flags are sufficiently documented, but what
about I2C_FUNC_I2C ?
Should this be set always if there is a master_xfer function or only if
the adapter is fully i2c compliant (and what does "fully i2c compliant"
mean ?) ?

To summarize: there is no possibilty to determine the maximum i2c data
length when using the i2c_xfer functions directly. It's basically try
and error and if the message is too long, the adapters should return
-EOPNOTSUPP.

Thanks for your explanations,
Frank