Re: [PATCH v2 5/6] iio: light: ROHM BU27034 Ambient Light Sensor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/12/23 17:36, Jonathan Cameron wrote:
On Sun, 5 Mar 2023 14:22:51 +0200
Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:

On 3/4/23 22:17, Jonathan Cameron wrote:
On Thu, 2 Mar 2023 12:58:59 +0200
Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:

// snip

+static const struct iio_chan_spec bu27034_channels[] = {
+	{
+		.type = IIO_LIGHT,
+		.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |
+				      BIT(IIO_CHAN_INFO_SCALE),

What is this scale for?

The scale is to inform users that we return data using milli lux.

Given the channel is computed from various different inputs, is there a
clear definition of how it is scaled?  What does a write to it mean?

Nothing. writing anything else but milli lux scale fails with -EINVAL.

I guess I am doing something in an unusual way here :) Do you have a
suggestion for me?

Return data in lux?

That's what I did originally have. But then I noticed we can get slightly better accuracy than that. Hence I switched to mLux and added the scale.

 Or return it as INFO_RAW - thus making it clear
that the reading is not in expected units and a conversion must be
applied by userspace.  SCALE is not applied to PROCESSED by userspace.

Ah. This makes sense then. Maybe it would be worth adding a warning to IIO-core if drivers set both the SCALE and PROCESSED info bits?

So, I need to select between the simplicity or better accuracy here? :/ I really hate ending up making choices like this without knowing all the real use-cases :( And it happens a lot for me. Well, I guess I'll drop the scale, use luxes and go with the PROCESSED data. My understanding is that the "thing" with the sensor is a wide-range for wavelengths, not the accuracy. So, maybe luxes are just good enough - and again, users needing something more accurate can utilize the raw intensity channels.


In the rare case where you do get SCALE and PROCESSED it's there to allow
for changes in the underlying signal measurement that are eaten up in the
computation needed to get to PROCESSED - that is they have no visible
affect (beyond range changes etc).

Oh, Ok. So there is a valid case for setting both SCALE and PROCESSED. Then we can't add teh warning I assume :(


Yours,
	-- Matti

--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux