[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8127d88-194a-4a23-b22e-040e2c6b3e9b@gmx.de>
Date: Mon, 28 Apr 2025 14:31:28 +0200
From: Armin Wolf <W_Armin@....de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: rui.zhang@...el.com, lenb@...nel.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] ACPI: thermal: Properly support the _SCP control
method
Am 27.04.25 um 00:52 schrieb Armin Wolf:
> Am 26.04.25 um 15:12 schrieb Rafael J. Wysocki:
>
>> On Sat, Apr 26, 2025 at 1:20 AM Armin Wolf <W_Armin@....de> wrote:
>>> Am 10.04.25 um 18:54 schrieb Armin Wolf:
>>>
>>>> The ACPI specification defines an interface for the operating system
>>>> to change the preferred cooling mode of a given ACPI thermal zone.
>>>> This interface takes the form of a special ACPI control method called
>>>> _SCP (see section 11.4.13 for details) and is already supported by the
>>>> ACPI thermal driver.
>>>>
>>>> However this support as many issues:
>>>>
>>>> - the kernel advertises support for the "3.0 _SCP Extensions"
>>>> yet the
>>>> ACPI thermal driver does not support those extensions. This may
>>>> confuse the ACPI firmware.
>>>>
>>>> - the execution of the _SCP control method happens after the driver
>>>> retrieved the trip point values. This conflicts with the ACPI
>>>> specification:
>>>>
>>>> "OSPM will automatically evaluate _ACx and _PSV objects after
>>>> executing _SCP."
>>>>
>>>> - the cooling mode is hardcoded to active cooling and cannot be
>>>> changed by the user.
>>>>
>>>> Those issues are fixed in this patch series. In the end the user
>>>> will be able to tell the ACPI firmware wether he prefers active or
>>>> passive cooling. This setting will also be interesting for
>>>> applications like TLP (https://linrunner.de/tlp/index.html).
>>>>
>>>> The whole series was tested on various devices supporting the _SCP
>>>> control method and on a device without the _SCP control method and
>>>> appears to work flawlessly.
>>> Any updates on this? I can proof that the new interface for setting
>>> the cooling mode
>>> works. Additionally the first two patches fix two issues inside the
>>> underlying code
>>> itself, so having them inside the mainline tree would be beneficial
>>> to users.
>> Sure.
>>
>> I'm going to get to them next week, probably on Monday.
>
> Ok, thanks.
>
> Armin Wolf
>
I am a bit ashamed of myself but i think we need to put this patch series on hold after all :(.
The reason of this is that i am confused by the ACPI specification regarding _SCP:
11.1.2.1. OSPM Change of Cooling Policy
When OSPM changes the platform’s cooling policy from one cooling mode to the other, the following occurs:
1. OSPM notifies the platform of the new cooling mode by running the Set Cooling Policy (_SCP) control method in all thermal zones and invoking the OS-specific Set Cooling Policy interface to all participating devices in each thermal zone.
2. Thresholds are updated in the hardware and OSPM is notified of the change.
3. OSPM re-evaluates the active and passive cooling temperature trip points for the zone and all devices in the zone to obtain the new temperature thresholds.
This section of the ACPI specification tells me that we need to evaluate the _SCP control method of all ACPI thermal zones
at the same time, yet section 11.4.13. tells me that each _SCP control methods belongs to the individual thermal zone.
The reason why i am concerned by this is because Windows adheres to section 11.1.2.1. and only exposes this setting
as a global tunable. This might cause device manufacturers to depend on this behavior and lead to strange things
should two thermal zones have different _SCP settings.
I will ask the UEFI mailing list which behavior is expected by the ACPI specification. Until then i suggest that
we put this patch series on hold.
Thanks,
Armin Wolf
Powered by blists - more mailing lists