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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
