[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ba407b6-a108-41ce-b1b2-3c03aa25d272@intel.com>
Date: Wed, 12 Nov 2025 12:07:07 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Kaushlendra Kumar <kaushlendra.kumar@...el.com>, mingo@...hat.com,
acme@...nel.org, namhyung@...nel.org, jolsa@...nel.org,
adrian.hunter@...el.com, bp@...en8.de, dave.hansen@...ux.intel.com,
x86@...nel.org
Cc: linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/events/intel/cstate: Add Pantherlake support
On 11/12/25 01:00, Kaushlendra Kumar wrote:
> It supports the same C-state residency counters as Lunarlake.This
> enables monitoring of C1, C6, C7 core states and C2,C3,C6,C10
> package states residency counters on Pantherlake platforms.
Is this actually documented? Or is there just a smoke-filled room at
Intel somewhere where this is decided?
> diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
> index ec753e39b007..b3582eeb6c4b 100644
> --- a/arch/x86/events/intel/cstate.c
> +++ b/arch/x86/events/intel/cstate.c
> @@ -41,7 +41,7 @@
> * MSR_CORE_C1_RES: CORE C1 Residency Counter
> * perf code: 0x00
> * Available model: SLM,AMT,GLM,CNL,ICX,TNT,ADL,RPL
> - * MTL,SRF,GRR,ARL,LNL
> + * MTL,SRF,GRR,ARL,LNL,PTL
Could we get rid of these, please?
Folks can 100% figure this out from the data structures themselves.
Unless there's a compelling reason, this is pure churn.
> @@ -652,6 +653,7 @@ static const struct x86_cpu_id intel_cstates_match[] __initconst = {
> X86_MATCH_VFM(INTEL_ARROWLAKE_H, &adl_cstates),
> X86_MATCH_VFM(INTEL_ARROWLAKE_U, &adl_cstates),
> X86_MATCH_VFM(INTEL_LUNARLAKE_M, &lnl_cstates),
> + X86_MATCH_VFM(INTEL_PANTHERLAKE_L, &lnl_cstates),
> { },
> };
> MODULE_DEVICE_TABLE(x86cpu, intel_cstates_match);
Also, why *can't* this just be enumerated?
Powered by blists - more mailing lists