Lines Matching full:states
28 processor's functional blocks into low-power states. That instruction takes two
42 .. _intel-idle-enumeration-of-states:
44 Enumeration of Idle States
50 as C-states (in the ACPI terminology) or idle states. The list of meaningful
51 ``MWAIT`` hint values and idle states (i.e. low-power configurations of the
55 In order to create a list of available idle states required by the ``CPUIdle``
56 subsystem (see :ref:`idle-states-representation` in :doc:`cpuidle`),
57 ``intel_idle`` can use two sources of information: static tables of idle states
68 states, ``intel_idle`` first looks for a ``_CST`` object under one of the ACPI
71 ``CPUIdle`` subsystem expects that the list of idle states supplied by the
75 state description and such that all of the idle states included in its return
80 descriptions extracted from it are stored in a preliminary list of idle states
84 Next, the first (index 0) entry in the list of available idle states is
91 the "internal" table is the primary source of information on idle states and the
92 information from it is copied to the final list of available idle states. If
93 using the ACPI tables for the enumeration of idle states is not required
97 states may not be enabled by default if there are no matching entries in the
98 preliminary list of idle states coming from the ACPI tables. In that case user
101 :ref:`idle-states-representation` in :doc:`cpuidle`). This basically means that
102 the idle states "known" to the driver may not be enabled by default if they have
106 supports ``MWAIT``, the preliminary list of idle states coming from the ACPI
110 entry in the final list of idle states. The name of the idle state represented
115 C1-type idle states the exit latency value is also used as the target residency
116 (for compatibility with the majority of the "internal" tables of idle states for
121 All of the idle states in the final list are enabled by default in this case.
134 driver, which determines the idle states enumeration method (see
142 `below <intel-idle-parameters_>`_), the idle states information provided by the
146 available idle states is created as explained
176 of idle states supplied to the ``CPUIdle`` core during the registration of the
177 driver. It is also the maximum number of regular (non-polling) idle states that
178 can be used by ``intel_idle``, so the enumeration of idle states is terminated
179 after finding that number of usable idle states (the other idle states that
182 ``intel_idle`` from exposing idle states that are regarded as "too deep" for
186 states in question cannot be enabled during system startup, because in the
188 QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states
199 list of idle states to be disabled by default in the form of a bitmask.
202 the indices of idle states to be disabled by default (as reflected by the names
205 idle state; see :ref:`idle-states-representation` in :doc:`cpuidle`).
208 states 0 and 1 by default, and if it is equal to 8, idle state 3 will be
212 The idle states disabled this way can be enabled (on a per-CPU basis) from user
216 .. _intel-idle-core-and-package-idle-states:
218 Core and Package Levels of Idle States
222 least) two levels of idle states (or C-states). One level, referred to as
223 "core C-states", covers individual cores in the processor, whereas the other
224 level, referred to as "package C-states", covers the entire processor package
228 Some of the ``MWAIT`` hint values allow the processor to use core C-states only
247 As a rule, there is no simple way to make the processor use core C-states only
248 if the conditions for entering the corresponding package C-states are met, so
253 tables of idle states in ``intel_idle`` reflect the properties of package
254 C-states.] If using package C-states is not desirable at all, either
257 restrict the range of permissible idle states to the ones with core-level only