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

[Mike Frysinger <vapier.adi@gmail.com>]

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 ?
-mike