Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

docs: admin-guide: pm: avoid using ReST :doc:`foo` markup

The :doc:`foo` tag is auto-generated via automarkup.py.
So, use the filename at the sources, instead of :doc:`foo`.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/04616d9fc0b4a0d33486fa0018631a2db2eba860.1623824363.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

authored by

Mauro Carvalho Chehab and committed by
Jonathan Corbet
17420f31 9129faf9

+15 -10
+10 -6
Documentation/admin-guide/pm/intel_idle.rst
··· 20 20 a particular processor model in it depends on whether or not it recognizes that 21 21 processor model and may also depend on information coming from the platform 22 22 firmware. [To understand ``intel_idle`` it is necessary to know how ``CPUIdle`` 23 - works in general, so this is the time to get familiar with :doc:`cpuidle` if you 24 - have not done that yet.] 23 + works in general, so this is the time to get familiar with 24 + Documentation/admin-guide/pm/cpuidle.rst if you have not done that yet.] 25 25 26 26 ``intel_idle`` uses the ``MWAIT`` instruction to inform the processor that the 27 27 logical CPU executing it is idle and so it may be possible to put some of the ··· 53 53 depend on the configuration of the platform. 54 54 55 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`), 56 + subsystem (see :ref:`idle-states-representation` in 57 + Documentation/admin-guide/pm/cpuidle.rst), 57 58 ``intel_idle`` can use two sources of information: static tables of idle states 58 59 for different processor models included in the driver itself and the ACPI tables 59 60 of the system. The former are always used if the processor model at hand is ··· 99 98 preliminary list of idle states coming from the ACPI tables. In that case user 100 99 space still can enable them later (on a per-CPU basis) with the help of 101 100 the ``disable`` idle state attribute in ``sysfs`` (see 102 - :ref:`idle-states-representation` in :doc:`cpuidle`). This basically means that 101 + :ref:`idle-states-representation` in 102 + Documentation/admin-guide/pm/cpuidle.rst). This basically means that 103 103 the idle states "known" to the driver may not be enabled by default if they have 104 104 not been exposed by the platform firmware (through the ACPI tables). 105 105 ··· 188 186 states in question cannot be enabled during system startup, because in the 189 187 working state of the system the CPU power management quality of service (PM 190 188 QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states 191 - even if they have been enumerated (see :ref:`cpu-pm-qos` in :doc:`cpuidle`). 189 + even if they have been enumerated (see :ref:`cpu-pm-qos` in 190 + Documentation/admin-guide/pm/cpuidle.rst). 192 191 Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail. 193 192 194 193 The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle`` ··· 205 202 the indices of idle states to be disabled by default (as reflected by the names 206 203 of the corresponding idle state directories in ``sysfs``, :file:`state0`, 207 204 :file:`state1` ... :file:`state<i>` ..., where ``<i>`` is the index of the given 208 - idle state; see :ref:`idle-states-representation` in :doc:`cpuidle`). 205 + idle state; see :ref:`idle-states-representation` in 206 + Documentation/admin-guide/pm/cpuidle.rst). 209 207 210 208 For example, if ``states_off`` is equal to 3, the driver will disable idle 211 209 states 0 and 1 by default, and if it is equal to 8, idle state 3 will be
+5 -4
Documentation/admin-guide/pm/intel_pstate.rst
··· 18 18 (``CPUFreq``). It is a scaling driver for the Sandy Bridge and later 19 19 generations of Intel processors. Note, however, that some of those processors 20 20 may not be supported. [To understand ``intel_pstate`` it is necessary to know 21 - how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if 22 - you have not done that yet.] 21 + how ``CPUFreq`` works in general, so this is the time to read 22 + Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.] 23 23 24 24 For the processors supported by ``intel_pstate``, the P-state concept is broader 25 25 than just an operating frequency or an operating performance point (see the ··· 445 445 ----------------------------------- 446 446 447 447 The interpretation of some ``CPUFreq`` policy attributes described in 448 - :doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver 449 - and it generally depends on the driver's `operation mode <Operation Modes_>`_. 448 + Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate`` 449 + as the current scaling driver and it generally depends on the driver's 450 + `operation mode <Operation Modes_>`_. 450 451 451 452 First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and 452 453 ``scaling_cur_freq`` attributes are produced by applying a processor-specific