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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7625BC18E5B for ; Mon, 16 Mar 2020 16:03:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5800420753 for ; Mon, 16 Mar 2020 16:03:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731672AbgCPQC7 (ORCPT ); Mon, 16 Mar 2020 12:02:59 -0400 Received: from muru.com ([72.249.23.125]:60608 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731618AbgCPQC7 (ORCPT ); Mon, 16 Mar 2020 12:02:59 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id A658F80AA; Mon, 16 Mar 2020 16:03:44 +0000 (UTC) Date: Mon, 16 Mar 2020 09:02:55 -0700 From: Tony Lindgren To: "Arthur D." Cc: Pavel Machek , Merlijn Wajer , sre@kernel.org, linux-pm@vger.kernel.org, linux-omap@vger.kernel.org Subject: Re: [PATCH 01/15] power: supply: cpcap-battery: Fix battery full status reporting Message-ID: <20200316160255.GL37466@atomide.com> References: <20200315151206.30909-1-spinal.by@gmail.com> <20200315185857.GA4914@amd> <20200315215949.GK37466@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org * Arthur D. [200316 01:31]: > Hi, Tony. > > It seems like a misunderstanding here. There's no problem in detecting > if the charging is in progress. The green led is switched off and > the battery current sign is changed from "-" to "+" (which means > that the battery is being discharged). So there's no need in additional > checks. For cpcap-battery this situation seems like a battery stopped > charging. And it doesn't matter if that was a user who disconnected > the charger or it was done somewhere in a driver/firmware/hardware. > > The problem is that the charging current cant get to the point <100 mA, > not talking about <50 mA. And that's why I set the value of 112 mA for > the end of charge current: to help the kernel to detect this plateau and > to stop the calibration cycle, so the userspace can get all the battery > parameters I mentioned in the previous mail. OK I guess that's easy to change if we figure out something better :) Maybe add some define for it like CPCAP_BATTERY_FULL_CHARGE_CURRENT or similar? > Please note, that the behaviour I mentioned was observed only when the > conditions written in my last mail were met. The important one was: > > 2) the display backlight is off > > Because when I unlocked the display the charging current was able > to go below 112 mA. Of course I couldn't rely on something like this: > the user should stay with backlight on to have the battery calibrated. > Think about it: waiting for the charging current to drop from 100 mA > to 50 mA can take dozens of minutes (it depends on the age of battery - > the older the battery the longer it will take), and the user should > force somehow the device to not switch off the display hightlight > until the battery is calibrated. > > Of course it's unacceptable, so I decided to set the end of charge > current limit to 112 mA. Which allows the user to just put the device > on a table and to wait until it's fully charged without a need > to interfere the charging process with some action from the user. Yeah OK thanks. Tony