mbox series

[RFC,v3,0/9] power: supply: Add some fuel-gauge logic

Message ID cover.1637061794.git.matti.vaittinen@fi.rohmeurope.com
Headers show
Series power: supply: Add some fuel-gauge logic | expand

Message

Matti Vaittinen Nov. 16, 2021, 12:24 p.m. UTC
As usual, I picked you as recipients just because I assumed
you could have something to say in here. Again, please let me know
if you wish to be dropped from CC if this gets any further.

power: supply: add simple-gauge for SOC estimation and CC correction

This RFC has received some testing under qemu, with recorded
battery-data and a dummy MFD driver converting the battery-data to
register-values for BD71815 PMIC driver. The testing has not really
covered a lot though. Some tests are also ran on a BeagleBoneBlack
connected to a real PMIC hwrdware - but unfortunately without a real
battery. So - this is still not tested too well.

Regarding the purpose of this RFC:

Patches 1 - 6
I hope that the patches which change the power-supply class for static
battery node information  could be properly reviewed and perhaps even
considered to be merged upstream. It'd be great if someone had the time
to test those in real HW to ensure existing stuff is not borked.
Especially the patches 4 and 6 might be of interest.

The patch 7:
This adds some simple fuel-gauge logic in kernel. I think this is
getting it's shape - but may have few hiccups left - and could benefit
from suggestions how to run the gauge thread. A few downstream setups do
use separate ROHM drivers for BD71815, BD71817, BD71827, BD71828 and
BD71879 which all contain similar fuel-gauge logic to what is implented
in simple-gauge. They poll the PMIC and compute the temperature/capacity
and zero-corrected "state of charge" and report that to the user-space.
Additionally those drivers 'calibrate' the CC based on OCV when battery
is relaxed - or when battery is fully charged. The patch 7 attempts to
make this logic generic and allows IC drivers to fill the IC specific
operations.

It is fair to say that I don't know the user-space software which is
utilizing the existing drivers - or why the SoC computation is
originally placed in-kernel. I can only assume the existing IC users
might have a bit wider smile if the SOC was reported by the kernel also
in the future.

Patches 8 and 9:
The patches 8 and 9 bring in IC level support for ROHM BD71815 and BD71828
PMIC charger IPs. It is also fairly trivial to extend the support to
ND71827 and BD71879 later. The state of these patches is not final yet,
I don't expect them to be thoroughly reviewed yet. They are provided to
give some more context.

Changelog RFC v3:
  - rename sw-gauge to simple-gauge
  batinfo:
     - kerneldoc fixes
     - add batinfo getters usable prior supply registration
     - Add constant battery aging degradation to batinfo
  simple-gauge:
      - use devm_add_action_or_reset
      - Rename to simple_gauge
      - Limit access to power_supply parameters
      - Introduce simple_gauge_drvdata
      - no need to show simple_gauge at config menu. Users should just SELECT it.
      - allow tristate
      - Add blocking 'iteration run' - loop.
      - updated the comment section
      - Fixed clamped SOC which was not updated
      - Small comment improvements
      - Don't allow negative CC after computing capacity corrections
      - Fix gauge looping when last client exits
 ROHM ic-drivers:
      - Updated BD71815 IRQ information
      - adapt to simple_gauge parameter changes
      - Initial BD71815 support
      - Use drvdata properly.
      - Sort includes
      - Prepare to provide dcin_collapse voltage from DT
      - clean unused defines
      - use OCV tables from batinfo if module params not given
      - do not directly call bd71827_voltage_to_capacity from calibration
        but use provided operation.
      - Mask the power-state from relax-condition on BD71815 as is done by
        the ROHM driver. REX state is used to do OCV => SOC conversion
        when battery is relaxed even if REX_CC was not used.
      - Clarify that we require either the module params or DT values for
        battery. Fail probe if parameters are not given.
      - Utilize degrade_cycle_uah aging degradation.
      - Get battery max and min values either as module parameters or from
        static battery node at DT.
      - Allow giving the zero correction threshold as a module param or
        compute it as 10% of "remaining battery voltage" based on max and
        min voltages given via DT.
      - Add proper MODULE_ALIAS
      - Implement VDR table reading from DT
      - Do not require fixed amount of battery parameters
      - Fix Coulomb Counter to uAh conversion
      - Fix endianess related warnings
      - clean-up comment
      - Avoid dividing by zero at VDR computation
      - Use the fwnode API instead of of_* API
      . don't assume 32bit int
      - Fix IC type prints
      - Fix the current sense resistor DT property *-ohm => *-ohms

Changelog RFC v2:
 - lots of logic fixes.
 - rechecked units
 - changed low-voltage correction to capacity correction
 - added first draft of IC driver which could use the swgauge

---

Matti Vaittinen (9):
  dt-bindings: battery: Add temperature-capacity degradation table
  power: supply: add cap2ocv batinfo helper
  power: supply: Support DT originated temperature-capacity tables
  power: supply: Add batinfo getters usable prior supply registration
  power: supply: Add constant battery aging degradation to batinfo
  power: supply: Add batinfo functions for OCV to SOC with 0.1% accuracy
  power: supply: add simple-gauge for SOC estimation and CC correction
  mfd: bd71828, bd71815 prepare for power-supply support
  power: supply: Add bd718(15/27/28/78) charger driver

 .../bindings/power/supply/battery.yaml        |   19 +
 drivers/mfd/rohm-bd71828.c                    |   42 +-
 drivers/power/supply/Kconfig                  |   14 +
 drivers/power/supply/Makefile                 |    2 +
 drivers/power/supply/bd71827-power.c          | 2473 +++++++++++++++++
 drivers/power/supply/power_supply_core.c      |  449 ++-
 drivers/power/supply/simple-gauge.c           | 1303 +++++++++
 include/linux/mfd/rohm-bd71827.h              |  295 ++
 include/linux/mfd/rohm-bd71828.h              |   65 +
 include/linux/mfd/rohm-generic.h              |    2 +
 include/linux/power/simple_gauge.h            |  244 ++
 include/linux/power_supply.h                  |   41 +
 12 files changed, 4843 insertions(+), 106 deletions(-)
 create mode 100644 drivers/power/supply/bd71827-power.c
 create mode 100644 drivers/power/supply/simple-gauge.c
 create mode 100644 include/linux/mfd/rohm-bd71827.h
 create mode 100644 include/linux/power/simple_gauge.h

Comments

Linus Walleij Nov. 18, 2021, 2:02 a.m. UTC | #1
On Tue, Nov 16, 2021 at 1:25 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> The power-supply core supports concept of OCV (Open Circuit Voltage) =>
> SOC (State Of Charge) conversion tables. Usually these tables are used
> to estimate SOC based on OCV. Some systems use so called "Zero Adjust"
> where at the near end-of-battery condition the SOC from coulomb counter
> is used to retrieve the OCV - and OCV and VSYS difference is used to
> re-estimate the battery capacity.
>
> Add helper to do look-up the other-way around and also get the OCV
> based on SOC
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>

It seems you will need this for your chargers indeed.

> +int power_supply_dcap2ocv_simple(struct power_supply_battery_ocv_table *table,
> +                               int table_len, int dcap)
> +{
> +       int i, ocv, tmp;
> +
> +       for (i = 0; i < table_len; i++)
> +               if (dcap > table[i].capacity * 10)
> +                       break;
> +
> +       if (i > 0 && i < table_len) {
> +               tmp = (table[i - 1].ocv - table[i].ocv) *
> +                     (dcap - table[i].capacity * 10);
> +
> +               tmp /= (table[i - 1].capacity - table[i].capacity) * 10;
> +               ocv = tmp + table[i].ocv;
> +       } else if (i == 0) {
> +               ocv = table[0].ocv;
> +       } else {
> +               ocv = table[table_len - 1].ocv;
> +       }
> +
> +       return ocv;
> +}
> +EXPORT_SYMBOL_GPL(power_supply_dcap2ocv_simple);

Rewrite this using the library fixpoint interpolation function but just
copypasting from my patch:
https://lore.kernel.org/linux-pm/20211116230233.2167104-1-linus.walleij@linaro.org/

Other than that it looks good to me!

Yours,
Linus Walleij
Linus Walleij Nov. 18, 2021, 2:10 a.m. UTC | #2
On Tue, Nov 16, 2021 at 1:26 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> Support obtaining the "capacity degradation by temperature" - tables
> from device-tree to batinfo.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>

Same questions as on the binding patch.

If we already support different degradation by temperature tables,
why do we need a second mechanism for the same thing?

I'd just calculate a few tables per temperature and be done with
it.

At least documentation needs to be updated to reflect that the two methods
are exclusive and you can only use one of them.

+ * Usually temperature impacts on battery capacity. For systems where it is
+ * sufficient to describe capacity change as a series of temperature ranges
+ * where the change is linear (Eg delta cap = temperature_change * constant +
+ * offset) can be described by this structure.

But what chemistry has this property? This seems to not be coming from
the real physical world. I would perhaps accept differential equations
but *linear* battery characteristics?

If the intent is only for emulation of something that doesn't exist in
reality I doubt how useful it is, all battery technologies I have seen
have been nonlinear and hence we have the tables.

If you want to simulate a linear discharge, then just write a few tables
with linear dissipation progression, it's easier I think.

Yours,
Linus Walleij
Matti Vaittinen Nov. 18, 2021, 5:30 a.m. UTC | #3
On 11/18/21 04:02, Linus Walleij wrote:
> On Tue, Nov 16, 2021 at 1:25 PM Matti Vaittinen
> <matti.vaittinen@fi.rohmeurope.com> wrote:
> 
>> The power-supply core supports concept of OCV (Open Circuit Voltage) =>
>> SOC (State Of Charge) conversion tables. Usually these tables are used
>> to estimate SOC based on OCV. Some systems use so called "Zero Adjust"
>> where at the near end-of-battery condition the SOC from coulomb counter
>> is used to retrieve the OCV - and OCV and VSYS difference is used to
>> re-estimate the battery capacity.
>>
>> Add helper to do look-up the other-way around and also get the OCV
>> based on SOC
>>
>> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> 
> It seems you will need this for your chargers indeed.
> 
>> +int power_supply_dcap2ocv_simple(struct power_supply_battery_ocv_table *table,
>> +                               int table_len, int dcap)
>> +{
>> +       int i, ocv, tmp;
>> +
>> +       for (i = 0; i < table_len; i++)
>> +               if (dcap > table[i].capacity * 10)
>> +                       break;
>> +
>> +       if (i > 0 && i < table_len) {
>> +               tmp = (table[i - 1].ocv - table[i].ocv) *
>> +                     (dcap - table[i].capacity * 10);
>> +
>> +               tmp /= (table[i - 1].capacity - table[i].capacity) * 10;
>> +               ocv = tmp + table[i].ocv;
>> +       } else if (i == 0) {
>> +               ocv = table[0].ocv;
>> +       } else {
>> +               ocv = table[table_len - 1].ocv;
>> +       }
>> +
>> +       return ocv;
>> +}
>> +EXPORT_SYMBOL_GPL(power_supply_dcap2ocv_simple);
> 
> Rewrite this using the library fixpoint interpolation function but just
> copypasting from my patch:
> https://lore.kernel.org/linux-pm/20211116230233.2167104-1-linus.walleij@linaro.org/

Thanks :)
I actually saw this (yesterday?) but didn't revise my patches. Thanks 
for the head's up - it's always good to have this kind of helpers :)

> 
> Other than that it looks good to me!

Thanks!

Best Regards
     --Matti
Matti Vaittinen Nov. 18, 2021, 6:11 a.m. UTC | #4
Hi Linus,

On 11/18/21 04:10, Linus Walleij wrote:
> On Tue, Nov 16, 2021 at 1:26 PM Matti Vaittinen
> <matti.vaittinen@fi.rohmeurope.com> wrote:
> 
>> Support obtaining the "capacity degradation by temperature" - tables
>> from device-tree to batinfo.
>>
>> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> 
> Same questions as on the binding patch.
> 
> If we already support different degradation by temperature tables,
> why do we need a second mechanism for the same thing?

Thanks for bringing this up. As I said, I didn't notice that we could 
indeed use the CAP-OCV tables for different temperatures to bring in 
this information :) I see certain benefit from the possibility of not 
requiring to measure the OCV at different temperatures - but it may not 
be meaningful. As I replied to your patch 1/9 review - I need to (try 
to) do some more research...

> I'd just calculate a few tables per temperature and be done with
> it.
> 
> At least documentation needs to be updated to reflect that the two methods
> are exclusive and you can only use one of them.
> 
> + * Usually temperature impacts on battery capacity. For systems where it is
> + * sufficient to describe capacity change as a series of temperature ranges
> + * where the change is linear (Eg delta cap = temperature_change * constant +
> + * offset) can be described by this structure.
> 
> But what chemistry has this property? This seems to not be coming from
> the real physical world. I would perhaps accept differential equations
> but *linear* battery characteristics?

linear *on a given small temperature range*. I think this is improvement 
to situation where we don't do temperature compensation at all. And, by 
shortening the temperature area where CAP change is linear, we can 
approach any non linear behaviour, right? With the current support of 
100 values, you can divide the temperature range to 100 pieces with 
linear CAP degradation impact - I think you get reasonably good 
estimates there even if your device was expected to be operational at 
temperatures where min...max is 100C. (that would allow us to divide the 
range to 1C slots and assume linear degradation at each 1C range. Or 
didvide this unevenly so that the temperature areas where change is more 
constant we could have bigger slots, and at the areas where change is 
faster we could have smaller slots. I don't see linear interpolation as 
such a big problem there?

> If the intent is only for emulation of something that doesn't exist in
> reality I doubt how useful it is, all battery technologies I have seen
> have been nonlinear and hence we have the tables.
> 
> If you want to simulate a linear discharge, then just write a few tables
> with linear dissipation progression, it's easier I think.

"linear dissipation progression" - that should be my next favourite 
sentence to sound professional ;) I need to first google what it is in 
Finnish though XD

Best Regards
	Matti
Linus Walleij Nov. 19, 2021, 1:42 a.m. UTC | #5
On Tue, Nov 16, 2021 at 1:26 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> In some cases it is beneficial to be able to query the static battery
> node properties prior power_supply registration. The device-tree
> parsing does not really depend on psy so add APIs which can
> be used without the power-supply. Also, convert APIs to operate on
> fwnode while at it.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>

This looks quite useful!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
Linus Walleij Nov. 19, 2021, 1:49 a.m. UTC | #6
On Tue, Nov 16, 2021 at 1:27 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> The battery info functions computing the state-of-charge (SOC) based
> on open-circuit-voltage (OCV) are returning SOC using units of 1%.
>
> Some capacity estimation computations require higher accuracy. Add
> functions that return SOC using units of 0.1% to reduce rounding error.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>

That sounds useful.

> +int power_supply_ocv2dcap_simple(struct power_supply_battery_ocv_table *table,
> +                               int table_len, int ocv)
> +{
> +       int i, cap, tmp;

Why a whole new function? Just rename the original power_supply_ocv2cap_simple()
to power_supply_ocv2dcap_simple and patch it to return the finegrained value,
then add a wrapper that use that function but drops it down by one order
of magnitude.

> +int power_supply_batinfo_ocv2dcap(struct power_supply_battery_info *info,
> +                                 int ocv, int temp)

Same with this, saves a lot of code!

(Also will use my new interpolation routines since you refactor
on top of that.)

Yours,
Linus Walleij
Linus Walleij Nov. 19, 2021, 1:54 a.m. UTC | #7
On Tue, Nov 16, 2021 at 1:28 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> Add generic 'simple gauge' helper for performing iterative SOC estimation
> and coulomb counter correction for devices with a (drifting) coulomb
> counter. This should allow few charger/fuel-gauge drivers to use generic
> loop instead of implementing their own.
>
> Charger/fuel-gauge drivers can register 'simple-gauge' which does
> periodically poll the driver and:
>  - get battery state
>  - adjust coulomb counter value (to fix drifting caused for example by ADC
>    offset) if:
>      - Battery is relaxed and OCV<=>SOC table is given
>      - Battery is full charged
>  - get battery age (cycles) from driver
>  - get battery temperature
>  - do battery capacity correction
>      - by battery temperature
>      - by battery age
>      - by computed Vbat/OCV difference at low-battery condition if
>        low-limit is set and OCV table given
>      - by IC specific low-battery correction if provided
>  - compute current State Of Charge (SOC)
>  - do periodical calibration if IC supports that. (Many ICs do calibration
>    of CC by shorting the ADC pins and getting the offset).
>  - provide the user-space a consistent interface for getting/setting the
>    battery-cycle information for ICs which can't store the battery aging
>    information. Uses POWER_SUPPLY_PROP_CYCLE_COUNT for this.
>
> The simple gauge provides the last computed SOC as
> POWER_SUPPLY_PROP_CAPACITY to power_supply_class when requested.
>
> Things that should/could be added but are missing from this commit:
>  - Support starting calibration in HW when entering to suspend. This
>    is useful for ICs supporting delayed calibration to mitigate CC error
>    during suspend - and to make periodical wake-up less critical.
>  - periodical wake-up for performing SOC estimation computation (RTC
>    integration)
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>

This is the right ambition, I haven't looked close at it but the way
you use it seem to be what you need, so:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
(and the rest of the patches to the Rohm chips)

Yours,
Linus Walleij
Matti Vaittinen Nov. 26, 2021, 11:56 a.m. UTC | #8
Hi dee Ho again,

On 11/18/21 08:11, Matti Vaittinen wrote:
> Hi Linus,
> 
> On 11/18/21 04:10, Linus Walleij wrote:
>> On Tue, Nov 16, 2021 at 1:26 PM Matti Vaittinen
>> <matti.vaittinen@fi.rohmeurope.com> wrote:
>>
>>> Support obtaining the "capacity degradation by temperature" - tables
>>> from device-tree to batinfo.
>>>
>>> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
>>
>> Same questions as on the binding patch.
>>
>> If we already support different degradation by temperature tables,
>> why do we need a second mechanism for the same thing?
> 
> Thanks for bringing this up. As I said, I didn't notice that we could 
> indeed use the CAP-OCV tables for different temperatures to bring in 
> this information :) I see certain benefit from the possibility of not 
> requiring to measure the OCV at different temperatures - but it may not 
> be meaningful. As I replied to your patch 1/9 review - I need to (try 
> to) do some more research...

I tried doing some pondering here today. Unfortunately, the Friday 
afternoon is probably the worst time to try this - my brains cease 
operating at the afternoon - and double so at the Friday. Friday 
afternoons are good for babbling via email though ;)

I don't see providing OCV tables at different temperature gives the 
degradation of battery capacity. Whoah. A big thought for Friday.

We get the OCV => SOC correspondance at different temperatures. I 
however don't see how this gives the OCV => energy relation. As far as I 
know both the OCV and the 'amount of uAhs battery is able to store' are 
impacted by temperature change. This means, seeing the OCV => SOC at 
different temperatures does not tell us what is the impact of 
temperature to the OCV, and what is the impact to SOC.

For cases like the ROHM Chargers, we are interested on how much has the 
'ability to store uAhs' changed due to the temperature. When we know the 
amount of uAhs we can store, we can use the coulomb counter value to 
estimate what we still have left in the battery.

In addition to this we do use the OCV information for the "nearly 
depleted battery" - to improve the estimation by zero-correction 
algorithm. I must admit Friday afternoon is not the time I can quite 
recap this part. I think it was something like:

1. Measure VBat with system load (VBAT)
2. Find OCV corresponding the current SOC estimate (SOC based on coulomb 
counter value) - OCV_NOW
3. Compute VDROP caused by the load (OCV_NOW - VBAT)
4. Assume VDROP stays constant (or use ROHM VDR parameters if provided)
5. Using VDROP compute the OCV_MIN which matches the minimum battery 
voltage where system is still operational
6. Use the OCV_MIN and "OCV at SOC0 from calibration data" difference to 
adjust the battery capacity.

(Explanation done at Friday afternoon accuracy here).

>> I'd just calculate a few tables per temperature and be done with
>> it.
>>
>> At least documentation needs to be updated to reflect that the two 
>> methods
>> are exclusive and you can only use one of them.

I don't see these exclusive (at Friday afternoon at least). I think they 
can complement each-others. The temp_degradation table gives us the 
temperature impact on <energy storing ability>, eg, how much the battery 
capacity has changed from designed one due to the temperature.

OCV-SOC tables at various temperatures tell us how OCV looks like when 
we have X% of battery left at different temperatures. Estimation of how 
much the X% is in absolute uAhs can be done by taking into account the 
designed_cap, aging degradation and the temperature degradation (and the 
position of moon, amount of muons created by cosmic rays hitting 
athmosphere at knee energy region and so on...)

Or am I just getting something terribly wrong (again)? :)
(I still for example like internal functions named as __foo() )

Yours
--Matti
Linus Walleij Nov. 27, 2021, 12:54 a.m. UTC | #9
Hi Matti,

don't worry you are probably right. You are the domain expert working
on stuff like this inside a company that actually makes charger ICs.
I am just some guy on the street. So I certainly trust you on this.

On Fri, Nov 26, 2021 at 12:56 PM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> wrote:

> I don't see providing OCV tables at different temperature gives the
> degradation of battery capacity. Whoah. A big thought for Friday.

I think we are getting close to academic definitions of the problem,
so we'd need input from people who actually work on charging and
knows how this works? Or we need to read up on it :/

> We get the OCV => SOC correspondance at different temperatures.

I read
OCV = Open Circuit Voltage (which we can't measure but must calculate)
and
SOC = State of Charge (a percentage of the capacity)

And we agree what the bindings and code gives today is
(temp, OCV) -> SoC (%)

And this assumption is:

A) wrong as in the earth is flat or it makes the same sens to
   take a random number and use as capacity

B) wrong as in not good enough and a bit rough around the
   edges and you have an idea how to improve it

I assume (B) and what we are seeing on the battery indicator on
most of the worlds mobile phones etc is sometimes a bit so-so
because they have only used the above. (I think some people can
attest to experiencing this problem.)

And now we want something better, think medical equipment.

> I
> however don't see how this gives the OCV => energy relation. As far as I
> know both the OCV and the 'amount of uAhs battery is able to store' are
> impacted by temperature change. This means, seeing the OCV => SOC at
> different temperatures does not tell us what is the impact of
> temperature to the OCV, and what is the impact to SOC.

It is definitely true that both the OCV and SOC changes according to
temperature.

But it is also true that these tables for a certain temperature are written
with an OCV measured at this temperature, so the OCV used in the
table is already compensated for the temperature, right?

> For cases like the ROHM Chargers, we are interested on how much has the
> 'ability to store uAhs' changed due to the temperature. When we know the
> amount of uAhs we can store, we can use the coulomb counter value to
> estimate what we still have left in the battery.
>
> In addition to this we do use the OCV information for the "nearly
> depleted battery" - to improve the estimation by zero-correction
> algorithm. I must admit Friday afternoon is not the time I can quite
> recap this part. I think it was something like:
>
> 1. Measure VBat with system load (VBAT)
> 2. Find OCV corresponding the current SOC estimate (SOC based on coulomb
> counter value) - OCV_NOW
> 3. Compute VDROP caused by the load (OCV_NOW - VBAT)
> 4. Assume VDROP stays constant (or use ROHM VDR parameters if provided)
> 5. Using VDROP compute the OCV_MIN which matches the minimum battery
> voltage where system is still operational
> 6. Use the OCV_MIN and "OCV at SOC0 from calibration data" difference to
> adjust the battery capacity.

That's a neat trick!
If you look at drivers/power/supply/ab8500_fg.c function
ab8500_fg_load_comp_volt_to_capacity() you find how
someone else chose to do this with a bit of averaging etc.

> >> I'd just calculate a few tables per temperature and be done with
> >> it.
> >>
> >> At least documentation needs to be updated to reflect that the two
> >> methods
> >> are exclusive and you can only use one of them.
>
> I don't see these exclusive (at Friday afternoon at least). I think they
> can complement each-others. The temp_degradation table gives us the
> temperature impact on <energy storing ability>, eg, how much the battery
> capacity has changed from designed one due to the temperature.
>
> OCV-SOC tables at various temperatures tell us how OCV looks like when
> we have X% of battery left at different temperatures. Estimation of how
> much the X% is in absolute uAhs can be done by taking into account the
> designed_cap, aging degradation and the temperature degradation (and the
> position of moon, amount of muons created by cosmic rays hitting
> athmosphere at knee energy region and so on...)
>
> Or am I just getting something terribly wrong (again)? :)
> (I still for example like internal functions named as __foo() )

OK so yeah I think you are at something here. Which is generic.

The battery indicator in my Tesla in Swedish winter times looks
like this:

+-------------------+---+
|       25%         | * |
+-------------------+---+

So the star * indicates some extra capacity that is taken away
because of the low temperature.

This must be because the system is aware about the impact on
the battery available uAh of the temperature. As you use the
battery it will get warmer and the capacity will increase and the
little star goes away.

Current random mobile phones are not this great and do not
estimate the capacity fall because of the temperature, just shows
a percentage of the full capacity at the temperature right now
whatever that capacity may be, so it is a relative scale and we
can never show anything as nice as what the Tesla does with
this.

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?

Yours,
Linus Walleij
Linus Walleij Nov. 27, 2021, 12:55 a.m. UTC | #10
On Fri, Nov 26, 2021 at 1:35 PM Matti Vaittinen
<mazziesaccount@gmail.com> wrote:

> Hope this did clarify. Afraid it didn't :)

I got it first time, I think. Or I just think I got it but didn't ;)

Yours,
Linus Walleij
Matti Vaittinen Nov. 28, 2021, 8:51 a.m. UTC | #11
Morning Linus & All,

First of all - thanks. I've no words to say how much I do appreciate 
this discussion. (There was zero sarcasm - I don't get much of 
discussion on these topics elsewhere...)

On 11/27/21 02:54, Linus Walleij wrote:
> Hi Matti,
> 
> don't worry you are probably right. You are the domain expert working
> on stuff like this inside a company that actually makes charger ICs.
> I am just some guy on the street. So I certainly trust you on this.

Please don't XD

I am working in a company which does pretty much _all_ frigging 
components from simple resistors to some CPU cores. There are PMICs, 
chargers, touch screens, SERDES, audio ICs - pretty much every 
semiconductor IC one can think of.

What comes to me - I have _very_ limited knowledge on any of these. I 
just do the drivers for whatever component they need one for. And for 
that purpose I do some research and a lot of "guesswork" - almost as if 
I was just a random guy on the street ;) I do _rarely_ have any proper 
documentation about how things are supposed to work - and if I do, I 
know how things are supposed to work at hardware-level, not how software 
should be orchestrating things :/

This discussion with guys like you helps _a lot_ regarding all the 
guesswork :)

> 
> On Fri, Nov 26, 2021 at 12:56 PM Vaittinen, Matti
> <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> 
>> I don't see providing OCV tables at different temperature gives the
>> degradation of battery capacity. Whoah. A big thought for Friday.
> 
> I think we are getting close to academic definitions of the problem,
> so we'd need input from people who actually work on charging and
> knows how this works? Or we need to read up on it :/

Studying is hard work. I am so glad I get to chat with someone who has 
obviously done some of it ;) And just to stress the point - that someone 
is You :]

>> We get the OCV => SOC correspondance at different temperatures.
> 
> I read
> OCV = Open Circuit Voltage (which we can't measure but must calculate)

Me too. Although we can measure this when designing the system in order 
to extract those OCV tables, right?

> and
> SOC = State of Charge (a percentage of the capacity)

Yes.

> And we agree what the bindings and code gives today is
> (temp, OCV) -> SoC (%)
> 
> And this assumption is:
> 
> A) wrong as in the earth is flat or it makes the same sens to
>     take a random number and use as capacity
> 
> B) wrong as in not good enough and a bit rough around the
>     edges and you have an idea how to improve it > I assume (B) and what we are seeing on the battery indicator on
> most of the worlds mobile phones etc is sometimes a bit so-so
> because they have only used the above. (I think some people can
> attest to experiencing this problem.) >
> And now we want something better, think medical equipment.

I'd vothe the (B) too.

In theory the OCV => SOC is correct. (Part of the) Problem is that we 
can't measure the OCV reliably/accurately when system is running 
(because there is load connected). Also, there is probably some change 
here caused by battery aging. So for proper state-of-charge information 
we can't rely the OCV only. (This is where the coulomb counter comes 
in). Furthermore, I would not say it is medical only. I think that even 
the consumer electronics can benefit (a lot) from any accuracy 
improvement we can provide. I guess the improved accuracy can prolong 
the battery life and help avoiding unnecessary charging.

>> I
>> however don't see how this gives the OCV => energy relation. As far as I
>> know both the OCV and the 'amount of uAhs battery is able to store' are
>> impacted by temperature change. This means, seeing the OCV => SOC at
>> different temperatures does not tell us what is the impact of
>> temperature to the OCV, and what is the impact to SOC.
> 
> It is definitely true that both the OCV and SOC changes according to
> temperature.
> 
> But it is also true that these tables for a certain temperature are written
> with an OCV measured at this temperature, so the OCV used in the
> table is already compensated for the temperature, right?

Yes. OCV is fitted but we typically don't have the accurate OCV at all 
times. This meand that we need to use the coulomb-counter value - which 
makes it mandatory for us to find out the absolute capacity at given 
temperature.

>> For cases like the ROHM Chargers, we are interested on how much has the
>> 'ability to store uAhs' changed due to the temperature. When we know the
>> amount of uAhs we can store, we can use the coulomb counter value to
>> estimate what we still have left in the battery.
>>
>> In addition to this we do use the OCV information for the "nearly
>> depleted battery" - to improve the estimation by zero-correction
>> algorithm. I must admit Friday afternoon is not the time I can quite
>> recap this part. I think it was something like:
>>
>> 1. Measure VBat with system load (VBAT)
>> 2. Find OCV corresponding the current SOC estimate (SOC based on coulomb
>> counter value) - OCV_NOW
>> 3. Compute VDROP caused by the load (OCV_NOW - VBAT)
>> 4. Assume VDROP stays constant (or use ROHM VDR parameters if provided)
>> 5. Using VDROP compute the OCV_MIN which matches the minimum battery
>> voltage where system is still operational
>> 6. Use the OCV_MIN and "OCV at SOC0 from calibration data" difference to
>> adjust the battery capacity.
> 
> That's a neat trick!
> If you look at drivers/power/supply/ab8500_fg.c function
> ab8500_fg_load_comp_volt_to_capacity() you find how
> someone else chose to do this with a bit of averaging etc.

Thanks for the pointer. I haven't read that yet but I will do. Although, 
I'll probably postpone that reading to the next week.

> 
>>>> I'd just calculate a few tables per temperature and be done with
>>>> it.
>>>>
>>>> At least documentation needs to be updated to reflect that the two
>>>> methods
>>>> are exclusive and you can only use one of them.
>>
>> I don't see these exclusive (at Friday afternoon at least). I think they
>> can complement each-others. The temp_degradation table gives us the
>> temperature impact on <energy storing ability>, eg, how much the battery
>> capacity has changed from designed one due to the temperature.
>>
>> OCV-SOC tables at various temperatures tell us how OCV looks like when
>> we have X% of battery left at different temperatures. Estimation of how
>> much the X% is in absolute uAhs can be done by taking into account the
>> designed_cap, aging degradation and the temperature degradation (and the
>> position of moon, amount of muons created by cosmic rays hitting
>> athmosphere at knee energy region and so on...)
>>
>> Or am I just getting something terribly wrong (again)? :)
>> (I still for example like internal functions named as __foo() )
> 
> OK so yeah I think you are at something here. Which is generic.
> 
> The battery indicator in my Tesla in Swedish winter times looks
> like this:

Oh, you're driving Tesla. I've wondered how do they work at winter time? 
At the Oulu Finland we can also have quite freezing cold winters so I 
wouldn't dare to buy Tesla (even if they weren't quite that expensive). 
I must admit that I do like the acceleration though. Well, on that front 
my old motorbike must suffice and for me my car is purely for 
transportation and not for run :/

> 
> +-------------------+---+
> |       25%         | * |
> +-------------------+---+
> 
> So the star * indicates some extra capacity that is taken away
> because of the low temperature.
> 
> This must be because the system is aware about the impact on
> the battery available uAh of the temperature. As you use the
> battery it will get warmer and the capacity will increase and the
> little star goes away.

Getting back to the topic - I think this is a good example. Coulomb 
counter can tell us the amoount of uAh we have drawn from the battery 
(with the drawback of for example the ADC offset causing drifting).

The temperature-degradation tables (and some figures explaining the 
impact of aging) can tell us how much absolute capacity we have lost 
(the star thingee) - some of which can be recovered when battery is 
warming - and finally we do get the SOC in %.

> Current random mobile phones are not this great and do not
> estimate the capacity fall because of the temperature, just shows
> a percentage of the full capacity at the temperature right now
> whatever that capacity may be, so it is a relative scale and we
> can never show anything as nice as what the Tesla does with
> this.

Yes. What I was after here is using the temperature-corrected capacity 
as a base of computing the relative SOC. I don't think we should tell 
user the battery is only half-full when it actually can't hold more 
charge in cold weather (due to reduced capacity) - because this 
instructs people to start charging.

OTOH, I do _really_ like your Tesla example of telling the user that 
even though your battery is as full as it can, it does not mean it lasts 
the same <XX> hours it usually does when you are indoors. 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.


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

Best Regards
	-- Matti Vaittinen
Linus Walleij Nov. 30, 2021, 1:34 a.m. UTC | #12
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@fi.rohmeurope.com> 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. 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).

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

Yours,
Linus Walleij
Matti Vaittinen Nov. 30, 2021, 6:33 a.m. UTC | #13
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@fi.rohmeurope.com> 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
Linus Walleij Dec. 2, 2021, 1:57 a.m. UTC | #14
On Tue, Nov 30, 2021 at 7:33 AM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> wrote:

> 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 ;)

Yeah someone will implement spline interpolation in the kernel one
day I bet...

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

IIUC the degradation of a battery is related to number of full charge cycles,
i.e. the times that the battery has been emptied and recharged fully.
This is of course never happening in practice, so e.g. two recharge cycles
from 50% to 100% is one full charge cycle. So you integrate this
over time (needs to be saved in a file system or flash if the battery does
not say it itself).

This measures how much the lithium ions have moved around in the
electrolyte and thus how much chemical interaction the battery has
seen.

Then the relationship between complete charge cycles and capacity
degradation is certainly also going to be something nonlinear so it
needs manufacturer data for the battery.

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

Yes this is how it is done. With a few measurements averaged to
iron out the noise.

> 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).

Yes there is some tight community of electronic engineers who read the
right articles and design these things. We don't know them :(

> 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).

I think so too, I don't think they are very rocket science once the
right abstractions fall out.

Yours,
Linus Walleij
Matti Vaittinen Dec. 2, 2021, 6:29 a.m. UTC | #15
On 12/2/21 03:57, Linus Walleij wrote:
> On Tue, Nov 30, 2021 at 7:33 AM Vaittinen, Matti
> <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> 
>> 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...
> 
> IIUC the degradation of a battery is related to number of full charge cycles,
> i.e. the times that the battery has been emptied and recharged fully.
> This is of course never happening in practice, so e.g. two recharge cycles
> from 50% to 100% is one full charge cycle. So you integrate this
> over time (needs to be saved in a file system or flash if the battery does
> not say it itself). 

Yes.

> This measures how much the lithium ions have moved around in the
> electrolyte and thus how much chemical interaction the battery has
> seen.
> 
> Then the relationship between complete charge cycles and capacity
> degradation is certainly also going to be something nonlinear so it
> needs manufacturer data for the battery.

Right. As far as I understand, at least part of the 'aging degradation' 
comes from the fact that battery materials are 'vaporizing' when battery 
is charged. And as far as I understand, the temperature in which 
charging occurs has a big impact on this. Eg, higher the temperature 
where you do charging, worse the degradation. Which means that the cycle 
count should actually be weighed by the charging temperature.

But this kind of missed my point :) I was thinking of how to give the 
absolute (uAh) value of capacity drop caused by the temperature. My 
original RFC patch gave this as linear change of absolute uAh's at a 
temperature range.

As you pointed, we should not include the linearity in the DT model. So 
the next step would be to just give measured value pairs (should be done 
by battery vendor or computed by some theoretical basis) of absolute 
uAh/temperature - and leave fitting of the data points to be done by SW.

What I was now considering is that maybe the capacity drop (in uAhs) 
caused by the temperature change - is not the same for new and old 
battery. It sounds more logical to me that the capacity drop caused by 
the temperature is proportional to the maximum capacity battery is 
having at that point of it's life. Eg, if new battery can hold 80 units 
of energy, and drops 20 units of energy when temperature changes from T0 
=> T1 - an badly aged battery which now only can hold 40 units would 
lose only 10 units at that same temperature drop T0 => T1. I was 
wondering if such an assumption is closer to the truth than saying that 
bot of the batteries would lose same 20 units - meaning that the new 
battery would lose 25% of energy at temperature drop T0 => T1 but old 
one would lose 50% of the capacity. I somehow think both of the 
batteries, old and new, would lose same % of capacity at the temperature 
change.

So, if this assumption is correct, then we should give the temperature 
impact as proportion of the full capacity taking the aging into account. 
So if we happen to know the aging impact to the capacity, then software 
should use aging compensation prior computing the temperature impact. If 
aging information or impact is not known, then designed capacity can be 
used as a fall-back, even though it means we will probably be somewhat 
off for old batteries.

My problem here is that I just assume the impact of temperature is 
proportional to the full-capacity which takes the aging into account. 
Knowing how this really is would be cool so we could get the temperature 
impact modelled correctly in DT.

>> 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.
> 
> Yes this is how it is done. With a few measurements averaged to
> iron out the noise.
> 
>> 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).
> 
> Yes there is some tight community of electronic engineers who read the
> right articles and design these things. We don't know them :(

Right. By the way, I heard tha the TI has patent protecting some type of 
battery internal resistance usage here. OTOH, ROHM has patent over some 
of the VDROP value table stuff. Occasionally it feels like the ice is 
getting thinner at each step here. :/

Best Regards
	Matti Vaittinen
Linus Walleij Dec. 5, 2021, 12:30 a.m. UTC | #16
Hi Matti,

On Thu, Dec 2, 2021 at 7:29 AM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> wrote:

(fast forward the stuff where we are in violent agreement)

> What I was now considering is that maybe the capacity drop (in uAhs)
> caused by the temperature change - is not the same for new and old
> battery. It sounds more logical to me that the capacity drop caused by
> the temperature is proportional to the maximum capacity battery is
> having at that point of it's life. Eg, if new battery can hold 80 units
> of energy, and drops 20 units of energy when temperature changes from T0
> => T1 - an badly aged battery which now only can hold 40 units would
> lose only 10 units at that same temperature drop T0 => T1. I was
> wondering if such an assumption is closer to the truth than saying that
> bot of the batteries would lose same 20 units - meaning that the new
> battery would lose 25% of energy at temperature drop T0 => T1 but old
> one would lose 50% of the capacity. I somehow think both of the
> batteries, old and new, would lose same % of capacity at the temperature
> change.
>
> So, if this assumption is correct, then we should give the temperature
> impact as proportion of the full capacity taking the aging into account.

This looks plausible.

> My problem here is that I just assume the impact of temperature is
> proportional to the full-capacity which takes the aging into account.
> Knowing how this really is would be cool so we could get the temperature
> impact modelled correctly in DT.

I suppose we should check some IEEE articles to verify that this is the
case before assuming. I have access to them but no time to read :(

> > Yes there is some tight community of electronic engineers who read the
> > right articles and design these things. We don't know them :(
>
> Right. By the way, I heard tha the TI has patent protecting some type of
> battery internal resistance usage here. OTOH, ROHM has patent over some
> of the VDROP value table stuff. Occasionally it feels like the ice is
> getting thinner at each step here. :/

This is none of our concern. Patents are concerns for people shipping
devices, not for open source code. Also patents are only valid for
20 years and we are looking at longer times anyway. If we define
generic DT properties for this they will be used more than 20 years
from now. We even have patented code in the kernel, see:
Documentation/RCU/rcu.rst

Yours,
Linus Walleij