linux-kernel - Re: [PATCH 2/2] iio: light: Add APDS9160 ALS & Proximity sensor driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z1MkUcNPXmRpWD3A@uva.nl>
Date: Fri, 6 Dec 2024 11:20:33 -0500
From: Mikael Gonella-Bolduc <mgonellabolduc@...onoff.com>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
	Mikael Gonella-Bolduc via B4 Relay <devnull+mgonellabolduc.dimonoff.com@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Mikael Gonella-Bolduc <m.gonella.bolduc@...il.com>,
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
	Hugo Villeneuve <hvilleneuve@...onoff.com>
Subject: Re: [PATCH 2/2] iio: light: Add APDS9160 ALS & Proximity sensor
 driver

On Thu, Dec 05, 2024 at 11:42:21AM +0200, Matti Vaittinen wrote:
> On 02/12/2024 10:22, Matti Vaittinen wrote:
> > Hi Jonathan & Mikael,
> > 
> > On 01/12/2024 15:20, Jonathan Cameron wrote:
> > > 
> > > > > > +};
> > > > > > +MODULE_DEVICE_TABLE(of, apds9160_of_match);
> > > > > > +
> > > > > > +static struct i2c_driver apds9160_driver = {
> > > > > > +    .driver      = {
> > > > > > +        .name    = APDS9160_DRIVER_NAME,
> > > > > > +        .owner = THIS_MODULE,
> > > > > > +        .of_match_table = apds9160_of_match,
> > > > > > +    },
> > > > > > +    .probe    = apds9160_probe,
> > > > > > +    .remove      = apds9160_remove,
> > > > > > +    .id_table = apds9160_id,
> > > > > > +};
> > > > First, regarding the integration time/gain/scale parameters. I
> > > > took a look at the datasheet again as there is a table
> > > > provided to get lux/count (scale?) for the ALS sensor depending
> > > > on gain and integration time.
> > > > 
> > > > It looks like the correlation in the table is almost linear but
> > > > it's not as there is a loss of precision.
> > > > For example, at 1x gain with integration time 100ms the
> > > > lux/count is 0.819 but at 3x the table is stating 0.269 instead
> > > > of exepected 0.273.
> > > > 
> > > > Is it still possible to use the gts helpers in that case?
> > > 
> > > Ah. Probably not if it goes non linear.  Matti? (+CC)
> > 
> > Disclaimer - I didn't go through the patch and I just respond from the
> > top of my head :) So, please take my words with a pinch of salt.
> > 
> > AFAIR, it is not required that the impact of integration time is
> > _linear_ through the range. The "multiplication factor" can be set for
> > each integration time separately. So, it is perfectly Ok to say:
> > 
> > time 1 => multiply by 1
> > time 2 => multiply by 2
> > time 10 => multiply by 9 <= not linear, as linear would be 10.
> > time 15 => multiply by 15
> > 
> > ...
> > 
> > The notable limitation of _current_ implementation is that the
> > "multiplication factor" needs to be integer. So, this may result loss of
> > accuracy.
> 
> // Snip.
> 
> I ended up re-reading this mail as a result of running some of my
> public-inbox scripts...
> 
> ...and I noticed that the non linear correlation was not about integration
> time, but about gain. Eg, if I now read you right, the integration time is
> kept constant 100mS, and gain is changed from 1x => 3x, which actually did
> not bring 3x gain to the lux/count values.
> 
> If this is the case, then the GTS helpers aren't likely to help you much.
> Sorry.
> 
> 
> Yours,
> 	-- Matti

Hi,

Thank you for the feedback.
The datasheet is not very clear on why exactly the correlation is almost linear.
I assume it is probably to compensate for some inaccuracies and that's why they
provide the table instead of a linear formula.

I took the approach to let the user control the integration time and I ajust
the available scales depending on the selected integration time.

I kept the hardware gain read-only, as you suggested, for debugging purposes.

See changes in v2.

Best regards,
Mikael