charge/discharge rates was incorrect - the value printed is actually
in A, W, Ah, or Wh, not in mA, mW, mAh, or mWh (assuming as we must
that the period is interpreted as a decimal point, not a thousands
separator).
- make sure that the driver checks the battery presence at acpibat_update()
if the battery has been not present, because the driver sometimes
(i.e. boot time or resuming time) miss to sense the presence.
- make sure that the driver always update the status at acpibat_gtredata();
I misunderstood about ACPI_NOTIFY_BatteryStatusChanged event.
it is very slow to access to EC on some machines (i.e. CASIO FIVA 2xx).
- clean the flags up.
- add locks while updating informations.
- some cosmetic changes.
ACPI defines two different battery device interfaces: "Control Method"
batteries, in which AML methods are defined in order to get battery
status and set battery alarm thresholds, and a "Smart Battery" device,
which is an SMbus device accessed through the ACPI Embedded Controller
device; this driver knows how to attach to the former sort of device.
As a total kludge, since we haven't wired things up to sysmon/envsys
yet, we report battery status through a once-per-minute kernel printf,
so don't use this driver yet if you want your disk to spin down.
Motivated by and tested on Sony PCG-R505TL laptop, which has
nonfunctional APM.
configure as:
acpibat* at acpi ?
Sample output:
acpibat0 at acpi0: ACPI Battery
acpibat0: Sony Corp. LION
acpibat0: Design 38480mWh, Predicted 38480mWh Warn 120mWh Low 0mWh
acpibat0: discharging: 15112mV cap 25480mWh (66%) rate 16849mW
...
acpibat0: discharging: 15224mV cap 25070mWh (65%) rate 18405mW
...
acpibat0: discharging: 15200mV cap 24310mWh (63%) rate 13771mW
...
acpibat0: charging: 15768mV cap 23330mWh (60%) rate 20388mW
mycroft