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

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

[Frank Schäfer]

Hi,

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 ?

Regards,
Frank

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

[Frank Schäfer]

Hi,

Am 27.10.2012 18:50, schrieb Jean Delvare:
> Hi Frank,
>
> On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
>> 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.

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

Ok, thanks, that's what I expected.

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

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.

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

Regards,
Frank

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

[Jean Delvare]

Hi Frank,

On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
> 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?

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

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

-- 
Jean Delvare

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

[Jean Delvare]

Hi Frank,

On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
> Am 27.10.2012 18:50, schrieb Jean Delvare:
> > On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
> >> 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 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.)

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

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

-- 
Jean Delvare

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

[Frank Schäfer]

Am 28.10.2012 14:03, schrieb Jean Delvare:
> Hi Frank,
>
> On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
>> Am 27.10.2012 18:50, schrieb Jean Delvare:
>>> On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
>>>> 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 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.)
>
>> (...)
>> 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.
>
>>>> 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.)
>

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 ?

Regards,
Frank

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

[Frank Schäfer]

Am 28.10.2012 17:11, schrieb Laurent Pinchart:
> Hi Jean,
>
> On Sunday 28 October 2012 13:03:01 Jean Delvare wrote:
>> On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
>>> Am 27.10.2012 18:50, schrieb Jean Delvare:
>>>> On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
>>>>> 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 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.)
>>
>>> (...)
>>> 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.
>
>>>>> 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)."
> The EM2765 might split reg + data write operations into two transactions 
> internally.

We don't know yet exactly what the EM2765 does.
All we can say at the moment is:
- transfers are working fine with a SCCB slave device (which doesn't
mean that the bus is for SCCB devices only)
- when sending n bytes to the slave device, the first byte sets the
register, the last byte is written to this register.
  All bytes inbetween are ignored
- when reading n bytes from the slave device, it returns n identical
bytes (beeing the value at the current register)
- 0 byte transfers always succeed, too (even if there is no device with
the i2c slave address !)

Regards,
Frank

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

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

[Laurent Pinchart]

Hi Jean,

On Sunday 28 October 2012 13:03:01 Jean Delvare wrote:
> On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
> > Am 27.10.2012 18:50, schrieb Jean Delvare:
> > > On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
> > >> 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 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.)
> 
> > (...)
> > 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.

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

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

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

-- 
Regards,

Laurent Pinchart

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

[Frank Schäfer]

Hi,

Am 28.10.2012 17:33, schrieb Jean Delvare:
> Hi Frank,
>
> On Sun, 28 Oct 2012 15:32:16 +0200, Frank Schäfer wrote:
>> Am 28.10.2012 14:03, schrieb Jean Delvare:
>>> On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
>>>> 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.)
>> 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.

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.

Thanks for your explanations,
Frank

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

[Jean Delvare]

Hi Frank,

On Sun, 28 Oct 2012 15:32:16 +0200, Frank Schäfer wrote:
> Am 28.10.2012 14:03, schrieb Jean Delvare:
> > On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
> >> 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.)
> 
> 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.

-- 
Jean Delvare

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

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

> 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

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

[Frank Schäfer]

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

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

[Jean Delvare]

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