Message-ID: <181472f0-5c00-4e1d-8f00-1d84b5c54685@gmail.com>
Date: Tue, 6 May 2025 09:03:41 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andreas Klinger <ak@...klinger.de>, Jonathan Cameron <jic23@...nel.org>
Cc: 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

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?

> - 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?

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

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


Yours,
	-- Matti

Powered by blists - more mailing lists