From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Matti Vaittinen <mazziesaccount@gmail.com>,
Sebastian Reichel <sre@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Lee Jones <lee.jones@linaro.org>,
"rostokus@gmail.com" <rostokus@gmail.com>,
"fan.chen@mediatek.com" <fan.chen@mediatek.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-power <linux-power@fi.rohmeurope.com>
Subject: Re: [RFC PATCH v3 1/9] dt-bindings: battery: Add temperature-capacity degradation table
Date: Thu, 18 Nov 2021 05:27:13 +0000 [thread overview]
Message-ID: <16489e77-4cfd-4185-1a7c-4a3fc41dd290@fi.rohmeurope.com> (raw)
In-Reply-To: <CACRpkdYE1r6mYAJsaMB9XyZjjAK-bGw3-9jhOpUFASWgkXaQBQ@mail.gmail.com>
Hi deee Ho peeps!
On 11/18/21 03:57, Linus Walleij wrote:
> On Tue, Nov 16, 2021 at 1:24 PM Matti Vaittinen
> <matti.vaittinen@fi.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@fi.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?
Oh, right. This is why sending out RFCs at early stage can be beneficial :)
The way I have seen OCV-CAP and TEMP-CAP 'dependencies' modelled has
been that the OCV-CAP is defined only in one temperature (say, 25 C).
The impact of the temperature has then been estimated by storing values
which reflect the delta CAP when temperature changes from this 'nominal
temperature'. Hence it never even crossed my mind that the temperature
impact to CAP should actually be modelled in OCV tables.
> What do you expect to happen if someone specifies both?
Right. I see this now. The current implementation would indeed apply the
temperature impact twice. I didn't even think of this as we have only
provided the OCV-CAP for one temperature.
> 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.)
I need to try to find out how the temperature-degradation is really used
in setups which use our chargers (sigh. this is always the hard part for
me) and see if we can replace the temp-degradation table by several
OCV-CAP tables for different temperatures. I am afraid we may lack the
OCV information for different temperatures - but I'll see. I'd rather
not add overlapping properties.
Anyways - Thanks a lot Linus for giving me another view on this :)
You're really helpful.
Best Regards
--Matti
--
The Linux Kernel guy at ROHM Semiconductors
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~ this year is the year of a signature writers block ~~
next prev parent reply other threads:[~2021-11-18 5:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 12:24 [RFC PATCH v3 0/9] power: supply: Add some fuel-gauge logic Matti Vaittinen
2021-11-16 12:24 ` [RFC PATCH v3 1/9] dt-bindings: battery: Add temperature-capacity degradation table Matti Vaittinen
2021-11-16 14:02 ` Rob Herring
2021-11-18 1:57 ` Linus Walleij
2021-11-18 5:27 ` Vaittinen, Matti [this message]
2021-11-16 12:25 ` [RFC PATCH v3 2/9] power: supply: add cap2ocv batinfo helper Matti Vaittinen
2021-11-18 2:02 ` Linus Walleij
2021-11-18 5:30 ` Vaittinen, Matti
2021-11-16 12:25 ` [RFC PATCH v3 3/9] power: supply: Support DT originated temperature-capacity tables Matti Vaittinen
2021-11-18 2:10 ` Linus Walleij
2021-11-18 6:11 ` Vaittinen, Matti
2021-11-26 11:56 ` Vaittinen, Matti
2021-11-26 12:35 ` Matti Vaittinen
2021-11-27 0:55 ` Linus Walleij
2021-11-27 0:54 ` Linus Walleij
2021-11-28 8:51 ` Vaittinen, Matti
2021-11-30 1:34 ` Linus Walleij
2021-11-30 6:33 ` Vaittinen, Matti
2021-12-02 1:57 ` Linus Walleij
2021-12-02 6:29 ` Vaittinen, Matti
2021-12-05 0:30 ` Linus Walleij
2021-11-16 12:26 ` [RFC PATCH v3 4/9] power: supply: Add batinfo getters usable prior supply registration Matti Vaittinen
2021-11-19 1:42 ` Linus Walleij
2021-11-16 12:27 ` [RFC PATCH v3 5/9] power: supply: Add constant battery aging degradation to batinfo Matti Vaittinen
2021-11-16 12:27 ` [RFC PATCH v3 6/9] power: supply: Add batinfo functions for OCV to SOC with 0.1% accuracy Matti Vaittinen
2021-11-19 1:49 ` Linus Walleij
2021-11-19 8:11 ` Matti Vaittinen
2021-11-16 12:28 ` [RFC PATCH v3 7/9] power: supply: add simple-gauge for SOC estimation and CC correction Matti Vaittinen
2021-11-19 1:54 ` Linus Walleij
2021-11-16 12:29 ` [RFC PATCH v3 8/9] mfd: bd71828, bd71815 prepare for power-supply support Matti Vaittinen
2021-11-16 12:29 ` [RFC PATCH v3 9/9] power: supply: Add bd718(15/27/28/78) charger driver Matti Vaittinen
2021-11-17 2:06 ` kernel test robot
2021-11-17 10:10 ` kernel test robot
2021-11-18 13:10 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16489e77-4cfd-4185-1a7c-4a3fc41dd290@fi.rohmeurope.com \
--to=matti.vaittinen@fi.rohmeurope.com \
--cc=devicetree@vger.kernel.org \
--cc=fan.chen@mediatek.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-power@fi.rohmeurope.com \
--cc=mazziesaccount@gmail.com \
--cc=robh+dt@kernel.org \
--cc=rostokus@gmail.com \
--cc=sre@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.