[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VdQyRrzYdTe5ak0Fyj2xDT2UVTwDMf+u9Y_6Hv-qMaPJw@mail.gmail.com>
Date: Tue, 1 Feb 2022 11:20:35 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Peter Rosin <peda@...ntia.se>
Cc: Liam Beguin <liambeguin@...il.com>,
Jonathan Cameron <jic23@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-iio <linux-iio@...r.kernel.org>,
devicetree <devicetree@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v13 06/11] iio: afe: rescale: make use of units.h
On Tue, Feb 1, 2022 at 3:59 AM Peter Rosin <peda@...ntia.se> wrote:
> On 2022-01-31 16:23, Andy Shevchenko wrote:
> > On Mon, Jan 31, 2022 at 4:50 PM Peter Rosin <peda@...ntia.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
Powered by blists - more mailing lists