public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Michael Jones <mjones@linear.com>
To: Tomas Frydrych <tf+lists.ecos@r-finger.com>
Cc: ecos-devel@ecos.sourceware.org
Subject: Re: Potential I2C API Enhancement
Date: Mon, 21 Jan 2013 19:53:00 -0000	[thread overview]
Message-ID: <BB7687F7-B4E6-48A4-A099-9E6F39219548@linear.com> (raw)
In-Reply-To: <50FD7AF1.2060805@r-finger.com>

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

      reply	other threads:[~2013-01-21 19:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-21 15:08 Michael Jones
2013-01-21 17:09 ` Michael Jones
2013-01-21 17:29   ` Tomas Frydrych
2013-01-21 19:53     ` Michael Jones [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BB7687F7-B4E6-48A4-A099-9E6F39219548@linear.com \
    --to=mjones@linear.com \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=tf+lists.ecos@r-finger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).