Lines Matching +full:quality +full:- +full:of +full:- +full:service
1 .. SPDX-License-Identifier: GPL-2.0
16 Every time one of the logical CPUs in the system (the entities that appear to
22 instructions from memory and putting some of the processor's functional units
28 particular idle state. That is the role of the CPU idle time management
31 The design of ``CPUIdle`` is modular and based on the code duplication avoidance
34 the hardware. It generally is divided into three categories of functional
43 A CPU idle time (``CPUIdle``) governor is a bundle of policy code invoked when
44 one of the logical CPUs in the system turns out to be idle. Its role is to
47 ``CPUIdle`` governors are generic and each of them can be used on any hardware
60 add the governor to the global list of available governors and, if it is the
61 only one in the list (that is, the list was empty before) or the value of its
62 :c:member:`rating` field is greater than the value of that field for the
63 governor currently in use, or the name of the new governor was passed to the
64 kernel as the value of the ``cpuidle.governor=`` command line parameter, the new
72 The interface between ``CPUIdle`` governors and the core consists of four
80 The role of this callback is to prepare the governor for handling the
84 with that CPU (among other things, it should contain the list of
89 code, and that causes the kernel to run the architecture-specific
90 default code for idle CPUs on the CPU in question instead of ``CPUIdle``
91 until the ``->enable()`` governor callback is invoked for that CPU
103 It is expected to reverse any changes made by the ``->enable()``
117 The list of idle states to take into consideration is represented by the
118 :c:member:`states` array of struct cpuidle_state objects held by the
135 of the governor to succeed).
142 Called to allow the governor to evaluate the accuracy of the idle state
143 selection made by the ``->select()`` callback (when it was invoked last
144 time) and possibly use the result of that to improve the accuracy of
148 quality of service (PM QoS) constraints on the processor wakeup latency into
151 expected to pass the number of the CPU to
152 :c:func:`cpuidle_governor_latency_req()`. Then, the governor's ``->select()``
153 callback must not return the index of an indle state whose
162 other parts of ``CPUIdle`` and the hardware.
164 First of all, a ``CPUIdle`` driver has to populate the :c:member:`states` array
165 of struct cpuidle_state objects included in the struct cpuidle_driver object
166 representing it. Going forward this array will represent the list of available
167 idle states that the processor hardware can be asked to enter shared by all of
171 value of the :c:member:`target_residency` field in struct cpuidle_state in
173 the minimum value of :c:member:`target_residency`). [Since the
174 :c:member:`target_residency` value is expected to reflect the "depth" of the
185 be saved by staying in a shallower idle state for the same amount of
210 The first two arguments of it point to the struct cpuidle_device object
213 and the last one is an index of the struct cpuidle_state entry in the driver's
217 The analogous ``->enter_s2idle()`` callback in struct cpuidle_state is used
218 only for implementing the suspend-to-idle system-wide power management feature.
219 The difference between in and ``->enter()`` is that it must not re-enable
220 interrupts at any point (even temporarily) or attempt to change the states of
221 clock event devices, which the ``->enter()`` callback may do sometimes.
223 Once the :c:member:`states` array has been populated, the number of valid
224 entries in it has to be stored in the :c:member:`state_count` field of the
229 to be the index of an idle state that is not "coupled" (that is, one that can be
233 subset of logical CPUs in the system, the :c:member:`cpumask` field in its
234 struct cpuidle_driver object must point to the set (mask) of CPUs that will be
244 all of the logical CPUs to be handled by the given ``CPUIdle`` driver with the
245 help of :c:func:`cpuidle_register_device()` after the driver has been registered
249 of registering the struct cpuidle_device objects as needed, so it is generally
253 The registration of a struct cpuidle_device object causes the ``CPUIdle``
254 ``sysfs`` interface to be created and the governor's ``->enable()`` callback to
260 them to be released. Due to dependencies between them, all of the
262 ``CPUIdle`` driver must be unregistered, with the help of
266 along with all of the struct cpuidle_device objects representing CPUs handled
270 lead to modifications of the list of available processor idle states (which can
272 battery or the other way around). Upon a notification of such a change,
275 all of the struct cpuidle_device objects representing CPUs affected by that
277 the new configuration of the system, call :c:func:`cpuidle_enable_device()` for
278 all of the relevant struct cpuidle_device objects and invoke