[PATCH] [RFC] Use ADC API

[Matt Reimer]

On Wed, Mar 11, 2009 at 3:12 PM, Nelson Castillo
<arhuaco at freaks-unidos.net> wrote:
> From: Nelson Castillo <arhuaco at freaks-unidos.net>
>
> This is a small fun patch that makes the TS driver use the s3c-adc
> driver. This is something we will have to do in order to get the
> driver upstream.
>
> This patch is a proof of concept only and should not be applied.
>
> It works but it is slow because we schedule conversions one by one. It
> could be improved in different ways. The following two come to my mind
> now:
>
> 1) As for conversion in quantums (say of 10) and discard a few if we
> don't get to need them.
>
> 2) Add a method to the TS filters called "minimum_needed" that helps
> the driver estimate how many points to ask for.

Nelson, I'm eager to see your ts_filter get into mainline. Thanks for
all your work on it.

I'm experimenting with ts_filter on a different device that samples
the ts over an ac97 link at 188 samples/sec. One problem we have is
that with the filters configured to give good results (particularly
feeding the median filter 20 samples), short taps (whose duration
lasts less than 20 samples) get ignored. At 188 samples/sec, 20
samples = 106 ms, which is way too long. Right now I'm configuring the
median filter to require fewer samples, but then more noise gets
through.

One way to improve this situation would be to specify both a minimum
number of samples and a preferred number of samples.

For example, I could set the minimum number of samples to 6 and the
preferred number of samples to 20. If fewer than 6 samples arrive
before pen-up, then the samples would be ignored. But if we received 8
samples due to a quick tap, then the filters would go ahead and do
their best to clean up the samples and emit a denoised sample for the
tap, even though the filters wouldn't have received the full 20 that
they prefer.

Thoughts? I think it would really help on my hardware.

Matt