Re: [RFC] Staging: IIO: New ABI V2

[Greg KH <gregkh@suse.de>]

On Mon, Feb 15, 2010 at 07:58:12PM -0500, Mike Frysinger wrote:
> On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote:
> > On Fri 5 Feb 2010 13:21, Jonathan Cameron pondered:
> >> 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).
> 
> does sysfs currently support mmap-ing of files in there ?

For binary files, yes.  If you are going to use mmap, use a character
device node instead please, that's not what sysfs is for.

thanks,

greg k-h