linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: David Frey <dpfrey@gmail.com>
Cc: linux-iio <linux-iio@vger.kernel.org>
Subject: Re: Adding "fault count" support to opt3001
Date: Sun, 6 Oct 2019 10:40:19 +0100	[thread overview]
Message-ID: <20191006104019.426638c7@archlinux> (raw)
In-Reply-To: <a3335ddc-6961-79fa-308d-868e156960d1@gmail.com>

On Fri, 27 Sep 2019 10:08:19 -0700
David Frey <dpfrey@gmail.com> wrote:

> Hi,
> 
> The TI opt3001 light sensor has a fault count field in its configuration
> register.  See http://www.ti.com/lit/ds/symlink/opt3001.pdf on page 23.
> Basically, this field controls how many samples must be above the high
> threshold or below the low threshold in order to trigger the interrupt.
> Currently the driver initializes this field to 0 meaning that one fault
> will trigger an interrupt.
> 
> 0b00 -> 1
> 0b01 -> 2
> 0b10 -> 4
> 0b11 -> 8
> 
> The driver has an IIO event which allows for the high/low threshold to
> be set and enabled/disabled.  I would like to add the ability to specify
> the fault count as well and I'm wondering how this should be done.  I
> believe it should be done by adding a .mask_shared_by_type =
> BIT(IIO_EV_INFO_???) definition within the struct iio_event_spec, but
> I'm not sure if any of the existing IIO_EV_INFO_ values are appropriate.
>  The only one that might be appropriate is IIO_EV_INFO_HYSTERESIS.

If I have understood what this is correctly...

IIO_EV_INFO_PERIOD is the right one.  From a userspace point of view
it really doesn't care how many samples it is, what it cares about is
how long it needs to break the threshold for.  So across different
sensor types it might want to ignore camera flashes for example.

This does mean it becomes dependent on the sampling frequency. Now
I can't actually work out from that datasheet what controls the sampling
frequency...  I suppose it might just start a new reading immediately
after the previous one, but there isn't anything that I can see that
documents that.  Any ideas?

> 
> Am I going about this the right way?
> Is IIO_EV_INFO_HYSTERESIS appropriate?
> Should a new enum value be defined?
> 
> Thanks,
> David


      reply	other threads:[~2019-10-06  9:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27 17:08 Adding "fault count" support to opt3001 David Frey
2019-10-06  9:40 ` Jonathan Cameron [this message]

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=20191006104019.426638c7@archlinux \
    --to=jic23@kernel.org \
    --cc=dpfrey@gmail.com \
    --cc=linux-iio@vger.kernel.org \
    /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).