<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/acpi/cppc_acpi.h, branch v6.6.55</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.6.55</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.6.55'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-10-04T14:28:53Z</updated>
<entry>
<title>ACPI: CPPC: Fix MASK_VAL() usage</title>
<updated>2024-10-04T14:28:53Z</updated>
<author>
<name>Clément Léger</name>
<email>cleger@rivosinc.com</email>
</author>
<published>2024-08-26T10:16:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8ad28208be7bbe748e90442c45963ddbef0fd1e2'/>
<id>urn:sha1:8ad28208be7bbe748e90442c45963ddbef0fd1e2</id>
<content type='text'>
[ Upstream commit 60949b7b805424f21326b450ca4f1806c06d982e ]

MASK_VAL() was added as a way to handle bit_offset and bit_width for
registers located in system memory address space. However, while suited
for reading, it does not work for writing and result in corrupted
registers when writing values with bit_offset &gt; 0. Moreover, when a
register is collocated with another one at the same address but with a
different mask, the current code results in the other registers being
overwritten with 0s. The write procedure for SYSTEM_MEMORY registers
should actually read the value, mask it, update it and write it with the
updated value. Moreover, since registers can be located in the same
word, we must take care of locking the access before doing it. We should
potentially use a global lock since we don't know in if register
addresses aren't shared with another _CPC package but better not
encourage vendors to do so. Assume that registers can use the same word
inside a _CPC package and thus, use a per _CPC package lock.

Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
Signed-off-by: Clément Léger &lt;cleger@rivosinc.com&gt;
Link: https://patch.msgid.link/20240826101648.95654-1-cleger@rivosinc.com
[ rjw: Dropped redundant semicolon ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI: CPPC: Add helper to get the highest performance value</title>
<updated>2024-09-12T09:11:40Z</updated>
<author>
<name>Meng Li</name>
<email>li.meng@amd.com</email>
</author>
<published>2024-01-19T09:04:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0b983c08ca810470a7020c212d6f6b0e38926928'/>
<id>urn:sha1:0b983c08ca810470a7020c212d6f6b0e38926928</id>
<content type='text'>
commit 12753d71e8c5c3e716cedba23ddeed508da0bdc4 upstream.

Add support for getting the highest performance to the
generic CPPC driver. This enables downstream drivers
such as amd-pstate to discover and use these values.

Refer to Chapter 8.4.6.1.1.1. Highest Performance of ACPI
Specification 6.5 for details on continuous performance control
of CPPC (linked below).

Tested-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Reviewed-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
Reviewed-by: Perry Yuan &lt;perry.yuan@amd.com&gt;
Acked-by: Huang Rui &lt;ray.huang@amd.com&gt;
Signed-off-by: Meng Li &lt;li.meng@amd.com&gt;
Link: https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html?highlight=cppc#highest-performance
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: CPPC: Add auto select register read/write support</title>
<updated>2023-03-17T18:06:23Z</updated>
<author>
<name>Wyes Karny</name>
<email>wyes.karny@amd.com</email>
</author>
<published>2023-03-07T11:27:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c984f5d5d45bd5f80d6a9d8541e809300c963aca'/>
<id>urn:sha1:c984f5d5d45bd5f80d6a9d8541e809300c963aca</id>
<content type='text'>
For some AMD shared memory based systems, the autonomous selection bit
needed to be set explicitly. Add autonomous selection register related
APIs to acpi driver, which amd_pstate driver uses later.

Acked-by: Huang Rui &lt;ray.huang@amd.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Signed-off-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
[ rjw: Fixed up kerneldoc comments, white space adjustment, subject edits ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: CPPC: Add AMD pstate energy performance preference cppc control</title>
<updated>2023-02-03T20:59:41Z</updated>
<author>
<name>Perry Yuan</name>
<email>Perry.Yuan@amd.com</email>
</author>
<published>2023-01-31T09:00:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7bc1fcd399018245575974508c26e882da0bd915'/>
<id>urn:sha1:7bc1fcd399018245575974508c26e882da0bd915</id>
<content type='text'>
Add support for setting and querying EPP preferences to the generic
CPPC driver.  This enables downstream drivers such as amd-pstate to discover
and use these values.

Downstream drivers that want to use the new symbols cppc_get_epp_caps
and cppc_set_epp_perf for querying and setting EPP preferences will need
to call cppc_set_epp_perf to enable the EPP function firstly.

Acked-by: Huang Rui &lt;ray.huang@amd.com&gt;
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Reviewed-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
Tested-by: Wyes Karny &lt;wyes.karny@amd.com&gt;
Signed-off-by: Perry Yuan &lt;Perry.Yuan@amd.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: CPPC: Disable FIE if registers in PCC regions</title>
<updated>2022-09-24T16:43:46Z</updated>
<author>
<name>Jeremy Linton</name>
<email>jeremy.linton@arm.com</email>
</author>
<published>2022-09-12T20:37:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ae2df912d1a557a3548be83da20851ac55f42ab3'/>
<id>urn:sha1:ae2df912d1a557a3548be83da20851ac55f42ab3</id>
<content type='text'>
PCC regions utilize a mailbox to set/retrieve register values used by
the CPPC code. This is fine as long as the operations are
infrequent. With the FIE code enabled though the overhead can range
from 2-11% of system CPU overhead (ex: as measured by top) on Arm
based machines.

So, before enabling FIE assure none of the registers used by
cppc_get_perf_ctrs() are in the PCC region. Finally, add a module
parameter which can override the PCC region detection at boot or
module reload.

Signed-off-by: Jeremy Linton &lt;jeremy.linton@arm.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Reviewed-by: Ionela Voinescu &lt;ionela.voinescu@arm.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: CPPC: Do not prevent CPPC from working in the future</title>
<updated>2022-07-26T18:56:49Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2022-07-21T17:41:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4f4179fcf420873002035cf1941d844c9e0e7cb3'/>
<id>urn:sha1:4f4179fcf420873002035cf1941d844c9e0e7cb3</id>
<content type='text'>
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+ &lt;stable@vger.kernel.org&gt; # 4.18+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported</title>
<updated>2022-07-05T18:36:11Z</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2022-07-05T18:29:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8b356e536e69f3a4d6778ae9f0858a1beadabb1f'/>
<id>urn:sha1:8b356e536e69f3a4d6778ae9f0858a1beadabb1f</id>
<content type='text'>
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 &lt;perry.yuan@amd.com&gt;
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>cpufreq: CPPC: Enable fast_switch</title>
<updated>2022-05-19T17:45:34Z</updated>
<author>
<name>Pierre Gondois</name>
<email>Pierre.Gondois@arm.com</email>
</author>
<published>2022-05-18T09:09:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3cc30dd00a580ca0c9c0b01639841cfd72d10129'/>
<id>urn:sha1:3cc30dd00a580ca0c9c0b01639841cfd72d10129</id>
<content type='text'>
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 &lt;pierre.gondois@arm.com&gt;
Reviewed-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: CPPC: Add CPPC enable register function</title>
<updated>2021-12-30T17:51:39Z</updated>
<author>
<name>Jinzhou Su</name>
<email>Jinzhou.Su@amd.com</email>
</author>
<published>2021-12-24T01:04:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fb0b00af04d083770d6e2762b2838357519f7d2d'/>
<id>urn:sha1:fb0b00af04d083770d6e2762b2838357519f7d2d</id>
<content type='text'>
Add a new function to enable CPPC feature. This function
will write Continuous Performance Control package
EnableRegister field on the processor.

CPPC EnableRegister register described in section 8.4.7.1 of ACPI 6.4:
This element is optional. If supported, contains a resource descriptor
with a single Register() descriptor that describes a register to which
OSPM writes a One to enable CPPC on this processor. Before this register
is set, the processor will be controlled by legacy mechanisms (ACPI
Pstates, firmware, etc.).

This register will be used for AMD processors to enable AMD P-State
function instead of legacy ACPI P-States.

Signed-off-by: Jinzhou Su &lt;Jinzhou.Su@amd.com&gt;
Signed-off-by: Huang Rui &lt;ray.huang@amd.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: CPPC: Introduce cppc_get_nominal_perf()</title>
<updated>2021-09-07T19:15:16Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2021-09-04T13:51:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0654cf05d17bc4d296a53a8bc7d107bc8a795f2e'/>
<id>urn:sha1:0654cf05d17bc4d296a53a8bc7d107bc8a795f2e</id>
<content type='text'>
On some systems the nominal_perf value retrieved via CPPC is just
a constant and fetching it doesn't require accessing any registers,
so if it is the only CPPC capability that's needed, it is wasteful
to run cppc_get_perf_caps() in order to get just that value alone,
especially when this is done for CPUs other than the one running
the code.

For this reason, introduce cppc_get_nominal_perf() allowing
nominal_perf to be obtained individually, by generalizing the
existing cppc_get_desired_perf() (and renaming it) so it can be
used to retrieve any specific CPPC capability value.

While at it, clean up the cppc_get_desired_perf() kerneldoc comment
a bit.

Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
</feed>
