diff options
author | Furquan Shaikh <furquan@chromium.org> | 2017-10-11 14:48:14 -0700 |
---|---|---|
committer | Furquan Shaikh <furquan@google.com> | 2017-10-12 22:13:42 +0000 |
commit | 74145f7615b67acae77fdf45c3e7f3f373b9b2c7 (patch) | |
tree | 5b5352366435d3af1c028a6931dc9b7bedbe4cb8 /src/vendorcode/google | |
parent | c4e652ff572d7eea3bbbae21825d0085e294cb98 (diff) | |
download | coreboot-74145f7615b67acae77fdf45c3e7f3f373b9b2c7.tar.xz |
intel/common/pmc: Disable all GPEs during pmc_init
If GPEs are not cleared during pmc_init, it could result in issues if
standard wake events are generated while coreboot is
initializing. e.g. (Observed on soraka):
1. Suspend to S3
2. Lidclose
3. Lidopen
4. EC wakes up the host using WAKE# pin
5. On wakeup, pmc_init occurs which does not clear GPEs
6. MP init enables SMI
7. In order to add wake event to elog, coreboot sets wake mask on the
EC, which causes the EC to assert WAKE#.
8. Since WAKE# is asserted, it results in an SMI#. However, EC does
not de-assert WAKE# until host queries and clears the host event
bit (which does not happen since coreboot is stuck in handling the
SMIs).
This is one of the issues that can occur when GPEs are unnecessarily
enabled in coreboot. Before the move to PMC common library, SKL PMC
driver set all GPEs to 0 and hence this issue did not occur.
This change explicitly disables all GPEs during pmc init in order to
avoid any side-effects.
BUG=b:67712608
TEST=Verified that device resumes fine using lidclose/lidopen to
suspend and resume.
Change-Id: Ic5be02a23a8dbf43c4d7adf00251639ded4a94c9
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/21969
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'src/vendorcode/google')
0 files changed, 0 insertions, 0 deletions