[lkml]   [2012]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RESEND] x86, intel_mid: ADC management
    > >> 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
    read_samples (block/nonblock)
    ->samples() callback

    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.

    > 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.

    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.


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