[PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
Some user space software (read: UPower) uses CHARGE_FULL_DESIGN for internal
calculations. The design capacity of the OLPC batteries is effectively fixed
and only needs to be exported.
Signed-off-by: Sascha Silbe sascha-...@silbe.org
Signed-off-by: Paul Fox p...@laptop.org
diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index 5bc1dcf..1f01d4c 100644
--- a/drivers/power/olpc_battery.c
+++ b/drivers/power/olpc_battery.c
@@ -201,6 +201,54 @@ static int olpc_bat_get_tech(union power_supply_propval
*val)
return ret;
}
+static int olpc_bat_get_charge_full_design(union power_supply_propval *val)
+{
+ uint8_t ec_byte;
+ union power_supply_propval tech;
+ int ret, mfr;
+
+ ret = olpc_bat_get_tech(tech);
+ if (ret)
+ return ret;
+
+ ec_byte = BAT_ADDR_MFR_TYPE;
+ ret = olpc_ec_cmd(EC_BAT_EEPROM, ec_byte, 1, ec_byte, 1);
+ if (ret)
+ return ret;
+
+ mfr = ec_byte 4;
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
+
/*
* Battery properties
*/
@@ -294,6 +342,11 @@ static int olpc_bat_get_property(struct power_supply *psy,
else
val-intval = POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
break;
+ case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
+ ret = olpc_bat_get_charge_full_design(val);
+ if (ret)
+ return ret;
+ break;
case POWER_SUPPLY_PROP_TEMP:
ret = olpc_ec_cmd(EC_BAT_TEMP, NULL, 0, (void *)ec_word, 2);
if (ret)
@@ -341,6 +394,7 @@ static enum power_supply_property olpc_bat_props[] = {
POWER_SUPPLY_PROP_CURRENT_AVG,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+ POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
POWER_SUPPLY_PROP_TEMP,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
POWER_SUPPLY_PROP_MANUFACTURER,
--
1.7.2.3
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
I don't much like hard-coding it in the kernel. Can the firmware expose
these values in the device-tree?
--
dwmw2
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
On Fri, 10 Dec 2010 22:15:10 +
David Woodhouse dw...@infradead.org wrote:
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
I don't much like hard-coding it in the kernel. Can the firmware
expose these values in the device-tree?
It there is, it's not at all clear. The values are fetched from the
EC, which get them from the EEPROM. The DT has a battery entry, but it
contains nothing useful:
/proc/device-tree/batt...@0/name
/proc/device-tree/batt...@0/reg
/proc/device-tree/batt...@0/.node
Nor is there anything in the DT related to the battery EEPROM.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
On Fri, 2010-12-10 at 16:38 -0800, Andres Salomon wrote: It there is, it's not at all clear. The values are fetched from the EC, which get them from the EEPROM. If the EC knows them, can't we ask the EC rather than pulling numbers our of our arse in the kernel? The DT has a battery entry, but it contains nothing useful: /proc/device-tree/batt...@0/name /proc/device-tree/batt...@0/reg /proc/device-tree/batt...@0/.node The driver ought to be matching on that rather than registering its own platform device. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
There is some battery info in the _BIF (battery info) method in the BATT
node of the ACPI DSDT. I don't remember if it is correct or not. The
numbers below match the DSDT numbers.
On 12/10/2010 2:38 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 22:15:10 +
David Woodhousedw...@infradead.org wrote:
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
I don't much like hard-coding it in the kernel. Can the firmware
expose these values in the device-tree?
It there is, it's not at all clear. The values are fetched from the
EC, which get them from the EEPROM. The DT has a battery entry, but it
contains nothing useful:
/proc/device-tree/batt...@0/name
/proc/device-tree/batt...@0/reg
/proc/device-tree/batt...@0/.node
Nor is there anything in the DT related to the battery EEPROM.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
On Sat, 11 Dec 2010 00:41:20 + David Woodhouse dw...@infradead.org wrote: On Fri, 2010-12-10 at 16:38 -0800, Andres Salomon wrote: It there is, it's not at all clear. The values are fetched from the EC, which get them from the EEPROM. If the EC knows them, can't we ask the EC rather than pulling numbers our of our arse in the kernel? Sorry, i meant the battery manufacturer/type info is fetched from the EC (and the DT doesn't appear to have *that* information, much less the magic values that this patch uses). Pgf or Richard can probably tell us if the magic numbers can be derived from the EC. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
On Fri, 10 Dec 2010 14:56:15 -1000
Mitch Bradley w...@laptop.org wrote:
There is some battery info in the _BIF (battery info) method in the
BATT node of the ACPI DSDT. I don't remember if it is correct or
not. The numbers below match the DSDT numbers.
Wait, so where did *those* numbers come from? A spec somewhere, the
EC, or did you actually reverse engineer them?
(Note that ACPI is only available on XO-1.5, so pulling them from ACPI
on XO-1 isn't an option.)
On 12/10/2010 2:38 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 22:15:10 +
David Woodhousedw...@infradead.org wrote:
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
By not providing more information, I was sending a subtle signal that I
am busy with something else right now and do not want to go into
digging up everything I know or can find out about batteries mode at
the moment.
On 12/10/2010 3:09 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 14:56:15 -1000
Mitch Bradleyw...@laptop.org wrote:
There is some battery info in the _BIF (battery info) method in the
BATT node of the ACPI DSDT. I don't remember if it is correct or
not. The numbers below match the DSDT numbers.
Wait, so where did *those* numbers come from? A spec somewhere, the
EC, or did you actually reverse engineer them?
(Note that ACPI is only available on XO-1.5, so pulling them from ACPI
on XO-1 isn't an option.)
On 12/10/2010 2:38 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 22:15:10 +
David Woodhousedw...@infradead.org wrote:
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
i'm pretty sure those numbers (and the corresponding numbers from the
1.5 DSDT) came from the battery manufacturer. obviously we could move
the data to the EC, but i'm not sure what the advantage of that would
be. i know that the numbers don't come from the battery itself.
paul
mitch wrote:
By not providing more information, I was sending a subtle signal that I
am busy with something else right now and do not want to go into
digging up everything I know or can find out about batteries mode at
the moment.
On 12/10/2010 3:09 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 14:56:15 -1000
Mitch Bradleyw...@laptop.org wrote:
There is some battery info in the _BIF (battery info) method in the
BATT node of the ACPI DSDT. I don't remember if it is correct or
not. The numbers below match the DSDT numbers.
Wait, so where did *those* numbers come from? A spec somewhere, the
EC, or did you actually reverse engineer them?
(Note that ACPI is only available on XO-1.5, so pulling them from ACPI
on XO-1 isn't an option.)
On 12/10/2010 2:38 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 22:15:10 +
David Woodhousedw...@infradead.org wrote:
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
Alright, thanks. I guess a comment in the (kernel) source saying as
much would be useful.
On Fri, 10 Dec 2010 21:41:00 -0500 Paul Fox p...@laptop.org wrote:
i'm pretty sure those numbers (and the corresponding numbers from the
1.5 DSDT) came from the battery manufacturer. obviously we could move
the data to the EC, but i'm not sure what the advantage of that would
be. i know that the numbers don't come from the battery itself.
paul
mitch wrote:
By not providing more information, I was sending a subtle signal
that I am busy with something else right now and do not want to go
into digging up everything I know or can find out about
batteries mode at the moment.
On 12/10/2010 3:09 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 14:56:15 -1000
Mitch Bradleyw...@laptop.org wrote:
There is some battery info in the _BIF (battery info) method in
the BATT node of the ACPI DSDT. I don't remember if it is
correct or not. The numbers below match the DSDT numbers.
Wait, so where did *those* numbers come from? A spec somewhere,
the EC, or did you actually reverse engineer them?
(Note that ACPI is only available on XO-1.5, so pulling them
from ACPI on XO-1 isn't an option.)
On 12/10/2010 2:38 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 22:15:10 +
David Woodhousedw...@infradead.org wrote:
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
On 12/10/2010 10:22 PM, Andres Salomon wrote: Alright, thanks. I guess a comment in the (kernel) source saying as much would be useful. On Fri, 10 Dec 2010 21:41:00 -0500 Paul Foxp...@laptop.org wrote: i'm pretty sure those numbers (and the corresponding numbers from the 1.5 DSDT) came from the battery manufacturer. obviously we could move the data to the EC, but i'm not sure what the advantage of that would be. i know that the numbers don't come from the battery itself. Some history for those who may not know: The design of the battery system in the EC is sort of out in its own class. OLPC sort of forced that to happen. 1) We used battery chemistry's few laptop have used and used both of them at the same time. NiMH and LiFePO4. (In the LiFePO4 case, I think we are the only laptop that has used it.) 2) In XO-1 we had the We hate the evil ACPI mantra. To top it off we had this requirement of the battery lasting 2000 cycles. This requires some very funky stuff in the NiMH case. Basically for NiMH there is a really complex 12 page flowchart on charging. We have now stopped caring about NiMH but the 1.0 and 1.5 carry around a lot of legacy NiMH baggage. In 1.75 we have purged all of that. We had (good) reasons for doing all of the above but we basically forced quanta to come up with a battery subsystem on their own. Not one that followed any of the accepted standards at the time. The system that they came up with does not have any concept of battery capacity. It uses markers inherent in the battery characteristics to determine when the battery is full and empty. To track the state of charge (SOC) each chemistry has a setting for what the net difference for 1% SOC is in the accumulated current register (ACR). If the ACR goes up or down that value then the SOC is ++ or -- 1%. The ACR is used as a free running counter of charge. When a full or empty marker is found the SOC is snapped to a full (97%) or empty (7%) [1]. So none of the max capacity values that you are asking about exist in the EC because they aren't necessary for things to work. All the values about max capacity are values that I pulled from the manufactures datasheet and put up on the wiki. http://wiki.laptop.org/go/Laptop_Batteries Until now there hasn't been a reason to add this info into the EC code. There is nothing hard about adding them except that its a few more commands for the EC, OFW, and kernel to add and then all be in sync. There's also no concept of calibration in the EC code. Last time Sascha brought all this up I began to think about how to do some sort of calibration. It would be a nice feature to have. We already have a some issues because the battery capacity varies +/- 5%. If I had calibration then I could store the real capacity in the eeprom of the battery. Hopefully I can get a chance to figure out a good way to do this for 1.75 and keep it so that batteries are backward compatible. in 1.5 and 1.0 If you want the max capacity values added to the EC code with EC commands to fetch that extra the data then that's not a big problem just tell me. But that won't help with running your new kernel on an old XO with older firmware so you will still have to hardcode it for them. I think it makes sense to hardcode them until such time as I have calibration in the EC code and then the kernel can ask the EC (or OFW via DT for them) [1] I have no idea where those values came from. I'm changing them in 1.75 to be more sane. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
The maximum (full) charge of the battery is required for UPower to
return the current capacity, both directly (as CHARGE_FULL_DESIGN) and
indirectly (calculating CHARGE_NOW).
Signed-off-by: Sascha Silbe sascha-...@silbe.org
---
drivers/power/olpc_battery.c | 54 ++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index 753c170..dbe5b85 100644
--- a/drivers/power/olpc_battery.c
+++ b/drivers/power/olpc_battery.c
@@ -200,6 +200,54 @@ static int olpc_bat_get_tech(union power_supply_propval
*val)
return ret;
}
+static int olpc_bat_get_charge_full_design(union power_supply_propval *val)
+{
+ uint8_t ec_byte;
+ union power_supply_propval tech;
+ int ret, mfr;
+
+ ret = olpc_bat_get_tech(tech);
+ if (ret)
+ return ret;
+
+ ec_byte = BAT_ADDR_MFR_TYPE;
+ ret = olpc_ec_cmd(EC_BAT_EEPROM, ec_byte, 1, ec_byte, 1);
+ if (ret)
+ return ret;
+
+ mfr = ec_byte 4;
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
+
/*
* Battery properties
*/
@@ -293,6 +341,11 @@ static int olpc_bat_get_property(struct power_supply *psy,
else
val-intval = POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
break;
+ case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
+ ret = olpc_bat_get_charge_full_design(val);
+ if (ret)
+ return ret;
+ break;
case POWER_SUPPLY_PROP_TEMP:
ret = olpc_ec_cmd(EC_BAT_TEMP, NULL, 0, (void *)ec_word, 2);
if (ret)
@@ -342,6 +395,7 @@ static enum power_supply_property olpc_bat_props[] = {
POWER_SUPPLY_PROP_CURRENT_AVG,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+ POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
POWER_SUPPLY_PROP_TEMP,
#ifndef CONFIG_OLPC_XO_1_5
POWER_SUPPLY_PROP_TEMP_AMBIENT,
--
1.6.5
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
