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