Messages in this thread | | | Date | Wed, 11 Apr 2012 11:48:19 +0100 | From | Jonathan Cameron <> | Subject | Re: [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 elements 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 regressions.
| |