Re: [RFC PATCH v3 3/9] power: supply: Support DT originated temperature-capacity tables

[Vaittinen, Matti]

On 11/30/21 03:34, Linus Walleij wrote:
> Hi Matti,
> 
> not so much time so trying to answer the central question here!
> 
> On Sun, Nov 28, 2021 at 9:51 AM Vaittinen, Matti
> <Matti.Vaittinen@xxxxxxxxxxxxxxxxx> wrote:
> 
>> I am pretty
>> sure the current power-supply framework allows us to expose the current
>> full_cap to userlans - so building your Tesla example with the star
>> should be doable - if the drivers can somehow get the information about
>> the absolute capacity drop.
> 
> To do this we would need to export a capacity at current temperature
> and capacity at nominal temperature (which is usually 25 deg C)
> so you can scale to something.

Hmm. I wonder if we need this. Perhaps the existing:
CHARGE_FULL_DESIGN, CHARGE_EMPTY_DESIGN 

   design charge values, when battery considered full/empty. 

 

ENERGY_FULL_DESIGN, ENERGY_EMPTY_DESIGN 

   same as above but for energy. 

 

CHARGE_FULL, CHARGE_EMPTY 

   These attributes means "last remembered value of charge when battery 

   became full/empty". It also could mean "value of charge when battery 

   considered full/empty at given conditions (temperature, age)". 

   I.e. these attributes represents real thresholds, not design values.

are enough? I am unsure the user is interested in knowing which part of 
the lost battery cap is caused by the temperature, and which is caused 
by some other phenomena. Or, do you think that showing loss of "not 
recoverable" capacity loss (like loss caused by aging) is something that 
should not be displayed...? (It'd be nice to see that when buying the 
second-hand Tesla - and that would for sure be a subject to 
'reprogramming'... :rolleyes:)

> This isn't in sysfs today but we could
> probably add it (and then the world of UI:s battery icons need to change
> in response).

Yes. I'd really like the userland displaying the difference of the 
designed-charge and full-charge already now. I could almost consider 
sending a patch if:

a) I could draw icons / design UIs - which I really can't
b) I knew which userland software to patch...

> 
>>> Then the question is: is the method used by Rohm universal and
>>> well-known and something many chargers will do exactly this
>>> way, so it should be in the core, or is it a particularity that should
>>> be in your driver?
>>
>> I am not sure this is the correct question. I'd rephrase it to: Would it
>> be beneficial for drivers to come if the core did support this
>> functionality - or is the feature unnecessary, or are there better
>> alternatives. If core does not provide the support - then it is a high
>> mountain for one to climb if he wants to use such improvement.
> 
> I think we need this.
> 
>> I think that the agreement we can do is that the OCV+temperature => SOC
>> tables do not provide quite same information as the suggested
>> temperature => capacity-drop tables would. Whether there are better
>> alternatives - or if this is generally useful remains to be discussed -
>> and this is something where I _do_ appreciate your (and everyone else's)
>> input!
> 
> temperature + OCV => SOC isn't enough I think.
> 
> We probably need something to tell us what the total usable
> capacity will be under different temperatures. I suspect an
> interpolated table is best though, this is going to be quite
> nonlinear in practice.

Hmm. Fair enough. Maybe instead of providing 'temperature range where 
degradation is constant' we should simply support providing the 
data-points. Eg, an array of known 
temperature-[degradation/change]-from-[designed/full]-capacity pairs and 
leave selecting the best fitting model to the software. Linear 
interpolation is simple, and may suffice for cases where we have enough 
of data-points - but you are correct that there probably are better 
alternatives. Nice thing is software is that it can be changed over time 
- so even implementing it with linear approach means opening a room for 
further improvements ;)

Well, I don't know how constant such degradation is over time. I just 
guess it is not constant but might be proportional to age-compensated 
capacity rather than the designed capacity. It'd be nice to use correct 
approximation of reality in device-tree... So, perhaps the data-points 
should not be absolute uAh values but values relative to age-corrected 
battery capacity (or if age correction is not available, then values 
relative to the designed capacity).

Sigh, so many things to improve, so little time :)

By the way, I was reading the ab8500 fuel-gauge driver as you suggested. 
So, if I am correct, you used the battery internal resistance + current 
to compute the voltage-drop caused by battery internal resistance. This 
for sure improves the accuracy when we assume VBAT can be used as OCV.

Epilogue:
In general, I see bunch of power-supply drivers scheduling work for 
running some battery-measurements. Some do this periodically (I think 
the ab8500 did this although I lost the track when I tried to see in 
which case the periodic work was not scheduled - and maybe for 
fuel-gauging) or after an IRQ is triggered (for example to see if change 
indication should be sent).

I think we could simplify a few drivers if the core provided some helper 
thread (like the simple-gauge) which could be woken by drivers (to do 
fuel-gauge operations, or to just conditionally send the change 
notification).

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