public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Richard Hughes <hughsient@gmail.com>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>,
	linux-acpi <linux-acpi@vger.kernel.org>, mjg <mjg@redhat.com>,
	Matthias Clasen <mclasen@redhat.com>
Subject: Re: [patch] ACPI battery driver emits POWER_SUPPLY_STATUS_FULL when power lead plugged in
Date: Sun, 25 Jan 2009 11:42:03 -0200	[thread overview]
Message-ID: <20090125134203.GA12776@khazad-dum.debian.net> (raw)
In-Reply-To: <1232879297.3518.26.camel@hughsie-work.lan>

On Sun, 25 Jan 2009, Richard Hughes wrote:
> +	/* good batteries update full_charge as the batteries degrade */
> +	if (battery->full_charge_capacity != ACPI_BATTERY_VALUE_UNKNOWN &&
> +	    battery->full_charge_capacity != 0) {
> +		percentage = (100 * battery->capacity_now) / battery->full_charge_capacity;
> +		if (percentage > 90)
> +			return 1;

You guys have to remember that the hardware can know when the cells are
physically full.  That has _nothing_ to do with any level estimation,
battery cells behave differently when they are full, and that's what the
overcharge protection circuitry detects.

So, the above test will still break on any proper battery subsystem with the
high watermark set below 100%, as those systems update full_charge_capacity
*only* when the cells really are full (and not because the EC decided to
stop the charging before they were full).

Thus, it will break if you set the threshold to stop charging (high
watermark) above 90% but below 100% on a T-, X-, R- or W-series ThinkPad,
for example.

The test would still have to be:
	if (battery->full_charge_capacity != ACPI_BATTERY_VALUE_UNKNOWN &&
	    battery->full_charge_capacity != 0 &&
	    battery->capacity_now == battery->full_charge_capacity)
		return 1;

or, if there is crap so bad out there that requires it:
	if (battery->full_charge_capacity != ACPI_BATTERY_VALUE_UNKNOWN &&
	    battery->full_charge_capacity != 0 &&
	    battery->capacity_now == battery->full_charge_capacity) {
		percentage = (100 * battery->capacity_now) / battery->full_charge_capacity;
		if (percentage > 90)
			return 1;

to work well on proper battery firmware set to stop before the battery is
full.

If that can't work well enough with the crap out there, I am out of ideas,
and I'd say we'd have to quirk either the good or the bad systems to
properly implement the FULL state.

As for the sub-second "blinks" the EC does in battery states, if one wants
to avoid that, better report states only after they have been stable for one
or two seconds.  Not that a report of CHARGING->IDLE->FULL is incorrect or a
problem IMHO, but I don't know if that's what you guys are observing.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

  parent reply	other threads:[~2009-01-25 13:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-23 16:57 ACPI battery driver emits POWER_SUPPLY_STATUS_FULL when power lead plugged in Richard Hughes
2009-01-23 19:00 ` Alexey Starikovskiy
2009-01-23 22:02   ` Henrique de Moraes Holschuh
2009-01-23 23:39     ` Richard Hughes
2009-01-24  0:14       ` Alexey Starikovskiy
2009-01-24 12:41         ` Henrique de Moraes Holschuh
2009-01-24 16:37           ` Alexey Starikovskiy
2009-01-25 10:28             ` [patch] " Richard Hughes
2009-01-25 10:55               ` Alexey Starikovskiy
2009-01-25 13:42               ` Henrique de Moraes Holschuh [this message]
2009-01-25 15:13                 ` Richard Hughes
2009-01-25 19:50                   ` Alexey Starikovskiy
2009-01-26  8:43                     ` Richard Hughes
2009-01-28 13:20                 ` [patch] ACPI battery driver emits POWER_SUPPLY_STATUS_FULL when power lead plugged in (resend) Richard Hughes
2009-01-30 14:07                   ` Henrique de Moraes Holschuh
2009-02-08  3:59                     ` Len Brown
2009-02-08 10:08                       ` Richard Hughes

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=20090125134203.GA12776@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=astarikovskiy@suse.de \
    --cc=hughsient@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mclasen@redhat.com \
    --cc=mjg@redhat.com \
    /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