From: Peter Zijlstra <peterz@infradead.org>
To: Patryk Wlazlyn <patryk.wlazlyn@linux.intel.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, rafael.j.wysocki@intel.com,
len.brown@intel.com, artem.bityutskiy@linux.intel.com,
dave.hansen@linux.intel.com, tglx@linutronix.de,
gautham.shenoy@amd.com
Subject: Re: [RFC PATCH v4 8/8] acpi_idle: Disallow play_dead with FFH cstate on AMD platforms
Date: Mon, 25 Nov 2024 14:54:54 +0100 [thread overview]
Message-ID: <20241125135454.GE38837@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20241125132029.7241-9-patryk.wlazlyn@linux.intel.com>
On Mon, Nov 25, 2024 at 02:20:28PM +0100, Patryk Wlazlyn wrote:
> Signed-off-by: Patryk Wlazlyn <patryk.wlazlyn@linux.intel.com>
> Suggested-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
> ---
> drivers/acpi/processor_idle.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 586cc7d1d8aa..4b4ac8d55b55 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -803,7 +803,11 @@ static int acpi_processor_setup_cstates(struct acpi_processor *pr)
>
> state->flags = 0;
>
> - state->enter_dead = acpi_idle_play_dead;
> + /* AMD doesn't want to use mwait for play dead. */
> + bool amd_or_hygon = boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
> + boot_cpu_data.x86_vendor == X86_VENDOR_HYGON;
> + if (!(cx->entry_method == ACPI_CSTATE_FFH && amd_or_hygon))
> + state->enter_dead = acpi_idle_play_dead;
So I don't like this. Less exceptions is better.
This *SHOULD* never trigger on AMD anyway, because they recommend IO
port C[23]. But if their partner BIOS engineer does a wobbly and they
end up in MWAIT anyway, it *should* all work regardless.
next prev parent reply other threads:[~2024-11-25 13:54 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 13:20 [RFC PATCH v4 0/8] SRF: Fix offline CPU preventing pc6 entry Patryk Wlazlyn
2024-11-25 13:20 ` [RFC PATCH v4 1/8] cpuidle: Do not return from cpuidle_play_dead() on callback failures Patryk Wlazlyn
2024-11-25 13:26 ` Rafael J. Wysocki
2024-11-25 14:36 ` Patryk Wlazlyn
2024-11-25 13:20 ` [RFC PATCH v4 2/8] cpuidle: Change :enter_dead() driver callback return type to void Patryk Wlazlyn
2024-11-25 13:20 ` [RFC PATCH v4 3/8] ACPI: processor_idle: Use acpi_idle_play_dead() for all C-states Patryk Wlazlyn
2024-11-25 13:24 ` Rafael J. Wysocki
2024-11-25 14:39 ` Patryk Wlazlyn
2024-11-25 14:36 ` Gautham R. Shenoy
2024-11-25 13:20 ` [RFC PATCH v4 4/8] x86/smp: Allow calling mwait_play_dead with arbitrary hint Patryk Wlazlyn
2024-11-25 14:39 ` Rafael J. Wysocki
2024-11-26 11:36 ` Patryk Wlazlyn
2024-11-26 11:45 ` Rafael J. Wysocki
2024-11-25 13:20 ` [RFC PATCH v4 5/8] x86/smp native_play_dead: Prefer cpuidle_play_dead() over mwait_play_dead() Patryk Wlazlyn
2024-11-25 13:45 ` Peter Zijlstra
2024-11-25 13:56 ` Rafael J. Wysocki
2024-11-25 14:43 ` Patryk Wlazlyn
2024-11-25 14:48 ` Rafael J. Wysocki
2024-11-26 11:56 ` Patryk Wlazlyn
2024-11-26 12:04 ` Rafael J. Wysocki
2024-11-26 13:10 ` Patryk Wlazlyn
2024-11-26 13:38 ` Rafael J. Wysocki
2024-11-25 13:20 ` [RFC PATCH v4 6/8] intel_idle: Provide enter_dead() handler for SRF Patryk Wlazlyn
2024-11-25 13:44 ` Rafael J. Wysocki
2024-11-25 14:48 ` Patryk Wlazlyn
2024-11-25 14:50 ` Rafael J. Wysocki
2024-11-25 13:53 ` Peter Zijlstra
2024-11-25 13:58 ` Rafael J. Wysocki
2024-11-25 14:12 ` Peter Zijlstra
2024-11-25 14:19 ` Rafael J. Wysocki
2024-11-25 13:20 ` [RFC PATCH v4 7/8] acpi_idle: Add FFH cstate handling Patryk Wlazlyn
2024-11-25 13:41 ` Rafael J. Wysocki
2024-11-25 14:00 ` Rafael J. Wysocki
2024-11-25 15:14 ` Gautham R. Shenoy
2024-11-26 12:03 ` Patryk Wlazlyn
2024-11-25 13:20 ` [RFC PATCH v4 8/8] acpi_idle: Disallow play_dead with FFH cstate on AMD platforms Patryk Wlazlyn
2024-11-25 13:46 ` Rafael J. Wysocki
2024-11-25 13:54 ` Peter Zijlstra [this message]
2024-11-25 14:56 ` Patryk Wlazlyn
2024-11-25 15:17 ` Gautham R. Shenoy
2024-11-25 15:15 ` Gautham R. Shenoy
2024-11-26 12:05 ` Patryk Wlazlyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241125135454.GE38837@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=artem.bityutskiy@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gautham.shenoy@amd.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=patryk.wlazlyn@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.