Message-ID: <dc2a9ea1-29fd-4ae8-b414-ca3acb0d8ad3@gmail.com>
Date: Thu, 21 Aug 2025 08:31:06 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andreas Kemnade <andreas@...nade.info>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 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 20/08/2025 19:05, Andreas Kemnade wrote:
> Am Mon, 18 Aug 2025 12:32:43 +0300
> schrieb Matti Vaittinen <mazziesaccount@...il.com>:
> 
>>> Kobo kernels have these tables as part of the driver, the right one is
>>> selected via an index in the NTX_HWCONFIG blob provided by the
>>> bootloader to the kernel. So that is not necessarily a problem. It
>>> could be translated into dt.
>>>
>>> static int ocv_table_28_PR284983N[23] = {
>>>           //4200000, 4162288, 4110762, 4066502, 4025265, 3988454, 3955695, 3926323, 3900244, 3876035, 3834038, 3809386, 3794093, 3782718, 3774483, 3768044, 3748158, 3728750, 3704388, 3675577, 3650676, 3463852, 2768530
>>>           4200000, 4166349, 4114949, 4072016, 4031575, 3995353, 3963956, 3935650, 3910161, 3883395, 3845310, 3817535, 3801354, 3789708, 3781393, 3774994, 3765230, 3749035, 3726707, 3699147, 3671953, 3607301, 3148394
>>> };
>>>
>>> static int vdr_table_h_28_PR284983N[23] = {
>>>           //100, 100, 101, 101, 102, 102, 103, 103, 104, 104, 105, 106, 106, 107, 107, 108, 108, 109, 110, 112, 124, 157, 786
>>>           100, 100, 101, 102, 102, 105, 106, 107, 112, 108, 108, 105, 105, 108, 110, 110, 110, 111, 112, 114, 120, 131, 620
>>> };
>>>
>>> static int vdr_table_m_28_PR284983N[23] = {
>>>           //100, 100, 101, 101, 102, 102, 103, 103, 104, 104, 105, 102, 100, 100, 102, 103, 103, 105, 108, 112, 124, 157, 586
>>>           100, 100, 103, 106, 110, 114, 115, 119, 122, 122, 115, 113, 112, 114, 117, 124, 126, 123, 122, 126, 140, 156, 558
>>> };
>>>
>>> static int vdr_table_l_28_PR284983N[23] = {
>>>           //100, 100, 103, 105, 110, 110, 113, 112, 112, 112, 105, 110, 110, 111, 122, 131, 138, 143, 150, 166, 242, 354, 357
>>>           100, 100, 105, 110, 114, 117, 121, 125, 126, 122, 116, 114, 115, 118, 124, 132, 140, 148, 156, 170, 210, 355, 579
>>> };
>>>
>>> static int vdr_table_vl_28_PR284983N[23] = {
>>>           //100, 100, 103, 106, 108, 111, 114, 117, 118, 115, 108, 106, 108, 113, 115, 114, 118, 125, 144, 159, 204, 361, 874
>>>           100, 100, 109, 115, 118, 123, 127, 130, 140, 139, 134, 130, 128, 138, 140, 150, 154, 164, 178, 204, 271, 362, 352
>>> };
>>
>> Oh, good. If we can get the right battery parameters from the vendor
>> driver, then the main problem gets solved. Although, multiple sets of
>> different VDR tables probably means, that there are variants with
>> different types of battery out there. I assume the bootloader can
>> somehow detect the battery type to provide the correct blob?
> 
> Historically the Kobo devices ship said HWCONFIG blob apparently to use
> the same kernel on multiple devices, then devicetree was invented and
> used what was available. There is then a
>                  switch(gptHWCFG->m_val.bBattery) {
> ...
>                                  ocv_table_default =
>                                  ocv_table_28_PR284983N;
> 
> 
> 
> So that all only means there
> are several different batteries amoung the devices supported by that
> kernel.

Ah. So you believe the other batteries are used on other devices which 
run the same kernel. Makes sense.

> From my guts feeling I wonder if the is_relaxed stuff is
> properly working and I wonder whether a Kalman filter would give better
> results, but that is all something for the future.

I believe your experience is stronger than mine (also) here :) I don't 
really know the theory behind the 'relaxed battery' (or much of other 
battery chemistry stuff). I was merely trusting the inventions of the HQ 
engineers, who told me that the OCV tables can be used to adjust the 
coulomb counter when the battery is 'relaxed'. 'Relaxed' here meaning 
that it has not been charged (or a lot of current has not been drawn 
from it) recently. AFAIR, most of the PMIC models had some hardware 
support for detecting if the battery is in 'relaxed' state.

I admit it sounds like somewhat uncertain approach. I'd love to hear how 
you think the filter would help. I suppose you think of applying some 
filtering to the CC correction? Eg, 'smoothen' the CC resetting based on 
relaxed OCV, by applying some filtering to the correction values? Sounds 
cool! But... It does also sound the analysis about the impact of the 
filtering will be hard.

The reason why I dropped the simple-gauge RFC is, that I don't even have 
a BD71828 which is connected to a battery (and even with that the 
testing would be hard and slow). I thought of trying to do some 
simulation, but even that felt quite futile without some proper 
battery-data. So, my work was largely just shooting blindly and 
listening if some customer started screaming so loud it could be heard 
in Finland ^_^;

I think the "ideology" of the fuel-gauging in the HQ was to accept some 
of the errors and trust the VDR table based zero-correction to fix 
things when battery was about to get empty. The thinking was that more 
accurate battery status gets important only when the battery is getting 
exhausted - and that's when the zero-correction kicks in.

Yours,
	-- Matti

Powered by blists - more mailing lists