Message ID | 20230612113059.247275-7-linux@rasmusvillemoes.dk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2523236vqr; Mon, 12 Jun 2023 04:43:43 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5HSu229+EcNzHe/5ncEJrAIZmORIunIU2RBg7kksRwc0SWQF/Z3bdO3KS5XCBjQow8shsI X-Received: by 2002:a19:4316:0:b0:4f3:ab4b:4d99 with SMTP id q22-20020a194316000000b004f3ab4b4d99mr3474319lfa.19.1686570222902; Mon, 12 Jun 2023 04:43:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686570222; cv=none; d=google.com; s=arc-20160816; b=gKJnKiCb/yYxTTNIuQkvdoqU3EvI9Qh+7Kvi1pVvyyQFlGXrMwDW81i2LKBIs8jxUw ihiFRkpexa5eS5ByUa7OIn/43HebW/8OcDQ7SuGyrVLBst+S+nGkwoCQKEN7eTb6g2xd VTZwX584qUSBJaVeKGeoHFoli8B/fM10a3i5Yqby1ktZYFZrfER/CEAbxIcWICspOlUu X9xmfjsy/DVj2lHd9QUPs+qAKnTHoTdaLE0vymlVTLqLypbQEWuUEEP1d+1tOQ2vFdx+ lXCTEj8sr90UmVXh/fEJyjysJVT50ToDyOowRsChf/Uox3yn50Vy7l9h+T8m8R51PlRH SqWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=oCDq0HPnZ/JW4aurWSialUZv9qnBUgo1v/zNc5H3vQE=; b=EjtakiAHXw1j1q6By57tzQETNepvPMLWboeZUlSfpwO54gYPoHtXC5gTY30ULsV6P3 6jvjW5oFRfCiMw6uL1tEDs3xuqn/Bn2gqY+lqRzh4gZxBrkTJC2StkTtsA32mwcRAJpE 5DOQBElMSMCeZoeKrqQbYGtlRfgrwMwxlhwX0yhYpViGlbKUdnVDIhZP6uxEDzcbGcmQ IYEDg3WZViSXMhrC+DOEancd3g1fdD8MQ+9LSv128zuV/gMV4e+zuIvRCYeB9ndOW/22 y0pFFayMjQG4rFG3rw1iTH8aPCABfxwEpGc6dIHre+BUQ4xSa/vEbdLVDUgZUVIQtW1S 4xaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=TI8xXEHM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x17-20020aa7d6d1000000b00514b9218964si5249848edr.583.2023.06.12.04.43.18; Mon, 12 Jun 2023 04:43:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=TI8xXEHM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234542AbjFLLkz (ORCPT <rfc822;rust.linux@gmail.com> + 99 others); Mon, 12 Jun 2023 07:40:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234998AbjFLLix (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 12 Jun 2023 07:38:53 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CE8A6591 for <linux-kernel@vger.kernel.org>; Mon, 12 Jun 2023 04:31:13 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-4f61d79b0f2so5059585e87.3 for <linux-kernel@vger.kernel.org>; Mon, 12 Jun 2023 04:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; t=1686569471; x=1689161471; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oCDq0HPnZ/JW4aurWSialUZv9qnBUgo1v/zNc5H3vQE=; b=TI8xXEHM0E1duX465xqlvlQJlUBu4kdYnE/gYUVnHchpW9NmMKbxTZ7pvXsNZ97Pyw VdSzV3IKFrAyAB5rXaWDofX5i9clGbUukci0IVENYxvf3rlTsTWPLmnoSv10Ew19MEdg l/YWMLYmrX+0ACs423hIDEnPAGTFv2+fxo8R0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686569471; x=1689161471; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oCDq0HPnZ/JW4aurWSialUZv9qnBUgo1v/zNc5H3vQE=; b=VP183/FDEDvQjH6DyK+U+WvbQuUV5/QFpWMk2MOETYea1+GCTmT5zltSBkkt+eFTqb 2hTsnrtVqTjbSs+oBSv0BG4b/pG9D7BfLiTFReFqfbtk3KNDFE4UNcTNv3R6pTYWEqLI qNcm7U5xPgNSjIb1Rn4UWuCVIIkuokAw++p01Y8x2bEsved5kk3cXbDxxG7M/+HDQYic SnhkkavmCgKRVdiBO//Z9YJCGQwws7Jb9YWyCgq30EqoBA4r0Kf/Qf/nTlzQnI4t/BMI LCc5iSp6TRy+dwmgaFudV7WKdUZW+BoOnxNXvCsWJLZTXMjW6jdzgyWLlWJaMe7FM92P fgkA== X-Gm-Message-State: AC+VfDwnZN5QlG/tO9ddPurwqxWT780pJcWyZd7JzLQlWUmVbLbQKFCD dXy1iMZhCmZHHb3T74lzVhwtow== X-Received: by 2002:a05:6512:3133:b0:4f6:2e4e:e425 with SMTP id p19-20020a056512313300b004f62e4ee425mr4005082lfd.50.1686569471577; Mon, 12 Jun 2023 04:31:11 -0700 (PDT) Received: from prevas-ravi.prevas.se ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id w26-20020a19c51a000000b004edb8fac1cesm1399320lfe.215.2023.06.12.04.31.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jun 2023 04:31:11 -0700 (PDT) From: Rasmus Villemoes <linux@rasmusvillemoes.dk> To: Alessandro Zummo <a.zummo@towertech.it>, Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, linux-rtc@vger.kernel.org, Rasmus Villemoes <linux@rasmusvillemoes.dk>, linux-kernel@vger.kernel.org Subject: [PATCH 6/8] rtc: isl12022: trigger battery level detection during probe Date: Mon, 12 Jun 2023 13:30:56 +0200 Message-Id: <20230612113059.247275-7-linux@rasmusvillemoes.dk> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20230612113059.247275-1-linux@rasmusvillemoes.dk> References: <20230612113059.247275-1-linux@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768497057752789514?= X-GMAIL-MSGID: =?utf-8?q?1768497057752789514?= |
Series |
rtc: isl12022: battery backup voltage and clock support
|
|
Commit Message
Rasmus Villemoes
June 12, 2023, 11:30 a.m. UTC
Since the meaning of the SR_LBAT85 and SR_LBAT75 bits are different in
battery backup mode, they may very well be set after power on, and
stay set for up to a minute (i.e. until the battery detection in VDD
mode happens when the seconds counter hits 59). This would mean that
userspace doing a ioctl(RTC_VL_READ) early on could get a false
positive.
The battery level detection can also be triggered by explicitly
writing a 1 to the TSE bit in the BETA register. Do that once during
boot (well, probe), and emit a single warning to the kernel log if the
battery is already low.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
drivers/rtc/rtc-isl12022.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
Comments
On 12/06/2023 13.30, Rasmus Villemoes wrote: > diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c > index 1b6659a9b33a..690dbb446d1a 100644 > --- a/drivers/rtc/rtc-isl12022.c > +++ b/drivers/rtc/rtc-isl12022.c > @@ -280,8 +280,25 @@ static void isl12022_set_trip_levels(struct device *dev) > mask = ISL12022_REG_VB85_MASK | ISL12022_REG_VB75_MASK; > > ret = regmap_update_bits(regmap, ISL12022_REG_PWR_VBAT, mask, val); > - if (ret) > + if (ret) { > dev_warn(dev, "unable to set battery alarm levels: %d\n", ret); > + return; > + } > + > + ret = regmap_write_bits(regmap, ISL12022_REG_BETA, > + ISL12022_BETA_TSE, ISL12022_BETA_TSE); > + if (ret) { > + dev_warn(dev, "unable to trigger battery level detection: %d\n", ret); > + return; > + } > + > + ret = isl12022_read_sr(regmap); So testing this a bit more thoroughly reveals that the LBAT85/LBAT75 bits do not get updated immediately after the TSE bit is set; one needs to wait a little before the battery voltage detection is done and the SR bits updated. Unfortunately, the data sheet doesn't say anything about how long that might be or if there's some busy bit one could look at; all it says is actually exactly what I've done above: The battery level monitor is not functional in battery backup mode. In order to read the monitor bits after powering up VDD, instigate a battery level measurement by setting the TSE bit to "1" (BETA register), and then read the bits. IOW, please don't apply this patch until I figure out how to do this properly. Rasmus
On 12/06/2023 13:30:56+0200, Rasmus Villemoes wrote: > Since the meaning of the SR_LBAT85 and SR_LBAT75 bits are different in > battery backup mode, they may very well be set after power on, and > stay set for up to a minute (i.e. until the battery detection in VDD > mode happens when the seconds counter hits 59). This would mean that > userspace doing a ioctl(RTC_VL_READ) early on could get a false > positive. > > The battery level detection can also be triggered by explicitly > writing a 1 to the TSE bit in the BETA register. Do that once during > boot (well, probe), and emit a single warning to the kernel log if the > battery is already low. > > Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > --- > drivers/rtc/rtc-isl12022.c | 19 ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c > index 1b6659a9b33a..690dbb446d1a 100644 > --- a/drivers/rtc/rtc-isl12022.c > +++ b/drivers/rtc/rtc-isl12022.c > @@ -280,8 +280,25 @@ static void isl12022_set_trip_levels(struct device *dev) > mask = ISL12022_REG_VB85_MASK | ISL12022_REG_VB75_MASK; > > ret = regmap_update_bits(regmap, ISL12022_REG_PWR_VBAT, mask, val); > - if (ret) > + if (ret) { > dev_warn(dev, "unable to set battery alarm levels: %d\n", ret); > + return; > + } > + > + ret = regmap_write_bits(regmap, ISL12022_REG_BETA, > + ISL12022_BETA_TSE, ISL12022_BETA_TSE); > + if (ret) { > + dev_warn(dev, "unable to trigger battery level detection: %d\n", ret); This is too verbose, there is no action for the user upon getting this message. Setting TSE also enables temperature compensation, which may be an undesirable side effect. Shouldn't this be reverted if necessary? > + return; > + } > + > + ret = isl12022_read_sr(regmap); > + if (ret < 0) { > + dev_warn(dev, "unable to read status register: %d\n", ret); > + } else if (ret & (ISL12022_SR_LBAT85 | ISL12022_SR_LBAT75)) { > + dev_warn(dev, "battery voltage is below %u%%\n", > + (ret & ISL12022_SR_LBAT75) ? 75 : 85); This message is useless, I'd drop the whole block. > + } > } > > static int isl12022_probe(struct i2c_client *client) > -- > 2.37.2 >
On 12/06/2023 14:30:18+0200, Rasmus Villemoes wrote: > On 12/06/2023 13.30, Rasmus Villemoes wrote: > > > diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c > > index 1b6659a9b33a..690dbb446d1a 100644 > > --- a/drivers/rtc/rtc-isl12022.c > > +++ b/drivers/rtc/rtc-isl12022.c > > @@ -280,8 +280,25 @@ static void isl12022_set_trip_levels(struct device *dev) > > mask = ISL12022_REG_VB85_MASK | ISL12022_REG_VB75_MASK; > > > > ret = regmap_update_bits(regmap, ISL12022_REG_PWR_VBAT, mask, val); > > - if (ret) > > + if (ret) { > > dev_warn(dev, "unable to set battery alarm levels: %d\n", ret); > > + return; > > + } > > + > > + ret = regmap_write_bits(regmap, ISL12022_REG_BETA, > > + ISL12022_BETA_TSE, ISL12022_BETA_TSE); > > + if (ret) { > > + dev_warn(dev, "unable to trigger battery level detection: %d\n", ret); > > + return; > > + } > > + > > + ret = isl12022_read_sr(regmap); > > So testing this a bit more thoroughly reveals that the LBAT85/LBAT75 > bits do not get updated immediately after the TSE bit is set; one needs > to wait a little before the battery voltage detection is done and the SR > bits updated. Unfortunately, the data sheet doesn't say anything about > how long that might be or if there's some busy bit one could look at; > all it says is actually exactly what I've done above: > > The battery level monitor is not functional in battery backup > mode. In order to read the monitor bits after powering up VDD, > instigate a battery level measurement by setting the TSE bit to > "1" (BETA register), and then read the bits. > > IOW, please don't apply this patch until I figure out how to do this > properly. > The datasheet states 22ms for the temperature conversion so I would expect it takes about that time.
On 12/06/2023 16.15, Alexandre Belloni wrote: > On 12/06/2023 13:30:56+0200, Rasmus Villemoes wrote: >> Since the meaning of the SR_LBAT85 and SR_LBAT75 bits are different in >> battery backup mode, they may very well be set after power on, and >> stay set for up to a minute (i.e. until the battery detection in VDD >> mode happens when the seconds counter hits 59). This would mean that >> userspace doing a ioctl(RTC_VL_READ) early on could get a false >> positive. >> >> The battery level detection can also be triggered by explicitly >> writing a 1 to the TSE bit in the BETA register. Do that once during >> boot (well, probe), and emit a single warning to the kernel log if the >> battery is already low. >> >> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> >> --- >> drivers/rtc/rtc-isl12022.c | 19 ++++++++++++++++++- >> 1 file changed, 18 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c >> index 1b6659a9b33a..690dbb446d1a 100644 >> --- a/drivers/rtc/rtc-isl12022.c >> +++ b/drivers/rtc/rtc-isl12022.c >> @@ -280,8 +280,25 @@ static void isl12022_set_trip_levels(struct device *dev) >> mask = ISL12022_REG_VB85_MASK | ISL12022_REG_VB75_MASK; >> >> ret = regmap_update_bits(regmap, ISL12022_REG_PWR_VBAT, mask, val); >> - if (ret) >> + if (ret) { >> dev_warn(dev, "unable to set battery alarm levels: %d\n", ret); >> + return; >> + } >> + >> + ret = regmap_write_bits(regmap, ISL12022_REG_BETA, >> + ISL12022_BETA_TSE, ISL12022_BETA_TSE); >> + if (ret) { >> + dev_warn(dev, "unable to trigger battery level detection: %d\n", ret); > > This is too verbose, there is no action for the user upon getting this > message. OK. > Setting TSE also enables temperature compensation, which may be an > undesirable side effect. Shouldn't this be reverted if necessary? Well, I can't imagine the board designer not wanting/expecting temperature compensation to be enabled since they've spent the $$ on using a part with that capability. Also, we anyway set TSE if CONFIG_HWMON so that the TEMP registers get updated once per minute. If you insist I'll do the proper logic to set it back to 0 if it wasn't set beforehand, but I prefer to just keep it as-is. > >> + return; >> + } >> + >> + ret = isl12022_read_sr(regmap); >> + if (ret < 0) { >> + dev_warn(dev, "unable to read status register: %d\n", ret); >> + } else if (ret & (ISL12022_SR_LBAT85 | ISL12022_SR_LBAT75)) { >> + dev_warn(dev, "battery voltage is below %u%%\n", >> + (ret & ISL12022_SR_LBAT75) ? 75 : 85); > > This message is useless, I'd drop the whole block. I only added this as "compensation" for ripping out the warning in 1/8, since I assumed somebody actually wanted at least one warning in the kernel log if the battery is low. I/we are not going to scrape dmesg but will use the ioctl() to monitor the battery, so I'm perfectly happy to just remove this. That will also make the question of how long to wait after setting TSE moot, since certainly userspace won't be able to issue the ioctl() soon enough to see stale values in the LBAT bits. Rasmus
On 12/06/2023 16.17, Alexandre Belloni wrote: > On 12/06/2023 14:30:18+0200, Rasmus Villemoes wrote: >> So testing this a bit more thoroughly reveals that the LBAT85/LBAT75 >> bits do not get updated immediately after the TSE bit is set; one needs >> to wait a little before the battery voltage detection is done and the SR >> bits updated. Unfortunately, the data sheet doesn't say anything about >> how long that might be or if there's some busy bit one could look at; >> all it says is actually exactly what I've done above: >> >> The battery level monitor is not functional in battery backup >> mode. In order to read the monitor bits after powering up VDD, >> instigate a battery level measurement by setting the TSE bit to >> "1" (BETA register), and then read the bits. >> >> IOW, please don't apply this patch until I figure out how to do this >> properly. >> > > The datasheet states 22ms for the temperature conversion so I would > expect it takes about that time. It's most likely much shorter than that - if I just busy-read SR until the LBAT bits are clear, that takes no more than 2ms, and the final read of SR still has the BUSY bit set, indicating a temp conversion being (still) in progress. But I'd prefer to have Renesas provide the proper value rather than using some seems-to-work-on-my-desk. But but, it's probably moot, see other reply. Rasmus
On 13/06/2023 09:44:55+0200, Rasmus Villemoes wrote: > On 12/06/2023 16.15, Alexandre Belloni wrote: > > On 12/06/2023 13:30:56+0200, Rasmus Villemoes wrote: > >> Since the meaning of the SR_LBAT85 and SR_LBAT75 bits are different in > >> battery backup mode, they may very well be set after power on, and > >> stay set for up to a minute (i.e. until the battery detection in VDD > >> mode happens when the seconds counter hits 59). This would mean that > >> userspace doing a ioctl(RTC_VL_READ) early on could get a false > >> positive. > >> > >> The battery level detection can also be triggered by explicitly > >> writing a 1 to the TSE bit in the BETA register. Do that once during > >> boot (well, probe), and emit a single warning to the kernel log if the > >> battery is already low. > >> > >> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > >> --- > >> drivers/rtc/rtc-isl12022.c | 19 ++++++++++++++++++- > >> 1 file changed, 18 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c > >> index 1b6659a9b33a..690dbb446d1a 100644 > >> --- a/drivers/rtc/rtc-isl12022.c > >> +++ b/drivers/rtc/rtc-isl12022.c > >> @@ -280,8 +280,25 @@ static void isl12022_set_trip_levels(struct device *dev) > >> mask = ISL12022_REG_VB85_MASK | ISL12022_REG_VB75_MASK; > >> > >> ret = regmap_update_bits(regmap, ISL12022_REG_PWR_VBAT, mask, val); > >> - if (ret) > >> + if (ret) { > >> dev_warn(dev, "unable to set battery alarm levels: %d\n", ret); > >> + return; > >> + } > >> + > >> + ret = regmap_write_bits(regmap, ISL12022_REG_BETA, > >> + ISL12022_BETA_TSE, ISL12022_BETA_TSE); > >> + if (ret) { > >> + dev_warn(dev, "unable to trigger battery level detection: %d\n", ret); > > > > This is too verbose, there is no action for the user upon getting this > > message. > > OK. > > > Setting TSE also enables temperature compensation, which may be an > > undesirable side effect. Shouldn't this be reverted if necessary? > > Well, I can't imagine the board designer not wanting/expecting > temperature compensation to be enabled since they've spent the $$ on > using a part with that capability. Also, we anyway set TSE if > CONFIG_HWMON so that the TEMP registers get updated once per minute. > > If you insist I'll do the proper logic to set it back to 0 if it wasn't > set beforehand, but I prefer to just keep it as-is. > Ok, fine > > > >> + return; > >> + } > >> + > >> + ret = isl12022_read_sr(regmap); > >> + if (ret < 0) { > >> + dev_warn(dev, "unable to read status register: %d\n", ret); > >> + } else if (ret & (ISL12022_SR_LBAT85 | ISL12022_SR_LBAT75)) { > >> + dev_warn(dev, "battery voltage is below %u%%\n", > >> + (ret & ISL12022_SR_LBAT75) ? 75 : 85); > > > > This message is useless, I'd drop the whole block. > > I only added this as "compensation" for ripping out the warning in 1/8, > since I assumed somebody actually wanted at least one warning in the > kernel log if the battery is low. > No need, I had a patch removing the message anyway. > I/we are not going to scrape dmesg but will use the ioctl() to monitor > the battery, so I'm perfectly happy to just remove this. That will also > make the question of how long to wait after setting TSE moot, since > certainly userspace won't be able to issue the ioctl() soon enough to > see stale values in the LBAT bits. > Exactly. > Rasmus >
diff --git a/drivers/rtc/rtc-isl12022.c b/drivers/rtc/rtc-isl12022.c index 1b6659a9b33a..690dbb446d1a 100644 --- a/drivers/rtc/rtc-isl12022.c +++ b/drivers/rtc/rtc-isl12022.c @@ -280,8 +280,25 @@ static void isl12022_set_trip_levels(struct device *dev) mask = ISL12022_REG_VB85_MASK | ISL12022_REG_VB75_MASK; ret = regmap_update_bits(regmap, ISL12022_REG_PWR_VBAT, mask, val); - if (ret) + if (ret) { dev_warn(dev, "unable to set battery alarm levels: %d\n", ret); + return; + } + + ret = regmap_write_bits(regmap, ISL12022_REG_BETA, + ISL12022_BETA_TSE, ISL12022_BETA_TSE); + if (ret) { + dev_warn(dev, "unable to trigger battery level detection: %d\n", ret); + return; + } + + ret = isl12022_read_sr(regmap); + if (ret < 0) { + dev_warn(dev, "unable to read status register: %d\n", ret); + } else if (ret & (ISL12022_SR_LBAT85 | ISL12022_SR_LBAT75)) { + dev_warn(dev, "battery voltage is below %u%%\n", + (ret & ISL12022_SR_LBAT75) ? 75 : 85); + } } static int isl12022_probe(struct i2c_client *client)