[lkml]   [2010]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 and
> 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    [W:0.055 / U:2.276 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site