From: David Brownell <david-b@pacbell.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Adding an async I2C interface
Date: Mon, 24 Jan 2005 08:36:38 -0800
User-Agent: KMail/1.7.1
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200501240836.38669.david-b@pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1994
Lines: 44

Quoth Corey Minyard:
> I would really like add asynchronous interface to the I2C bus drivers. 

Applause!  This is IMO overdue, but maybe sensor systems don't need it
as much as other I2C applications do.  For example, see the isp1301_omap
driver, which could have been hugely simpler if there were an async I2C
framework to build on.  That's probably one of the more complex examples
floating around ... but it's hardly the only place where needing to talk
synchronously to I2C chips creates trouble.


> I propose: 
> 
>    * Adding an async send interface to the busses that does a callback
>      when the operation is complete.

It'd have to have a queue, so that several different chips could have
operations pending concurrently.  I suspect you wouldn't need to cancel
operations once they're queued ... useful simplification, compared to
for example USB.  (Which in retrospect needs a "kill queue" operation,
per endpoint, rather than the "cancel request" operation we've got.
But when 2.2 started with USB, we didn't quite know that ... ;)


>    * Adding a poll interface to the busses.  The I2C core code could
>      call this if a synchronous call is made from task context (much
>      like all the current drivers do right now).  For asyncronous
>      operation, the I2C core code would call it from a timer
>      interrupt.  If the driver supported interrupts, polling from the
>      timer interrupt would not be necessary.
>    * Add async operations for the user to call, including access to the
>      polling code.
>    * If the driver didn't support an async send, it would work as it
>      does today and the async calls would return ENOSYS.

To the extent I've thought about it, that sounds like a good approach.

- Dave
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/