From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65F1AC433EF for ; Thu, 2 Dec 2021 01:57:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344435AbhLBCAw (ORCPT ); Wed, 1 Dec 2021 21:00:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232166AbhLBCAt (ORCPT ); Wed, 1 Dec 2021 21:00:49 -0500 Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79E72C06174A for ; Wed, 1 Dec 2021 17:57:28 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id w6-20020a9d77c6000000b0055e804fa524so37905735otl.3 for ; Wed, 01 Dec 2021 17:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5lCMYrhm5t5lva25mCfOVtAtdQc5BhH6E74NoPZjUbA=; b=kbN5VAd3EWzVITSWCiuAVlnCBYntE1oSbkRiiStHk1SRl2vjP37dW0UwV64k66adwJ 24qzE5a2BByZfzxyqgIhnICyaWuBh3cNZ5C2z6mXlOayvRTACgLiuXA2g1/BUZ4WjJjP ojly8x07Q/pDR4d7mbyPlm0peu5bCtQRY1yo7pNSbQOgeTiMjPX3e609cubVq0Yy5XRs /EaM+/1qFkCc26ZrmY3ZLJlq41thk/SL4G6sL10fSD9B3Lg/opEU9nQ1gbDZ0cOIObaI eOQVGa52Q1VpEo7UqP0Qn6gBg/OrwMUeNvDtUUUNxlEGcjlLoy4/zF1yznZldgc1Su1Y 2C6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5lCMYrhm5t5lva25mCfOVtAtdQc5BhH6E74NoPZjUbA=; b=G1fkGhO040GMsqWGgZM4i2m+NUuHF4vcXVEvvJ0oUgr+ktNyt65XuwZvLpDmWvF6cx YW9gtcMLwzMOZN0UOib5M6/ysVZrZtw54BBpwo3SdfbIbLVA0QDagzseWsgmrpAJ14vB Js1PqJl1qRuijJlLplXw13C7tIBsvxwYM5Z54cmYmn1sYc2wQwHZecxAw2GuPunsyjWi JVntsWg8lu3S+RMsGT1yyaBzUeMUMs51Zrtgtq6b5U3uNV2jm+hjwesX6F4OdpuHUAAw 67VgK9Z0OzJLCp3NTxr71rn7oxmXdsejhUSRe4EJyTqsGcfLyMMPx+RTc7oCt7UAEB1U UJKQ== X-Gm-Message-State: AOAM5312gXAwM0g5PzXXZEPE6gfhRz9bU63QkVY0Tu3Qf6QnXP/6boOx thLonev4z/nm4GlOof5obtxUuVzkA42h2h4N4uwEdw== X-Google-Smtp-Source: ABdhPJyuIlyp15f6FFJnwyRvnSdZY2wzuaWptSL7NkR9cG64eNxcHaqNqhS0ll24px3A6oDmh6YoPPsJyo6JDsiPOz0= X-Received: by 2002:a9d:74d0:: with SMTP id a16mr8829373otl.237.1638410247820; Wed, 01 Dec 2021 17:57:27 -0800 (PST) MIME-Version: 1.0 References: <6123f62ac44e6513a498d15034a4b6b22abe5f5b.1637061794.git.matti.vaittinen@fi.rohmeurope.com> <7b34e88f-54f3-6d0a-293e-b2b411d1c5c2@fi.rohmeurope.com> <676253b9-ff69-7891-1f26-a8b5bb5a421b@fi.rohmeurope.com> <57f97c5f-aedb-7f7e-d269-90bd97bbba09@fi.rohmeurope.com> In-Reply-To: From: Linus Walleij Date: Thu, 2 Dec 2021 02:57:16 +0100 Message-ID: Subject: Re: [RFC PATCH v3 3/9] power: supply: Support DT originated temperature-capacity tables To: "Vaittinen, Matti" Cc: Matti Vaittinen , Sebastian Reichel , Rob Herring , Lee Jones , "rostokus@gmail.com" , "fan.chen@mediatek.com" , "linux-pm@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-power , =?UTF-8?B?c2hpbWkgPj4g5riF5rC0IOW0h+W8mA==?= Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Nov 30, 2021 at 7:33 AM Vaittinen, Matti 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