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

[Mike Frysinger]

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