On Monday, July 20, 2015 03:20:46 PM Sudeep Holla wrote: > > On 09/07/15 19:04, Ashwin Chaugule wrote: > > 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 <ashwin.chaugule@xxxxxxxxxx> > > --- > > 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 *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? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
