linux/drivers/acpi/cppc_acpi.c, branch v6.0

ACPI: CPPC: Do not prevent CPPC from working in the future

2022-07-26T18:56:49Z

There is a problem with the current revision checks in is_cppc_supported() that they essentially prevent the CPPC support from working if a new _CPC package format revision being a proper superset of the v3 and only causing _CPC to return a package with more entries (while retaining the types and meaning of the entries defined by the v3) is introduced in the future and used by the platform firmware. In that case, as long as the number of entries in the _CPC return package is at least CPPC_V3_NUM_ENT, it should be perfectly fine to use the v3 support code and disregard the additional package entries added by the new package format revision. For this reason, drop is_cppc_supported() altogether, put the revision checks directly into acpi_cppc_processor_probe() so they are easier to follow and rework them to take the case mentioned above into account. Fixes: 4773e77cdc9b ("ACPI / CPPC: Add support for CPPC v3") Cc: 4.18+ # 4.18+ Signed-off-by: Rafael J. Wysocki

ACPI: CPPC: Don't require flexible address space if X86_FEATURE_CPPC is supported

2022-07-18T18:40:05Z

Commit 0651ab90e4ad ("ACPI: CPPC: Check _OSC for flexible address space") changed _CPC probing to require flexible address space to be negotiated for CPPC to work. However it was observed that this caused a regression for Arek's ROG Zephyrus G15 GA503QM which previously CPPC worked, but now it stopped working. To avoid causing a regression waive this failure when the CPU is known to support CPPC. Cc: Pierre Gondois Link: https://bugzilla.kernel.org/show_bug.cgi?id=216248 Fixes: 0651ab90e4ad ("ACPI: CPPC: Check _OSC for flexible address space") Reported-and-tested-by: Arek Ruśniak Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki

ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported

2022-07-05T18:36:11Z

commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") added support for claiming to support CPPC in _OSC on non-Intel platforms. This unfortunately caused a regression on a vartiety of AMD platforms in the field because a number of AMD platforms don't set the `_OSC` bit 5 or 6 to indicate CPPC or CPPC v2 support. As these AMD platforms already claim CPPC support via a dedicated MSR from `X86_FEATURE_CPPC`, use this enable this feature rather than requiring the `_OSC` on platforms with a dedicated MSR. If there is additional breakage on the shared memory designs also missing this _OSC, additional follow up changes may be needed. Fixes: 72f2ecb7ece7 ("Set CPPC _OSC bits for all and when CPPC_LIB is supported") Reported-by: Perry Yuan Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki

ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked

2022-07-05T18:36:11Z

Previously the kernel used to ignore whether the firmware masked CPPC or CPPCv2 and would just pretend that it worked. When support for the USB4 bit in _OSC was introduced from commit 9e1f561afb ("ACPI: Execute platform _OSC also with query bit clear") the kernel began to look at the return when the query bit was clear. This caused regressions that were misdiagnosed and attempted to be solved as part of commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag""). This caused a different regression where non-Intel systems weren't able to negotiate _OSC properly. This was reverted in commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag"") and attempted to be fixed by commit c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware") but the regression still returned. These systems with the regression only load support for CPPC from an SSDT dynamically when _OSC reports CPPC v2. Avoid the problem by not letting CPPC satisfy the requirement in `acpi_cppc_processor_probe`. Reported-by: CUI Hao Reported-by: maxim.novozhilov@gmail.com Reported-by: lethe.tree@protonmail.com Reported-by: garystephenwright@gmail.com Reported-by: galaxyking0419@gmail.com Fixes: c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware") Fixes: 2ca8e6285250 ("Revert "ACPI Pass the same capabilities to the _OSC regardless of the query flag"") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213023 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2075387 Reviewed-by: Mika Westerberg Tested-by: CUI Hao Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-glue', 'acpi-osl', 'acpi-processor' and 'acpi-cppc'

2022-05-30T16:04:57Z

Merge general ACPI cleanups and processor support updates for 5.19-rc1: - Rearrange find_child_checks() to simplify code (Rafael Wysocki). - Use memremap() to map the UCSI mailbox that is always in main memory and drop acpi_release_memory() that has no more users (Heikki Krogerus, Dan Carpenter). - Make max_cstate/nocst/bm_check_disable processor module parameters visible in sysfs (Yajun Deng). - Fix typo in the CPPC driver (Julia Lawall). * acpi-glue: ACPI: glue: Rearrange find_child_checks() * acpi-osl: usb: typec: ucsi: acpi: fix a NULL vs IS_ERR() check in probe ACPI: OSL: Remove the helper for deactivating memory region usb: typec: ucsi: acpi: Map the mailbox with memremap() * acpi-processor: ACPI: processor: idle: Expose max_cstate/nocst/bm_check_disable read-only in sysfs * acpi-cppc: ACPI: CPPC: fix typo in comment

ACPI: CPPC: fix typo in comment

2022-05-25T13:34:28Z

Spelling mistake (triple letters) in comment. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall Signed-off-by: Rafael J. Wysocki

cpufreq: CPPC: Enable fast_switch

2022-05-19T17:45:34Z

The communication mean of the _CPC desired performance can be PCC, System Memory, System IO, or Functional Fixed Hardware. commit b7898fda5bc7 ("cpufreq: Support for fast frequency switching") fast_switching is 'for switching CPU frequencies from interrupt context'. Writes to SystemMemory and SystemIo are fast and suitable this. This is not the case for PCC and might not be the case for FFH. Enable fast_switching for the cppc_cpufreq driver in above cases. Add cppc_allow_fast_switch() to check the desired performance register address space and set fast_switching accordingly. Signed-off-by: Pierre Gondois Reviewed-by: Sudeep Holla Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

ACPI: CPPC: Assume no transition latency if no PCCT

2022-05-19T17:45:34Z

The transition_delay_us (struct cpufreq_policy) is currently defined as: Preferred average time interval between consecutive invocations of the driver to set the frequency for this policy. To be set by the scaling driver (0, which is the default, means no preference). The transition_latency represents the amount of time necessary for a CPU to change its frequency. A PCCT table advertises mutliple values: - pcc_nominal: Expected latency to process a command, in microseconds - pcc_mpar: The maximum number of periodic requests that the subspace channel can support, reported in commands per minute. 0 indicates no limitation. - pcc_mrtt: The minimum amount of time that OSPM must wait after the completion of a command before issuing the next command, in microseconds. cppc_get_transition_latency() allows to get the max of them. commit d4f3388afd48 ("cpufreq / CPPC: Set platform specific transition_delay_us") allows to select transition_delay_us based on the platform, and fallbacks to cppc_get_transition_latency() otherwise. If _CPC objects are not using PCC channels (no PPCT table), the transition_delay_us is set to CPUFREQ_ETERNAL, leading to really long periods between frequency updates (~4s). If the desired_reg, where performance requests are written, is in SystemMemory or SystemIo ACPI address space, there is no delay in requests. So return 0 instead of CPUFREQ_ETERNAL, leading to transition_delay_us being set to LATENCY_MULTIPLIER us (1000 us). This patch also adds two macros to check the address spaces. Signed-off-by: Pierre Gondois Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki

ACPI: CPPC: Check _OSC for flexible address space

2022-05-19T17:45:34Z

ACPI 6.2 Section 6.2.11.2 'Platform-Wide OSPM Capabilities': Starting with ACPI Specification 6.2, all _CPC registers can be in PCC, System Memory, System IO, or Functional Fixed Hardware address spaces. OSPM support for this more flexible register space scheme is indicated by the “Flexible Address Space for CPPC Registers” _OSC bit Otherwise (cf ACPI 6.1, s8.4.7.1.1.X), _CPC registers must be in: - PCC or Functional Fixed Hardware address space if defined - SystemMemory address space (NULL register) if not defined Add the corresponding _OSC bit and check it when parsing _CPC objects. Signed-off-by: Pierre Gondois Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki

ACPI: CPPC: Change default error code and clean up debug messages in probe

2022-03-25T17:18:55Z

Change the default error code returned by acpi_cppc_processor_probe() from -EFAULT (which is completely inadequate) to -ENODATA and change the debug messages printed by it to contain more information and be more consistent. While at it, format some white space to follow the coding style. Signed-off-by: Rafael J. Wysocki Reviewed-by: Huang Rui