Message-ID: <e8955365-73c0-4c7a-a579-0ee6940340b2@gmail.com>
Date: Mon, 18 Aug 2025 09:34:02 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
 Andreas Kemnade <andreas@...nade.info>
Cc: Lee Jones <lee@...nel.org>, Sebastian Reichel <sre@...nel.org>,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 2/2] power: supply: Add bd718(15/28/78) charger driver

On 17/08/2025 11:13, Krzysztof Kozlowski wrote:
> On 17/08/2025 10:11, Andreas Kemnade wrote:
>> Am Sun, 17 Aug 2025 07:58:35 +0200
>> schrieb Krzysztof Kozlowski <krzk@...nel.org>:
>>
>>> On 16/08/2025 21:19, Andreas Kemnade wrote:
>>>> Add charger driver for ROHM BD718(15/28/78) PMIC charger block.
>>>> It is a stripped down version of the driver here:
>>>> https://lore.kernel.org/lkml/dbd97c1b0d715aa35a8b4d79741e433d97c562aa.1637061794.git.matti.vaittinen@fi.rohmeurope.com/
>>>
>>> Why are you duplicating the driver? Why original cannot be used?
>>>
>>>
>> I am not duplicating the driver. That patch series never went in. I am
>> stripping it down to let things go in step by step. I have also talked
>> with Sebastian about this. And he also prefers a step by step approach
>> to have it more easily reviewed.
>> I also do not have the infrastructure to test things like capacity
>> degradation over time. There is non-trivial rebasing work involved, so
>> I even do not feel confident submitting such at all.
> 
> 
> OK, but if you refer to other work, then also please explain why this is
> stripped down.

First of all, thanks a ton Andreas for continuing this work which I 
never managed to finish!

Battery fuel-gauging with coulomb-counter is hard. I believe we can get 
some results with the original RFC code - but it requires quite a bit of 
effort. AFAIR, there are (at least) 4 "pain-points".

1. Lack of persistent storage for charging cycles. For proper 
fuel-gauging, we would need information about battery aging. The PMIC 
has nothing to store the charging cycle counter when power is cut. 
That'd require some user-space solution which could store the cycle 
information in a persistent storage && tell it to the driver at 
start-up. I don't know if there is open-source userspace solution for this.

2. Battery parameters. This is the real problem. In order to make the 
fuel-gauging work, the driver needs proper battery information. I wrote 
the original driver to be able to retrieve the data from a 
static-battery DT node - but I have a feeling the device-vendor using 
this PMIC provided battery-info via module parameters. I am not sure if 
those parameters can be recovered - and as Andreas said, defining them 
is not easy task. By minimum we would need the OCV-tables and some aging 
+ temperature degradation effects (or VDR-tables which ROHM uses for 
it's zero-correction algorithm - but AFAIR, defining those VDR tables is 
not widely known information).

3. ADC offset. The coulomb-counter operates by measuring and integrating 
voltage-drop over known Rsense resistor. If (when) the ADC has some 
measurement offset, it will produce a systematic error which accumulates 
over time. Hence a calibration is required. The BD718[15/28] have an ADC 
calibration routine, but AFAIR, there was some limitations. I don't 
remember all the dirty details, but it probably didn't work too well if 
current consumption was varying during the calibration(?). I think 
running the calibration is not supported by the driver.

4. Maintaining all this. The fuel-gauging is maths which uses quite a 
few of battery parameters. Pinpointing an error from parameters, 
algorithm(s) or hardware is far from trivial because errors can specific 
to the very battery/system they were detected at.

There are probably more problems (some of which I have forgotten, and 
some of which I haven't even hit yet).

TLDR; It'd be hard to do accurate fuel-gauging without proper battery 
information and some extra work. We could probably get some rough 
estimates about the capacity - but implementing it only makes sense if 
there is someone really using it. Charger control on the other hand 
makes some sense. [It at least allows Andreas to charge his eReader 
using solar-power when on a biking hiking! How cool is that? ;)]

So, dropping fuel-gauge (for now), and upstreaming the rest seems like a 
very good approach to me.

Thanks for CC'in me Andreas. I don't have much time to work on this (as 
I never do), but please keep me in loop and let me know if I can help... 
I can at very least review things :)

Thanks again for working with this!

(Ps. Are you joining ELCE in Amsterdam? It'd be nice to see you there if 
you do).

Yours,
	-- Matti

Powered by blists - more mailing lists