Re: [PATCH 0/3] ACPI: thermal: Properly support the _SCP control method

[Armin Wolf <W_Armin@gmx.de>]

Am 16.05.25 um 15:59 schrieb Rafael J. Wysocki:

> On Sat, May 3, 2025 at 12:29 AM Armin Wolf <W_Armin@gmx.de> wrote:
>> Am 28.04.25 um 14:34 schrieb Rafael J. Wysocki:
>>
>>> On Mon, Apr 28, 2025 at 2:31 PM Armin Wolf <W_Armin@gmx.de> wrote:
>>>> 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@gmx.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.
>>> Sure, no problem.
>>>
>>> Please resend it when you think it is good to go.
>>>
>>> Thanks!
>> Alright, the UEFI mailing list gave no response, so i am kind of stuck.
>>
>> It seems that many firmware implementation only have a single cooling policy register which is set by all _SCP control methods inside the whole system.
>> The reason for this seems to be that Windows treats this setting as global, but the ACPI specification seemingly does not directly mandate this.
>>
>> Do you think we should take the risk and allow users to control each _SCP instance manually?
> No, I don't.
>
> Doing things that are not done in Windows with ACPI objects is
> generally asking for trouble unless there is a specific use case and
> there is high confidence that it is actually going to work.
>
> At least to begin with, I wouldn't do it.

Alright, i will go with a single global interface then.

I am already thinking of using the platform profile interface (with performance and quiet profiles) instead of a custom
sysfs interface to allow for better integration with tuned/platform-profiles-daemon/etc.

I am currently a bit preoccupied so this will take a while.

>> Apart from that the first two patches should be safe, so you can still pick them.
> Done.

Thanks :)

Armin Wolf

>> Only the last patch needs some more work.
> OK
>
> Thanks!