summaryrefslogtreecommitdiff
path: root/util/amdtools
diff options
context:
space:
mode:
authorFurquan Shaikh <furquan@chromium.org>2017-10-11 14:48:14 -0700
committerFurquan Shaikh <furquan@google.com>2017-10-12 22:13:42 +0000
commit74145f7615b67acae77fdf45c3e7f3f373b9b2c7 (patch)
tree5b5352366435d3af1c028a6931dc9b7bedbe4cb8 /util/amdtools
parentc4e652ff572d7eea3bbbae21825d0085e294cb98 (diff)
downloadcoreboot-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 'util/amdtools')
0 files changed, 0 insertions, 0 deletions