Re: [PATCH v13 06/11] iio: afe: rescale: make use of units.h

From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Peter Rosin <peda@axentia.se>
Cc: Liam Beguin <liambeguin@gmail.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v13 06/11] iio: afe: rescale: make use of units.h
Date: Tue, 1 Feb 2022 11:20:35 +0200	[thread overview]
Message-ID: <CAHp75VdQyRrzYdTe5ak0Fyj2xDT2UVTwDMf+u9Y_6Hv-qMaPJw@mail.gmail.com> (raw)
In-Reply-To: <d9f3032c-539e-800f-289c-14971b7e3b15@axentia.se>

On Tue, Feb 1, 2022 at 3:59 AM Peter Rosin <peda@axentia.se> wrote:
> On 2022-01-31 16:23, Andy Shevchenko wrote:
> > On Mon, Jan 31, 2022 at 4:50 PM Peter Rosin <peda@axentia.se> wrote:
> >> On 2022-01-30 17:10, Liam Beguin wrote:
> >
> > ...
> >
> >>> -             tmp = div_s64_rem(tmp, 1000000000LL, &rem);
> >>> +             tmp = div_s64_rem(tmp, GIGA, &rem);
> >>
> >> It is NOT easy for me to say which of GIGA/NANO is most fitting.
> >
> > What do you mean? The idea behind is the use of the macro depending on
> > the actual power of 10 in use (taking into account the sign of the
> > exponent part).
> >
> >> There are a couple of considerations:
> >>
> >> A) 1000000000 is just a big value (GIGA fits). Something big is
> >>    needed to not lose too much precision.
> >
> > Does it have a physical meaning?
>
> No, this is just a scaling factor which is moments later
> eliminted by a matching inverse operation. It's math purely
> about attempting to preserve precision and has nothing to do
> with the units of the values that are involved.

I see your point now, shame on me.

-- 
With Best Regards,
Andy Shevchenko