[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.052 / U:4.988 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site