From dd825fe73ec9832ff100955cf564dea68cee2d81 Mon Sep 17 00:00:00 2001 From: Furquan Shaikh Date: Tue, 17 Oct 2017 15:06:37 -0700 Subject: 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 Reviewed-on: https://review.coreboot.org/22089 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin --- src/soc/intel/skylake/elog.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'src') diff --git a/src/soc/intel/skylake/elog.c b/src/soc/intel/skylake/elog.c index 2be6b7bc22..25a9610b53 100644 --- a/src/soc/intel/skylake/elog.c +++ b/src/soc/intel/skylake/elog.c @@ -226,6 +226,16 @@ static void pch_log_pme_internal_wake_source(void) dev_found = true; } + /* + * If device is still not found, but the wake source is internal PME, + * try probing XHCI ports to see if any of the USB2/3 ports indicate + * that it was the wake source. This path would be taken in case of GSMI + * logging with S0ix where the pci_pm_resume_noirq runs and clears the + * PME_STS_BIT in controller register. + */ + if (!dev_found) + dev_found = pch_xhci_update_wake_event(PCH_DEV_XHCI); + if (!dev_found) elog_add_event_wake(ELOG_WAKE_SOURCE_PME_INTERNAL, 0); } -- cgit v1.2.3