On Sat, May 3, 2025 at 12:29 AM Armin Wolf <W_Armin@xxxxxx> 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@xxxxxx> 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@xxxxxx> 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. > Apart from that the first two patches should be safe, so you can still pick them. Done. > Only the last patch needs some more work. OK Thanks!
