lkml.org 
[lkml]   [2012]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RESEND] x86, intel_mid: ADC management
    On 4/11/2012 12:13 PM, Alan Cox wrote:
    >>>> happily enough. IIO can use it from staging and IIO can migrate whenever.
    >> IIO is about a heck of a lot other than ADCs. Keep that in mind. They
    >> are a substantial
    >> corner but we handle a lot of output devices and other input devices
    >> (though these
    >> might be adc's inside, that's not what your average users think of them as).
    >> We 'have' to ensure anything we do works for the other device types as well.
    > At the IIO layer, but an ADC layer itself needs very very little indeed.
    >
    > You've got
    > allocate
    > deallocate
    > read_samples (block/nonblock)
    > setup
    > ->samples() callback

    To add a few more things that are common (there are others).

    Read scale, read offset.
    Hardware event interrupts,
    Triggering control.
    Filtering control.

    Some adcs may only need what you specify, others need a whole lot more.
    You might term these setup I suppose, but the consumer of the data often
    needs to know about them.
    >
    > and devices are either polled, IRQ driven or DMA.
    >
    > Now setup is a lot of different things but those can be abstracted and
    > added as needed (and much probably taken from the IIO bits).
    >
    > A pure ADC abstraction ought to be a very very thin layer of code.
    Except that you then end up with simple_adc abstraction and a whole host
    of more
    complex abstractions on top.
    >
    >> I know it's not ideal, but at the end of the day IIO had a rather
    >> different target when
    >> we wrote it from SoC ADCs. That target of consistent userspace
    >> interfaces and
    >> brute force data capture still has to be met without introducing major
    >> regressions.
    > I don't see the two conflicting. At one level we have a need for a simple
    > abstraction for low level ADC access within devices (akin to gpio). At the
    > level above we have a need for a consistent, sensible interface to
    > userspace with a stable API.
    We have that simple abstraction. Dumb polled or irq driven adc stuff
    can be done cleanly
    in minimal code.
    What I disagree on is that the bit you have grouped into setup is
    actually separate. That
    needs to be abstracted as well. Consumers might not care that the gain
    just doubled
    because someone else requested it, but I suspect many of them will.
    >
    > Your simple IIO examples would just use the ADC abstraction, your complex
    > IIO examples would use the ADC abstraction *and* layer it with IIO level
    > code that is mixing it with all the other needed work.
    I suspect you'll end up adding more and more to your adc abstraction
    till you actually
    end up with most of IIO. That's effectively what we did... It's big
    because there are
    actually not that many 'simple' adc's out there.

    Jonathan


    \
     
     \ /
      Last update: 2012-04-11 13:21    [W:0.028 / U:0.408 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site