bq2700_battery.c changes and observations

[Sean McNeil]

Hi Andy,

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
> /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
Works here for me:

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

I relied on the APM emulation routine that gets set in i2c. Perhaps 
there is something messed up there?