Age | Commit message (Collapse) | Author |
|
If the battery is not present hdq_read will always return an error.
If the drivers knows that the battery is not present the correct thing to do is
to return -ENODEV instead of passing the error on.
Do this for all properties except POWER_SUPPLY_PROP_PRESENT.
The power supply sysfs expects us to do so, else it won't generate a proper
uevent file.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
Using HAL for E's battery gadget highlighted an oddity: the kernel exposed
last full charge property but didn't expose current charge property. This
resulted in the wrong computation of current battery capacity by E's gadget
(and probably other programs as well).
This patch exposes a corresponding bq27000 register to make E battery
gadget happy (it is still not showing correct values because of bugs in HAL
resulting in 3 batteries (apm emulation and usb supply being bogus here)
instead of one).
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
|
This patch adds a call to cancel_delayed_work before a call
to schedule_delayed_work.
Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
Signed-off-by: Daniel Willmann <daniel@totalueberwachung.de>
|
|
This patch adds the call to the worker in
bq27000_battery_external_power_changed. Now (un)plugging the USB cable
effects the battery status soon. I don't know if it is possible call
the status change directly.
Signed-off-by: Michael Trimarchi <michael@panicking.kicks-ass.org>
Signed-off-by: Daniel Willmann <daniel@totalueberwachung.de>
|
|
X-Git-Url: http://git.openmoko.org/?p=kernel.git;a=commitdiff_plain;h=c94ea3d685fa6e9b24d62adb11a7ad6087b9edf5
fix_gta03_fiq_stuff.patch
Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
|
|
fix-ac-redefinition.patch
|
|
hes-tracking-fix-stray-endmenu-patch-1232632040-1232632141
pending-tracking-hist top was MERGE-via-stable-tracking-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040-1232632141 / fdf777a63bcb59e0dfd78bfe2c6242e01f6d4eb9 ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-stable-tracking-hist-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040
stable-tracking-hist top was MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040 / 90463bfd2d5a3c8b52f6e6d71024a00e052b0ced ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-mokopatches-tracking-hist-fix-stray-endmenu-patch
mokopatches-tracking-hist top was fix-stray-endmenu-patch / 3630e0be570de8057e7f8d2fe501ed353cdf34e6 ... parent commitmessage:
From: Andy Green <andy@openmoko.com>
fix-stray-endmenu.patch
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Changes related to pcf50633_mfd.patch
|
|
Adds AC and USB powersupply objects, and a workqueue to automonitor
changes in battery state and fire change events on any change to
selected registers.
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
We failed to report status of "discharging", instead reporting
"not charging" even if we knew that the charger was not present.
This patch corrects it and reports "discharging" when charger
is absent.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
If the charger was removed, we fell through back to old
hdq-driven code with normally wrong but slightly random
results for charging LED behaviour in that circumstance
This patch makes us use the tracked charger status
callbacks alone if they are defined in the platform
data.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
Subject: [PATCH] [battery] Make the bq27000 send an uevent when the charging state possible changed
Remove the todo entries from the pcf50633, make the mach-gta02
call the bq27000 driver from the pmu callback.
|
|
Subject: [PATCH] [bq27000] Make the checkpatch.pl happy
|
|
Model name isn't in the bq27000 register set, remove the
claim that we can deliver it
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
|