Potential I2C API Enhancement

Potential I2C API Enhancement

[Michael Jones]

While working with the I2C interface using Kinetis to write a SMBus/PMBus layer over it, I could not implement a probe.

PMBus developers typically probe the bus looking for slaves by sending an address and using ACK/NACK to determine presence.

The only way one can probe with the current I2C API is to send at least one data byte, so that the return is an indicator of success or failure. However, this is a dangerous way to probe, because it might have side effects.

Sometimes people probe with Addr+Read, but most use Addr+Write, because that avoids a potential ARA response.

I am looking for ideas how best to deal with this problem. Potential solutions:

1) Use a target specific API
2) Add to existing API, like i2c_slave_present(...
3) Add new API/Package

In my opinion, choice 2 would be the best because it is target independent, and least confusing.

The practical impact is people developing SMBus/PMBus tend to use Cortex M. There are a small number of targets (5) in the dev tree. So perhaps it is still possible to add to the I2C API?

Thoughts?

Mike

Re: Potential I2C API Enhancement

[Michael Jones]

I would also like to point out that SMBus 2.0 Section 5.5.1 documents Quick Command, which is composed as:

S | Slave Address | Rd/Wr | A | P

which has no data. If this were performed with i2c_transaction_tx, there is no way to know with the current API if the command was error free by using the return value.

If the i2c API could return a negative integer, -1 could be used to indicate errors like NACK, arbitration loss, timeout, etc.

Mike



On Jan 21, 2013, at 8:08 AM, Michael Jones <mjones@linear.com> wrote:

> While working with the I2C interface using Kinetis to write a SMBus/PMBus layer over it, I could not implement a probe.
> 
> PMBus developers typically probe the bus looking for slaves by sending an address and using ACK/NACK to determine presence.
> 
> The only way one can probe with the current I2C API is to send at least one data byte, so that the return is an indicator of success or failure. However, this is a dangerous way to probe, because it might have side effects.
> 
> Sometimes people probe with Addr+Read, but most use Addr+Write, because that avoids a potential ARA response.
> 
> I am looking for ideas how best to deal with this problem. Potential solutions:
> 
> 1) Use a target specific API
> 2) Add to existing API, like i2c_slave_present(...
> 3) Add new API/Package
> 
> In my opinion, choice 2 would be the best because it is target independent, and least confusing.
> 
> The practical impact is people developing SMBus/PMBus tend to use Cortex M. There are a small number of targets (5) in the dev tree. So perhaps it is still possible to add to the I2C API?
> 
> Thoughts?
> 
> Mike
> 
> 

Re: Potential I2C API Enhancement

[Tomas Frydrych]

On 21/01/13 17:09, Michael Jones wrote:
> I would also like to point out that SMBus 2.0 Section 5.5.1 documents
> Quick Command, which is composed as:
> 
> S | Slave Address | Rd/Wr | A | P
> 
> which has no data. If this were performed with i2c_transaction_tx,
> there is no way to know with the current API if the command was error
> free by using the return value.
> 
> If the i2c API could return a negative integer, -1 could be used to
> indicate errors like NACK, arbitration loss, timeout, etc.

I entirely agree that being able to report errors through the i2c API is
desirable, and it's one of the issues I run into when implementing the
Kinetis i2c driver. For example, there is no way to report when the bus
is busy, so the driver ends up just waiting for the bus to become free
-- this is not always desirable behaviour, as discussed in
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397.

Tomas

Re: Potential I2C API Enhancement

[Michael Jones]

From what I read, I believe the eCos strategy is to return status, not error, in APIs.

With respect to SMBus, the following are typically status:

- Timeout
- Loss of Arbitration
- NACK
- OK

NACK can indicate that a slave is too busy to accept a transaction.

These are a bit orthogonal to the need for a probe API.

One option would be to add a new device type, say "smb", in addition to i2c. Then map the smb interface over the i2c internal implementation. This would create a dependency between /dev/smb and /dev/i2c.

I don't know the eCos architecture well enough to know if this dependency can be managed properly with the CDL/Configuration, etc. But if it could, it would mean the i2c API could be left alone.

Can someone comment on whether this could be done?

Mike



On Jan 21, 2013, at 10:29 AM, Tomas Frydrych <tf+lists.ecos@r-finger.com> wrote:

> On 21/01/13 17:09, Michael Jones wrote:
>> I would also like to point out that SMBus 2.0 Section 5.5.1 documents
>> Quick Command, which is composed as:
>> 
>> S | Slave Address | Rd/Wr | A | P
>> 
>> which has no data. If this were performed with i2c_transaction_tx,
>> there is no way to know with the current API if the command was error
>> free by using the return value.
>> 
>> If the i2c API could return a negative integer, -1 could be used to
>> indicate errors like NACK, arbitration loss, timeout, etc.
> 
> I entirely agree that being able to report errors through the i2c API is
> desirable, and it's one of the issues I run into when implementing the
> Kinetis i2c driver. For example, there is no way to report when the bus
> is busy, so the driver ends up just waiting for the bus to become free
> -- this is not always desirable behaviour, as discussed in
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397.
> 
> Tomas