Hi Jonathan,
hi Matti,

Matti Vaittinen <mazziesaccount@gmail.com> schrieb am Mo, 07. Apr 08:52:
> On 06/04/2025 14:08, Jonathan Cameron wrote:
> > On Sun, 6 Apr 2025 10:43:23 +0200
> > Andreas Klinger <ak@it-klinger.de> wrote:
> > 
> > > Hi Jonathan,
> > > 
> > > I need to pick up the meaning of scale once again for clarification.
> > > 
> > > Jonathan Cameron <jic23@kernel.org> schrieb am Mo, 17. Mär 11:50:
> > > > On Sun, 16 Mar 2025 12:31:30 +0100
> > > > Andreas Klinger <ak@it-klinger.de> wrote:
> > > > > +static int veml6046x00_get_scale(struct veml6046x00_data *data,
> > > > > +				 int *val, int *val2)
> > > > 
> > > > How is this related to integration time?  I'd normally expect
> > > > to see that read in here somewhere as well as doubling integration
> > > > time tends to double scale.
> > > 
> > > In the documentation file "sysfs-bus-iio" it says:
> > > "
> > > What:           /sys/.../iio:deviceX/in_illuminanceY_raw
> > > [...]
> > > Description:
> > >                  Illuminance measurement, units after application of scale
> > >                                  and offset are lux.
> > > "
> > > 
> > > This means that the scale should be the real factor and not the gain multiplied
> > > by photodiode size (PDDIV) as i implemented it so far.
> > > 
> > > This means also that doubling integration time should halve the scale. The
> > > higher raw value should lead to the same lux value.
> > 
> > Sounds correct.
> 
> 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:
- User wants to be able to set up the integration time as well as scale and the
  driver should not optimize it somehow.
- 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'll come up with a version 3 shortly.

Andreas