Changes since V8:
- Removed unncessary header files.
- Added kerneldoc comments.
- Added intro about PCC in pcc.c
Changes since V7:
- Added timeout to tx method in case the remote dies.
- Restructured usage of acpi_status. Had inverted logic previously.
Changes since V6:
- Cosmetic changes based on Lv's suggestions
Changes since V5:
- Optimize loop that matches channel request.
- Use platform_create_bundle.
- Replace ioread/writes.
- Remove redundant code and headers.
- Restructure common mailbox macros.
- Reformat PCC cmd parsing.
Changes since V4:
- Folded PCC Mailbox helpers into pcc.c
Changes since V3:
- Added PCC helper functions to work around "struct device" limitations.
- PCC driver changes to work with PCC specific Mailbox helpers.
Changes since V2:
- Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git
branch mailbox-for-3.17
- Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI.
Changes since V1:
- Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49
This patchset adds support for the PCC (Platform Communication Channel)
interface as described in the current ACPI 5.0 spec. See Section 14 of the
ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details
on how PCC works.
In brief PCC is a generic means for PCC clients, to talk to the firmware. The
PCC register space is typically memory mapped IO and uses a doorbell mechanism
to communicate synchronously from the OS to the firmware. The PCC driver is
completely agnostic to the protocol implemented by the PCC clients. It only
implements the enumeration of PCC channels and the low level transport mechanism
and leaves the rest to the PCC clients.
The PCC is meant to be useable in the future by clients such as CPPC
(Collaborative Processor Performance Control), RAS (Reliability,
Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others.
Ashwin Chaugule (1):
Mailbox: Add support for Platform Communication Channel
drivers/mailbox/Kconfig | 12 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/mailbox.c | 4 +-
drivers/mailbox/mailbox.h | 16 ++
drivers/mailbox/pcc.c | 369 ++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 400 insertions(+), 3 deletions(-)
create mode 100644 drivers/mailbox/mailbox.h
create mode 100644 drivers/mailbox/pcc.c
--
1.9.1
This patchset introduces CPPC(Collaborative Processor Performance Control) as a backend
to the PID governor. The PID governor from intel_pstate.c maps cleanly onto some CPPC
interfaces.
e.g. The CPU performance requests are made on a continuous scale as against discrete pstate
levels. The CPU performance feedback over an interval is gauged using platform specific
counters which are also described by CPPC.
Although CPPC describes several other registers to provide more hints to the platform,
Linux as of today does not have the infrastructure to make use of those registers.
Some of the CPPC specific information could be made available from the scheduler as
part of the CPUfreq and Scheduler intergration work. Until then PID can be used as the
front end for CPPC.
This implementation was tested using a Thinkpad X240 Laptop which seemed to have
CPPC and PCC tables in its ACPI firmware. However, it seems as though some addresses
pointed to by the tables do not exist. This patchset also shows the hacks that
were made in order to work around those limitations and test the control flow.
This patchset builds on top of the PCC driver which is being reviewed separately[3].
Changes since V1:
- Create a new driver based on Dirks suggestion.
- Fold in CPPC backend hooks into main driver.
Changes since V0: [1]
- Split intel_pstate.c into a generic PID governor and platform specific backend.
- Add CPPC accessors as PID backend.
CPPC:
====
CPPC (Collaborative Processor Performance Control) is a new way to control CPU
performance using an abstract continous scale as against a discretized P-state scale
which is tied to CPU frequency only. It is defined in the ACPI 5.0+ spec. In brief,
the basic operation involves:
- OS makes a CPU performance request. (Can provide min and max tolerable bounds)
- Platform (such as BMC) is free to optimize request within requested bounds depending
on power/thermal budgets etc.
- Platform conveys its decision back to OS
The communication between OS and platform occurs through another medium called (PCC)
Platform communication Channel. This is a generic mailbox like mechanism which includes
doorbell semantics to indicate register updates. The PCC driver is being discussed in a
separate patchset [3] and is not included here, since CPPC is only one client of PCC.
Finer details about the PCC and CPPC spec are available in the latest ACPI 5.1
specification.[2]
[1] - http://lwn.net/Articles/608715/
[2] - http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf
[3] - http://comments.gmane.org/gmane.linux.acpi.devel/71171
Ashwin Chaugule (3):
PCC HACKS: Update PCC comm region with MSR data
CPPC as a PID controller backend
CPPC HACKS
drivers/cpufreq/Kconfig | 12 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/acpi_pid.c | 1085 ++++++++++++++++++++++++++++++++++++++++++++
drivers/mailbox/pcc.c | 125 ++++-
4 files changed, 1207 insertions(+), 16 deletions(-)
create mode 100644 drivers/cpufreq/acpi_pid.c
--
1.9.1