From: Tony Lindgren <tony@atomide.com>
To: "Arthur D." <spinal.by@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>, Merlijn Wajer <merlijn@wizzup.org>,
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
Date: Mon, 16 Mar 2020 09:02:55 -0700 [thread overview]
Message-ID: <20200316160255.GL37466@atomide.com> (raw)
In-Reply-To: <op.0hjs4kk2hxa7s4@supervisor.net28>
* Arthur D. <spinal.by@gmail.com> [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
prev parent reply other threads:[~2020-03-16 16:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-15 15:11 [PATCH 01/15] power: supply: cpcap-battery: Fix battery full status reporting Arthur Demchenkov
2020-03-15 15:11 ` [PATCH 02/15] power: supply: cpcap-battery: Improve battery full status detection Arthur Demchenkov
2020-03-15 16:46 ` Tony Lindgren
2020-03-15 15:11 ` [PATCH 03/15] power: supply: cpcap-battery: Fix battery low status reporting Arthur Demchenkov
2020-03-21 14:47 ` Tony Lindgren
2020-03-21 21:40 ` Arthur D.
2020-03-15 15:11 ` [PATCH 04/15] power: supply: cpcap-battery: Add charge_full property Arthur Demchenkov
2020-03-15 15:11 ` [PATCH 05/15] power: supply: cpcap-battery: Add charge_now property Arthur Demchenkov
2020-03-15 15:11 ` [PATCH 06/15] power: supply: cpcap-battery: Initialize with user provided data Arthur Demchenkov
2020-03-21 14:54 ` Tony Lindgren
2020-03-21 22:08 ` Arthur D.
2020-03-21 22:21 ` Tony Lindgren
2020-03-15 15:11 ` [PATCH 07/15] power: supply: cpcap-battery: Rewrite capacity reporting Arthur Demchenkov
2020-03-15 15:11 ` [PATCH 08/15] power: supply: cpcap-battery: Get rid of rough capacity percentage Arthur Demchenkov
2020-03-15 15:12 ` [PATCH 09/15] power: supply: cpcap-battery: Increse low voltage bound Arthur Demchenkov
2020-03-15 15:12 ` [PATCH 10/15] power: supply: cpcap-battery: Improve full status reporting Arthur Demchenkov
2020-03-15 15:12 ` [PATCH 11/15] power: supply: cpcap-battery: Rename properties, variables and functions Arthur Demchenkov
2020-03-15 15:12 ` [PATCH 12/15] power: supply: cpcap-battery: stabilize charge_full value Arthur Demchenkov
2020-03-15 15:12 ` [PATCH 13/15] power: supply: cpcap-battery: Fine tune end of charge current Arthur Demchenkov
2020-03-15 15:12 ` [PATCH 14/15] power: supply: cpcap-battery: Make it behave like bq27200 Arthur Demchenkov
2020-03-15 15:12 ` [PATCH 15/15] power: supply: cpcap-battery: Add rounding to capacity reporting Arthur Demchenkov
2020-03-15 18:58 ` [PATCH 01/15] power: supply: cpcap-battery: Fix battery full status reporting Pavel Machek
2020-03-15 19:19 ` Tony Lindgren
2020-03-15 20:51 ` Arthur D.
2020-03-15 21:59 ` Tony Lindgren
2020-03-16 1:30 ` Arthur D.
2020-03-16 16:02 ` Tony Lindgren [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200316160255.GL37466@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=merlijn@wizzup.org \
--cc=pavel@ucw.cz \
--cc=spinal.by@gmail.com \
--cc=sre@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).