From: Jonathan Cameron <jic23@kernel.org>
To: Andreas Klinger <ak@it-klinger.de>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
lars@metafoo.de, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
javier.carrasco.cruz@gmail.com, mazziesaccount@gmail.com,
subhajit.ghosh@tweaklogic.com, muditsharma.info@gmail.com,
arthur.becker@sentec.com, ivan.orlov0322@gmail.com,
Matti Vaittinen <mazziesaccount@gmail.com>
Subject: Re: [PATCH 2/3] iio: light: add support for veml6046x00 RGBIR color sensor
Date: Sun, 6 Apr 2025 12:08:25 +0100 [thread overview]
Message-ID: <20250406120825.41b2575c@jic23-huawei> (raw)
In-Reply-To: <Z_I-qwzUrTNz1DZp@mail.your-server.de>
On Sun, 6 Apr 2025 10:43:23 +0200
Andreas Klinger <ak@it-klinger.de> wrote:
> Hi Jonathan,
>
> I need to pick up the meaning of scale once again for clarification.
>
> Jonathan Cameron <jic23@kernel.org> schrieb am Mo, 17. Mär 11:50:
> > On Sun, 16 Mar 2025 12:31:30 +0100
> > Andreas Klinger <ak@it-klinger.de> wrote:
> >
> > > +static int veml6046x00_get_scale(struct veml6046x00_data *data,
> > > + int *val, int *val2)
> >
> > How is this related to integration time? I'd normally expect
> > to see that read in here somewhere as well as doubling integration
> > time tends to double scale.
>
> In the documentation file "sysfs-bus-iio" it says:
> "
> What: /sys/.../iio:deviceX/in_illuminanceY_raw
> [...]
> Description:
> Illuminance measurement, units after application of scale
> and offset are lux.
> "
>
> This means that the scale should be the real factor and not the gain multiplied
> by photodiode size (PDDIV) as i implemented it so far.
>
> This means also that doubling integration time should halve the scale. The
> higher raw value should lead to the same lux value.
Sounds correct.
>
> The documentation of the sensor (veml6046x00.pdf) provides us the calculation
> between raw green values and lux.
> Wouldn't it be better to give the user the real factor to be able to get lux?
Absolutely. That's the expectation if we are providing illuminance_raw and
illuminance_scale.
>
> The fact that only the green channel can be used for calculation could be
> documented in the driver.
Ah. One of these devices. Hmm. Why do people pretend they can get from
Green to illuminance. That has to assume 'white light'.
I get grumpy about this, but if it is the best we can do I guess we have
to live with it (I might not be consistent on this).
>
> Then i found the "in_illuminance_hardwaregain" property. It seems that this is
> exactly what the combination of gain and PDDIV is used for.
>
> So what is the scale at the moment could become the hardwaregain and the scale
> the factor from raw value to lux.
If it is useful to export it separately that works, however it's not typically
the control attribute - those tend to be read only because, without access to
datasheets simple software has no idea how to control them.
The alternative is the GTS helpers that attempt to figure out the best
way to meet the user requirements in setting the integration time and amplifier
gain when a scale is requested.
+CC Matti who is the expert on those.
>
>
> To sum up the suggested interface under /sys/bus/iio/devices/iio\:deviceX would
> be something like:
>
> in_illuminance_hardwaregain --> set and get gain and PDDIV on the sensor
This is usually the read only one as it reflects things that aren't
easy for a userspace program / user to tune. They typically want to control
integration time because it reflects noise level and scale because they want
to avoid saturation etc and because we need it to get to the actual value
in lux.
>
> integration_time --> set and get integration time on the sensor
driving these directly is fine.
>
> integration_time_available --> show available integration time values
>
> scale --> (only) get real calculation value, taken from
> sensor documenation, e.g. 1.3440
This should remain a main control attribute.
>
> scale_available --> not existing anymore
This gets tricky but the GTS helpers will calculate it for you I think.
Jonathan
>
>
> What do you think?
>
> Andreas
>
next prev parent reply other threads:[~2025-04-06 11:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-16 11:31 [PATCH 0/3] iio:light: add driver for veml6046x00 RGBIR color sensor Andreas Klinger
2025-03-16 11:31 ` [PATCH 1/3] dt-bindings: iio: light: veml6046x00: add " Andreas Klinger
2025-03-16 12:19 ` Rob Herring (Arm)
2025-03-17 11:00 ` Jonathan Cameron
2025-03-17 11:17 ` Andreas Klinger
2025-03-17 11:26 ` Krzysztof Kozlowski
2025-03-16 11:31 ` [PATCH 2/3] iio: light: add support for veml6046x00 RGBIR " Andreas Klinger
2025-03-17 11:50 ` Jonathan Cameron
2025-03-18 2:15 ` Andreas Klinger
2025-03-23 11:51 ` Jonathan Cameron
2025-04-06 8:43 ` Andreas Klinger
2025-04-06 11:08 ` Jonathan Cameron [this message]
2025-04-07 5:52 ` Matti Vaittinen
2025-05-05 19:10 ` Andreas Klinger
2025-05-06 6:03 ` Matti Vaittinen
2025-05-06 8:28 ` Andreas Klinger
2025-05-06 9:17 ` Matti Vaittinen
2025-03-16 11:31 ` [PATCH 3/3] MAINTAINER: add maintainer for veml6046x00 Andreas Klinger
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=20250406120825.41b2575c@jic23-huawei \
--to=jic23@kernel.org \
--cc=ak@it-klinger.de \
--cc=arthur.becker@sentec.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ivan.orlov0322@gmail.com \
--cc=javier.carrasco.cruz@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mazziesaccount@gmail.com \
--cc=muditsharma.info@gmail.com \
--cc=robh@kernel.org \
--cc=subhajit.ghosh@tweaklogic.com \
/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).