From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: Linux ACPI <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Len Brown <len.brown@intel.com>, Zhang Rui <rui.zhang@intel.com>,
David Box <david.e.box@linux.intel.com>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>
Subject: [PATCH 1/2] intel_idle: Introduce 'use_acpi' module parameter
Date: Thu, 30 Jan 2020 15:46:24 +0100 [thread overview]
Message-ID: <5626578.OFR1oUKyPK@kreacher> (raw)
In-Reply-To: <1720216.0Jr2BLnqKp@kreacher>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
For diagnostics, it is generally useful to be able to make intel_idle
take the system's ACPI tables into consideration even if that is not
required for the processor model in there, so introduce a new module
parameter, 'use_acpi', to make that happen and update the documentation
to cover it.
While at it, fix the 'no_acpi' module parameter name in the
documentation.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Documentation/admin-guide/pm/intel_idle.rst | 13 +++++++++----
drivers/idle/intel_idle.c | 11 +++++++++--
2 files changed, 18 insertions(+), 6 deletions(-)
Index: linux-pm/drivers/idle/intel_idle.c
===================================================================
--- linux-pm.orig/drivers/idle/intel_idle.c
+++ linux-pm/drivers/idle/intel_idle.c
@@ -1131,6 +1131,10 @@ static bool no_acpi __read_mostly;
module_param(no_acpi, bool, 0444);
MODULE_PARM_DESC(no_acpi, "Do not use ACPI _CST for building the idle states list");
+static bool use_acpi __read_mostly; /* No effect if no_acpi is set. */
+module_param(use_acpi, bool, 0444);
+MODULE_PARM_DESC(use_acpi, "Use ACPI _CST for building the idle states list");
+
static struct acpi_processor_power acpi_state_table __initdata;
/**
@@ -1258,6 +1262,8 @@ static bool __init intel_idle_off_by_def
return true;
}
#else /* !CONFIG_ACPI_PROCESSOR_CSTATE */
+#define use_acpi (false)
+
static inline bool intel_idle_acpi_cst_extract(void) { return false; }
static inline void intel_idle_init_cstates_acpi(struct cpuidle_driver *drv) { }
static inline bool intel_idle_off_by_default(u32 mwait_hint) { return false; }
@@ -1460,7 +1466,8 @@ static void __init intel_idle_init_cstat
/* Structure copy. */
drv->states[drv->state_count] = cpuidle_state_table[cstate];
- if (icpu->use_acpi && intel_idle_off_by_default(mwait_hint) &&
+ if ((icpu->use_acpi || use_acpi) &&
+ intel_idle_off_by_default(mwait_hint) &&
!(cpuidle_state_table[cstate].flags & CPUIDLE_FLAG_ALWAYS_ENABLE))
drv->states[drv->state_count].flags |= CPUIDLE_FLAG_OFF;
@@ -1607,7 +1614,7 @@ static int __init intel_idle_init(void)
icpu = (const struct idle_cpu *)id->driver_data;
if (icpu) {
cpuidle_state_table = icpu->state_table;
- if (icpu->use_acpi)
+ if (icpu->use_acpi || use_acpi)
intel_idle_acpi_cst_extract();
} else if (!intel_idle_acpi_cst_extract()) {
return -ENODEV;
Index: linux-pm/Documentation/admin-guide/pm/intel_idle.rst
===================================================================
--- linux-pm.orig/Documentation/admin-guide/pm/intel_idle.rst
+++ linux-pm/Documentation/admin-guide/pm/intel_idle.rst
@@ -60,6 +60,9 @@ of the system. The former are always us
recognized by ``intel_idle`` and the latter are used if that is required for
the given processor model (which is the case for all server processor models
recognized by ``intel_idle``) or if the processor model is not recognized.
+[There is a module parameter that can be used to make the driver use the ACPI
+tables with any processor model recognized by it; see
+`below <intel-idle-parameters_>`_.]
If the ACPI tables are going to be used for building the list of available idle
states, ``intel_idle`` first looks for a ``_CST`` object under one of the ACPI
@@ -165,7 +168,7 @@ and ``idle=nomwait``. If any of them is
``MWAIT`` instruction is not allowed to be used, so the initialization of
``intel_idle`` will fail.
-Apart from that there are two module parameters recognized by ``intel_idle``
+Apart from that there are three module parameters recognized by ``intel_idle``
itself that can be set via the kernel command line (they cannot be updated via
sysfs, so that is the only way to change their values).
@@ -186,9 +189,11 @@ QoS) feature can be used to prevent ``CP
even if they have been enumerated (see :ref:`cpu-pm-qos` in :doc:`cpuidle`).
Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail.
-The ``noacpi`` module parameter (which is recognized by ``intel_idle`` if the
-kernel has been configured with ACPI support), can be set to make the driver
-ignore the system's ACPI tables entirely (it is unset by default).
+The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle``
+if the kernel has been configured with ACPI support) can be set to make the
+driver ignore the system's ACPI tables entirely or use them for all of the
+recognized processor models, respectively (they both are unset by default and
+``use_acpi`` has no effect if ``no_acpi`` is set).
.. _intel-idle-core-and-package-idle-states:
next prev parent reply other threads:[~2020-01-30 14:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 14:44 [PATCH 0/2] intel_idle: Two new module parameters Rafael J. Wysocki
2020-01-30 14:46 ` Rafael J. Wysocki [this message]
2020-02-02 14:23 ` [PATCH 1/2] intel_idle: Introduce 'use_acpi' module parameter kbuild test robot
2020-01-30 14:47 ` [PATCH 2/2] intel_idle: Introduce 'states_off' " Rafael J. Wysocki
2020-01-31 11:07 ` David Laight
2020-01-31 11:23 ` Rafael J. Wysocki
2020-01-31 11:24 ` Artem Bityutskiy
2020-01-31 11:54 ` David Laight
2020-01-31 12:03 ` Rafael J. Wysocki
2020-02-03 11:13 ` [PATCH v2 0/2] intel_idle: Two new module parameters Rafael J. Wysocki
2020-02-03 11:15 ` [PATCH v2 1/2] intel_idle: Introduce 'use_acpi' module parameter Rafael J. Wysocki
2020-02-03 11:19 ` [PATCH v2 2/2] intel_idle: Introduce 'states_off' " 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=5626578.OFR1oUKyPK@kreacher \
--to=rjw@rjwysocki.net \
--cc=artem.bityutskiy@linux.intel.com \
--cc=david.e.box@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
/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).