| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provides a new EC host command 'uptime info' which gathers up some
information which may be useful for debugging spurious resets on the AP
(was the EC reset recently? Why was the EC reset? If the EC reset the
AP, why did it do so?, etc.). Provide ectool support for the same.
Example results of `ectool uptimeinfo`:
```
localhost ~ # ectool uptimeinfo
EC uptime: 475.368 seconds
AP resets since EC boot: 2
Most recent AP reset causes:
315.903: reset: console command
363.507: reset: keyboard warm reboot
EC reset flags at last EC boot: reset-pin | sysjump
```
BRANCH=none
TEST=Perform some `apreset` commands from the EC console and observe
their side-effects via the `ectool uptimeinfo` command on the AP side.
Test sequences include no-resets through 5 resets, observing that the
ring buffer handling was correct.
BUG=b:110788201, b:79529789
Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Change-Id: I0bf29d69de471c64f905ee8aa070b15b4f34f2ba
Reviewed-on: https://chromium-review.googlesource.com/1139028
Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chipset reset logic chipset_reset() is same for APL, GLK,
SKL, KBL and CNL hence move it to common code.
BUG=b:72426192
BRANCH=none
TEST=make buildall -j
Change-Id: I289e9807d53e397e62d650289e80b6ce25fe399e
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/974471
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When SLP_SUS_L is deasserted, that means the chipset is in S5.
BUG=None
BRANCH=None
TEST=Flash meowth; boot from AC only, verify that when SoC actually
boots the power state is reported as S0 instead of G3.
Change-Id: Ib9cd76aa9efd6f81df432205b8c1e8c342e32af6
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/837485
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cannonlake power state chipset code would fail to keep an accurate
record of the chipset's power state. For example, the EC could claim
that the AP was in G3, whereas the SLP_SUS_L signal was deasserted.
This commit fixes a few issues with the chipset code.
- First, don't have PP3300_DSW_EN enabled by default coming out of
reset.
The default chipset power state when the EC comes out of reset is G3,
therefore we should not enable the PP33000 DSW rail until we decide to
leave G3. This is usually triggered by a power button press.
- Similarly, when we wish to enter G3, we should turn off the PP3300 DSW
rail instead of the noop that was done before.
- Lastly, turn on the 5V rail when entering S5 instead of S3 and turn it
off when leaving S5 to G3.
BUG=b:70184397,b:70244199
BRANCH=None
TEST=Flash zoombini; Verify that AP boots to S0 and can shutdown to S5
and the EC tracks it. Verify that after the S5 inactivity timer, we
fall to G3. Verify that SLP_SUS_L is asserted and DSWPWROK is low.
Verify that we can still perform BC1.2 detection in G3. `reboot ap-off`
and verify that the AP does indeed remain off and no port 80 codes are
seen.
TEST=Verify that 5V is off in G3, but can be turned on if needed.
TEST=Verify that 5V is on in S5.
TEST=With the exception of BC1.2, repeat the above tests for meowth.
Change-Id: I444a8f29969ef6a68a83d1734912d239bad429a5
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/813501
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to CL:774298, intention of chipset_force_shutdown is to power
off the AP by simulating power button press until it results in power
button override and shuts down AP. However, if AP is already in hard
or soft off conditions (i.e. G3, S5G3, G3S5 or S5) then AP is already
off, and simulating power button press results in
charge_prevent_power_on from incorrectly assuming that the power
button is pressed by user. Thus, check if the system is in soft or
hard off before shutting it down.
BUG=b:65864825
BRANCH=None
TEST=make -j buildall
Change-Id: I4b6d798af4618cbd4179f8700ebb2aa78021207e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791933
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For certain cannonlake designs, the 5V rail can be controlled by both
the chipset task as well as other tasks such as the USB charger tasks to
perform BC1.2 detection. This commit introduces an API that allows the
tasks to enable/disable the 5V rail. Enable requests will immediately
enable the rail, however, attempting to disable the rail will only
result in a request. Once all tasks want to turn off the 5V rail, the
rail will be turned off.
A bitmask is introduced to keep track of the requests. Index 0 is for
the chipset task.
All of this is gated behind a config option:
CONFIG_POWER_PP5000_CONTROL
BUG=b:65991615
BRANCH=None
TEST=With other zoombini code, verify that 5V can be enabled and disabled.
Change-Id: I1722b4a272c4d6ee24408929f5a7402051bb9cf3
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/722322
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The EC cannot control warm vs cold reset of the chipset using the
SYS_RST_L pin; it's just a reset request. This commit changes the
behaviour of chipset_reset to assert SYS_RST_L regardless if a cold or a
warm reset is requested.
BUG=b:63508740
BRANCH=None
TEST=make -j buildall; Flash a modified image on npcx7_evb, verify that
no panics or asserts are hit.
Change-Id: Idfd6f556bf909c7df4e8bd50a79b60719478cde7
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/585573
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds support for the virtual wire signals over eSPI.
Additionally, the SLP_S0_L signal is added for the board and some minor
changes are made to some GPIOs.
BUG=None
BRANCH=None
TEST=flash zoombini image on npcx7 EVB with some modifications. Verify
no panics or asserts are hit.
Change-Id: I6ada270b3e3fc7e24b28a8da6ee9dcde707414fc
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/577054
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
BUG=b:63508740
BRANCH=None
TEST=`make -j buildall`
Change-Id: I66e0e229c61c85af8f1f1c263e107e9990399e6a
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/564798
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|