Messages in this thread | | | From | "Zhang, Rui" <> | Subject | RE: [PATCH] intel: thermal: PCH: Drop ACPI_FADT_LOW_POWER_S0 check | Date | Fri, 22 Jul 2022 02:59:53 +0000 |
| |
> -----Original Message----- > From: Rafael J. Wysocki <rafael@kernel.org> > Sent: Monday, July 18, 2022 3:39 AM > To: Zhang, Rui <rui.zhang@intel.com> > Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Linux PM <linux- > pm@vger.kernel.org>; Linux ACPI <linux-acpi@vger.kernel.org>; LKML <linux- > kernel@vger.kernel.org>; Mario Limonciello <mario.limonciello@amd.com>; > Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > Subject: Re: [PATCH] intel: thermal: PCH: Drop ACPI_FADT_LOW_POWER_S0 > check > Importance: High > > On Sun, Jul 17, 2022 at 8:14 AM Zhang Rui <rui.zhang@intel.com> wrote: > > > > On Thu, 2022-07-14 at 21:11 +0200, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > If ACPI_FADT_LOW_POWER_S0 is not set, this doesn't mean that low- > > > power > > > S0 idle is not usable. It merely means that using S3 on the given > > > system is more beneficial from the energy saving perspective than > > > using low-power S0 idle, as long as S3 is supported. > > > > Agreed. > > > > > > > > Suspend-to-idle is still a valid suspend mode if > > > ACPI_FADT_LOW_POWER_S0 > > > is not set and the pm_suspend_via_firmware() check in > > > pch_wpt_suspend() > > > is sufficient to distinguish suspend-to-idle from S3, so drop the > > > confusing ACPI_FADT_LOW_POWER_S0 check. > > > > the cooling delay in the suspend callback is to make sure PCH > > temperature won't block S0ix during s2idle. So if S0ix is not > > supported, it is meaningless to invoke the cooling delay during s2idle. > > But there is no way to determine whether or not S0ix is supported. In > particular, ACPI_FADT_LOW_POWER_S0 is not one. > > > so the problem is that we don't have an indicator for S0ix capability. > > And this also applies to drivers/rtc/rtc-cmos.c, where we use ACPI SCI > > for runtime RTC wakeup instead of HPET interrupt on "S0ix capable" > > platforms because the HPET timer may block S0ix. > > "S0ix capable" doesn't matter. What matters is whether or not the current > transition under way is into S0 or into suspend-to-idle. In the latter case > there is no reason to avoid doing whatever is done in the expectation that > S0ix may be entered going forward.
Okay. It is not perfect but we have to live with this.
Acked-by: Zhang Rui <rui.zhang@intel.com>
| |