Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1335784 > unrolled thread

Re: [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-02-16 21:20 +0100
    Re: [PATCH v3 4/5] ACPI / processor_idle : introduce  ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE Sudeep Holla <sudeep.holla@arm.com> - 2016-02-17 13:30 +0100
      Re: [PATCH v3 4/5] ACPI / processor_idle : introduce  ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE Sudeep Holla <sudeep.holla@arm.com> - 2016-02-22 14:50 +0100

#1335784 — Re: [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE

On Wednesday, December 02, 2015 02:10:45 PM Sudeep Holla wrote:
> ACPI 6.0 adds a new method to specify the CPU idle states(C-states)
> called Low Power Idle(LPI) states. Since new architectures like ARM64
> use only LPIs, introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE to
> encapsulate all the code supporting the old style C-states(_CST)

No.

The way it really should work is to check if the firmware supports LPI
(and what kind of it) and try to use _CST if LPI is not supported.

If LPI is supported by the firmware, use it if the LPI objects are
present as expected or fall back to using _CST otherwise.

This way it all should work without any new Kconfig options.

Thanks,
Rafael

[toc] | [next] | [standalone]

#1336373 — Re: [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE

On 16/02/16 20:18, Rafael J. Wysocki wrote:
> On Wednesday, December 02, 2015 02:10:45 PM Sudeep Holla wrote:
>> ACPI 6.0 adds a new method to specify the CPU idle states(C-states)
>> called Low Power Idle(LPI) states. Since new architectures like ARM64
>> use only LPIs, introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE to
>> encapsulate all the code supporting the old style C-states(_CST)
>
> No.
>
> The way it really should work is to check if the firmware supports LPI
> (and what kind of it) and try to use _CST if LPI is not supported.
>

Agreed

> If LPI is supported by the firmware, use it if the LPI objects are
> present as expected or fall back to using _CST otherwise.
>

I have something similar but I need to reverse the order I think.

> This way it all should work without any new Kconfig options.
>

I agree with you in terms of avoiding new Kconfig option. However the
main reason for adding it is to avoid declaring dummy functions and
variables on ARM64.

It's hard to justify the maintainers as it's totally useless on ARM64.
E.g. boot_option_idle_override, IDLE_NOMWAIT, acpi_unlazy_tlb,
arch_safe_halt.

Other option is to push those under CONFIG_X86, but then I don't have
much idea on what are all needed for IA64, so took an option that
encapsulates everything under CSTATE feature Kconfig, which is not user
visible and selected by archs supporting it by default.

I am open to any other alternative.

-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1339490 — Re: [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE

Hi Rafael,

On 17/02/16 12:21, Sudeep Holla wrote:
>
>
> On 16/02/16 20:18, Rafael J. Wysocki wrote:

[..]

>
>> This way it all should work without any new Kconfig options.
>>
>
> I agree with you in terms of avoiding new Kconfig option. However the
> main reason for adding it is to avoid declaring dummy functions and
> variables on ARM64.
>
> It's hard to justify the maintainers as it's totally useless on ARM64.
> E.g. boot_option_idle_override, IDLE_NOMWAIT, acpi_unlazy_tlb,
> arch_safe_halt.
>
> Other option is to push those under CONFIG_X86, but then I don't have
> much idea on what are all needed for IA64, so took an option that
> encapsulates everything under CSTATE feature Kconfig, which is not user
> visible and selected by archs supporting it by default.
>
> I am open to any other alternative.
>

Whatever alternative methods I tried so far ended up much horrible than
this. So any suggestions are much appreciated.

-- 
Regards,
Sudeep

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web