bq2700_battery.c changes and observations
sean at mcneil.com
Mon Apr 14 05:49:30 CEST 2008
Sorry for the delay. Been a busy weekend....
Andy Green wrote:
> 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
> 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?
Works here for me:
I relied on the APM emulation routine that gets set in i2c. Perhaps
there is something messed up there?
More information about the openmoko-kernel