Date:	Mon, 15 Feb 2010 15:26:53 -0500
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	Jonathan Cameron <jic23@....ac.uk>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Kay Sievers <kay.sievers@...y.org>,
	Dmitry Torokhov <dtor@...l.ru>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	Manuel Stahl <manuel.stahl@....fraunhofer.de>,
	"Frysinger, Michael" <Michael.Frysinger@...log.com>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>,
	"Zhang, Xing Z" <xing.z.zhang@...el.com>,
	Ira Snyder <iws@...o.caltech.edu>,
	Jean Delvare <khali@...ux-fr.org>,
	Samu Onkalo <samu.p.onkalo@...ia.com>,
	Stefani Seibold <stefani@...bold.net>
Subject: Re: [RFC] Staging: IIO: New ABI V2

On Fri 5 Feb 2010 13:21, Jonathan Cameron pondered:
> Dear All,
> 
> Here is another iteration of the ABI spec for IIO with changes made
> in response to http://lkml.org/lkml/2010/1/20/195 and
> http://marc.info/?l=lm-sensors&m=126496271320649&w=2 along with a few
> other general tidy ups.
> 
> If there are no major issues raised, we may begin working on the move 
> to this ABI shortly on the basis any minor changes can always get
> cleaned up before those patches merge.  I'll also be doing a formal
> version of this file for in kernel documentation once things are
> fairly stable with all of the information not relevant to this
> discussion. 
> 
> Changes since v1:
> 
> * iio is now a bus with directory changes resulting in this document.
> * moved to in0_raw etc for voltage sensors to avoid confusion with
>   a completely different ABI from hwmon.  Jean made the point that
>   we shouldn't take this to far, but as things currently stand there
>   is no disadvantage in this name change. 
> * dropped freefall event for now. More discussions need to be had on this
>   and in a straight IIO world we normally won't care about this one anyway.
> * 'device' naming changed for the various subsidiary devices so as make
>   the interconnections more obvious.  I haven't tried implementing this
>   yet, but I think the small amount of pain involved is worth it for
>   increased clarity. The only exception is triggers where the connections
>   are not specified as a given trigger may not have and IIO device
>   associated with it.  Anyone suggest a scheme for this? (see about 10
>   lines below to clarify what I mean here!) 
> * As conversion of the max1363 driver over to a consistent scan_element
>   interface will mean that these will only apply to the ring buffer
>   (rather than direct capture), scan_elements is moved into the ring
>   buffer device directory.
> * Switch ring for simply buffer as it might be a fifo or other buffer
>   form instead. 
> 
> At times I may have suppressed links that would be created by the tree of
> devices. In the flat base directory a given driver can now create the
> following: 
> 
> device[n]
> device[n]:ring
> device[n]:ring:access
> device[n]:ring:event
> device[n]:event[m]
> trigger[o]
> 

What exists today still requires a copy_[to|from]_user when using the ring 
buffer (and then another cache_flush if you are dma'ing things). These seems 
pretty expensive and will consume extra cycles that will limit throughput.

Any thoughts to a mmaped interface directly to the IIO ring buffer, so the 
system could avoid some of the above overhead? (This is what we had to do for 
some other drivers - which were able to handle a 40 MSample/second data 
processed by userspace for a soft radio).

?

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

Powered by blists - more mailing lists