This is a fairly stupid place to reply but I don't have any way of
replying to the original
patch whilst at work. Looking quickly at it in a web browser, looks
like we fundamentally
have a couple of interfaces exported. An alloc and free pair and two
types of sample?
The second, during gsmpulse sample is some sort of triggered capture?
Mapping to what is now in IIO (and hasn't been for that long!).
We handle alloc and free via a mapping table that registered with the
core by the
consumer driver (often coming from platform data).
Raw channel reads are available via polling or you can register a
callback function
(that's the bit that is going through review at the moment) if you have
a buffered
situation. So the missing bit is that we don't have a 'request n
samples' call.
We also don't currently have the functions to switch the triggering
mechanism from
consumers (though they should be easy to add).
Anyhow, those are the differences and looks like IIO needs a few small
tweaks to
meet the interface requirements if you did decide to go that way. The
only one
I'm not immediately sure how to handle is the 'read n samples' bit. A
self unregistering
version of the callback buffer might do it reasonably cleanly....
What you have may correspond to an arbitary scan. The question is do
you ever do
uneven reading of different channels? e.g. AABAAB.
Jonathan
Mark Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
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...
I guess it comes down to whether Linus will pull. 2 should be there within a week or so anyway depending mostly on analog testing I haven't broken any of their drivers.
* 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.
Agreed.
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.
Quite a lot of things in miscellaneous as well to possibly pull in over time.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
