Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1893263pxj; Sat, 5 Jun 2021 06:20:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykKtMRDAdFvrHiKKLcgFlNxB47zPn3X73UgAhyuDCp6Du3apwSXd5U2o2H7VWo7kmxKLgr X-Received: by 2002:aa7:d510:: with SMTP id y16mr10281480edq.233.1622899247189; Sat, 05 Jun 2021 06:20:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622899247; cv=none; d=google.com; s=arc-20160816; b=dq0oTCU6+3mFOtX8IANqATbnAcg/UY2Uyqi2Sn/zBI437+7bS5bknCxiNAjvArfWBR sOcEpuklG+y9EE6sy5pCeiK9tkQC9MJzj3Wi+VVkg3tCpAhZc2rj5HxKPtZr/VI0wsw3 t2fpzIM9jIHVYnDNpuE9qKAJn+fbHl5SvV6MBL+KA6QDBqjOn8oFWeEZfVwUKWM5dlFp 1sLEoJh84mStJOijUTyQbYlZRsCZWImUJpsKXPqpItjA5Z6wkGW+jGfqRWgDeg9OQQMW GTTDMM0HZH9HIukN/x17wbJVyXMVSGsF1lQoa2UZ5HzYqBcz65QuPWzTFNq+wow6yP2H B4qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=LgZDPURG1DdcHVpCZCK2XBkcFbpaTucz4LipiT0NUsU=; b=BIysSAiwBZGiig+zgGPkb7kCQYhxlaaG/+ZM2C781yRa93LhmgDZpz18FGNdESVM5C JdsaId+FE6o5bAWpKbfej8+2kz2dgpwC/Ii7pKeqEGkviu1vFIhprWcKiq3CpxoWZ+lv QRJkDYQRPjaVRMNHbfWeGfNC7whPG9s42sIxQHa+elVR/uYQrhb8bni9PhqHIaYEV3Mb aQ4L/aNMZVQgPYh69j+mAZXjdQ5VFjmNInQ7oxoTcCEUYXgx/MLd3Rhoimw98baJcXtq u+1/ciRAhgA6DmAjMmY3/2vp4SSfkLbUKkgP2EjMjtXzywx62BjlK1gJkY3uKfibvIrb ji0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pQxK4XdE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n22si7341799ejz.259.2021.06.05.06.20.22; Sat, 05 Jun 2021 06:20:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pQxK4XdE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230235AbhFENUa (ORCPT + 99 others); Sat, 5 Jun 2021 09:20:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:34954 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229964AbhFENUZ (ORCPT ); Sat, 5 Jun 2021 09:20:25 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7868D61406; Sat, 5 Jun 2021 13:18:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622899117; bh=pFz1r1h81+i/mGF2uSwI/JWJDbJHTjv4eb/e5YOT/x0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pQxK4XdEDHJQGeiboJ2g6mZ7vs+PsXACokEa4SvwWCPZjIFf3KXNCFGYdb+jks5tz gPosWFuCYwipga33qKhV213sUEjR72eTxPCOiY7z6EptQ72f5kjSsONf7G7BaCW5j4 7zWKEMtsU3woFei5RmXtHvDB4CfBlQCQ1U0IQmASMkNSnYr7RUYEByenkBiTKVNdI0 qQbR3/PM8ZZQUjjsseP3UrLrw2X3SLxybnKEDVbfCPsroJlTO+asdujng/M8prZSPs WNftfLV18nSeajxhQOV+muQ6+obPwW1fZnZl2lrfRSfzq0Z/BmybhhKZiIcdlVj0ao 1h9/Zo5DClsIg== Received: by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1lpWCB-008GEv-IU; Sat, 05 Jun 2021 15:18:35 +0200 From: Mauro Carvalho Chehab To: "Jonathan Corbet" , Linux Doc Mailing List Cc: Mauro Carvalho Chehab , "Rafael J. Wysocki" , Viresh Kumar , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: [PATCH 07/34] docs: admin-guide: pm: avoid using ReSt :doc:`foo` markup Date: Sat, 5 Jun 2021 15:18:06 +0200 Message-Id: <447890cd6772ec55e2100ff6f53fffef38674d6b.1622898327.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- Documentation/admin-guide/pm/intel_idle.rst | 16 ++++++++++------ Documentation/admin-guide/pm/intel_pstate.rst | 9 +++++---- 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/Documentation/admin-guide/pm/intel_idle.rst b/Documentation/admin-guide/pm/intel_idle.rst index 89309e1b0e48..b799a43da62e 100644 --- a/Documentation/admin-guide/pm/intel_idle.rst +++ b/Documentation/admin-guide/pm/intel_idle.rst @@ -20,8 +20,8 @@ Nehalem and later generations of Intel processors, but the level of support for a particular processor model in it depends on whether or not it recognizes that processor model and may also depend on information coming from the platform firmware. [To understand ``intel_idle`` it is necessary to know how ``CPUIdle`` -works in general, so this is the time to get familiar with :doc:`cpuidle` if you -have not done that yet.] +works in general, so this is the time to get familiar with +Documentation/admin-guide/pm/cpuidle.rst if you have not done that yet.] ``intel_idle`` uses the ``MWAIT`` instruction to inform the processor that the logical CPU executing it is idle and so it may be possible to put some of the @@ -53,7 +53,8 @@ processor) corresponding to them depends on the processor model and it may also depend on the configuration of the platform. In order to create a list of available idle states required by the ``CPUIdle`` -subsystem (see :ref:`idle-states-representation` in :doc:`cpuidle`), +subsystem (see :ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst), ``intel_idle`` can use two sources of information: static tables of idle states for different processor models included in the driver itself and the ACPI tables of the system. The former are always used if the processor model at hand is @@ -98,7 +99,8 @@ states may not be enabled by default if there are no matching entries in the preliminary list of idle states coming from the ACPI tables. In that case user space still can enable them later (on a per-CPU basis) with the help of the ``disable`` idle state attribute in ``sysfs`` (see -:ref:`idle-states-representation` in :doc:`cpuidle`). This basically means that +:ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst). This basically means that the idle states "known" to the driver may not be enabled by default if they have not been exposed by the platform firmware (through the ACPI tables). @@ -186,7 +188,8 @@ be desirable. In practice, it is only really necessary to do that if the idle states in question cannot be enabled during system startup, because in the working state of the system the CPU power management quality of service (PM QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states -even if they have been enumerated (see :ref:`cpu-pm-qos` in :doc:`cpuidle`). +even if they have been enumerated (see :ref:`cpu-pm-qos` in +Documentation/admin-guide/pm/cpuidle.rst). Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail. The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle`` @@ -202,7 +205,8 @@ Namely, the positions of the bits that are set in the ``states_off`` value are the indices of idle states to be disabled by default (as reflected by the names of the corresponding idle state directories in ``sysfs``, :file:`state0`, :file:`state1` ... :file:`state` ..., where ```` is the index of the given -idle state; see :ref:`idle-states-representation` in :doc:`cpuidle`). +idle state; see :ref:`idle-states-representation` in +Documentation/admin-guide/pm/cpuidle.rst). For example, if ``states_off`` is equal to 3, the driver will disable idle states 0 and 1 by default, and if it is equal to 8, idle state 3 will be diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index df29b4f1f219..7a7d4b041eac 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -18,8 +18,8 @@ General Information (``CPUFreq``). It is a scaling driver for the Sandy Bridge and later generations of Intel processors. Note, however, that some of those processors may not be supported. [To understand ``intel_pstate`` it is necessary to know -how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if -you have not done that yet.] +how ``CPUFreq`` works in general, so this is the time to read +Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.] For the processors supported by ``intel_pstate``, the P-state concept is broader than just an operating frequency or an operating performance point (see the @@ -445,8 +445,9 @@ Interpretation of Policy Attributes ----------------------------------- The interpretation of some ``CPUFreq`` policy attributes described in -:doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver -and it generally depends on the driver's `operation mode `_. +Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate`` +as the current scaling driver and it generally depends on the driver's +`operation mode `_. First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and ``scaling_cur_freq`` attributes are produced by applying a processor-specific -- 2.31.1