[v6,2/7] ACPI: Make ACPI processor driver more extensible

On 8 July 2015 at 15:55, Rafael J. Wysocki <rafael@kernel.org> wrote:
> Hi Ashwin,
>
> On Wed, Jul 8, 2015 at 9:16 PM, Ashwin Chaugule
> <ashwin.chaugule@linaro.org> wrote:
>> Hi Rafael,
>>
>> On 8 July 2015 at 09:34, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>> Hi Ashwin,
>>>
>>> On Wed, Jul 8, 2015 at 3:27 AM, Ashwin Chaugule
>>> <ashwin.chaugule@linaro.org> wrote:
>>>> On 7 July 2015 at 21:07, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>>>>> On Monday, June 15, 2015 04:09:06 PM Ashwin Chaugule wrote:
>>>>>> The ACPI processor driver is currently tied too closely
>>>>>> to the ACPI C-states (CST), P-states (PSS) and other related
>>>>>> constructs for controlling CPU idle and CPU performance.
>>>>>>
>>>>>> The newer ACPI specification (v5.1 onwards) introduces
>>>>>> alternative methods to CST and 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 two new Kconfig symbols to allow for
>>>>>> finer configurability among the various options for controlling
>>>>>> CPU idle and performance states. There is no change in functionality
>>>>>> and these options are defaulted to enabled to maintain previous
>>>>>> behaviour.
>>>>>>
>>>>>> 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@linaro.org>
>>>>>> Reviewed-by: Al Stone <al.stone@linaro.org>
>>>>>> ---
>>>>>>  drivers/acpi/Kconfig            |  31 +++++++++--
>>>>>>  drivers/acpi/Makefile           |   7 ++-
>>>>>>  drivers/acpi/processor_driver.c |  86 ++++++++++++++++++----------
>>>>>>  drivers/cpufreq/Kconfig         |   2 +-
>>>>>>  drivers/cpufreq/Kconfig.x86     |   2 +
>>>>>>  include/acpi/processor.h        | 120 ++++++++++++++++++++++++++++------------
>>>>>>  6 files changed, 176 insertions(+), 72 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>>>>> index ab2cbb5..5942754 100644
>>>>>> --- a/drivers/acpi/Kconfig
>>>>>> +++ b/drivers/acpi/Kconfig
>>>>>> @@ -166,18 +166,39 @@ 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_PROCESSOR
>>>>>> -     tristate "Processor"
>>>>>> -     select THERMAL
>>>>>> -     select CPU_IDLE
>>>>>> +config ACPI_CST
>>>>>> +     bool "ACPI C states (CST) driver"
>>>>>> +     depends on ACPI_PROCESSOR
>>>>>>       depends on X86 || IA64
>>>>>> +     select CPU_IDLE
>>>>>>       default y
>>>>>>       help
>>>>>>         This driver installs ACPI as the idle handler for Linux and uses
>>>>>>         ACPI C2 and C3 processor states to save power on systems that
>>>>>> -       support it.  It is required by several flavors of cpufreq
>>>>>> +       support it.
>>>>>> +
>>>>>> +config ACPI_PSS
>>>>>> +     bool "ACPI P States (PSS) driver"
>>>>>> +     depends on ACPI_PROCESSOR
>>>>>> +     depends on X86 || IA64
>>>>>> +     select THERMAL
>>>>>> +     default y
>>>>>> +     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.
>>>>>
>>>>> For starters, I don't like these new Kconfig options.
>>>>>
>>>>> Isn't there a way to implement what you need without adding them?
>>>>
>>>> We need to use the ACPI Processor driver for CPPC without including
>>>> all its current dependencies. (i.e. PSS, TSS, CSS etc.). The upcoming
>>>> LPI work from Sudeep will also face the same issue. I considered the
>>>> alternative of adding a probe routine which matches
>>>> ACPI_PROCESSOR_OBJECT/DEVICE_HID to each driver, but this seemed like
>>>> a better option. Do you have any other ideas?
>>>
>>> First of all, I don't see what _CST has to do with CPPC.
>>>
>>> Second, it looks like the problem is that x86 probably won't use CPPC,
>>> while arm64 probably won't use _PSS.
>>>
>>> That can be addressed by adding Kconfig options, but those options
>>> should not be user-selectable (because quite honestly users don't have
>>> to know what those things are and they don't care *and* things break
>>> if they make a wrong choice).  Instead, I'd make architecture Kconfigs
>>> select those options automatically.
>>>
>>
>> I've made changes locally. Basically s/ACPI_PSS/HAVE_ACPI_PSS/ and in
>> arch/x86/Kconfig; select HAVE_ACPI_PSS if ACPI. Similarly for CST.
>> Just wanted to check if there were any other comments before sending
>> out v7.
>
> Can you please just send the new version of the $subject patch alone for now?

Attached below. (hope that worked.)

>
> Also I'm still unsure what the connection between _CST and CPPC is.
>

There isnt. But I'm missing where I've implied the dependency?

Thanks,
Ashwin.

On 8 July 2015 at 16:05, Ashwin Chaugule <ashwin.chaugule@linaro.org> wrote:
> On 8 July 2015 at 15:55, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> Hi Ashwin,
>>
>> On Wed, Jul 8, 2015 at 9:16 PM, Ashwin Chaugule
>> <ashwin.chaugule@linaro.org> wrote:
>>> Hi Rafael,
>>>
>>> On 8 July 2015 at 09:34, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>>> Hi Ashwin,
>>>>
>>>> On Wed, Jul 8, 2015 at 3:27 AM, Ashwin Chaugule
>>>> <ashwin.chaugule@linaro.org> wrote:
>>>>> On 7 July 2015 at 21:07, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>>>>>> On Monday, June 15, 2015 04:09:06 PM Ashwin Chaugule wrote:
>>>>>>> The ACPI processor driver is currently tied too closely
>>>>>>> to the ACPI C-states (CST), P-states (PSS) and other related
>>>>>>> constructs for controlling CPU idle and CPU performance.
>>>>>>>
>>>>>>> The newer ACPI specification (v5.1 onwards) introduces
>>>>>>> alternative methods to CST and 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 two new Kconfig symbols to allow for
>>>>>>> finer configurability among the various options for controlling
>>>>>>> CPU idle and performance states. There is no change in functionality
>>>>>>> and these options are defaulted to enabled to maintain previous
>>>>>>> behaviour.
>>>>>>>
>>>>>>> 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@linaro.org>
>>>>>>> Reviewed-by: Al Stone <al.stone@linaro.org>
>>>>>>> ---
>>>>>>>  drivers/acpi/Kconfig            |  31 +++++++++--
>>>>>>>  drivers/acpi/Makefile           |   7 ++-
>>>>>>>  drivers/acpi/processor_driver.c |  86 ++++++++++++++++++----------
>>>>>>>  drivers/cpufreq/Kconfig         |   2 +-
>>>>>>>  drivers/cpufreq/Kconfig.x86     |   2 +
>>>>>>>  include/acpi/processor.h        | 120 ++++++++++++++++++++++++++++------------
>>>>>>>  6 files changed, 176 insertions(+), 72 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>>>>>> index ab2cbb5..5942754 100644
>>>>>>> --- a/drivers/acpi/Kconfig
>>>>>>> +++ b/drivers/acpi/Kconfig
>>>>>>> @@ -166,18 +166,39 @@ 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_PROCESSOR
>>>>>>> -     tristate "Processor"
>>>>>>> -     select THERMAL
>>>>>>> -     select CPU_IDLE
>>>>>>> +config ACPI_CST
>>>>>>> +     bool "ACPI C states (CST) driver"
>>>>>>> +     depends on ACPI_PROCESSOR
>>>>>>>       depends on X86 || IA64
>>>>>>> +     select CPU_IDLE
>>>>>>>       default y
>>>>>>>       help
>>>>>>>         This driver installs ACPI as the idle handler for Linux and uses
>>>>>>>         ACPI C2 and C3 processor states to save power on systems that
>>>>>>> -       support it.  It is required by several flavors of cpufreq
>>>>>>> +       support it.
>>>>>>> +
>>>>>>> +config ACPI_PSS
>>>>>>> +     bool "ACPI P States (PSS) driver"
>>>>>>> +     depends on ACPI_PROCESSOR
>>>>>>> +     depends on X86 || IA64
>>>>>>> +     select THERMAL
>>>>>>> +     default y
>>>>>>> +     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.
>>>>>>
>>>>>> For starters, I don't like these new Kconfig options.
>>>>>>
>>>>>> Isn't there a way to implement what you need without adding them?
>>>>>
>>>>> We need to use the ACPI Processor driver for CPPC without including
>>>>> all its current dependencies. (i.e. PSS, TSS, CSS etc.). The upcoming
>>>>> LPI work from Sudeep will also face the same issue. I considered the
>>>>> alternative of adding a probe routine which matches
>>>>> ACPI_PROCESSOR_OBJECT/DEVICE_HID to each driver, but this seemed like
>>>>> a better option. Do you have any other ideas?
>>>>
>>>> First of all, I don't see what _CST has to do with CPPC.
>>>>
>>>> Second, it looks like the problem is that x86 probably won't use CPPC,
>>>> while arm64 probably won't use _PSS.
>>>>
>>>> That can be addressed by adding Kconfig options, but those options
>>>> should not be user-selectable (because quite honestly users don't have
>>>> to know what those things are and they don't care *and* things break
>>>> if they make a wrong choice).  Instead, I'd make architecture Kconfigs
>>>> select those options automatically.
>>>>
>>>
>>> I've made changes locally. Basically s/ACPI_PSS/HAVE_ACPI_PSS/ and in
>>> arch/x86/Kconfig; select HAVE_ACPI_PSS if ACPI. Similarly for CST.
>>> Just wanted to check if there were any other comments before sending
>>> out v7.
>>
>> Can you please just send the new version of the $subject patch alone for now?
>
> Attached below. (hope that worked.)
>
>>
>> Also I'm still unsure what the connection between _CST and CPPC is.
>>
>
> There isnt. But I'm missing where I've implied the dependency?

Perhaps the confusion is coming from the introduction of ACPI_CST in
this file. I could leave it as it is and just separate out the
ACPI_PSS bits. But I figured, while I'm at it, I'd introduce ACPI_CST,
since we know the LPI stuff is coming up soon as a CST alternative
anyway. So if you prefer, I can drop the CST bits and maybe Sudeep can
address that as part of his LPI patchset?

Thanks,
Ashwin.

On 8 July 2015 at 16:46, Rafael J. Wysocki <rafael@kernel.org> wrote:
> Hi Ashwin,

Hi,

> On Wed, Jul 8, 2015 at 10:28 PM, Ashwin Chaugule
> <ashwin.chaugule@linaro.org> wrote:
>> On 8 July 2015 at 16:05, Ashwin Chaugule <ashwin.chaugule@linaro.org> wrote:
>>> On 8 July 2015 at 15:55, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>>> Hi Ashwin,
>>>>
>>>> On Wed, Jul 8, 2015 at 9:16 PM, Ashwin Chaugule
>>>> <ashwin.chaugule@linaro.org> wrote:
>>>>> Hi Rafael,
>>>>>
>
> [cut]
>
>>>>
>>>> Also I'm still unsure what the connection between _CST and CPPC is.
>>>>
>>>
>>> There isnt. But I'm missing where I've implied the dependency?
>>
>> Perhaps the confusion is coming from the introduction of ACPI_CST in
>> this file. I could leave it as it is and just separate out the
>> ACPI_PSS bits. But I figured, while I'm at it, I'd introduce ACPI_CST,
>> since we know the LPI stuff is coming up soon as a CST alternative
>> anyway. So if you prefer, I can drop the CST bits and maybe Sudeep can
>> address that as part of his LPI patchset?
>
> Yes, please.  That would be much less confusing.

Deja Vu. :)

When I let processor_driver and processor_idle compile on ARM64, I get
a bunch of errors because processor_idle.c contains a lot of X86
specific defines. That is why I'd created the ACPI_CST option which
we'd enable only on X86.

I'm not entirely sure what these enums and functions should default
to, or what they should be on ARM specifically. Given that on ARM64
we're likely to use LPI as against CST, it seems the original approach
is better. Thoughts?

------8<------

rivers/acpi/processor_idle.c: In function ‘disabled_by_idle_boot_param’:
drivers/acpi/processor_idle.c:73:9: error: ‘boot_option_idle_override’
undeclared (first use in this function)
  return boot_option_idle_override == IDLE_POLL ||
         ^
drivers/acpi/processor_idle.c:73:9: note: each undeclared identifier
is reported only once for each function it appears in
drivers/acpi/processor_idle.c:73:38: error: ‘IDLE_POLL’ undeclared
(first use in this function)
  return boot_option_idle_override == IDLE_POLL ||
                                      ^
drivers/acpi/processor_idle.c:74:32: error: ‘IDLE_HALT’ undeclared
(first use in this function)
   boot_option_idle_override == IDLE_HALT;
                                ^
drivers/acpi/processor_idle.c: In function ‘acpi_safe_halt’:
drivers/acpi/processor_idle.c:121:3: error: implicit declaration of
function ‘arch_safe_halt’ [-Werror=implicit-function-declaration]
   safe_halt();
   ^
drivers/acpi/processor_idle.c: In function ‘acpi_processor_get_power_info_cst’:
drivers/acpi/processor_idle.c:435:9: error:
‘boot_option_idle_override’ undeclared (first use in this function)
        (boot_option_idle_override == IDLE_NOMWAIT)) {
         ^
drivers/acpi/processor_idle.c:435:38: error: ‘IDLE_NOMWAIT’ undeclared
(first use in this function)
        (boot_option_idle_override == IDLE_NOMWAIT)) {
                                      ^
drivers/acpi/processor_idle.c: In function ‘acpi_idle_enter_bm’:
drivers/acpi/processor_idle.c:749:2: error: implicit declaration of
function ‘acpi_unlazy_tlb’ [-Werror=implicit-function-declaration]
  acpi_unlazy_tlb(smp_processor_id());
  ^
drivers/acpi/processor_idle.c: In function ‘acpi_processor_power_init’:
drivers/acpi/processor_idle.c:1072:3: error: implicit declaration of
function ‘acpi_processor_cstate_check’
[-Werror=implicit-function-declaration]
   max_cstate = acpi_processor_cstate_check(max_cstate);
   ^
drivers/acpi/processor_idle.c: In function ‘disabled_by_idle_boot_param’:
drivers/acpi/processor_idle.c:75:1: warning: control reaches end of
non-void function [-Wreturn-type]
 }
 ^
------8<------

Regards,
Ashwin.

On 8 July 2015 at 18:21, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Wednesday, July 08, 2015 05:46:45 PM Ashwin Chaugule wrote:
>> On 8 July 2015 at 16:46, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> >>
>> >> Perhaps the confusion is coming from the introduction of ACPI_CST in
>> >> this file. I could leave it as it is and just separate out the
>> >> ACPI_PSS bits. But I figured, while I'm at it, I'd introduce ACPI_CST,
>> >> since we know the LPI stuff is coming up soon as a CST alternative
>> >> anyway. So if you prefer, I can drop the CST bits and maybe Sudeep can
>> >> address that as part of his LPI patchset?
>> >
>> > Yes, please.  That would be much less confusing.
>>
>> Deja Vu. :)
>>
>> When I let processor_driver and processor_idle compile on ARM64, I get
>> a bunch of errors because processor_idle.c contains a lot of X86
>> specific defines. That is why I'd created the ACPI_CST option which
>> we'd enable only on X86.
>>
>> I'm not entirely sure what these enums and functions should default
>> to, or what they should be on ARM specifically. Given that on ARM64
>> we're likely to use LPI as against CST, it seems the original approach
>> is better. Thoughts?
>
> Before we go anywhere deeper, have you checked what happens on ia64?

I dont have access, but I'm really not changing anything functionally.

Thanks,
Ashwin.

Hi Sudeep,


On 9 July 2015 at 05:06, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Hi,
>
> On 08/07/15 21:28, Ashwin Chaugule wrote:
>>
>> On 8 July 2015 at 16:05, Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> wrote:
>>>
>>> On 8 July 2015 at 15:55, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> Perhaps the confusion is coming from the introduction of ACPI_CST in
>> this file. I could leave it as it is and just separate out the
>> ACPI_PSS bits. But I figured, while I'm at it, I'd introduce ACPI_CST,
>> since we know the LPI stuff is coming up soon as a CST alternative
>> anyway. So if you prefer, I can drop the CST bits and maybe Sudeep can
>> address that as part of his LPI patchset?
>>
>
> Correct, I will handle it as a prerequisite for introducing _LPI
> support. I had posted an RFC long back, will revive those patches and
> repost them soon.
>
> It's better to enable ACPI_PROCESSOR on ARM64 only after we have all
> these dependencies resolved. Until then we need to carry some patches
> locally for testing.

With Rafaels latest suggestion of adding ACPI_PROCESSOR_IDLE, we dont
need to wait until all dependencies are resolved to enable
acpi_processor on ARM64. CPPC patchwork has been up for review for
quite a long time and has been validated on hardware. There is no
reason for it to be blocked until LPI is upstream ready.

Regards,
Ashwin.