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    [W:0.024 / U:397.908 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site