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

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

Hi Frank,

On Mon, 29 Oct 2012 17:24:16 +0200, Frank Schäfer wrote:
> Am 28.10.2012 19:39, schrieb Jean Delvare:
> > 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.

I agree.

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

This is only one of the various limitations we've seen in I2C
controllers so far. The maximum length may even by different in both
directions. Some controllers only support a discrete set of message
lengths or numbers. Etc... I don't think it makes sense to try to
exhaustively describe all these possible limitations. The current
approach where bus drivers return -EOPNOTSUPP on what they do not
support seems a lot better to me.

> It would also be useful for i2c_smbus_xfer_emulated, which can do a much
> better emulation with this information.

Can't see how. i2c_smbus_xfer_emulated translates an SMBus transaction
to an I2C message set, and there's only one way it can do that. Either
the controller can handle it, or it can't, but it's definitely not
i2c_smbus_xfer_emulated's job to silently tinkle the request to work
around hardware limitations.

-- 
Jean Delvare