On Thu, Jun 2, 2016 at 12:53 PM, One Thousand Gnomes <[email protected]> wrote: >> How would this spuriously trigger during boot? This code is only run >> during freeze. If there's some issue with not entering S0ix before a >> module or firmware is loaded, it's better to not use suspend to idle >> until those are in place. > > Ok yes you are correct it's not likely to trigger during boot (although > if you close the lid during boot...) > >> I'm not familiar with the ISH driver. How does it prevent entry into >> S0ix? I would argue that you don't want to use suspend to idle on a >> Skylake system that can't enter S0ix and instead use suspend to RAM. > > Several IP blocks on the systems do their own power management if present > and enabled by the firmware. If they do not have drivers loaded then you > will not be able to enter some power states. Thus you'll now get warnings > if you try to freeze such a system and those warnings are not themselves > terribly helpful to a user.
I would expect those IP blocks to do nothing and not block lower power states if the firmware is not loaded. If that is not the case, I think that should be fixed such that those lower power states are at least available during suspend (if not during runtime). If your Skylake+ system is not entering S0ix during freeze, I consider that a bug that needs to be addressed. > > It's a good debug feature, but it doesn't belong anywhere but debug menus > and off by default. If you want to ship it enabled in ChromeOS for > product fine, but I don't think it belongs on for everywhere and > everything. If other Linux distributions choose not to enable it in their kernel configs, that's their decision. As I said, this does nothing in the !CONFIG_INTEL_PMC_CORE case, but if a finer level config is warranted, I can add that. I would prefer if others used this more, since there would be better debug coverage and I would have to fix fewer bugs. > > Alan
