On 20 July 2015 at 17:59, Rafael J. Wysocki [off-list ref] wrote:

On Monday, July 20, 2015 03:20:46 PM Sudeep Holla wrote:

quoted

On 09/07/15 19:04, Ashwin Chaugule wrote:

quoted

The ACPI processor driver is currently tied too closely
to the ACPI P-states (PSS) and other related constructs
for controlling CPU performance.

The newer ACPI specification (v5.1 onwards) introduces
alternative methods to PSS. These new mechanisms are
described within each ACPI Processor object and so they
need to be scanned whenever a new Processor object is detected.
This patch introduces a new Kconfig symbol to allow for
finer configurability among the two options for controlling
performance states. There is no change in functionality and
the option is auto-selected by the architecture Kconfig files.

The following patchwork introduces CPPC: A newer method of
controlling CPU performance. The OS is not expected to support
CPPC and PSS at runtime. So the kconfig option lets us make
these two mutually exclusive at compile time.

Signed-off-by: Ashwin Chaugule <redacted>
---
  arch/x86/Kconfig                |  1 +
  drivers/acpi/Kconfig            | 19 ++++++---
  drivers/acpi/Makefile           |  6 +--
  drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
  drivers/cpufreq/Kconfig         |  2 +-
  drivers/cpufreq/Kconfig.x86     |  2 +
  include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
  7 files changed, 142 insertions(+), 68 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 226d569..93d150d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig

@@ -143,6 +143,7 @@ config X86
         select ACPI_LEGACY_TABLES_LOOKUP if ACPI
         select X86_FEATURE_NAMES if PROC_FS
         select SRCU
+       select ACPI_CPU_FREQ_PSS if ACPI

  config INSTRUCTION_DECODER
         def_bool y

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ab2cbb5..00748dc 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig

@@ -166,17 +166,26 @@ config ACPI_DOCK
           This driver supports ACPI-controlled docking stations and removable
           drive bays such as the IBM Ultrabay and the Dell Module Bay.

+config ACPI_CPU_FREQ_PSS
+       bool
+       depends on ACPI_PROCESSOR && CPU_FREQ
+       select THERMAL
+       help
+         This driver implements ACPI methods for controlling CPU performance
+         using PSS methods as described in the ACPI spec. It also enables support
+         for ACPI based performance throttling (TSS) and ACPI based thermal
+         monitoring. It is required by several flavors of cpufreq
+         performance-state drivers.
+

Though I agree CPUFreq and the thermal control are related, having _PSS
in config name shouldn't match well IMO. You can have more generic name.

You are selecting one config while depending on the other, any
particular reason ?

I don't like adding these, but I leave it to Rafael.

My opinion is analogous. :-)

I dont like bloating Kconfigs either, but its slim pickings in this case.

I *guess* the idea was to avoid selecting ACPI_CPU_FREQ_PSS withouth
ACPI_PROCESSOR so we don't build unnecessary code.  That's a good point,
but I would also like to keep they way ACPI_PROCESSOR works on x86 and
ia64 without adding new user-selectable Kconfig options.

So, what about this:

 config ACPI_PROCESSOR
        tristate "Processor"
        select THERMAL
        select CPU_IDLE
-       depends on X86 || IA64
+       select ACPI_CPU_FREQ_PSS if X86 || IA64
        default y
        help
          This driver installs ACPI as the idle handler for Linux and uses

and define ACPI_CPU_FREQ_PSS in analogy with ACPI_CCA_REQUIRED for example?

Seems better. I'll respin this series with the feedback so far.


Thanks,
Ashwin.