[PATCH 0/2] x86/cpu: P-state support for Lightning Mountain

[PATCH 0/2] x86/cpu: P-state support for Lightning Mountain

[Martin Schiller]

This patch set contains 2 commits to get P-state support for Intel /
MaxLinear Lightning Mountain. The first adds the needed code to the
intel_pstate driver. The second adds a workaround to the x86/cpu
subsystem to enable EIST on all cpus.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
---
Martin Schiller (2):
      cpufreq: intel_pstate: Add Lightning Mountain support
      x86/cpu/intel: Add EIST workaround for Lightning Mountain.

 arch/x86/kernel/cpu/intel.c    | 23 ++++++++++++++++
 drivers/cpufreq/intel_pstate.c | 62 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 85 insertions(+)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260306-cpufreq_lgm-c0280ef989c3

Best regards,
-- 
Martin Schiller <ms@dev.tdt.de>

[PATCH 1/2] cpufreq: intel_pstate: Add Lightning Mountain support

[Martin Schiller]

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

[PATCH 2/2] x86/cpu/intel: Add EIST workaround for Lightning Mountain.

[Martin Schiller]

Add a workaround for Intel / MaxLinear Lightning Mountain to enable
Enhanced Intel SpeedStep Technology (EIST) for each cpu. Otherwise, the
frequency on some cpus is locked to the minimum value of 624 MHz.
This usually would be the job of the BIOS / bootloader, but U-Boot only
enables it on the cpu on which it is running.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
---
 arch/x86/kernel/cpu/intel.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 98ae4c37c93eccf775d5632acf122603a19918a8..e49df04e8d491158cc48f8d8bef824c434256d09 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -466,6 +466,29 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 #else
 static void intel_workarounds(struct cpuinfo_x86 *c)
 {
+	u64 misc_enable;
+
+	/*
+	 * Intel / MaxLinear Lightning Mountain workaround to enable Enhanced
+	 * Intel SpeedStep Technology (EIST) for each cpu. Otherwise, the
+	 * frequency on some cpus is locked to the minimum value of 624 MHz.
+	 * This usually would be the job of the BIOS / bootloader, but U-Boot
+	 * only enables it on the cpu on which it is running.
+	 */
+	if (c->x86_vfm == INTEL_ATOM_AIRMONT_NP) {
+		rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
+		if (!(misc_enable & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
+			misc_enable |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP;
+			wrmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
+
+			/* check to see if it was enabled successfully */
+			rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
+			if (!(misc_enable & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
+				pr_info("CPU%d: Can't enable Enhanced SpeedStep\n",
+					c->cpu_index);
+			}
+		}
+	}
 }
 #endif
 

-- 
2.47.3

Re: [PATCH 2/2] x86/cpu/intel: Add EIST workaround for Lightning Mountain.

[Dave Hansen]

So what's weird about these systems? Do they not have a "normal" BIOS
based on the Intel reference one?

I don't know much about this specific feature, but this patch is doing
some unusual things. I'll elaborate below:

> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 98ae4c37c93eccf775d5632acf122603a19918a8..e49df04e8d491158cc48f8d8bef824c434256d09 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -466,6 +466,29 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
>  #else
>  static void intel_workarounds(struct cpuinfo_x86 *c)
>  {
> +	u64 misc_enable;
> +
> +	/*
> +	 * Intel / MaxLinear Lightning Mountain workaround to enable Enhanced
> +	 * Intel SpeedStep Technology (EIST) for each cpu. Otherwise, the
> +	 * frequency on some cpus is locked to the minimum value of 624 MHz.
> +	 * This usually would be the job of the BIOS / bootloader, but U-Boot
> +	 * only enables it on the cpu on which it is running.
> +	 */
> +	if (c->x86_vfm == INTEL_ATOM_AIRMONT_NP) {

Model checks area kinda a last resort. A quick search in the SDM found:

CPUID.01H:ECX[7]: If 1, supports Enhanced Intel SpeedStep® technology.

But there's other chit chat in the "Runtime Mutable CPUID Fields"
section that makes it seem that it's not a really feature enumeration
bit, but a flag to tell if the BIOS enabled it:

	CPUID.01H:ECX[7] -- This feature flag reflects the setting in
			    IA32_MISC_ENABLE[16]

But the plot thickens because the *existing* code does this:

static int centrino_cpu_init(struct cpufreq_policy *policy)
{
...
        /* Only Intel makes Enhanced Speedstep-capable CPUs */
        if (cpu->x86_vendor != X86_VENDOR_INTEL ||
            !cpu_has(cpu, X86_FEATURE_EST))
                return -ENODEV;
...
        if (!(l & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {

Which, again, makes it seem like X86_FEATURE_EST (aka. CPUID.01H:ECX[7])
tells you if the MSR bit is supported, not whether it is enabled.

I'd tend to trust the existing kernel code over quibbling with the SDM
wording in general. It's also possible the old code was just confused or
something was buggy.

> +		rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
> +		if (!(misc_enable & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
> +			misc_enable |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP;
> +			wrmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
> +
> +			/* check to see if it was enabled successfully */
> +			rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
> +			if (!(misc_enable & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
> +				pr_info("CPU%d: Can't enable Enhanced SpeedStep\n",
> +					c->cpu_index);
> +			}
> +		}
> +	}
>  }


This is also not written in the normal kernel style which minimizes
indentation. For instance, the function should have opened with:

	if (c->x86_vfm != INTEL_ATOM_AIRMONT_NP)
		return;

It also needs to be reconciled with centrino_cpu_init() (at least).
Having *a* single place to go in and say "If this CPU supports 'EST',
turn it on" would be a minimal refactoring that could be shared by your
new workaround and the old centrino code.

centrino_cpu_init() does look gated on X86_FEATURE_EST already, though
because of the centrino_ids[]. So, you still need to figure out the
interaction with X86_FEATURE_EST for when you call the workaround.

Re: [PATCH 2/2] x86/cpu/intel: Add EIST workaround for Lightning Mountain.

[Martin Schiller]

On 2026-03-06 17:54, Dave Hansen wrote:
> So what's weird about these systems? Do they not have a "normal" BIOS
> based on the Intel reference one?

That's right, the Lightning Mountain SoC is an x86 (Atom) system, but
it doesn't have a classic BIOS.


> I don't know much about this specific feature, but this patch is doing
> some unusual things. I'll elaborate below:
> 
>> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
>> index 
>> 98ae4c37c93eccf775d5632acf122603a19918a8..e49df04e8d491158cc48f8d8bef824c434256d09 
>> 100644
>> --- a/arch/x86/kernel/cpu/intel.c
>> +++ b/arch/x86/kernel/cpu/intel.c
>> @@ -466,6 +466,29 @@ static void intel_workarounds(struct cpuinfo_x86 
>> *c)
>>  #else
>>  static void intel_workarounds(struct cpuinfo_x86 *c)
>>  {
>> +	u64 misc_enable;
>> +
>> +	/*
>> +	 * Intel / MaxLinear Lightning Mountain workaround to enable 
>> Enhanced
>> +	 * Intel SpeedStep Technology (EIST) for each cpu. Otherwise, the
>> +	 * frequency on some cpus is locked to the minimum value of 624 MHz.
>> +	 * This usually would be the job of the BIOS / bootloader, but 
>> U-Boot
>> +	 * only enables it on the cpu on which it is running.
>> +	 */
>> +	if (c->x86_vfm == INTEL_ATOM_AIRMONT_NP) {
> 
> Model checks area kinda a last resort. A quick search in the SDM found:
> 
> CPUID.01H:ECX[7]: If 1, supports Enhanced Intel SpeedStep® technology.
> 
> But there's other chit chat in the "Runtime Mutable CPUID Fields"
> section that makes it seem that it's not a really feature enumeration
> bit, but a flag to tell if the BIOS enabled it:
> 
> 	CPUID.01H:ECX[7] -- This feature flag reflects the setting in
> 			    IA32_MISC_ENABLE[16]
> 
> But the plot thickens because the *existing* code does this:
> 
> static int centrino_cpu_init(struct cpufreq_policy *policy)
> {
> ...
>         /* Only Intel makes Enhanced Speedstep-capable CPUs */
>         if (cpu->x86_vendor != X86_VENDOR_INTEL ||
>             !cpu_has(cpu, X86_FEATURE_EST))
>                 return -ENODEV;
> ...
>         if (!(l & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
> 
> Which, again, makes it seem like X86_FEATURE_EST (aka. 
> CPUID.01H:ECX[7])
> tells you if the MSR bit is supported, not whether it is enabled.
> 
> I'd tend to trust the existing kernel code over quibbling with the SDM
> wording in general. It's also possible the old code was just confused 
> or
> something was buggy.
> 
>> +		rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
>> +		if (!(misc_enable & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
>> +			misc_enable |= MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP;
>> +			wrmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
>> +
>> +			/* check to see if it was enabled successfully */
>> +			rdmsrq(MSR_IA32_MISC_ENABLE, misc_enable);
>> +			if (!(misc_enable & MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP)) {
>> +				pr_info("CPU%d: Can't enable Enhanced SpeedStep\n",
>> +					c->cpu_index);
>> +			}
>> +		}
>> +	}
>>  }
> 
> 
> This is also not written in the normal kernel style which minimizes
> indentation. For instance, the function should have opened with:
> 
> 	if (c->x86_vfm != INTEL_ATOM_AIRMONT_NP)
> 		return;
> 
> It also needs to be reconciled with centrino_cpu_init() (at least).
> Having *a* single place to go in and say "If this CPU supports 'EST',
> turn it on" would be a minimal refactoring that could be shared by your
> new workaround and the old centrino code.
> 
> centrino_cpu_init() does look gated on X86_FEATURE_EST already, though
> because of the centrino_ids[]. So, you still need to figure out the
> interaction with X86_FEATURE_EST for when you call the workaround.

As you already noted, EIST is also enabled in the Intel Enhanced
SpeedStep (deprecated) "speedstep-centrino.c" driver. It is also
enabled in the VIA C7 Enhanced PowerSaver driver "e_powersaver.c".

The question now is whether and where this is best handled centrally.

Re: [PATCH 0/2] x86/cpu: P-state support for Lightning Mountain

[Rafael J. Wysocki]

On Fri, Mar 6, 2026 at 9:27 AM Martin Schiller <ms@dev.tdt.de> wrote:
>
> This patch set contains 2 commits to get P-state support for Intel /
> MaxLinear Lightning Mountain. The first adds the needed code to the
> intel_pstate driver. The second adds a workaround to the x86/cpu
> subsystem to enable EIST on all cpus.

Can you please combine the patches?

Or does the first one work just fine without the second one?

> Signed-off-by: Martin Schiller <ms@dev.tdt.de>
> ---
> Martin Schiller (2):
>       cpufreq: intel_pstate: Add Lightning Mountain support
>       x86/cpu/intel: Add EIST workaround for Lightning Mountain.
>
>  arch/x86/kernel/cpu/intel.c    | 23 ++++++++++++++++
>  drivers/cpufreq/intel_pstate.c | 62 ++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 85 insertions(+)
> ---
> base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
> change-id: 20260306-cpufreq_lgm-c0280ef989c3
>
> Best regards,
> --
> Martin Schiller <ms@dev.tdt.de>
>

Re: [PATCH 0/2] x86/cpu: P-state support for Lightning Mountain

[Martin Schiller]

On 2026-03-06 18:59, Rafael J. Wysocki wrote:
> On Fri, Mar 6, 2026 at 9:27 AM Martin Schiller <ms@dev.tdt.de> wrote:
>> 
>> This patch set contains 2 commits to get P-state support for Intel /
>> MaxLinear Lightning Mountain. The first adds the needed code to the
>> intel_pstate driver. The second adds a workaround to the x86/cpu
>> subsystem to enable EIST on all cpus.
> 
> Can you please combine the patches?
> 
> Or does the first one work just fine without the second one?

Well, the first patch can basically be applied without the second one,
but then frequency stepping will only work on the first cpu core.

I split the two changes because they apply to different parts of the
kernel sources.

But you're probably right, and it makes sense to combine the two
patches.


BTW: The original code from the MaxLinear SDK enables EIST in the
intel_pstate driver, but I don't think that's the right place for it.

Re: [PATCH 0/2] x86/cpu: P-state support for Lightning Mountain

[srinivas pandruvada]

On Mon, 2026-03-09 at 07:53 +0100, Martin Schiller wrote:
> On 2026-03-06 18:59, Rafael J. Wysocki wrote:
> > On Fri, Mar 6, 2026 at 9:27 AM Martin Schiller <ms@dev.tdt.de>
> > wrote:
> > > 
> > > This patch set contains 2 commits to get P-state support for
> > > Intel /
> > > MaxLinear Lightning Mountain. The first adds the needed code to
> > > the
> > > intel_pstate driver. The second adds a workaround to the x86/cpu
> > > subsystem to enable EIST on all cpus.
> > 
> > Can you please combine the patches?
> > 
> > Or does the first one work just fine without the second one?
> 
> Well, the first patch can basically be applied without the second
> one,
> but then frequency stepping will only work on the first cpu core.
> 
> I split the two changes because they apply to different parts of the
> kernel sources.
> 
> But you're probably right, and it makes sense to combine the two
> patches.
> 
> 
> BTW: The original code from the MaxLinear SDK enables EIST in the
> intel_pstate driver, but I don't think that's the right place for it.

This is a special case. But intel_pstate driver can be disabled from
kernel command line to use acpi cpufreq driver. So in that case
enabling in intel_pstate will not help.

Thanks,
Srinivas

Re: [PATCH 0/2] x86/cpu: P-state support for Lightning Mountain

[Martin Schiller]

On 2026-03-09 16:57, srinivas pandruvada wrote:
> On Mon, 2026-03-09 at 07:53 +0100, Martin Schiller wrote:
>> On 2026-03-06 18:59, Rafael J. Wysocki wrote:
>> > On Fri, Mar 6, 2026 at 9:27 AM Martin Schiller <ms@dev.tdt.de>
>> > wrote:
>> > >
>> > > This patch set contains 2 commits to get P-state support for
>> > > Intel /
>> > > MaxLinear Lightning Mountain. The first adds the needed code to
>> > > the
>> > > intel_pstate driver. The second adds a workaround to the x86/cpu
>> > > subsystem to enable EIST on all cpus.
>> >
>> > Can you please combine the patches?
>> >
>> > Or does the first one work just fine without the second one?
>> 
>> Well, the first patch can basically be applied without the second
>> one,
>> but then frequency stepping will only work on the first cpu core.
>> 
>> I split the two changes because they apply to different parts of the
>> kernel sources.
>> 
>> But you're probably right, and it makes sense to combine the two
>> patches.
>> 
>> 
>> BTW: The original code from the MaxLinear SDK enables EIST in the
>> intel_pstate driver, but I don't think that's the right place for it.
> 
> This is a special case. But intel_pstate driver can be disabled from
> kernel command line to use acpi cpufreq driver. So in that case
> enabling in intel_pstate will not help.

You're basically right, but the MaxLinear Lightning Mountain doesn't
support ACPI either, so the acpi cpufreq driver wouldn't work anyway.

So perhaps it would be best after all if I integrated this routine
into the intel_pstate driver.

Regards,
Martin