Linux Power Management development
 help / color / mirror / Atom feed
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 13:21:55 +0300	[thread overview]
Message-ID: <20210619102155.GC14960@home.paul.comp> (raw)
In-Reply-To: <8390c743-e4a4-bf1d-457e-2bfdcf9143d2@manjaro.org>

Hi Tobias,

On Sat, Jun 19, 2021 at 11:52:34AM +0200, Tobias Schramm wrote:
> > Are you sure the chip reports current state of charge relative to the
> > full design capacity rather than to the latest auto-calibrated full
> > capacity? That would mean that over time as the cells wear out
> > cw_bat->soc (PROP_CAPACITY) is never going to be reaching 100; does
> > this match your experience?
> > 
> As far as I'm aware the gauge reports SoC relative to what it believes to be
> the the current, auto-calibrated full battery capacity.
> However, since I don't know how to extract that value from the gauge we just
> always assume it to be the design capacity [1].
> Since we inquire the gauge about current SoC directly [2] there is no way
> for any miscalculation on our end preventing it from reaching 100%.

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.

So to sum up, what you can get from the chip itself:

0. Battery voltage; pretty accurate.

1. Its idea of current state of charge; this is percentage relative to
the charge_full; I'd expect that to be reasonably accurate for not too
worn-out batteries.

2. Its idea of the remaining run time; involves secret magic to
somehow guess the current; I'd expect this to be relatively
inaccurate, would be interesting to learn how this performs for your
real life loads.

That's it. We can't learn charge_full and current_now.


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.

Now you're also using the same value to calculate the current
reported. But the CW2015 datasheet says that SOC is relative to the
full capacity, not full design capacity, so the current you report
might get wildly inaccurate too. Same about charge_now that Martin
added: you just can't rely on unknown values when doing calculations.


If I was using this driver I would certainly prefer it to _not_ report
any grossly inaccurate guessimations. So I propose to remove
POWER_SUPPLY_PROP_CHARGE_FULL, POWER_SUPPLY_PROP_CHARGE_NOW and
POWER_SUPPLY_PROP_CURRENT_NOW altogether since they can't be
meaningfully obtained from anywhere. Please do not fool userspace into
thinking they have some information when in fact it's pulled out of
thin air.

I'm not the authority here so it would be nice to hear the opinion of
the subsystem maintainers, adding Sebastian to Cc. Ready to be proven
wrong :)

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

  reply	other threads:[~2021-06-19 10:22 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 [this message]
2021-06-19 13:48       ` Tobias Schramm
2021-06-19 19:06         ` Paul Fertser

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=20210619102155.GC14960@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