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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/26/21 13:56, Vaittinen, Matti wrote:
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@xxxxxxxxxxxxxxxxx> wrote:

Support obtaining the "capacity degradation by temperature" - tables
from device-tree to batinfo.

Signed-off-by: Matti Vaittinen <matti.vaittinen@xxxxxxxxxxxxxxxxx>

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

After reading what I wrote even I didn't know what I tried to say. Well, I think I tried to explain that I don't see how we can use this information to do any estimation what the Coulomb Counter reading represent at the given temperature. This is what the temperature-degradation tables aim to give us.

 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.

I think I tried to say that these curves don't help us to tell how many uAhs we have in battery with different temperatures when battery is empty, or half full or, ... Again, what we would like to know is what SOC our CC value represents - and use OCV to just adjust this further (or in some cases to correct the CC value using OCV - if we can trust the battery to be properly relaxed).

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

Best Regards
	-- Matti Vaittinen




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux