Attention is currently required from: Benjamin Doron. Michael Niewöhner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/49140 )
Change subject: soc/intel/skylake/acpi: Add PEP table ......................................................................
Patch Set 5:
(1 comment)
Commit Message:
https://review.coreboot.org/c/coreboot/+/49140/comment/ffa8fdcc_d5c7ae00 PS3, Line 11:
Not needed. SlpS0 is not asserted externally but by the SoC.
And the pad doesn't need to be `_NF`?
It can be but it simply doesn't matter because your board doesn't use it.
So, the problem seems to be that Linux doesn't differentiate PC10-only and PC10+SlpS0 systems. Iow. there's a check missing here ... https://github.com/torvalds/linux/blob/master/drivers/platform/x86/intel_pmc...
Well, ideally the system would make it to SlpS0. I think it's correct to warn that this didn't happen. However, if the table doesn't advertise support, it can be argued that the kernel doesn't need to check the default address...
That's the point. When SlpS0 is not advertised there is no need to check/warn for S0Slp.
To me, this appears deliberate, but I couldn't be sure.
Hmm, somewhere above you wrote Linux prints an error for PC10 on vendor firmware. Did you really mean PC10 or SlpS0?
I meant PC10.
Are ASPM and L1 substates involved? The vendor firmware has the "ASPM not supported" bit set in FADT and disables L1 substates.
Yes, both are required to get to PC10.
Ah. That would explain the issues.
In coreboot, I had disabled L1 substates and set ASPM to "L1" on the WLAN's root port to mitigate AER errors. I noticed now that the LAN's root port has disabled ASPM but I'm not sure why (the bit is read-write-once, I'll look into that).
Check Kconfig and devicetree for L1 states.
The kernel r8169 module always disables ASPM on these Realtek LAN devices because it apparently causes some to stop working or hang the system. The only difference is that coreboot gives ASPM control to the OS, but the vendor firmware does not. Besides that, the module must change ASPM state before accessing some registers. So, perhaps S0ix will not work on this board.
Hmmm... just curious, what kernel version exactly? There was some fix recently that should be in mainline or maybe even stable.
So, perhaps S0ix will not work on this board.
PC10 worked, so S0ix works. It's just SlpS0 that doesn't work :-) Since it wouldn't have any effect on that board, that's ok.
Thanks for the help. Can we get this in now?
-
Michael Niewöhner (Code Review)