From: Richard Hughes <hughsient@gmail.com>
To: Alexey Starikovskiy <astarikovskiy@suse.de>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
linux-acpi <linux-acpi@vger.kernel.org>, mjg <mjg@redhat.com>,
Matthias Clasen <mclasen@redhat.com>
Subject: [patch] ACPI battery driver emits POWER_SUPPLY_STATUS_FULL when power lead plugged in
Date: Sun, 25 Jan 2009 10:28:17 +0000 [thread overview]
Message-ID: <1232879297.3518.26.camel@hughsie-work.lan> (raw)
In-Reply-To: <497B43D3.80703@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
On Sat, 2009-01-24 at 19:37 +0300, Alexey Starikovskiy wrote:
> > I don't understand, why this guesswork over fully charged? If you cannot
> > detect fully charged, then *don't*.
> >
> > But if you must sinthesize it, and you can get an up-to-date "last full
> > capacity" from the battery when comparing, I suggest:
> >
> > full = (current capacity == last full capacity) && !charging &&
> > !discharging
> certainly, 90% is wrong, but 100% makes a day...
I think we need some sort of logic like this.
> > That would *still* be wrong in a few corner cases, but at least they're rare
> > corner cases that happens only when the pack recalibrates its fuel gauge.
> full in this case is not exact term. As any other term beside current_now and voltage_now.
> Capacity of the battery is estimated, so any number that was depending on it, is estimated too.
Right, never underestimate the brokenness of some people's batteries out
there. Coupled with broken BIOS's, some of the fix-up code in HAL is
'interesting'. I think all the fix-up code in HAL belongs in in the
kernel.
> > If there isn't a reliable way to detect the "full" state, just drop the
> > fully charged detection altogether.
> People are used to see "full" state of the battery. I think we could tolerate not-full-enough
> for sub-second interval instead of dropping full state altogether.
We shouldn't drop the full state, we should just add some metric like
above. What about something like the attached (untested) patch? Would
something this be accepted?
Richard.
[-- Attachment #2: acpi-battery-charged.patch --]
[-- Type: text/x-patch, Size: 1776 bytes --]
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 65132f9..d400a11 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -138,6 +138,38 @@ static int acpi_battery_technology(struct acpi_battery *battery)
static int acpi_battery_get_state(struct acpi_battery *battery);
+static int acpi_battery_is_charged(struct acpi_battery *battery)
+{
+ int percentage;
+
+ /* either charging or discharging */
+ if (battery->state != 0)
+ return 0;
+
+ /* battery not reporting charge */
+ if (battery->full_charge_capacity == ACPI_BATTERY_VALUE_UNKNOWN ||
+ battery->capacity_now == 0)
+ return 0;
+
+ /* 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;
+ }
+
+ /* fallback to using design values for broken batteries */
+ if (battery->design_capacity != ACPI_BATTERY_VALUE_UNKNOWN &&
+ battery->design_capacity != 0) {
+ percentage = (100 * battery->capacity_now) / battery->design_capacity;
+ if (percentage > 90)
+ return 1;
+ }
+
+ return 0;
+}
+
static int acpi_battery_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
@@ -155,7 +187,7 @@ static int acpi_battery_get_property(struct power_supply *psy,
val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
else if (battery->state & 0x02)
val->intval = POWER_SUPPLY_STATUS_CHARGING;
- else if (battery->state == 0)
+ else if (acpi_battery_is_charged(battery))
val->intval = POWER_SUPPLY_STATUS_FULL;
else
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
next prev parent reply other threads:[~2009-01-25 10:35 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 ` Richard Hughes [this message]
2009-01-25 10:55 ` [patch] " Alexey Starikovskiy
2009-01-25 13:42 ` Henrique de Moraes Holschuh
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=1232879297.3518.26.camel@hughsie-work.lan \
--to=hughsient@gmail.com \
--cc=astarikovskiy@suse.de \
--cc=hmh@hmh.eng.br \
--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