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

Martin Schiller posted 2 patches 1 month ago
arch/x86/kernel/cpu/intel.c    | 23 ++++++++++++++++
drivers/cpufreq/intel_pstate.c | 62 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+)
[PATCH 0/2] x86/cpu: P-state support for Lightning Mountain
Posted by Martin Schiller 1 month ago
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>
Re: [PATCH 0/2] x86/cpu: P-state support for Lightning Mountain
Posted by Rafael J. Wysocki 1 month ago
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
Posted by Martin Schiller 1 month ago
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
Posted by srinivas pandruvada 1 month ago
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
Posted by Martin Schiller 3 weeks, 4 days ago
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