mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2025-12-29 10:00:51 +00:00
0939fffdeb
The charger task relies on calc_next_state() performing a delay before
returning. My reading of the code suggests that this doesn't happen
always. For example:
When pre-charging:
if (battery_temperature(&batt_temp) == EC_SUCCESS)
return ST_CHARGING;
When discharging and capacity is low:
/* Check remaining charge % */
if (battery_state_of_charge(&capacity) == 0 && capacity < 10)
return notify_battery_low();
I would like to suggest that the code be refactored to more like:
int next_checkms = 5000; /* next time to check battery */
while (1) {
int action = ACTION_NONE;
err = get_state(&state);
if (!err) {
action = calculate_action(&state);
err = perform_action(action, &next_check_ms);
}
usleep(next_check_ms * 1000);
}
so that the delays are really clear, the state is all read at once,
there is no reliance on earlier state, and we always delay even on
error.
In the meantime, this CL inserts a mandatory 5 second delay in the
loop, which should prevent the charger task lockup.
BUG=chrome-os-partner:11285
TEST=manual
(please do this test before committing)
1. boot to kernel, see that battery can be seen
2. suspend and resume device
3. see that the charger loop does not cause an EC watchdog reset and
AP power off/reset. There should be no watchdog warning message on the
EC console.
Change-Id: I141e374933c4dc0ec60bcdccf96443f57067c585
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27353
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Ready: Katie Roberts-Hoffman <katierh@chromium.org>
- EC Lib
This wraps Blizzard driverlib and implements the EC chip interface defined
by Google. See below diagram for architecture.
+--------------------+
| Host BIOS/OS |
+--------------------+
---- host interface ----
+--------------------+
| Google EC features |
+--------------------+
---- chip interface ---- The interface is defined in
src/platform/ec/chip_interface/*.
+--------------------+ But the real implementation is in EC Lib.
| EC Lib |
+--------------------+
| Blizzard low level |
| driver, the |
| driverlib. |
+--------------------+
Build Options
=============
- CONFIG_WATCHDOG_HELP
Try to detect a watchdog that is about to fire, and print a trace.
This is needed on STM32, where the independent watchdog has no early
warning feature and the windowed watchdog has a very short period.
- CONFIG_PANIC_NEW_STACK
When reporting a panic, change to a completely new stack. This might
help get a useful trace out a situation where the stack or stack
pointer has been corrupted.
- CONFIG_PANIC_HELP
Report extra information about a panic, such as the fault address,
here shown as bfar. This shows the reason for the fault and may help
to determine the cause.
=== EXCEPTION: 03 ====== xPSR: 01000000 ===========
r0 :0000000b r1 :00000047 r2 :60000000 r3 :200013dd
r4 :00000000 r5 :080053f4 r6 :200013d0 r7 :00000002
r8 :00000000 r9 :200013de r10:00000000 r11:00000000
r12:00000000 sp :200009a0 lr :08002b85 pc :08003a8a
Precise data bus error, Forced hard fault, Vector catch, bfar = 60000000
mmfs = 00008200, shcsr = 00000000, hfsr = 40000000, dfsr = 00000008
- CONFIG_ASSERT_HELP
Report assertion failures in a vebose manner to aid debugging. When
enabled an ASSERT() which fails will produce message in the form:
ASSERTION FAILURE '<expr>' in function() at file:line