Hi deee Ho peeps!

On 11/18/21 03:57, Linus Walleij wrote:

On Tue, Nov 16, 2021 at 1:24 PM Matti Vaittinen
[off-list ref] wrote:

quoted

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 <redacted>

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 ~~