From: Paul Fertser <fercerpav@gmail.com>
To: Tobias Schramm <t.schramm@manjaro.org>
Cc: Martin Ashby <martin@ashbysoft.com>,
linux-pm@vger.kernel.org, Sebastian Reichel <sre@kernel.org>
Subject: Re: [PATCH] power: supply: cw2015: Add CHARGE_NOW support
Date: Sat, 19 Jun 2021 22:06:29 +0300 [thread overview]
Message-ID: <20210619190628.GN14960@home.paul.comp> (raw)
In-Reply-To: <84e6a4f2-7eaa-c606-d5e7-b15da91b24be@manjaro.org>
Hi Tobias,
On Sat, Jun 19, 2021 at 03:48:12PM +0200, Tobias Schramm wrote:
> Am 19.06.21 um 12:21 schrieb Paul Fertser:
> ...
> > After reading the datasheet for the gauge I'm rather disappointed. Not
> > using a shunt resistor for real current measurements and instead
> > relying on some magic doesn't make any sense in my book.
>
> I felt similarly when reading it for the first time. However, by now some
> more well known manufacturers have started offering similar products [1].
Thank you for the link, that's rather interesting, especially combined
with the TRM for the product.
What I find of specific relevance to our current discussion is that
this chip provides not one but two "charge_full" values: one assuming
less than C/20 load, and another assuming the current load. While
cx2015 doesn't give even one.
> It seems the manufacturers are relying on internal resistance of the battery
> to measure current draw.
I'm still puzzled about how they might be able to estimate the current
looking just at the voltage and temperature. Apparently they're
successful enough but how do they manage?
> In general it seems to work pretty well in the Pine64 Pinebook Pro for about
> two years now.
In other words, if you leave the laptop idling and check RRT every now
and then, you see reasonable values and it reaches zero at about the
time it turns off; and same when you're doing an e.g. stress-ng --cpu
run?
> > Your driver code always reports charge_full equal to
> > charge_full_design which is plain incorrect IMHO. It's just wrong and
> > misleading, as after e.g. 2 years of usage the battery might lose half
> > its capacity; and people are used to get real data from power_supply
> > subsystem to be able to judge about battery health and performance.
>
> It most definitely is. I'm not really happy with reporting them either.
> However it seems that a lot of battery widgets get very confused if those
> stats are not reported.
Probably rightfully so? Having no reliable data to show _is_ indeed
confusing.
> Thus I went for some level of guestimation there. Please feel free to remove
> them and test whether all the usual battery monitoring tools still work.
> I'll be more than happy to remove them if it is not a problem anymore.
If I had a Pinebook Pro I would be using Xmobar on it and I would
propose a patch to fall back to show "capacity" and "time_to_empty" in
cases like that; in other words, knowing the limitations, I'd make my
own choices about what to show where and whether I need any
guessimations or not.
> The supported parameters were mostly chosen based on the Android
> reference code provided to me by CellWise
If anything, that should serve as a "requires careful
re-consideration" red flag ;)
> and user feedback (battery applet compatibility). I'd hate breaking
> the latter.
If some battery applet finds certain set of parameters to be
insufficient then it's just that, the applet is not compatible with
this hardware. I know the "we do not break userspace" mantra but
breaking something (that used to work before) is one thing and luring
the userspace into doing things by presenting it with fake data is
another.
My userspace is Xmobar and I'm ready to fix it for Pinebook Pro users
if you remove reporting of the fake data.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
prev parent reply other threads:[~2021-06-19 19:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 12:42 [PATCH] power: supply: cw2015: Add CHARGE_NOW support Martin Ashby
2021-02-18 14:53 ` Tobias Schramm
2021-06-18 12:30 ` Paul Fertser
2021-06-19 9:52 ` Tobias Schramm
2021-06-19 10:21 ` Paul Fertser
2021-06-19 13:48 ` Tobias Schramm
2021-06-19 19:06 ` Paul Fertser [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=20210619190628.GN14960@home.paul.comp \
--to=fercerpav@gmail.com \
--cc=linux-pm@vger.kernel.org \
--cc=martin@ashbysoft.com \
--cc=sre@kernel.org \
--cc=t.schramm@manjaro.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