[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYE1r6mYAJsaMB9XyZjjAK-bGw3-9jhOpUFASWgkXaQBQ@mail.gmail.com>
Date: Thu, 18 Nov 2021 02:57:23 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Cc: Matti Vaittinen <mazziesaccount@...il.com>,
Sebastian Reichel <sre@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Lee Jones <lee.jones@...aro.org>, rostokus@...il.com,
fan.chen@...iatek.com, linux-pm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-power@...rohmeurope.com
Subject: Re: [RFC PATCH v3 1/9] dt-bindings: battery: Add temperature-capacity
degradation table
On Tue, Nov 16, 2021 at 1:24 PM Matti Vaittinen
<matti.vaittinen@...rohmeurope.com> wrote:
> Some charger/battery vendors describe the temperature impact to
> battery capacity by providing tables with capacity change at
> given temperature. Support providing this temperature - capacity
> dependency using the simple-battery DT nodes.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Since we already support providing the capacity at different
temperatures using ocv-capacity-celsius and the array of
arrays ocv-capacity-table-0, 1, 2... you are introducing a
second parallel method of describing how capacity changes
in accordance with temperature, right?
What do you expect to happen if someone specifies both?
If this is an either/or situation then the schema has to
guarantee the exclusiveness for each.
(I would probably just use the formula you have to calculate
a few tables using the existing method but that's just me.)
Yours,
Linus Walleij
Powered by blists - more mailing lists