Message-ID: <aBnINvJ0aS69kUI8@mail.your-server.de>
Date: Tue, 6 May 2025 10:28:38 +0200
From: Andreas Klinger <ak@...klinger.de>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>, robh@...nel.org,
	krzk+dt@...nel.org, conor+dt@...nel.org, lars@...afoo.de,
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, javier.carrasco.cruz@...il.com,
	subhajit.ghosh@...aklogic.com, muditsharma.info@...il.com,
	arthur.becker@...tec.com, ivan.orlov0322@...il.com
Subject: Re: [PATCH 2/3] iio: light: add support for veml6046x00 RGBIR color
 sensor

Hi Matti,

Matti Vaittinen <mazziesaccount@...il.com> schrieb am Di, 06. Mai 09:03:
> On 05/05/2025 22:10, Andreas Klinger wrote:
> > > 
> > > I was CC'd due to the GTS (gain-time-scale)-helpers. The above is the beef
> > > of those helpers - which, attempt to aid drivers to convert the impact of
> > > the hardware gain + integration time into a single scale value. This
> > > approach has some caveats, but the goal is to fulfill the expectations of
> > > those user-space apps which expect only scale to change the gain, while also
> > > need to have the integration time controllable (for example to reduce the
> > > measurement time for one reason or another).
> > > 
> > > Problem is that, especially when there are multiple channels with separate
> > > gain control but common integration time, there will be some situations
> > > where the integration time change _will_ cause changes to "total gain (E.g.
> > > scale)" too. There may also be cases where some scale values can be met only
> > > with certain integration times, or where a scale for a channel can't be met
> > > maintaining the scale for other channels etc.
> > > 
> > > All in all, I am not sure if the 'unchangeable hardware gain' approach makes
> > > things as simple as possible - but as long as we want to have it, the GTS
> > > helpers may be of use :) There are couple of drivers using them - feel free
> > > to take a look. "git grep gts_ drivers/iio/light/" should point you the
> > > current users.
> > > 
> > 
> > Thanks a lot for illustrating and explaining the GTS. I implemented the driver
> > with GTS and by this learned a lot about it. But at the end i found it in my
> > case to be simpler to implement it without GTS for some reasons:
> 
> Firstly, it's perfectly Ok to choose to not to use the GTS helpers. Yet, I
> would like to understand couple of things.
> 
> > - User wants to be able to set up the integration time as well as scale and the
> >    driver should not optimize it somehow.
> 
> How does using GTS to do the conversion from
> HWGAIN + time => scale
> cause optimization? Or, do you just mean that part of the functionality
> provided by these helpers wouldn't be applicable, while the conversion could
> still be done?

This functionality is not applicable. The user wants to set up the time and gain
manually. There are applications in which the driver should be fast with a lower
integration time and others in which the best accurate result is required. As
i'm developing it for the sensor vendor they want to be able to demonstrate
all the different settings to their customers.

> > - There is not only a relation from the scale to the gain of the sensor but also
> >    to the photodiode size. Because of this i need another helper table asize of
> >    GTS for translating the scale into sensor gain and photodiode size.
> 
> I suppose that using the GTS with gains and times without PD, and then
> computing the impact of the PD size after the GTS conversions would have
> caused the available scales to be wrong, right?

Exactly this caused me most of the headache. With GTS i need to use a "virtual"
scale for the calculation. When user asks for available scales or set up the
desired scale i need to convert it to the real scale and then further translate
it to the register values of gain and PD.

> Couldn't you still have used two different set of gain tables (one for each
> PD size) if you chose to use the GTS?

Of course there are solutions for it and i was about to finish one with GTS as i
saw that the driver will get simpler without. As i cannot use the nice features
of GTS it turns out to use only the data structures and functions on it. But the
data structures don't fit exactly to this sensor as we have gain and PD in two
different regfields. So another table to translate the scale to the regfields is
needed anyway.

> > I'll come up with a version 3 shortly.
> 
> I took a very quick look at the v3 - not one worth a reviewed-by :) And, as
> I wrote, I have nothing against skipping the GTS. I'm not sure the values in
> the multi-dimensional array were clear to me at a glance - but I assume it's
> lean and efficient when one wraps his head around it. 

The large table contains exactly the values from the datasheet for the
conversion of raw measured counts to lux. I only combined the two tables for PD
1/2 and 2/2 as hwgain x0.5 and x1 are existing twice.

> So, I'm not trying to argue you should've used GTS - I just want to understand
> what was the exact issue with it :)

There is not an issue with GTS. In my opinion it's not the simplest solution for
this sensor in this case. I'm quite sure there are other cases in which it makes
a lot of sense to use it and as i'm now a little bit familiar with it i'll be
using it if appropriate.

Best regards,

Andreas


Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)

Powered by blists - more mailing lists