[v7,3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

Message ID da1eb99c0e128a4c8160537295045164d8fde00d.1436464513.git.ashwin.chaugule@linaro.org
State New
Headers show

Commit Message

Ashwin Chaugule July 9, 2015, 6:04 p.m.
This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
which is auto selected by architectures which support the ACPI
based C states for CPU Idle management.

The processor_idle driver in its present form contains declarations
specific to X86 and IA64. Since there are no reasonable defaults
for other architectures e.g. ARM64, the driver is selected only by
the arch/x86/Kconfig.

This helps in decoupling the ACPI processor_driver from the ACPI
processor_idle driver which is useful for the upcoming alternative
patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
---
 drivers/acpi/Kconfig     |  6 +++++-
 drivers/acpi/Makefile    |  3 ++-
 include/acpi/processor.h | 26 ++++++++++++++++++++++++--
 3 files changed, 31 insertions(+), 4 deletions(-)

Comments

Ashwin Chaugule Aug. 3, 2015, 5:40 p.m. | #1
On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>
>> This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
>> which is auto selected by architectures which support the ACPI
>> based C states for CPU Idle management.
>>
>> The processor_idle driver in its present form contains declarations
>> specific to X86 and IA64. Since there are no reasonable defaults
>> for other architectures e.g. ARM64, the driver is selected only by
>> the arch/x86/Kconfig.
>>
>> This helps in decoupling the ACPI processor_driver from the ACPI
>> processor_idle driver which is useful for the upcoming alternative
>> patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).
>>
>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> ---
>>   drivers/acpi/Kconfig     |  6 +++++-
>>   drivers/acpi/Makefile    |  3 ++-
>>   include/acpi/processor.h | 26 ++++++++++++++++++++++++--
>>   3 files changed, 31 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 00748dc..8a60b6e 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -177,9 +177,13 @@ config ACPI_CPU_FREQ_PSS
>>           monitoring. It is required by several flavors of cpufreq
>>           performance-state drivers.
>>
>> +config ACPI_PROCESSOR_IDLE
>> +       def_bool y
>> +       depends on X86 || IA64
>> +
>
>
> In general, you need to split this series so that initially few patches
> deal with all the existing Kconfig fix-ups and then introduce
> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
> support.

Hm. I tried to maintain bisectability and make it easier for you to
rebase LPI patchwork too. Let me see if I can revisit now that I'm
back from vacation. :)

>
> Regards,
> Sudeep
Ashwin Chaugule Aug. 4, 2015, 2:58 p.m. | #2
On 4 August 2015 at 10:51, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 03/08/15 18:40, Ashwin Chaugule wrote:
>>
>> On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>
>>>
>>> In general, you need to split this series so that initially few patches
>>> deal with all the existing Kconfig fix-ups and then introduce
>>> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
>>> support.
>>
>>
>> Hm. I tried to maintain bisectability and make it easier for you to
>> rebase LPI patchwork too. Let me see if I can revisit now that I'm
>> back from vacation. :)
>>
>
> How about you just drop any idle related changes so that I will handle
> that to keep it simple.

Unfortunately I can't skip idle changes completely since it is tightly
coupled with the acpi_processor driver as well.

Regards,
Ashwin.
Ashwin Chaugule Aug. 4, 2015, 3:44 p.m. | #3
On 4 August 2015 at 11:18, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 04/08/15 15:58, Ashwin Chaugule wrote:
>>
>> On 4 August 2015 at 10:51, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>
>>> On 03/08/15 18:40, Ashwin Chaugule wrote:
>>>>
>>>>
>>>> On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>
>>>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>>>
>>>>>>
>>>>>
>>>>> In general, you need to split this series so that initially few patches
>>>>> deal with all the existing Kconfig fix-ups and then introduce
>>>>> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
>>>>> support.
>>>>
>>>>
>>>>
>>>> Hm. I tried to maintain bisectability and make it easier for you to
>>>> rebase LPI patchwork too. Let me see if I can revisit now that I'm
>>>> back from vacation. :)
>>>>
>>>
>>> How about you just drop any idle related changes so that I will handle
>>> that to keep it simple.
>>
>>
>> Unfortunately I can't skip idle changes completely since it is tightly
>> coupled with the acpi_processor driver as well.
>>
>
> True, but only for ARM64 where we haven't enabled ACPI_PROCESSOR yet in
> mainline. So from that perspective, it should not cause any issue for
> keeping changes bisectable on x86/ia64. You can keep these idle changes
> locally for your testing. Trying to get everything at once will
> definitely be problematic IMO.

Bisectability aside, without the idle changes to decouple it from
ACPI_PROCESSOR, the CPPC code will be non-functional. CPPC code has
been around for review publicly for almost a year and we need it to be
mainlined soon. So, given that we've converged on a solution for new
Kconfigs for Idle and PSS and that they're separate patches, why not
let it progress forwards as part of this series?

Thanks,
Ashwin.
Ashwin Chaugule Aug. 5, 2015, 1:47 p.m. | #4
Hi Sudeep,

On 4 August 2015 at 13:00, Sudeep Holla <sudeep.holla@arm.com> wrote:

> On 04/08/15 16:44, Ashwin Chaugule wrote:
>> On 4 August 2015 at 11:18, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Bisectability aside, without the idle changes to decouple it from
>> ACPI_PROCESSOR, the CPPC code will be non-functional. CPPC code has
>> been around for review publicly for almost a year and we need it to be
>> mainlined soon. So, given that we've converged on a solution for new
>> Kconfigs for Idle and PSS and that they're separate patches, why not
>> let it progress forwards as part of this series?
>>
> Sorry, I didn't mean to block this series in anyway. I was just thinking
> on how to post the preparatory changes to introduce _LPI. I prefer to
> base it on mainline rather than this patch series and hence I made that
> request.
>

Can you please try rebasing with Patch 2,3,6 and 9 of the V8 series?
Those should get you going for your LPI work.

Thanks,
Ashwin.

Patch

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 00748dc..8a60b6e 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -177,9 +177,13 @@  config ACPI_CPU_FREQ_PSS
 	  monitoring. It is required by several flavors of cpufreq
 	  performance-state drivers.
 
+config ACPI_PROCESSOR_IDLE
+	def_bool y
+	depends on X86 || IA64
+
 config ACPI_PROCESSOR
 	tristate "Processor"
-	select CPU_IDLE
+	select CPU_IDLE if ACPI_PROCESSOR_IDLE
 	depends on X86 || IA64
 	default y
 	help
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 62e32bd..0633af6 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -82,7 +82,8 @@  obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
 
 # processor has its own "processor." module_param namespace
-processor-y			:= processor_driver.o processor_idle.o
+processor-y			:= processor_driver.o
+processor-$(CONFIG_ACPI_PROCESSOR_IDLE)	+= processor_idle.o
 processor-$(CONFIG_ACPI_CPU_FREQ_PSS)	+= processor_perflib.o	\
 	processor_throttling.o processor_thermal.o
 
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index bedcab3..c071a92 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -369,13 +369,35 @@  static inline void acpi_processor_throttling_init(void) {}
 #endif	/* CONFIG_ACPI_CPU_FREQ_PSS */
 
 /* in processor_idle.c */
+extern struct cpuidle_driver acpi_idle_driver;
+#ifdef CONFIG_ACPI_PROCESSOR_IDLE
 int acpi_processor_power_init(struct acpi_processor *pr);
 int acpi_processor_power_exit(struct acpi_processor *pr);
 int acpi_processor_cst_has_changed(struct acpi_processor *pr);
 int acpi_processor_hotplug(struct acpi_processor *pr);
-extern struct cpuidle_driver acpi_idle_driver;
+#else
+static inline int acpi_processor_power_init(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+
+static inline int acpi_processor_power_exit(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+
+static inline int acpi_processor_cst_has_changed(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+
+static inline int acpi_processor_hotplug(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+#endif /* CONFIG_ACPI_PROCESSOR_IDLE */
 
-#ifdef CONFIG_PM_SLEEP
+#if defined(CONFIG_PM_SLEEP) & defined(CONFIG_ACPI_PROCESSOR_IDLE)
 void acpi_processor_syscore_init(void);
 void acpi_processor_syscore_exit(void);
 #else