mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lirongqing <lirongqing@baidu.com>
To: "Rafael J . Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	<linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: <zhongqiu.han@oss.qualcomm.com>, Li RongQing <lirongqing@baidu.com>
Subject: [PATCH v5 0/2] cpufreq: acpi-cpufreq: fix P-state index mismatch between perf->states[] and freq_table[]
Date: Sat, 7 Nov 2026 02:40:06 +0800	[thread overview]
Message-ID: <20261106184008.1728-1-lirongqing@baidu.com> (raw)

From: Li RongQing <lirongqing@baidu.com>

policy->freq_table is built by filtering out _PSS entries that are not
lower in frequency than the previous one, and the original ACPI P-state
index of each remaining entry is kept in freq_table[].driver_data.  The
index spaces of perf->states[] and freq_table[] therefore differ, and
mixing them up leads to the frequency of one P-state being attributed to
another.

Patch 1/2 is unchanged from v4 and fixes the cached frequency used by
get_cur_freq_on_cpu() to detect a firmware frequency change behind the
OS's back.

Patch 2/2 is new in v5.  As Rafael pointed out, Sashiko observed that
the extract_msr() fallback interferes with 1/2 and can render it
ineffective: when the status read from the hardware matches no
freq_table entry, extract_msr() returns freq_table[0].frequency instead
of reporting the status as unknown.  If the OS is already at the P-state
corresponding to freq_table[0], a firmware switch to a filtered-out
P-state then compares equal to the cached frequency, data->resume is
left clear and the next ->target() call does not rewrite the control
register.  So 1/2 alone does not make the detection work in that case,
and the two patches are posted together rather than separately as I had
suggested earlier.

v4: https://lkml.iu.edu/2609.1/07369.html

Changes since v4:
 - Drop "cpufreq: acpi-cpufreq: fix P-state index mismatch in
   extract_io()", which has been applied.  This series is based on top
   of it.
 - Add 2/2 to stop extract_msr() from masking firmware P-state changes,
   as reported by Sashiko, and note the dependency in 1/2's changelog.
 - 1/2: no functional change; changelog extended to say that it fixes
   only the cached side of the comparison, and a duplicate
   Signed-off-by was removed.

Li RongQing (2):
  cpufreq: acpi-cpufreq: fix P-state index mismatch in
    get_cur_freq_on_cpu()
  cpufreq: acpi-cpufreq: don't mask firmware P-state changes

 drivers/cpufreq/acpi-cpufreq.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

-- 
2.9.4


             reply	other threads:[~2026-11-06 18:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 18:40 lirongqing [this message]
2026-11-06 18:40 ` [PATCH v5 1/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in get_cur_freq_on_cpu() lirongqing
2026-11-06 18:40 ` [PATCH v5 2/2] cpufreq: acpi-cpufreq: don't mask firmware P-state changes lirongqing
2026-11-10 20:01 ` [PATCH v5 0/2] cpufreq: acpi-cpufreq: fix P-state index mismatch between perf->states[] and freq_table[] Rafael J. Wysocki (Intel)
2026-11-12  2:15   ` 答复: [外部邮件] " Li,Rongqing

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=20261106184008.1728-1-lirongqing@baidu.com \
    --to=lirongqing@baidu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=viresh.kumar@linaro.org \
    --cc=zhongqiu.han@oss.qualcomm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®