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 19:39, schrieb Jean Delvare:
> On Sun, 28 Oct 2012 17:25:19 +0200, Frank Schäfer wrote:
>> Am 28.10.2012 17:33, schrieb Jean Delvare:
>>> 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.
> Yes, this is correct.
>
>> I2C_FUNC_SMBUS functionality flags are sufficiently documented, but what
>> about I2C_FUNC_I2C ?
> I2C_FUNC_I2C means that you can call i2c_transfer, i2c_master_send and
> i2c_master_recv on the I2C adapter.

... which is always possible if master_xfer is implemented...

>
>> 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 ?) ?
> If i2c_transfer() has a chance to succeed for any transaction type not
> covered by I2C_FUNC_SMBUS_* flags, then I2C_FUNC_I2C should be set.

I would say this is not the case for my adapter.
smbus capability flags I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_BYTE_DATA
should cover everything which is possible.

> So
> yes, you are right, I2C_FUNC_I2C is set if and only if master_xfer is
> implemented.

That seems obvious.

> In theory, "fully I2C compliant" means that i2c_transfer() would
> succeed regardless of the message set passed (unless protocol mangling
> flags are used.) In practice, it is still OK to set I2C_FUNC_I2C if the
> controller has limitations, as long as these limitations are less
> restrictive than SMBus.

I would say no, not true in my this case.

So we have 1x pro and 2x contra I2C_FUNC_I2C.

My feeling is, that a max. data size of 1 byte isn't what users of
i2c_transfer, i2c_master_send and i2c_master_recv expect.
So I think I will stay with I2C_FUNC_SMBUS_READ_BYTE |
I2C_FUNC_SMBUS_BYTE_DATA only.

>
>> 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.
> Yes, this is correct. I2C_FUNC_* flags aren't fine-grained enough to
> describe all cases, so they should be used as a way for device driver
> to exclude transactions which aren't supported at all, but they may
> still have to deal with -EOPNOTSUPP on supported transactions. This is
> handled on a case-by-case basis.
>
> It could be argued that the I2C_FUNC_* flags aren't really necessary
> and drivers could simply try what they need and deal with -EOPNOTSUPP
> afterward. This is correct but it would probably make the driver code
> more complex in most cases.

What about adding a field/function i2c_xfer_maxlen to struct i2c_algortihm ?
It would also be useful for i2c_smbus_xfer_emulated, which can do a much
better emulation with this information.

Regards,
Frank