linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Martin Fuzzey <mfuzzey@parkeon.com>
Cc: linux-iio@vger.kernel.org, pmeerw@pmeerw.net
Subject: Re: [PATCH V2 7/8] iio: mma8452: add an attribute to enable the highpass filter
Date: Thu, 14 Aug 2014 18:10:04 +0100	[thread overview]
Message-ID: <53ECED6C.30305@kernel.org> (raw)
In-Reply-To: <53E3B921.6050203@parkeon.com>

On 07/08/14 18:36, Martin Fuzzey wrote:
> On 07/08/14 18:30, Jonathan Cameron wrote:
>> On 29/07/14 10:01, Martin Fuzzey wrote:
>>> The hardware contains a single configurable highpass filter which
>>> is normally used for transient detection (event).
>>>
>>> However it is also possible to enable this filter for normal channel
>>> reading. Add a new attribute in_accel_high_pass_filter_en to do this.
>>>
>>> Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
>> The obvious answer to this would be to set the cuttoff to 0.
>> Presumably the complexity here is there  is only one high pass filter
>> implementation, both for the data and for the event?
> Yes exactly
> 
>> If so I would probably still prefer it was done via the 3db point
>> setting, just that you have two attributes to access that - one for
>> the channel and one for the event.  Setting the channel version to
>> non zero would change both.  Setting the event one to any value
>> would change both only if the channel version is not zero.
> But I don't think that would handle the use case of
> * No filter for channel data
> * Filter for event
That was what the nasty bit (which I also don't like!) in my suggestion
was meant to handle.  Any time the channel version is 0 then a write
to the event one doesn't change it.  If it is non zero then it does.
(uggly use of 0 to specify that we have disabled the filter).
> 
> The hardware has
> 1) A register to set the filter frequency (one of 4 possible values, with the allowed set depending on the current
> sampling frequency)
> 2) A bit to enable the filter for value readings  (default disabled)
> 3) A bit to disable the filter for transient detection (default enabled)
> 
> My current patchset does not support 3) - the filter is always enabled for transient events
Ah. In that case perhaps a slight extension of the above:

Again two filter setting attributes, one for the event and one for the channel.
Both default to off
event : 0, channel : 0
write event version with value A

event : A, channel : 0

write channel version with value B
event : B, channel : B

write event version with value C

event : C, channel : C

write event version with 0

event : 0, channel : C

write event version with D

event : D, channel : D

write channel version with 0 to disable

event : D, channel : 0

write event version with 0 to disable

event : 0, channel 0 - no filters on.

Should be relatively easy to implement.  When you get a write simply check if the
other cached value is currently 0.  If it is, don't update it.  If it isn't then
do.  Unless a 0 is being written, in which case only disable which ever one has
been written to.

Mind you this logic will get interesting for low pass filters as setting the
cut off to 0 will end up letting through everything (somewhat counterintuitive!)


> 
>> It's a little fiddly, perhaps having an enable on a filter is
>> the way to go... Anyone else have any thought on this?
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-08-14 17:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29  9:01 [PATCH V2 0/8] iio: mma8452 enhancements Martin Fuzzey
2014-07-29  9:01 ` [PATCH V2 1/8] iio: mma8452: Initialise before activating Martin Fuzzey
2014-08-07 14:21   ` Jonathan Cameron
2014-08-07 17:47     ` Peter Meerwald
2014-08-14 17:30       ` Jonathan Cameron
2014-07-29  9:01 ` [PATCH V2 2/8] iio: mma8452: Add access to registers via DebugFS Martin Fuzzey
2014-07-29  9:01 ` [PATCH V2 3/8] iio: mma8452: Basic support for transient events Martin Fuzzey
2014-08-07 14:37   ` Jonathan Cameron
2014-07-29  9:01 ` [PATCH V2 4/8] iio: mma8452: Add support for transient event debouncing Martin Fuzzey
2014-08-07 14:41   ` Jonathan Cameron
2014-07-29  9:01 ` [PATCH V2 5/8] iio: core: add high pass filter attributes Martin Fuzzey
2014-08-07 14:42   ` Jonathan Cameron
2014-07-29  9:01 ` [PATCH V2 6/8] io: mma8452: Add highpass filter configuration Martin Fuzzey
2014-08-07 14:49   ` Jonathan Cameron
2014-07-29  9:01 ` [PATCH V2 7/8] iio: mma8452: add an attribute to enable the highpass filter Martin Fuzzey
2014-08-07 16:30   ` Jonathan Cameron
2014-08-07 17:36     ` Martin Fuzzey
2014-08-14 17:10       ` Jonathan Cameron [this message]
2014-07-29  9:01 ` [PATCH V2 8/8] iio: mma8452: Add support for interrupt driven triggers Martin Fuzzey
2014-08-07 16:34   ` Jonathan Cameron
2014-08-07 17:20     ` Martin Fuzzey
2014-08-14 17:12       ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53ECED6C.30305@kernel.org \
    --to=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=mfuzzey@parkeon.com \
    --cc=pmeerw@pmeerw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).