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

the i2c interface of my device is capable of writing 2 bytes (reg + data) and reading a single data byte only.

A block read/write emulation function would have to do an i2c write (to increase the register) followed by either an i2c read or write for each data byte.
The question is now: does it make sense to emulate block operations for the i2c/smbus layer in this case ?
I'm not sure if an i2c read through the smbus/i2c subsystem should really trigger multiple low level i2c reads/writes...

What's the right error code to return from the drivers master_xfer function if the message length is not supported ? -EMSGSIZE ?

Hi Frank,

Quoted 2 lines · Frank Schäfer

the i2c interface of my device is capable of writing 2 bytes (reg + data) and reading a single data byte only.

Are you talking about an I2C master (controller) here, or a slave device?

Quoted 8 lines

A block read/write emulation function would have to do an i2c write (to increase the register) followed by either an i2c read or write for each data byte.
The question is now: does it make sense to emulate block operations for the i2c/smbus layer in this case ?
I'm not sure if an i2c read through the smbus/i2c subsystem should really trigger multiple low level i2c reads/writes...

No, that would be bad. There's no single way to emulate a transaction using smaller transactions. Different slaves will react differently (some have a notion of "current address", with or without auto-increment, some don't.) Plus, in a multi-master environment, splitting a transaction into small chunks is not safe. So doing that transparently at the bus driver level would be plain wrong.

What could be done (this has been discussed earlier and is already implemented in individual drivers) is provide helper functions reading blocks in a best-effort mode. The caller's expectations would be different from the regular block read functions. These helper functions would be in neutral ground to avoid any improper assumption.

Quoted 3 lines

What's the right error code to return from the drivers master_xfer function if the message length is not supported ? -EMSGSIZE ?

-EOPNOTSUPP, per Documentation/i2c/fault-codes.

Note that ideally, the slave driver should check the bus functionality and not try transactions which aren't supported. So returning -EOPNOTSUPP normally never happens.

Am 27.10.2012 18:50, schrieb Jean Delvare:

Quoted 5 lines · Frank Schäfer

Quoted 2 lines

the i2c interface of my device is capable of writing 2 bytes (reg + data) and reading a single data byte only.

Are you talking about an I2C master (controller) here, or a slave device?

It's an em2765 USB-video-bridge with an OV2640 sensor slave. The i2c transfer functions I'm currently working on are not yet in the em28xx driver.

I don't know yet if it is a general bus limitation or a client limitiation. The procedures are based on reverse-engineering work and the OV2640 is the only device we have seen so far.
Maybe it has something to do with the fact that the OV2640 uses SCCB.

(...)
Yes, emulating block reads/writes internally (the em28xx driver in this case) is not the problem.
My question was if it makes sense to export the emulation through the i2c subsystem.

Quoted 7 lines

Quoted 2 lines

What's the right error code to return from the drivers master_xfer function if the message length is not supported ? -EMSGSIZE ?

-EOPNOTSUPP, per Documentation/i2c/fault-codes.

Note that ideally, the slave driver should check the bus functionality and not try transactions which aren't supported. So returning -EOPNOTSUPP normally never happens.

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 ?

Hi Frank,

Quoted 6 lines · Frank Schäfer

Am 27.10.2012 18:50, schrieb Jean Delvare:

Quoted 5 lines · Frank Schäfer

Quoted 2 lines

the i2c interface of my device is capable of writing 2 bytes (reg + data) and reading a single data byte only.

Are you talking about an I2C master (controller) here, or a slave device?

Quoted 8 lines

It's an em2765 USB-video-bridge with an OV2640 sensor slave. The i2c transfer functions I'm currently working on are not yet in the em28xx driver.

I don't know yet if it is a general bus limitation or a client limitiation. The procedures are based on reverse-engineering work and the OV2640 is the only device we have seen so far.
Maybe it has something to do with the fact that the OV2640 uses SCCB.

Yes SCCB is apparently very limited in terms of supported transaction types. Plus it diverges from the equivalent SMBus transactions in the details. Note that we do have support for SCCB since kernel v3.6 (commit d47726c52122d64253ae56e0fafdb7d0b954e97c by Laurent Pinchart.)

Quoted 5 lines

(...)
Yes, emulating block reads/writes internally (the em28xx driver in this case) is not the problem.
My question was if it makes sense to export the emulation through the i2c subsystem.

If you do, you'll have to make it flexible enough that it can be used by other drivers, such as at24 and eeprom.

Quoted 9 lines

Quoted 7 lines

Quoted 2 lines

What's the right error code to return from the drivers master_xfer function if the message length is not supported ? -EMSGSIZE ?

-EOPNOTSUPP, per Documentation/i2c/fault-codes.

Note that ideally, the slave driver should check the bus functionality and not try transactions which aren't supported. So returning -EOPNOTSUPP normally never happens.

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

Am 28.10.2012 14:03, schrieb Jean Delvare:

Quoted 8 lines · Frank Schäfer

Quoted 2 lines

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

Quoted 7 lines

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 ?

Hi Frank,

Quoted 14 lines · Frank Schäfer

Am 28.10.2012 14:03, schrieb Jean Delvare:

Quoted 13 lines · Frank Schäfer

Quoted 2 lines

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

Quoted 8 lines

Quoted 2 lines

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.

Am 28.10.2012 17:33, schrieb Jean Delvare:

Quoted 9 lines

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

Quoted 7 lines

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.

Quoted 17 lines

Am 28.10.2012 17:33, schrieb Jean Delvare:

Quoted 9 lines

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

Quoted 7 lines

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.

Quoted 6 lines

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.

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Am 28.10.2012 19:39, schrieb Jean Delvare:

Quoted 5 lines

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.

Quoted 10 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 12 lines · Frank Schäfer

Am 27.10.2012 18:50, schrieb Jean Delvare:

Quoted 6 lines · Frank Schäfer

Quoted 2 lines

the i2c interface of my device is capable of writing 2 bytes (reg + data) and reading a single data byte only.

Are you talking about an I2C master (controller) here, or a slave device?

It's an em2765 USB-video-bridge with an OV2640 sensor slave. The i2c transfer functions I'm currently working on are not yet in the em28xx driver.

Quoted 5 lines

I don't know yet if it is a general bus limitation or a client limitiation.
The procedures are based on reverse-engineering work and the OV2640 is the only device we have seen so far.
Maybe it has something to do with the fact that the OV2640 uses SCCB.

Yes SCCB is apparently very limited in terms of supported transaction types. Plus it diverges from the equivalent SMBus transactions in the details. Note that we do have support for SCCB since kernel v3.6 (commit d47726c52122d64253ae56e0fafdb7d0b954e97c by Laurent Pinchart.)

Quoted 5 lines

(...)
Yes, emulating block reads/writes internally (the em28xx driver in this case) is not the problem.
My question was if it makes sense to export the emulation through the i2c subsystem.

If you do, you'll have to make it flexible enough that it can be used by other drivers, such as at24 and eeprom.

Quoted 11 lines

Quoted 8 lines

Quoted 2 lines

What's the right error code to return from the drivers master_xfer function if the message length is not supported ? -EMSGSIZE ?

-EOPNOTSUPP, per Documentation/i2c/fault-codes.

Note that ideally, the slave driver should check the bus functionality and not try transactions which aren't supported. So returning -EOPNOTSUPP normally never happens.

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

Hi Jean,

Quoted 21 lines · On Sunday 28 October 2012 13:03:01 Jean Delvare wrote:

Quoted 10 lines · Frank Schäfer

Am 27.10.2012 18:50, schrieb Jean Delvare:

Quoted 5 lines · Frank Schäfer

Quoted 2 lines

the i2c interface of my device is capable of writing 2 bytes (reg + data) and reading a single data byte only.

Are you talking about an I2C master (controller) here, or a slave device?

It's an em2765 USB-video-bridge with an OV2640 sensor slave. The i2c transfer functions I'm currently working on are not yet in the em28xx driver.

Quoted 5 lines

I don't know yet if it is a general bus limitation or a client limitiation.
The procedures are based on reverse-engineering work and the OV2640 is the only device we have seen so far.
Maybe it has something to do with the fact that the OV2640 uses SCCB.

Yes SCCB is apparently very limited in terms of supported transaction types. Plus it diverges from the equivalent SMBus transactions in the details. Note that we do have support for SCCB since kernel v3.6 (commit d47726c52122d64253ae56e0fafdb7d0b954e97c by Laurent Pinchart.)

Quoted 7 lines

Quoted 5 lines

(...)
Yes, emulating block reads/writes internally (the em28xx driver in this case) is not the problem.
My question was if it makes sense to export the emulation through the i2c subsystem.

If you do, you'll have to make it flexible enough that it can be used by other drivers, such as at24 and eeprom.

Is that really mandatory ? The EM2765 will only be connected to video sensors in practice.

Quoted 12 lines

Quoted 9 lines

Quoted 7 lines

Quoted 2 lines

What's the right error code to return from the drivers master_xfer function if the message length is not supported ? -EMSGSIZE ?

-EOPNOTSUPP, per Documentation/i2c/fault-codes.

Note that ideally, the slave driver should check the bus functionality and not try transactions which aren't supported. So returning -EOPNOTSUPP normally never happens.

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:

Quoted 6 lines

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

The EM2765 might split reg + data write operations into two transactions internally.

Quoted 3 lines

You can take a look at Documentation/i2c/smbus-protocol to match transactions to function names (and from there to I2C_FUNC flags.)