Battery information in sysfs for userspace tools

Battery information in sysfs for userspace tools

[Yves-Alexis Perez]

Hi,

Evgeni Golov (CC:ed) is currently taking care of fixing acpitool wrt.
sysfs support (which is badly broken). 

Using the files in /sys/class/power_supply/BAT*/ we have some wondering
about units.

For the current rate, for example, we have:

corsac@hidalgo: grep . /sys/class/power_supply/BAT0/*now    
/sys/class/power_supply/BAT0/current_now:14415000
/sys/class/power_supply/BAT0/energy_now:44170000
/sys/class/power_supply/BAT0/voltage_now:12481000
corsac@hidalgo: grep . /sys/devices/platform/smapi/BAT0/*now
/sys/devices/platform/smapi/BAT0/current_now:1151
/sys/devices/platform/smapi/BAT0/power_now:14365

I'm a bit puzzled with the differences in current_now (the battery is
charging at that time), and don't really know if we can trust the units.

I would assume (in /sys/class/power_supply):
current_now to be in uA
energy_now to be in uWh
voltage_now to be in uV

as said in include/linux/power_supply.h

/*
 * All voltages, currents, charges, energies, time and temperatures in uV,
 * µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
 * stated. It's driver's job to convert its raw values to units in which
 * this class operates.
 */


and the current (dis)charging rate in W to be
(current_now/1.000.000)*(energy_now/1.000.000). But that gives, for an
end of charge, a charging rate of:

(14415000 / 1000000) * (12481000 / 1000000) = approx. 179.91362

which seems definitely wrong.

Where am I mistaken?

Btw this is on 2.6.29.2 on a Thinkpad T61, and tp-smapi is loaded.

Cheers,
-- 
Yves-Alexis

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Battery information in sysfs for userspace tools

[Alexey Starikovskiy]

Yves-Alexis Perez wrote:
> Hi,
>
> Evgeni Golov (CC:ed) is currently taking care of fixing acpitool wrt.
> sysfs support (which is badly broken). 
>
> Using the files in /sys/class/power_supply/BAT*/ we have some wondering
> about units.
>
> For the current rate, for example, we have:
>
> corsac@hidalgo: grep . /sys/class/power_supply/BAT0/*now    
> /sys/class/power_supply/BAT0/current_now:14415000
> /sys/class/power_supply/BAT0/energy_now:44170000
> /sys/class/power_supply/BAT0/voltage_now:12481000
> corsac@hidalgo: grep . /sys/devices/platform/smapi/BAT0/*now
> /sys/devices/platform/smapi/BAT0/current_now:1151
> /sys/devices/platform/smapi/BAT0/power_now:14365
>
> I'm a bit puzzled with the differences in current_now (the battery is
> charging at that time), and don't really know if we can trust the units.
>
> I would assume (in /sys/class/power_supply):
> current_now to be in uA
> energy_now to be in uWh
> voltage_now to be in uV
>
> as said in include/linux/power_supply.h
>
> /*
>  * All voltages, currents, charges, energies, time and temperatures in uV,
>  * µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
>  * stated. It's driver's job to convert its raw values to units in which
>  * this class operates.
>  */
>
>
> and the current (dis)charging rate in W to be
> (current_now/1.000.000)*(energy_now/1.000.000). But that gives, for an
> end of charge, a charging rate of:
>
>   
Currently, sysfs interface repeats brokenness of /proc/acpi/battery 
interface.
it is possible to have battery info in energy units and charge units.
If you see 'energy_now' variable, then 'current_now' and more 
appropriate 'power_now'
will report in uW units.
But if you have 'charge_now', then 'current_now' will report in uA 
units, and you will not see 'power_now'.
So, in short, 'charge_now' reports in same units (sans *h) as capacity, 
either 'charge_now' or 'energy_now'.
The proper way to handle it is to check for 'energy_now' and if it is 
present, look for 'power_now'. It should be
present in 2.6.30 and later kernels (remaining time 
energy_now/power_now). If it is not present (as in 2.6.29), then you 
should assume that 'current_now' has value in uW, and remaining time is 
energy_now/current_now.
If you have 'charge_now', remaining time is charge_now/current_now 
without any complications.

Regards,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Battery information in sysfs for userspace tools

[Yves-Alexis Perez]

On dim, 2009-05-17 at 01:06 +0400, Alexey Starikovskiy wrote:
> Currently, sysfs interface repeats brokenness of /proc/acpi/battery 
> interface.

Hmmh, ok, but it seems to have change recently (since powertop and
acpitools are definitely wrong when it comes to that)

[…]
> The proper way to handle it is to check for 'energy_now' and if it is 
> present, look for 'power_now'. It should be
> present in 2.6.30 and later kernels (remaining time 
> energy_now/power_now). If it is not present (as in 2.6.29), then you 
> should assume that 'current_now' has value in uW, and remaining time
> is energy_now/current_now.
> If you have 'charge_now', remaining time is charge_now/current_now 
> without any complications.

Wow. Thanks for the info, that's definitely not really easily
guessable :) It'd be nice to have that documented somewhere until things
settle down a bit and the situation becomes unbroken.

Cheers,
-- 
Yves-Alexis

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html