Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When we are calling the re-scheduling routine at the end of an irq
handling routine, we need to ensure that the high registers are not
currently saved on the system stack.
On Cortex-M3/M4, the compiler is normally doing tail-call optimization
there and behaving properly, but this fixes the fact that insanely large
interrupt handling routines where sometimes not compile and not running
properly (aka issue 24515).
This also prepares for one more core-specific DECLARE_IRQ routine on
Cortex-M0.
Note: now on, the IRQ handling routines should no longer be "static".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24515
TEST=make -j buildall
revert the workaround for 24515, see the issue happening only without
this CL.
Change-Id: Ic419369231925568df05815fd079ed191a5446db
Reviewed-on: https://chromium-review.googlesource.com/189153
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When we are detecting Apple charger type, we disable TSU6721 interrupt.
This, however, doesn't create a race condition, because any pending
interrupt fires immediately after we re-enable TSU6721 interrupt, and in
turns schedules charger task. As a result, charger task gets waken right
after it finishes its current iteration.
As for overcurrent detection, the current algorithm seems to do a good
enough job.
BUG=chrome-os-partner:23743, chrome-os-partner:23744
TEST=None
BRANCH=None
Change-Id: Ib3a6d562a305020ef5413e2a493e4163a6e70954
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179303
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The charge state machine asks for all of this stuff at the same time
anyway. Bundling it into a single function removes a number of
redundant (and painfully slow) I2C reads.
Also refactor the battery debug command so it doesn't have so many
local variables all in one function; it was consuming considerably
more stack space than any other debug command.
Spring still needs low-level access to the smart battery, so move the
two functions it needs directly into the Spring implementation.
BUG=chrome-os-partner:20881
BRANCH=none
TEST=charge/discharge rambi, pit and spring; watch debug messages and
LED and output of 'battery' debug command. All should behave the
same as before. Then run 'taskinfo' and see that the console task
has at least 20 bytes unused.
Change-Id: I951b569542e28bbbb58853d62b57b0aaaf183e3f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177797
No code changes, just comment fixes. Added config #ifdefs for the
debug commands as requested; they're enabled for Spring, so
functionality is unchanged.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build spring; see that ilim and batdebug commands still exist
Change-Id: I7c9f12281afa7ec68aa7e62dcfcd51682d88a16a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175216
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Remove comments if no longer applicable, or assign bug numbers if they
still are. Tidy some debug output. No code changes other than the
debug output.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms, pass unit tests
Change-Id: I2277e73fbf8cc93f3b1b35ee115e0f2f52eb8cf9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175215
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Rather than compile it by default for host-based tests, only compile
it for the few tests that actually use it. Since those (and all
boards) now only use if if they also have a keyscan task, we can get
rid of the #ifdefs in keyboard_mkbp.c as well.
And remove a TODO we'll never do...
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests. These pass:
util/make_all.sh
make BOARD=pit tests
Change-Id: I44d1806cfb375027a7ed0b33a5e9bdbbed8ccddc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174513
Device-specific headers belong in driver/ or chip/. The include/
directory should be for common interfaces.
Code should not normally need to include driver-specific headers. If
it does, it should use the full relative path from the EC project root
(for example, drivers/charger/bq24715.h).
Change-Id: Id23db37a431e2d802a74ec601db6f69b613352ba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173746
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
battery.h is the high-level interface. battery_smart.h is the
low-level interface. Most things don't need the low-level interface,
but were including smart_battery.h solely to get at battery.h. Fixed
this. Also merged battery_pack.h into battery.h, since it was odd to
split that data across multiple header files. Tidied the function
comments in battery.h as well.
No functional changes, just renaming files and adding comments.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I5ef372f0a5f8f5f36e09a3a1ce24008685c1fd0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171967
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The ID detection and charging circuits on Spring are very different from
that on Kirby. PWM current limit is no longer used. The ID detection
sequence is also different. Also, there is no boost circuit on Kirby.
Given those hardware issues that we had to work around on Spring, it's
unlikely that we will have another board that shares the same/similar
ID detection design with Spring. Let's rename extpower_usb to
extpower_spring to better reflect this.
BUG=None
TEST=Build and boot Spring.
BRANCH=None
Change-Id: I7c212a121eed55665593cb7e1b2b672891819940
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/67031
