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