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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7194cce7-5082-4df5-8599-186c2e39c599@gmail.com>
Date: Thu, 5 Dec 2024 11:42:21 +0200
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Jonathan Cameron <jic23@...nel.org>,
 Mikael Gonella-Bolduc <mgonellabolduc@...onoff.com>
Cc: 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 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