linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org, x86@kernel.org,
	Al Stone <al.stone@linaro.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Mahesh Sivasubramanian <msivasub@codeaurora.org>,
	Ashwin Chaugule <ashwin.chaugule@linaro.org>,
	Prashanth Prakash <pprakash@codeaurora.org>
Subject: Re: [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE
Date: Wed, 17 Feb 2016 12:21:34 +0000	[thread overview]
Message-ID: <56C465CE.50403@arm.com> (raw)
In-Reply-To: <12469811.iv3SctjXxl@vostro.rjw.lan>



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

  reply	other threads:[~2016-02-17 12:21 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02 14:10 [PATCH v3 0/5] ACPI / processor_idle: Add ACPI v6.0 LPI support Sudeep Holla
2015-12-02 14:10 ` [PATCH v3 1/5] ACPI / processor : add support for ACPI0010 processor container Sudeep Holla
2016-02-16 20:10   ` Rafael J. Wysocki
2016-02-17 11:54     ` Sudeep Holla
2016-02-17 11:54   ` [UPDATE] " Sudeep Holla
2016-02-23 23:41     ` Rafael J. Wysocki
2015-12-02 14:10 ` [PATCH v3 2/5] ACPI / sleep: move acpi_processor_sleep to sleep.c Sudeep Holla
2016-02-16 20:13   ` Rafael J. Wysocki
2016-02-17 12:03     ` Sudeep Holla
2016-02-17 12:03   ` [UPDATE] " Sudeep Holla
2016-02-23 23:42     ` Rafael J. Wysocki
2015-12-02 14:10 ` [PATCH v3 3/5] ACPI / processor_idle: replace PREFIX with pr_fmt Sudeep Holla
2016-02-16 20:15   ` Rafael J. Wysocki
2015-12-02 14:10 ` [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE Sudeep Holla
2016-02-16 20:18   ` Rafael J. Wysocki
2016-02-17 12:21     ` Sudeep Holla [this message]
2016-02-22 13:46       ` Sudeep Holla
2016-02-22 23:28         ` Rafael J. Wysocki
2016-02-23  9:32           ` Sudeep Holla
2015-12-02 14:10 ` [PATCH v3 5/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states Sudeep Holla
2016-02-16 20:46   ` Rafael J. Wysocki
2016-02-17 16:10     ` Sudeep Holla
2016-04-12  4:06   ` Vikas Sajjan
2016-04-12 14:29     ` Sudeep Holla
2015-12-09 22:52 ` [PATCH v3 0/5] ACPI / processor_idle: Add ACPI v6.0 LPI support Prakash, Prashanth
2015-12-10  8:48   ` Sudeep Holla
2016-01-15 19:13     ` Prakash, Prashanth
2016-01-18 12:15       ` Sudeep Holla
2016-01-18 14:53         ` Rafael J. Wysocki
2016-01-27 18:26           ` Sudeep Holla
2016-02-16 20:08 ` Rafael J. Wysocki
2016-02-17 11:37   ` Sudeep Holla
2016-02-18  2:08     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56C465CE.50403@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=al.stone@linaro.org \
    --cc=ashwin.chaugule@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msivasub@codeaurora.org \
    --cc=pprakash@codeaurora.org \
    --cc=rjw@rjwysocki.net \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).