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

[Mikael Gonella-Bolduc]

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