| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium:547879
BRANCH=samus
TEST=make BOARD=samus
Change-Id: Iba29d53918245714ffcf6c87f42d1fa98be028b8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309142
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 12d924b7a05ddcd64a6d845faba5d6dc348c4bbd)
Reviewed-on: https://chromium-review.googlesource.com/309553
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the ALS is not enabled in S3/S5 states then it will generate
errors when trying to read so should be gated.
This could be done with a check for chipset_state or adding a
new CONFIG_ALS_POWER_GPIO to check. However the ALS is also not
needed when the host is in S3/S5 yet the task continues to run
in the background every 1 second.
This commit adds a new task enable/disable hook to disable the
task when the system is suspended and enable the task when it
is resumed.
In order to fit this new task in glados the als console command
is guarded by a new config option. Since this is not a very
frequently used/needed console command it is disabled by default.
And finally the kunimitsu and strago boards try to enable ALS
but they never actually enabled the ALS task so this new code was
failing to build because TASK_ID_ALS did not exist. Also samus
was enabling it but as TASK_NOTEST so tests will fail, though
they are disabled globally on samus.
BUG=chrome-os-partner:43493
BRANCH=none
TEST=enable ALS on glados and successfully build and use it,
also successfully build EC and tests for kunimitsu, strago,
and samus which are the other boards that use the ALS task.
Change-Id: I192940d7f306a1663c7cb789c313151bbb5f2b90
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/298156
Reviewed-by: Shawn N <shawnn@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we have RAM to spare, increase the stack sizes of certain tasks
that may come close to stack overflow.
BUG=chrome-os-partner:36914
TEST=Manual on samus / samus_pd. Run task_info, verify new task stack
sizes.
BRANCH=Samus
Change-Id: Id667f963bffbf7776e7cbe07b7e7d34f4ac27398
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251420
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Increase extpower task stack size due to occasional stack
overflow in extpower task on plugging/unpluggin AC.
BUG=chrome-os-partner:36760
BRANCH=samus
TEST=load onto samus, connect/disconnect a bunch of times
and check high water mark on stack usage: 368/512
Change-Id: I4531176ce6f15356a2267cdecf907a7694567da9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249920
Reviewed-by: Shawn N <shawnn@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change backboosting workaround into a new extpower task. This
new task runs exactly what used to be run in a deferred function,
but at higher priority than charger task, which means that i2c
transactions from this new task will occur before charger task
i2c transactions.
This fixes the EC watchdog when writing PD device firmware
because the hooks task is no longer blocked on trying to grab
the i2c mutex for talking to BQ.
BUG=chrome-os-partner:33905
BRANCH=samus
TEST=loaded onto samus and tested remote update of zinger 10 times.
Change-Id: I01d259857aefc6bf456ab217bf46536237bc4008
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235862
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes I2C1 is wedging and this can cause the ALS task to
overflow its stack.
As a temporary measure to stop the random reboots increase the
ALS task size.
BUG=chrome-os-partner:32471
BRANCH=samus
TEST=build and boot on samus with stuck I2C1
taskinfo before (after fresh reboot):
2 ALS 00000000 0.001012 364/384
taskinfo after (notice it is >384 after some time):
2 ALS 00000000 0.031586 400/512
Change-Id: I04e9b93d3cc60afd3303eb4610c81952f365b992
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220442
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Increase task stack size for PD host command task to 512. The nominal
stack size is 328 / 384, which is pretty close to the edge.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: Ifdf04923b817c832cbb77ba7f61c06a560aec97d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217452
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Base: lsm6ds0
- Lid : kxcj9
- gyro: lsm6ds0
BUG=chrome-os-partner:27313
BRANCH=ToT
TEST=Verified on Samus.
Tested with EC CLI utils
accelrate, accelrange, accelres, accelread, accelcalib
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Change-Id: I9f5f771e43a7b026ac59fb4d459638a4b8ea8f79
Reviewed-on: https://chromium-review.googlesource.com/212373
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Increase the stack size for the charger task to work around I2C
battery communication issues.
BUG=chrome-os-partner:29839
BRANCH=None
TEST=watch for I2C0 transation failures and ensure that the charger
task does not stack overflow and reset the EC+system.
Change-Id: Iabae3e2c302b68eb9e25a604dd72ef48128866df
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205142
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Created a new smaller task size, 384, for tasks that don't need much
stack space including PDCMD and ALS tasks.
BUG=none
BRANCH=none
TEST=loaded on samus, ran taskinfo, made sure we were comfortbaly
under the smaller task size for those tasks that changed.
Change-Id: Icfa26eeaeed26171ec8b2d888e1190be32f688d1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202719
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a EC to PD host command to notify the PD MCU when a battery
is present and charged enough that it is ok to negotiate for a
higher power. The PD MCU will not negotiate until the host command
is received, which allows the system to be powered without a
battery or with a dead battery with 5V.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=Tested on a samus:
1) Tested the normal case of battery charged and plugged in. When
charger is plugged in, the device immediately starts negotiating
for 20V and starts charging.
2) Tested with no battery. Plug in a charger, samus boots and stays
alive. VBUS measured at 5V. When a battery is plugged in, device
negotiates for 20V and starts charging.
3) Tested dead battery by taking a battery with no charge, and
plugging in zinger. Everything boots, but PD does not negotiate
for power. Then when battery reaches 1%, PD negotiates and zinger
switches to 20V without causing a reboot.
Change-Id: Iaa451403674e86cddbd3fe80e9503584910be576
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201958
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moved sampling of ALS to its own task. The problem is that it
spin waits on the i2c bus mutex, and it's a bad idea to spin wait
for very long in the hooks task because the hooks task tickles
the watchdog.
BUG=chrome-os-partner:29003
BRANCH=none
TEST=tested on samus: make sure ALS task is running and no
watchdog timeouts when the i2c bus is wedged indefinitely.
Change-Id: Ifcebabdfc151ea85cecdfe7a8ed489e8a82ee5ba
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202545
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With change b610695b61db3b3784e2a516c91f429139616100, we fixed a problem
with the number of FP regs that were being saved on the stack. That change
decreased the required stack size for non-FP tasks by 64 bytes, but
increased the size needed for FP tasks (such as the lightbar).
The lightbar task was previously using within 64 bytes of its alloted stack,
so handling the task switching correctly meant that it now overflowed.
The hooks task had the same problem, but was hidden by the lightbar task.
This CL bumps the LARGER_TASK_STACK_SIZE up a bit, and switches the lightbar
task to use it instead of the default size.
BUG=chrome-os-partner:27971, chrome-os-partner:28407
BRANCH=ToT
TEST=Try it on both Link and Samus.
Before this change, the Samus lightbar was overflowing its stack every time
the AP booted (causing the lightbar to do things). With this change, it
doesn't. Here are typical stack sizes after this CL:
Task Ready Name Events Time (s) StkUsed
0 R << idle >> 00000000 28.394913 328/512
1 HOOKS 00000000 0.534085 640/768
2 R LIGHTBAR 10000000 5.359356 520/768
3 CHARGER 00000000 0.094674 384/512
4 CHIPSET 00000000 0.003353 320/512
5 KEYPROTO 00000000 0.002814 312/512
6 HOSTCMD 00000000 0.002942 244/512
7 R CONSOLE 00000000 0.193776 340/768
8 POWERBTN 00000000 0.000392 248/512
9 KEYSCAN 00000000 0.409337 332/512
Change-Id: Ica93608c8adb225410a62ec3a0a27944c479270a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197733
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vboot hash calculation takes ~350 ms during EC boot. Since the hash
task is higher priority than the hook task, this starves all the hooks
during boot.
We could, in theory, fix that simply by swapping the priority of the
hook and hash tasks. But then watchdog detection (in the hook task)
wouldn't detect hangs in the hash task.
A better fix (implemented here) is to convert the hashing operation to
a series of deferred function calls. This gets rid of the hash task
entirely, and allows all pending hooks and other deferred function
calls to take place between each chunk of hashing.
On STM32-based boards, we need to bump up the hook task stack size,
since hashing is called from several layers deep in the hook task
instead of at the top of its own task, but this is still a net win of
several hundred bytes of SRAM.
BUG=chrome-os-partner:24892
BRANCH=rambi
TEST=Boot EC; look for "hash start" and "hash done" debug output.
'taskinfo' shows at least 32 bytes of unused stack for HOOKS task.
'hash ro' runs properly from EC console.
Change-Id: I9e580dc10fc0bc8e44896d84451218ef67578bbe
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181954
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AP throttling in the thermal task ends up calling a pretty deep nested
set of calls, and in the worst case can overflow the stack. Bump up
the stack size for the hook task on x86 platforms to compensate.
BUG=chrome-os-partner:24536
BRANCH=peppy/falco
TEST=taskinfo shows hook task increased from 512 to 640 bytes stack
shmem shows at least 4000 bytes free
Change-Id: I63da7c47b993c935d895f91d787844655071da0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180684
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
This just does a copy/rename from Bolt. Tweaking for Samus' peculiarities
will come next.
BUG=chrome-os-partner:22870
BRANCH=none
TEST=manual
The only thing we can check is that it compiles:
cd src/platform/ec
make BOARD=samus
Change-Id: Ied95ebdd1137548b21334b4a65a298c68482c517
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
