From: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
To: rishi gupta <gupt21@gmail.com>
Cc: linux-iio@vger.kernel.org
Subject: Re: Custom sysfs entries for persistence, gain & threshold in light sensor
Date: Sat, 7 Sep 2019 11:49:19 +0100 [thread overview]
Message-ID: <20190907114919.15d8c638@archlinux> (raw)
In-Reply-To: <CALUj-gsjKkiF8vrzgeWkh9wo-qBuJDW+5eLPqHqdj3v3ngk4UA@mail.gmail.com>
On Fri, 6 Sep 2019 22:03:52 +0530
rishi gupta <gupt21@gmail.com> wrote:
> Hi experts,
Hi Rishi,
>
> I am writing driver for veml6030 ambient light sensor. Application can
> set persistence, gain & threshold which will in turn update registers
> in sensor.
>
> In IIO framework there is no standard constant for this.
So first element here is whether there aren't standard ABI elements for these.
A quick look suggest threshold maps to an IIO event, so look at that ABI.
Persistence - I'm guessing as the datasheet I have doesn't actually explain
what it is... Probably number of cycles for which the value has to be
over the threshold for an interrupt to occur? This maps to period, though
you'll have to do the magic to convert form cycles to seconds.
Gain maps to 1/Gain == scale in IIO terms. What userspace cares about is
what maths it needs to do to get a real world value and that is given
by scale. Here you have the complexity of integration time also feeding
into that value so it's not that straight forward.
Think about what combination makes sense for light sensor uses...
Gain typically increases noise, integration time decreases it. Otherwise
they both effect the scale. So various options exist:
1) Just provide scale and pick sensible combinations to give low noise
and reasonable integration time for a given scale.
2) Map scale control just to gain, but the values it takes will change
as the integration time is changed.
From an IIO ABI point of view either is fine.
>
> 1) Does using sysfs entries will be fine or there is better alternative.
>
> static IIO_DEVICE_ATTR_WO(gain, 0);
> static IIO_DEVICE_ATTR_WO(threshold, 0);
> static IIO_DEVICE_ATTR_WO(persistence, 0);
> static IIO_CONST_ATTR(persistence_available, "1 2 4 8");
> static IIO_CONST_ATTR(gain_available, "0.125 0.25 1 2");
>
> static struct attribute *veml6030_attributes[] = {
> &iio_const_attr_gain.dev_attr.attr,
> &iio_const_attr_threshold.dev_attr.attr,
> &iio_const_attr_persistence.dev_attr.attr,
> &iio_const_attr_persistence_available.dev_attr.attr,
> NULL
> };
If we do need to define things for a particular device that aren't
generic enough to add to the main ABI then this approach is one
option. However, it makes them only available to userspace. May
be fine for this sort of device, but in general the use of
iio_chan_spec_ext_info is preferred. Here however, I think the
examples all map to existing ABI.
>
> 2) Can IIO_CHAN_INFO_HARDWAREGAIN can be used for gain instead of
> custom sysfs file.
>
> Datasheet: https://www.vishay.com/docs/84366/veml6030.pdf
Nope. Hardware gain is normally used for things like time of
flight sensors, where it is changing the gain of something that
is only indirectly connected to the thing being measured. In those
cases it lets them measure at larger distances but doesn't make
any difference as long as the measurement is successful.
>
> Regards,
> Rishi
Thanks,
Jonathan
prev parent reply other threads:[~2019-09-07 10:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 16:33 Custom sysfs entries for persistence, gain & threshold in light sensor rishi gupta
2019-09-07 10:49 ` 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=20190907114919.15d8c638@archlinux \
--to=jic23@jic23.retrosnub.co.uk \
--cc=gupt21@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