fix-bq27000-charger-state-tracking.patch

Charger trigger stuff goes and asks for POWER_SUPPLY_PROP_STATUS
to figure out what the charger state is.  But until now, we only
reported there what we found out from HDQ, and the HDQ registers
are not updated very often in the coulomb counter, it can be 4
or more second lag before it tells us about what it experiences.

When we react to USB insertion and only after 500ms debounce tell
power_supply stuff that something changed, it most times will
see old pre-USB-insertion state from bq27000 over HDQ at that time
and will report it ain't charging, buggering up the LED trigger
tracking.

This patch maintains distance between bq27000 and pcf50633 by
having platform callbacks in bq27000 that it can use to ask about
definitive charger "online" presence and "activity", whether the
charger says it is charging.  If these callbacks are implemented
(and we implement them in this patch up in mach_gta02.c) then
this information is used in preference to what is found from
HDQ.

Result is if you set the LED trigger like this:

echo bat-charging > /sys/devices/platform/gta02-led.0/leds/gta02-aux:red/trigger

then it lights up properly on USB insertion now, goes away on
removal properly, as as far as I saw, when charging stops too.

Signed-off-by: Andy Green <andy@openmoko.com>

1 files changed, 2 insertions, 0 deletions

diff --git a/include/linux/bq27000_battery.h b/include/linux/bq27000_battery.h
index fed4287d756..a617466a517 100644
--- a/include/linux/bq27000_battery.h
+++ b/include/linux/bq27000_battery.h
@@ -9,6 +9,8 @@ struct bq27000_platform_data {
 	int (*hdq_read)(int);
 	int (*hdq_write)(int, u8);
 	int (*hdq_initialized)(void);
+	int (*get_charger_online_status)(void);
+	int (*get_charger_active_status)(void);
 };
 
 #endif