From: Krishna Chomal <krishna.chomal108@gmail.com>
To: Julien ROBIN <julien.robin28@free.fr>
Cc: platform-driver-x86@vger.kernel.org,
"Suryansh Singh" <technosfan14@gmail.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Hans de Goede" <hansg@kernel.org>
Subject: Re: hp_wmi: Unknown EC layout for board 8C9C
Date: Tue, 13 Oct 2026 00:31:20 +0530 [thread overview]
Message-ID: <as0tBtG_BZSBdfXO@archlinux> (raw)
In-Reply-To: <f3e855cd-259f-440f-be81-d491ae3df7e3@free.fr>
On Wed, Oct 07, 2026 at 03:17:00AM +0200, Julien ROBIN wrote:
>> About victus_s_powersource_event() to manually trigger CPU power limits change, I remember the problem only existed when performance mode was active, it was only about CPU power limits (not GPU) and didn't exist with any of the others modes (balanced, low-power or fallback). Maximum/excessive power limits were kept despite going from AC to battery, and I believe they also weren't restored correctly when going back on AC. On Windows with Omen Gaming Hub this seemed to be addressed by rewriting power limits on power source change. As I updated BIOS to F.18 I'll check if anything evolved about this.
>>
>> I'll do the tests tonight: Unloading hp-wmi driver and looking at RyzenAdj allows testing what happens when nothing is done by hp-wmi driver. But I need physical access to the device to unplug the cord, and also to put it to sleep mode, waking it up.
>> I'll keep you informed of the results.
>
>Hi back, to complete my feedback from few hours ago: having physical access to the laptop I did the complete tests again on BIOS F.18, same behavior as BIOS F.11
>
>About going to suspend / waking up the computer from sleep:
> - When the computer is placed to suspend mode while performance mode is active, and hp-wmi unloaded, when resuming, it's still in performance mode without having to ask for it again (even if asleep for more than 120 seconds)
> - About the 120 seconds delay before going to fallback mode, this delay is only elapsing when the computer is running. When resuming, 120 seconds are available again (even if only few seconds were left when entering suspend mode)
> - However when the computer is placed to suspend mode while max fan speed is active, when resuming the fan isn't max speed anymore.
>
>About power source changes:
> - When the laptop is running on performance mode, unloading the hp-wmi driver and disconnecting the power plug let the CPU stuck to maximum/excessive power limits (60/65W in my case instead of expected reduction to 25/30W when running on battery).
> - Same thing in the other way, when the laptop is running on battery, on performance mode and CPU power limits to 25/30W, unloading hp-wmi driver and connecting the power plug let the CPU stuck to low power limits (instead of rising to 60/65W).
> - However if the power source change occurs while the computer is suspended, then when waking up, the CPU power limits are set to the right ones by the laptop itself.
> - Also, in every others modes (balanced, low-power, or fallback after 120 seconds without hp-wmi interaction), on power source changes, CPU power limits are automatically adjusted by the laptop itself.
>
>So the laptop forgetting to adjust CPU power limits on power source change, only occurs in performance mode while the computer isn't suspended.
>In any other circumstance the laptop behave fine. Would be interesting to see if this strange quirk I found out by extensive testing also occurs to some others models.
I wish I could test it, but unfortunately sleep modes in firmware are
broken for a lot of laptops in the Omen series (including mine) so I
would not be able to wake up from sleep and test the states.
I did test the CPU power limits during power supply change as you
suggested. For me, it looks like the firmware is automatically taking
care of it. But to be fair, it doesn't cost us a lot to enforce limits
during such events, so it is fine if it is applied on all boards.
>As always, I keep available if anything more is needed!
>Thanks again for the work
I will be sure to get my patches tested by you, when I do eventually
start working on this. Thanks a lot for your help.
>Best regards,
>Julien
next prev parent reply other threads:[~2026-10-12 19:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-03 22:45 hp_wmi: Unknown EC layout for board 8C9C Julien ROBIN
2026-10-05 20:00 ` Krishna Chomal
2026-10-06 13:41 ` Julien ROBIN
2026-10-07 1:17 ` Julien ROBIN
2026-10-12 19:01 ` Krishna Chomal [this message]
2026-10-12 18:54 ` Krishna Chomal
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=as0tBtG_BZSBdfXO@archlinux \
--to=krishna.chomal108@gmail.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=julien.robin28@free.fr \
--cc=platform-driver-x86@vger.kernel.org \
--cc=technosfan14@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.