[PATCH v3] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards

[PATCH v3] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards

[Shuwen Bao]

The HP HyperX OMEN 16-am2xxx (DMI board 8F1C, 26C1 platform cycle,
Arrow Lake-HXR) is listed in the OMEN Command Center device
capability table with DisplayName "HyperX OMEN 16" and the
"PerformanceControl" feature, but is missing from the kernel's
hp_wmi_feature_boards[] list.

Add 8F1C to the hp_wmi_feature_boards[] list, using
omen_v1_legacy_board_params as driver_data.

Tested on a HyperX OMEN 16-am2xxx (kernel 7.3.0-rc6):
after loading the patched hp-wmi module, the platform_profile
interface is exposed, and switching to the performance profile
raises the CPU from a ~2.9 GHz (P-core) / 2.6 GHz (E-core) cap to
~5 GHz / ~3.5 GHz under a multi-thread load (stress-ng). The GPU cap is
raised to ~114W, tested with gpu_burn.

Suggested-by: Krishna Chomal <krishna.chomal108@gmail.com>
Signed-off-by: Shuwen Bao <baoshuwen2013@outlook.com>

---
v3:
 - Switch to the hp_wmi_feature_boards[] approach instead of
   omen_thermal_profile_boards[], as suggested by Krishna.

v2: https://lore.kernel.org/platform-driver-x86/SI2PR04MB58957D08A31E56D73C751885A2862@SI2PR04MB5895.apcprd04.prod.outlook.com/
v1: https://lore.kernel.org/platform-driver-x86/SI2PR04MB589526A21FB0EF4E8ABA749CA2AB2@SI2PR04MB5895.apcprd04.prod.outlook.com/
---
 drivers/platform/x86/hp/hp-wmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/hp/hp-wmi.c b/drivers/platform/x86/hp/hp-wmi.c
index 615b4cf6fc45..37c3e94e6819 100644
--- a/drivers/platform/x86/hp/hp-wmi.c
+++ b/drivers/platform/x86/hp/hp-wmi.c
@@ -343,6 +343,10 @@ static const struct dmi_system_id hp_wmi_feature_boards[] __initconst = {
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8E35") },
 		.driver_data = (void *)&omen_v1_legacy_board_params,
 	},
+	{
+		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8F1C") },
+		.driver_data = (void *)&omen_v1_legacy_board_params,
+	},
 	{},
 };
 
-- 
2.53.0

Re: [PATCH v3] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards

[Ilpo Järvinen]

On Wed, 07 Oct 2026 11:08:36 +0800, Shuwen Bao wrote:

> The HP HyperX OMEN 16-am2xxx (DMI board 8F1C, 26C1 platform cycle,
> Arrow Lake-HXR) is listed in the OMEN Command Center device
> capability table with DisplayName "HyperX OMEN 16" and the
> "PerformanceControl" feature, but is missing from the kernel's
> hp_wmi_feature_boards[] list.
> 
> Add 8F1C to the hp_wmi_feature_boards[] list, using
> omen_v1_legacy_board_params as driver_data.
> 
> [...]

Thank you for your contribution, it has been applied to my local
review-ilpo-next branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-next branch only once I've pushed my
local branch there, which might take a while.

FYI [if applicable to your patch], as per Linus' policy change, also
fixes are mostly routed through for-next unless the fix is for a
commit introduced in the most recent cycle or is clearly a regression
fix.

The list of commits applied:
[1/1] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards
      commit: 2cd10a35f3f09c49698956d32c6374fbdc03245d

--
 i.

Re: [PATCH v3] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards

[Shuwen Bao]

在 2026年10月15日星期四 中国标准时间 22:28:33，Ilpo Järvinen 写道：
> On Wed, 07 Oct 2026 11:08:36 +0800, Shuwen Bao wrote:
> > The HP HyperX OMEN 16-am2xxx (DMI board 8F1C, 26C1 platform cycle,
> > Arrow Lake-HXR) is listed in the OMEN Command Center device
> > capability table with DisplayName "HyperX OMEN 16" and the
> > "PerformanceControl" feature, but is missing from the kernel's
> > hp_wmi_feature_boards[] list.
> > 
> > Add 8F1C to the hp_wmi_feature_boards[] list, using
> > omen_v1_legacy_board_params as driver_data.
> > 
> > [...]
> 
> Thank you for your contribution, it has been applied to my local
> review-ilpo-next branch. Note it will show up in the public
> platform-drivers-x86/review-ilpo-next branch only once I've pushed my
> local branch there, which might take a while.
> 
> FYI [if applicable to your patch], as per Linus' policy change, also
> fixes are mostly routed through for-next unless the fix is for a
> commit introduced in the most recent cycle or is clearly a regression
> fix.
> 
> The list of commits applied:
> [1/1] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards
>       commit: 2cd10a35f3f09c49698956d32c6374fbdc03245d
> 
> --
>  i.

Hi Krishna, Ilpo,

Thank you for applying the patch. However, after further extended testing, 
I noticed a regression on this hardware. 

Specifically, the board automatically reverts from performance mode back 
to balanced mode after a period of time (it seems like the time is not 
constant), which resembles the behavior of a timed thermal board. 

This doesn't seem to be a thermal threshold or PL1/PL2 limitation, 
because manually switching the profile back to balanced and then to 
performance will re-enable performance mode successfully.

I am still investigating the root cause and am currently unsure how to 
properly fix this yet. I'm currently testing adding 8F1C to 
omen_timed_thermal_profile_boards as a fix.

I haven't looked deeply into hp-wmi.c before, so if adding it to that 
array is not the correct or intended way to handle this, please let me 
know.

@Ilpo, since commit 2cd10a35f3f0 ("platform/x86: hp-wmi: add support for 
OMEN 16-am2xxx boards") is already in review-ilpo-next, would you prefer 
to revert it for now until I figure out a proper solution, or should we 
keep it as-is while I investigate?

Thanks,
Shuwen

Re: [PATCH v3] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 3437 bytes --]

On Sat, 24 Oct 2026, Shuwen Bao wrote:

> 在 2026年10月15日星期四 中国标准时间 22:28:33，Ilpo Järvinen 写道：
> > On Wed, 07 Oct 2026 11:08:36 +0800, Shuwen Bao wrote:
> > > The HP HyperX OMEN 16-am2xxx (DMI board 8F1C, 26C1 platform cycle,
> > > Arrow Lake-HXR) is listed in the OMEN Command Center device
> > > capability table with DisplayName "HyperX OMEN 16" and the
> > > "PerformanceControl" feature, but is missing from the kernel's
> > > hp_wmi_feature_boards[] list.
> > > 
> > > Add 8F1C to the hp_wmi_feature_boards[] list, using
> > > omen_v1_legacy_board_params as driver_data.
> > > 
> > > [...]
> > 
> > Thank you for your contribution, it has been applied to my local
> > review-ilpo-next branch. Note it will show up in the public
> > platform-drivers-x86/review-ilpo-next branch only once I've pushed my
> > local branch there, which might take a while.
> > 
> > FYI [if applicable to your patch], as per Linus' policy change, also
> > fixes are mostly routed through for-next unless the fix is for a
> > commit introduced in the most recent cycle or is clearly a regression
> > fix.
> > 
> > The list of commits applied:
> > [1/1] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards
> >       commit: 2cd10a35f3f09c49698956d32c6374fbdc03245d
> > 
> > --
> >  i.
> 
> Hi Krishna, Ilpo,
> 
> Thank you for applying the patch. However, after further extended testing, 
> I noticed a regression on this hardware. 
> 
> Specifically, the board automatically reverts from performance mode back 
> to balanced mode after a period of time (it seems like the time is not 
> constant), which resembles the behavior of a timed thermal board. 
> 
> This doesn't seem to be a thermal threshold or PL1/PL2 limitation, 
> because manually switching the profile back to balanced and then to 
> performance will re-enable performance mode successfully.
> 
> I am still investigating the root cause and am currently unsure how to 
> properly fix this yet. I'm currently testing adding 8F1C to 
> omen_timed_thermal_profile_boards as a fix.
>
> I haven't looked deeply into hp-wmi.c before, so if adding it to that 
> array is not the correct or intended way to handle this, please let me 
> know.

Hi,

It certainly sounds like a similar problem. I'm not sure if the code 
related to omen_timed_thermal_profile_boards is hooked though with this 
board because it requires is_omen_thermal_profile() returning true.

Some other drivers do profile keepalive by writing the same profile 
periodically if nothing has changed the profile for a while, that would 
seem easier/more generic solution than finding timer offset the current 
solution uses.

If you need to change something it would be nice to generalize this 
so that the keepalive is not bound to a particular submodel category. 
The driver is slowly moving towards that for all models so that we'd 
have only one central dmi matching table where the struct would hold all 
necessary info/quirk details.

> @Ilpo, since commit 2cd10a35f3f0 ("platform/x86: hp-wmi: add support for 
> OMEN 16-am2xxx boards") is already in review-ilpo-next, would you prefer 
> to revert it for now until I figure out a proper solution, or should we 
> keep it as-is while I investigate?

I think I'll keep the change as it still works to an extent so it seems 
better than nothing.

-- 
 i.

Re: [PATCH v3] platform/x86: hp-wmi: add support for OMEN 16-am2xxx boards

[Shuwen Bao]

On Tue, 27 Oct 2026 Ilpo Järvinen wrote:
> On Sat, 24 Oct 2026, Shuwen Bao wrote:
> 
> Hi,
> 
> It certainly sounds like a similar problem. I'm not sure if the code
> related to omen_timed_thermal_profile_boards is hooked though with
> this board because it requires is_omen_thermal_profile() returning
> true.
> 
> Some other drivers do profile keepalive by writing the same profile
> periodically if nothing has changed the profile for a while, that
> would seem easier/more generic solution than finding timer offset the
> current solution uses.
> 
> If you need to change something it would be nice to generalize this
> so that the keepalive is not bound to a particular submodel category.
> The driver is slowly moving towards that for all models so that we'd
> have only one central dmi matching table where the struct would hold
> all necessary info/quirk details.
> 
> > @Ilpo, since commit 2cd10a35f3f0 ("platform/x86: hp-wmi: add support
> > for OMEN 16-am2xxx boards") is already in review-ilpo-next, would
> > you prefer to revert it for now until I figure out a proper
> > solution, or should we keep it as-is while I investigate?
> 
> I think I'll keep the change as it still works to an extent so it
> seems better than nothing.

Hi Ilpo, Krishna,

Thank you for the guidance. I'll look into generalizing the keepalive 
mechanism as suggested.
In the meantime, I have observed a new symptom regarding this behavior: 
if no heavy load is applied to the system, the ~5000MHz boost clock 
(which only occurs under performance mode) can still be observed even 
after several hours.
It is currently still unclear whether this automatic reversion under 
load is being enforced directly by the EC firmware or handled somewhere 
within hp_wmi.c. I will continue investigating to determine the root 
cause.

Best regards,
Shwen Bao