| Message ID | da1eb99c0e128a4c8160537295045164d8fde00d.1436464513.git.ashwin.chaugule@linaro.org (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
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. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: >>> >>> 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. :) > How about you just drop any idle related changes so that I will handle that to keep it simple. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/08/15 16:44, Ashwin Chaugule wrote: > 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? > 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. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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(-)