mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Martin Schiller <ms@dev.tdt.de>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Len Brown <lenb@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Florian Eckert <fe@dev.tdt.de>, Martin Schiller <ms@dev.tdt.de>
Subject: [PATCH 1/2] cpufreq: intel_pstate: Add Lightning Mountain support
Date: Fri, 06 Mar 2026 09:27:24 +0100	[thread overview]
Message-ID: <20260306-cpufreq_lgm-v1-1-47f104aed7c2@dev.tdt.de> (raw)
In-Reply-To: <20260306-cpufreq_lgm-v1-0-47f104aed7c2@dev.tdt.de>

This adds Intel / MaxLinear Lightning Mountain (LGM) support to the
intel P-state driver.

Although the LGM is related to the AIRMONT (Atom), it uses different
register values and frequency table.

This changes are based on patched kernel sources of the MaxLinear SDK,
which can be found at https://github.com/maxlinear/linux

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
---
 drivers/cpufreq/intel_pstate.c | 62 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index ec4abe3745736b0130fae117d037c5204e048f80..330a04d9af15309e231c5f8f3dc78e9eea0635e6 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2150,6 +2150,58 @@ static void atom_get_vid(struct cpudata *cpudata)
 	cpudata->vid.turbo = value & 0x7f;
 }
 
+static int lgm_get_max_pstate(int not_used)
+{
+	/* The Lightning Mountain hardware seems to be designed to run up to
+	 * P-state 32 (2496 MHz), which is what atom_get_max_pstate() will
+	 * return. But the Data Sheet shows a max. supported CPU freqency of
+	 * 2028 MHz and also the code from the MaxLinear SDK tells, that "the
+	 * max. P-state is currently not supported". So we have to manually
+	 * limit the P-state here to 26 (2028 MHz).
+	 */
+	return 26;
+}
+
+static u64 lgm_get_val(struct cpudata *cpudata, int pstate)
+{
+	u64 val;
+	int index;
+
+	static const u32 vid[] = {
+		2, 2, 2, 2, 3, 3, 3, 4, 5, 6, 7, 7, 7
+	};
+
+	pstate &= ~0x1;
+
+	val = (u64)pstate << 8;
+
+	index = (pstate - cpudata->pstate.min_pstate) >> 1;
+	WARN_ON(index >= ARRAY_SIZE(vid));
+	return val | vid[index];
+}
+
+static int lgm_get_scaling(void)
+{
+	u64 value;
+	int i, xtal, div, multi;
+
+	static const u32 freq[8] = {
+		26000, 25000, 19200, 38400,
+		40000, 40000, 40000, 40000
+	};
+
+	rdmsrq(MSR_FSB_FREQ, value);
+	i = value & 0x1f;
+	WARN_ON(i != 0x1f);
+
+	xtal = freq[(value >> 32) & 0x7];
+	div = (value >> 40) & 0xff;
+	WARN_ON(div == 0x0);
+	multi = (value >> 48) & 0xff;
+
+	return (xtal * multi) / div;
+}
+
 static int core_get_min_pstate(int cpu)
 {
 	u64 value;
@@ -2669,6 +2721,15 @@ static const struct pstate_funcs airmont_funcs = {
 	.get_vid = atom_get_vid,
 };
 
+static const struct pstate_funcs lgm_funcs = {
+	.get_max = lgm_get_max_pstate,
+	.get_max_physical = lgm_get_max_pstate,
+	.get_min = atom_get_min_pstate,
+	.get_turbo = atom_get_turbo_pstate,
+	.get_val = lgm_get_val,
+	.get_scaling = lgm_get_scaling,
+};
+
 static const struct pstate_funcs knl_funcs = {
 	.get_max = core_get_max_pstate,
 	.get_max_physical = core_get_max_pstate_physical,
@@ -2695,6 +2756,7 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
 	X86_MATCH(INTEL_HASWELL_G,		core_funcs),
 	X86_MATCH(INTEL_BROADWELL_G,		core_funcs),
 	X86_MATCH(INTEL_ATOM_AIRMONT,		airmont_funcs),
+	X86_MATCH(INTEL_ATOM_AIRMONT_NP,	lgm_funcs),
 	X86_MATCH(INTEL_SKYLAKE_L,		core_funcs),
 	X86_MATCH(INTEL_BROADWELL_X,		core_funcs),
 	X86_MATCH(INTEL_SKYLAKE,		core_funcs),

-- 
2.47.3


  reply	other threads:[~2026-03-06  8:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-06  8:27 [PATCH 0/2] x86/cpu: P-state support for Lightning Mountain Martin Schiller
2026-03-06  8:27 ` Martin Schiller [this message]
2026-03-06  8:27 ` [PATCH 2/2] x86/cpu/intel: Add EIST workaround " Martin Schiller
2026-03-06 16:54   ` Dave Hansen
2026-03-09  9:30     ` Martin Schiller
2026-03-06 17:59 ` [PATCH 0/2] x86/cpu: P-state support " Rafael J. Wysocki
2026-03-09  6:53   ` Martin Schiller
2026-03-09 15:57     ` srinivas pandruvada
2026-03-17  6:53       ` Martin Schiller

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=20260306-cpufreq_lgm-v1-1-47f104aed7c2@dev.tdt.de \
    --to=ms@dev.tdt.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fe@dev.tdt.de \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rafael@kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tglx@kernel.org \
    --cc=viresh.kumar@linaro.org \
    --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 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®