[lkml]   [2012]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RESEND] x86, intel_mid: ADC management
On Tue, Apr 10, 2012 at 08:39:40PM +0100, Jonathan Cameron wrote:

> 1) Review of code. This is crucial. If people have a little time
> ripping holes in the core IIO code is what we need. Arnd did a good job
> of this a while back. Others have done bits of it since.

> 2) Getting the push code tidied up and pushed out. I'll post it as an
> updated rfc to linux-iio shortly. All I had left that definitely
> wanted doing here was cleaning up the example iio to input bridge
> driver. That can happen later.

For these two can we refactor in place? That's pretty much what seems
to have been happening anyway...

> * Event passing to consumers else where in the kernel. Right now an
> input driver can readings from a sensor, but there is no way of
> requesting threshold interrupts.

> * Interaction between consumer drivers (e.g. hwmon or input) where some
> are requesting data by polling when they want it and others want a

These sound like something that can be added incrementally?

> > If the code was moved out of staging today what would go wrong?

> Churn in interfaces is probably about it. Maybe a good use of any time

I guess the big question is then if we can live with that.

> would be for people to take their non IIO drivers that they think might
> fit (or data sheets!) and see whether there are things that they would
> like to be different.

In tree there's a few auxadc and comparator drivers in drivers/mfd, plus
things like arch/arm/plat-samsung/adc.c in the arch direcories. These
are all broadly similar to the at91 code that's been sent to IIO
already. There's also the code Alan posted at the top of this thread.
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2012-04-11 00:39    [W:0.080 / U:7.084 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site