On Tue, 04 Oct 2011 15:23:42 +0100 Jonathan Cameron <jic23@xxxxxxxxx> wrote: > On 10/04/11 13:39, JohnLM wrote: > > On Fri, 30 Sep 2011 11:17:57 +0100 > > Jonathan Cameron <jic23@xxxxxxxxx> 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(-) > >> > > > > > -- 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
