lkml.org 
[lkml]   [2010]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] Staging: IIO: New ABI V2
Date
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).

?



\
 
 \ /
  Last update: 2010-02-15 21:29    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site