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.
Attachment:
signature.asc
Description: Digital signature
