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

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

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.

> 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. So
yes, you are right, I2C_FUNC_I2C is set if and only if master_xfer is
implemented.

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.

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

-- 
Jean Delvare