| commit | dd825fe73ec9832ff100955cf564dea68cee2d81 | |
| author | Furquan Shaikh <furquan@chromium.org> | |
| Tue, 17 Oct 2017 22:06:37 +0000 (17 15:06 -0700) | ||
| committer | Furquan Shaikh <furquan@google.com> | |
| Thu, 19 Oct 2017 00:43:45 +0000 (19 00:43 +0000) | ||
| tree | e941c884a44db4bacba5b7820494613ee3706969 | treesnapshot (tar.gz zip) |
| parent | 7284efe594114c7bcc933550ade9f728cbf0ca8f | commitdiff |
soc/intel/skylake: Probe XHCI for wake source for Internal PME
If GPE_STS indicates that the wake source is internal PME, but none of
the controllers have the PME_STS bit set, then try probing individual
XHCI ports to see if one of those was a wake source. In some cases
e.g. gsmi logging with S0ix, pci_pm_resume_noirq runs before gsmi
callback and clears PME_STS_BIT in controller register. In such cases,
xhci port status might provide a better idea about the wake source.
BUG=b:67874513
Change-Id: I841bb2abccfa9bd6553c1513e88a6306b40315e4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/22089
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If GPE_STS indicates that the wake source is internal PME, but none of
the controllers have the PME_STS bit set, then try probing individual
XHCI ports to see if one of those was a wake source. In some cases
e.g. gsmi logging with S0ix, pci_pm_resume_noirq runs before gsmi
callback and clears PME_STS_BIT in controller register. In such cases,
xhci port status might provide a better idea about the wake source.
BUG=b:67874513
Change-Id: I841bb2abccfa9bd6553c1513e88a6306b40315e4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/22089
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
| src/soc/intel/skylake/elog.c | diffblobblamehistory |