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 Fox wrote:
>
>> i'm pretty sure those numbers (and the corresponding numbers from the
>> 1.5 DSDT) came f
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 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 da
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:1
On Fri, 10 Dec 2010 14:56:15 -1000
Mitch Bradley 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 spe
On Sat, 11 Dec 2010 00:41:20 +
David Woodhouse 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
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 Woodhouse wrote:
>
>> O
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
On Fri, 10 Dec 2010 22:15:10 +
David Woodhouse 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 */
> > +
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;
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
Signed-off-by: Paul Fox
diff --git a/drivers/power/olpc_battery.c b/drivers/power/
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
---
drivers/power/olpc_battery.c | 54 ++
1 files
12 matches
Mail list logo
