[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250118121629.7c3028f6@jic23-huawei>
Date: Sat, 18 Jan 2025 12:16:29 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Javier Carrasco <javier.carrasco.cruz@...il.com>, Lars-Peter Clausen
<lars@...afoo.de>, Rishi Gupta <gupt21@...il.com>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, Jonathan Cameron
<Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH 2/2] iio: light: veml6030: fix scale to conform to ABI
On Tue, 14 Jan 2025 16:26:16 +0200
Matti Vaittinen <mazziesaccount@...il.com> wrote:
> On 14/01/2025 15:02, Javier Carrasco wrote:
> > On Tue Jan 14, 2025 at 7:43 AM CET, Matti Vaittinen wrote:
> > ...
> >>> I will give you a simple example, so you can tell me where my reasoning
> >>> fails:
> >>>
> >>> raw = 100 counts
> >>> scale = 2.1504 lux/count (when IT=25ms and GAIN=1/8)
> >>> processed = 215.04 lux (raw * scale, ABI compliant for IIO_LIGHT)
> >>
> >> Your reasoning does not fail. But, the scale = 1 / (N * total_gain),
> >> right? (N here depends on how we choose the scale/gain values) Here,
> >> the total_gain means the effect of both the hardware_gain and the
> >> integration time.
> >>
> >> Hence,
> >> processed = X * (raw * scale)
> >>
> >> => processed = X * (raw * (1 / (N * total_gain))
> >> => processed = X * raw / (N * total_gain);
> >>
> >> Hence I thought you might be able to get rid of this 64bit division by
> >> using the total_gain from the iio_gts_get_total_gain() instead of
> >> using the scale. Or, am I missing something?
> >>
> >
> > I am not sure by X you mean the maximum resolution, but if that is the
> > case, the following would work (pseudo-code):
>
> Yes. X denoted the value by which the count needs to be multiplied to
> get the lux (when total gain "in the terms of gts" is x1. I think in
> this particular case the "gain is x1" is a bit confusing as it appears
> this really means the hardware gain is 1/8, right?). Anyways, lux/count
> it is, so in short - yes. :)
>
> >
> > /* Maximum resolution (2.1504 lux/count) * 10000 */
> > #define VEML6030_MAX_RES 21504
> >
> > total_gain = iio_gts_get_total_gain();
> > processed_int = raw * VEML6030_MAX_RES / total_gain / 10000;
>
> Yes. This is what I was thinking of.
>
> > processed_micro = ((raw * VEML6030_MAX_RES / total_gain) % 10000) * 100;
>
> gah. I didn't consider representing the micro portion. Staring this
> makes me feel dizzy :) Well, it looks correct, and I guess the precision
> is not lost by the division(?) But yes, you did perfectly get what I was
> after!
>
> Jonathan, do you think I am just guiding Javier to make a mess? :)
This is an area you've thought about a lot more than me.
Whether it is worth avoiding the 64 bit maths is an interesting question
and I guess depends where this part is typically showing up.
Jonathan
>
> If not, then this might be the way to go.
>
> Yours,
> -- Matti
Powered by blists - more mailing lists