[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
    On 4/11/2012 11:38 AM, Mark Brown wrote:
    > On Wed, Apr 11, 2012 at 11:24:11AM +0100, Alan Cox wrote:
    >> If that code gets pulled out of IIO dumped into drivers/adc and has a bit
    >> of a different API to the gpadc code then no problem, gpadc can follow it
    >> 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.
    >> It does make sense to think hard about userspace APIs for IIO but for
    >> kernel APIs its really being too conservative - we break kernel APIs
    >> every release. They are not set into stone.
    > The way I keep thinking about this (which I'm sure I've suggested
    > before) is that we should be refactoring IIO such that the userspace ABI
    > is just another in-kernel consumer of the device driver bit of IIO and
    > that driver bit should be small enough to just use. I think that winds
    > up being roughly equivalent to your suggestion but means that there's
    > just one place to put the drivers which seems like a win.
    The intent is there, but there are an awful lot of corner cases that
    need working out.
    Mostly these don't relate to simple adc usage. Just take a look at those
    of the drivers that don't pass through the read_raw and write_raw callbacks.

    It might be possible to make the userspace interfaces optional without
    too much pain.

    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

     \ /
      Last update: 2012-04-11 12:51    [W:0.020 / U:9.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site