Re: [RFC PATCH 0/2] IIO: Filtering - how to handle.

[JohnLM <johnlm@apollo.lv>]

On Tue, 04 Oct 2011 15:23:42 +0100
Jonathan Cameron <jic23@cam.ac.uk> wrote:

> On 10/04/11 13:39, JohnLM wrote:
> > On Fri, 30 Sep 2011 11:17:57 +0100
> > Jonathan Cameron <jic23@cam.ac.uk> wrote:
> > 
> >> Hi All,
> >>
> >> One big area we have pretty much glossed over so far is devices
> >> with controllable hardware filters.  This RFC proposes one option
> >> for how to handle this. For low pass filters at least, the 3db
> >> point seems the obvious choice as it allows us to gloss over
> >> exactly what type of filter it is whilst still capturing it's basic
> >> property of what it lets through.
> >>
> >> What do people think?
> > I have no exact filters in mind but in general since they affect the
> > readings I think some kind of framework is needed.
> > Some generic types should be defined, but even when IIO can't make
> > out what kind of filter it is, user-space app might so it should be
> > exposed.
> True.  But how generic do we want and how do we specify it?
> 
> The version here assumes that knowing it is low pass is enough, but
> is that true.  Do we need to know for example if it is a Butterworth
> filter?
IMO it makes most sense we categorize them by
basic functionality. Thus making it 'low pass filter' should be good
enough, but we can (and should) expose it's type.
> 
> If we do, does it need to be in the naming?   If not, should we
> perhaps have in_voltage_filter_low_pass_type with named filter
> types?  Perhaps this also has say butterworth-N for N tap butterworth
> for example? Or should be have filter_low_pass_type and
> filter_low_pass_taps? Number of taps is often tied up with the 3db
> point, which would make things a little interesting.  We might have
> to buffer the 3db request and do a hardware update on any of type,
> taps, 3db_frequency and sampling frequency changing.  We are already
> doing that on frequency in the example given here, so not so bad.
> 
> > 
> > For filters that can be enabled/disabled userspace could even
> > abstract the filtering routine to use hardware filter when desired
> > or use software filter when hardware filter is not present or is
> > unreliable.
> I'm unconvinced that we want to do software filtering in kernel land.
> Can't immediately see the point, unless possibly it was used to do
> data reduction into a buffer.  Worth keeping in mind, but no something
> I can see happening any time soon.
I ran a bit ahead of me. I didn't intend to do this kind of processing
in kernel space. Surely software filters should stay in userspace, I
don't see the point of this being in kernel space either.
What I meant was that enough information about filters must be exposed
so this abstraction could be done in userspace library or/and app.

> > 
> > The implementation is a whole other story I don't have time to think
> > about right now. :)
> :)
> > 
> >>
> >> Jonathan
> >>
> >> Jonathan Cameron (2):
> >>   staging:iio: filter description - low pass 3db frequency.
> >>   staging:iio:imu:adis16400 add control of data filtering.
> >>
> >>  drivers/staging/iio/iio.h                |    2 +
> >>  drivers/staging/iio/imu/adis16400.h      |    2 +
> >>  drivers/staging/iio/imu/adis16400_core.c |  177
> >> +++++++++++++++++++++++------
> >> drivers/staging/iio/industrialio-core.c  |    2 + 4 files changed,
> >> 146 insertions(+), 37 deletions(-)
> >>
> > 
> > 
>