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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4B27EE9270E for ; Sat, 27 Dec 2025 21:38:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=F+zOPMJ/+XQOoQnBvgthrqy4sMQ6IWP6qjfRNJSiwKc=; b=kIK+0Nshq0nF7vp2mu7Il1gVc8 AdYo6vK0LyL02eH41wOhmyuE0BMgWPxh4Y+yOXrsVEDG7ghXd9Or8ue8KEKlrCPPGO8Qk8YlpEeOK Qq2mK33IxltxXcEgIfxkhZSYSonChuQruft7aJUljWZcsU36eL8S7yi/DjlvNsV5AE0QMOVX3oHUN bzLYTTQ66L+JHwxIyeESMVLgNhyPB7GI0e4xWjTc+K3MPd0fz34WwdjjZD0vRdvOpBatpH0opfg/J E9nvOrI5OPOnQSHg/kepI7GfoxgwsusxOIjOj6nbtYjEQmgozQalZyyeLcjF4rwlbTUJlCH4uFNbc 1vT5OpeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vZbzj-00000002DRg-044L; Sat, 27 Dec 2025 21:38:39 +0000 Received: from mail.andi.de1.cc ([2a02:c205:3004:2154::1]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vZbzg-00000002DRJ-15rR for linux-arm-kernel@lists.infradead.org; Sat, 27 Dec 2025 21:38:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kemnade.info; s=20220719; h=References:In-Reply-To:Cc:From:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID; bh=F+zOPMJ/+XQOoQnBvgthrqy4sMQ6IWP6qjfRNJSiwKc=; b=mXokZZdZCUhEmvIIodt4+AKwvf qV+hn0iP51XPavx8HvYW5FR1ZNN2C6zl3xzZzGppGTUsMWgucwNEQi0xnQ4Uqzu3eMToE795u0r61 f3viGkybinu7ceE/m/hqVhfLJnGXNWpJKe/t0TYIXqPoUI2Qy+OGGal/Zaf7ihnl+bcmXp3piO5Gk Phh9R1SCOk3+c4FrrgNjTnhv58qIl/RByk1yPM4/UkC7GzHGOxOU3i/1s1jfvljeREW83SfFYa8IR jTVFx6OZAi/8XSI5tpVrCuYeHC6DWcECq+LU8x1zERvRg5k06rX+xy/NcipPf2EVgnJTIq1xMv3x/ srzCshwg==; Date: Sat, 27 Dec 2025 22:38:15 +0100 From: Andreas Kemnade To: Josua Mayer Cc: Jonathan =?UTF-8?B?TmV1c2Now6RmZXI=?= , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sebastian Reichel , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/3] power: supply: add battery driver for netronix ec Message-ID: <20251227223815.17dea51d@kemnade.info> In-Reply-To: <20251227-kobo-aura-battery-v1-1-328a90ef5122@jm0.eu> References: <20251227-kobo-aura-battery-v1-0-328a90ef5122@jm0.eu> <20251227-kobo-aura-battery-v1-1-328a90ef5122@jm0.eu> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.49; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251227_133836_330036_72AA19EA X-CRM114-Status: GOOD ( 21.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 27 Dec 2025 17:28:13 +0100 Josua Mayer wrote: > Implement a simple battery driver for monitoring voltage with the > netronix embedded controller found in certain ebook readers. > > Signed-off-by: Josua Mayer This also produces a value somehow depending on battery voltage on the Tolino vision. [...] > diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c > index 08c68de0f01bc..d5059b8862aa8 100644 > --- a/drivers/mfd/ntxec.c > +++ b/drivers/mfd/ntxec.c > @@ -139,6 +139,7 @@ static const struct regmap_config regmap_config = { > static const struct mfd_cell ntxec_subdev[] = { > { .name = "ntxec-rtc" }, > { .name = "ntxec-pwm" }, > + { .name = "ntxec-battery" }, > }; > > static const struct mfd_cell ntxec_subdev_pwm[] = { I think that should be a separate patch for mfd. [...] > + switch (psp) { > + case POWER_SUPPLY_PROP_VOLTAGE_NOW: > + ret = regmap_read(priv->ec->regmap, NTXEC_REG_READ_BATTERY, &value); > + if (ret < 0) > + return ret; > + > + /* ec value to microvolt conversion: > + * vendor kernel source suggests linear behaviour from 3V to 4.2V > + * with readings 767 to 1023; each increment represents 4687,5uV. > + * adjust 3V boundary slightly to report exactly 4.2V when full. > + */ > + val->intval = 2999872 + (value - 767) * 4688; > + break; I find this code both in some kobo 2.6.35.3 code and on the tolino 3.0.35: const unsigned short battGasgauge[] = { // 3.0V, 3.1V, 3.2V, 3.3V, 3.4V, 3.5V, 3.6V, 3.7V, 3.8V, 3.9V, 4.0V, 4.1V, 4.2V, // 743, 767, 791, 812, 835, 860, 885, 909, 935, 960, 985, 1010, 1023, 767, 791, 812, 833, 852, 877, 903, 928, 950, 979, 993, 1019, 1023, }; This does not look very linear... We have offsets 24 21 21 19 25 26 25 22 29 14 26 4 Do you have something looking more sane? No idea what should produce such flaky offsets besides of improper measurements. At least that should be commented. And why do these tables exist at all? Hmm, the more weird thing is that these voltages are translated linearly inot capacity. So maybe they are just adjusted to have the capacity look more sane. That would explain the 4 units step between 4.1V and 4.2V. Having linear adc result -> voltage and nonlinear voltage-> capcity would make more sense. looking at such code snippet like this: case POWER_SUPPLY_PROP_CAPACITY: if (POWER_SUPPLY_STATUS_NOT_CHARGING == g_ntx_bat_di->battery_status) { val->intval = 100; return 0; } value = ntx_up_battery_vol(); [...] val->intval = 100 - ((4100000 - value)/7000); I am wondering whether we should just return capacity that way without calculating voltage... Regards, Andreas