bq2700_battery.c changes and observations

Andy Green andy at openmoko.com
Sat Apr 12 10:25:57 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Attached is a patch to add:
|
| Battery health
| USB and AC power indicators
| Change to threshold for detecting charge status
|
| The last item is problematical for me. The battery tends to hover at 11
| for BQ27000_AI_L and BQ27000_TTF_L is not zero. This is with 2 usb
| connections - one direct, 1 via debug board - directly into laptop. My
| blackberry complains it doesn't get enough juice under linux, so maybe
| that is the issue. Capacity on the battery is at 100%, though.

Nice work.  Since you signed this mail I took the pretty big liberty of
adding "Signed-off-by: Sean McNeil <sean at mcneil.com>" to the patch
header.  We need to get hardcore about Signed-off-by if we will ever get
stuff upstream.  Most of mokopatches does not have anyone responsible
for the content :-(

You also fixed the battery name thing -- I added this because I expected
to find a serial number or some such in the BQ27000 EEPROM, but there
was none.  Setting it to "gta02" is fine under the circumstances.

BQ27000_AI at 11 can be the load of the BQ itself over the battery, or
the impedence of the PMU battery connection to 0V when it does not have
the load enabled.  The AI thing is specified in a super perverse way as
being the current but in units of 3.57uV with the note "Divide by Rs in
milliohms to convert µV to mA or µVh to mAh."  Rs is 20mR I believe so
11 comes out as (11 x 3.57uV ) / 20mR --> 1.9... 1.9mA?  Seems a lot.
Maybe what happens here is to sense the battery level for some period
the PMU tries to power the device from it, and averaged over the BQ27000
sample period that comes out at 1.9mA... something like that?

The nonzero TTF can be because to top off the battery it does a sort of
PWM if I understood it, maybe it is waiting for a period or threshold
before giving it another jolt of charging.  If the capacity is saying
100 that's "full" for our purposes I think.

I tested it and found things like

# cat
/sys/bus/platform/devices/bq27000-battery.0/power_supply/battery/health
Good

But when I did

cat /sys/bus/platform/devices/bq27000-battery.0/power_supply/ac/online

the cat blocked and never came back?  I also noticed

[    3.310000] power_supply ac: POWER_SUPPLY_NAME=ac
[    3.315000] power_supply ac: Static prop TYPE=Mains
[    3.320000] power_supply ac: 1 dynamic props
[    3.325000] power_supply ac: driver failed to report `online' property
[    3.330000] power_supply usb: power_supply_changed
[    3.335000] power_supply usb: power_supply_changed_work
[    3.340000] power_supply usb: uevent
[    3.345000] power_supply usb: POWER_SUPPLY_NAME=usb
[    3.350000] power_supply usb: Static prop TYPE=USB
[    3.355000] power_supply usb: 1 dynamic props
[    3.360000] power_supply usb: driver failed to report `online' property

but maybe it is not connected as battery status also fails there and
that works OK.  Do these things act differently for you?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgAcg0ACgkQOjLpvpq7dMrgrQCfecmewH+3ig/6hT09HF7dE1xC
HYYAoIjObpgyqv1pxR2Iz7dQ51Ejx7p8
=LnZu
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list