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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.