lkml.org 
[lkml]   [2021]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 08/40] docs: driver-api: thermal: Use ASCII subset instead of UTF-8 alternate symbols
    From
    Date
    On 12/05/2021 14:50, Mauro Carvalho Chehab wrote:
    > The conversion tools used during DocBook/LaTeX/Markdown->ReST conversion
    > and some automatic rules which exists on certain text editors like
    > LibreOffice turned ASCII characters into some UTF-8 alternatives that
    > are better displayed on html and PDF.
    >
    > While it is OK to use UTF-8 characters in Linux, it is better to
    > use the ASCII subset instead of using an UTF-8 equivalent character
    > as it makes life easier for tools like grep, and are easier to edit
    > with the some commonly used text/source code editors.
    >
    > Also, Sphinx already do such conversion automatically outside literal blocks:
    > https://docutils.sourceforge.io/docs/user/smartquotes.html
    >
    > So, replace the occurences of the following UTF-8 characters:
    >
    > - U+2018 ('‘'): LEFT SINGLE QUOTATION MARK
    > - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
    >
    > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

    Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>

    > ---
    > .../driver-api/thermal/cpu-idle-cooling.rst | 14 +++++++-------
    > .../driver-api/thermal/intel_powerclamp.rst | 6 +++---
    > .../thermal/x86_pkg_temperature_thermal.rst | 2 +-
    > 3 files changed, 11 insertions(+), 11 deletions(-)
    >
    > diff --git a/Documentation/driver-api/thermal/cpu-idle-cooling.rst b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
    > index c2a7ca676853..60934a518560 100644
    > --- a/Documentation/driver-api/thermal/cpu-idle-cooling.rst
    > +++ b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
    > @@ -49,7 +49,7 @@ belong to the same cluster, with a duration greater than the cluster
    > idle state target residency, we lead to dropping the static and the
    > dynamic leakage for this period (modulo the energy needed to enter
    > this state). So the sustainable power with idle cycles has a linear
    > -relation with the OPP’s sustainable power and can be computed with a
    > +relation with the OPP's sustainable power and can be computed with a
    > coefficient similar to::
    >
    > Power(IdleCycle) = Coef x Power(OPP)
    > @@ -134,7 +134,7 @@ The idle injection duration value must comply with the constraints:
    > user experience, reactivity vs performance trade off we want. This
    > value should be specified.
    >
    > -- It is greater than the idle state’s target residency we want to go
    > +- It is greater than the idle state's target residency we want to go
    > for thermal mitigation, otherwise we end up consuming more energy.
    >
    > Power considerations
    > @@ -146,11 +146,11 @@ power for a specific temperature but at this time we consume::
    > Power = Capacitance x Voltage^2 x Frequency x Utilisation
    >
    > ... which is more than the sustainable power (or there is something
    > -wrong in the system setup). The ‘Capacitance’ and ‘Utilisation’ are a
    > -fixed value, ‘Voltage’ and the ‘Frequency’ are fixed artificially
    > -because we don’t want to change the OPP. We can group the
    > -‘Capacitance’ and the ‘Utilisation’ into a single term which is the
    > -‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have::
    > +wrong in the system setup). The 'Capacitance' and 'Utilisation' are a
    > +fixed value, 'Voltage' and the 'Frequency' are fixed artificially
    > +because we don't want to change the OPP. We can group the
    > +'Capacitance' and the 'Utilisation' into a single term which is the
    > +'Dynamic Power Coefficient (Cdyn)' Simplifying the above, we have::
    >
    > Pdyn = Cdyn x Voltage^2 x Frequency
    >
    > diff --git a/Documentation/driver-api/thermal/intel_powerclamp.rst b/Documentation/driver-api/thermal/intel_powerclamp.rst
    > index 3f6dfb0b3ea6..d349c1b64281 100644
    > --- a/Documentation/driver-api/thermal/intel_powerclamp.rst
    > +++ b/Documentation/driver-api/thermal/intel_powerclamp.rst
    > @@ -29,7 +29,7 @@ By:
    > INTRODUCTION
    > ============
    >
    > -Consider the situation where a system’s power consumption must be
    > +Consider the situation where a system's power consumption must be
    > reduced at runtime, due to power budget, thermal constraint, or noise
    > level, and where active cooling is not preferred. Software managed
    > passive power reduction must be performed to prevent the hardware
    > @@ -39,7 +39,7 @@ Currently, P-states, T-states (clock modulation), and CPU offlining
    > are used for CPU throttling.
    >
    > On Intel CPUs, C-states provide effective power reduction, but so far
    > -they’re only used opportunistically, based on workload. With the
    > +they're only used opportunistically, based on workload. With the
    > development of intel_powerclamp driver, the method of synchronizing
    > idle injection across all online CPU threads was introduced. The goal
    > is to achieve forced and controllable C-state residency.
    > @@ -264,7 +264,7 @@ CPUs).
    > Usage and Interfaces
    > ====================
    > The powerclamp driver is registered to the generic thermal layer as a
    > -cooling device. Currently, it’s not bound to any thermal zones::
    > +cooling device. Currently, it's not bound to any thermal zones::
    >
    > jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . *
    > cur_state:0
    > diff --git a/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst b/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst
    > index 2ac42ccd236f..5b95af96e40f 100644
    > --- a/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst
    > +++ b/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst
    > @@ -13,7 +13,7 @@ Authors: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    > Reference
    > ---------
    >
    > -Intel® 64 and IA-32 Architectures Software Developer’s Manual (Jan, 2013):
    > +Intel® 64 and IA-32 Architectures Software Developer's Manual (Jan, 2013):
    > Chapter 14.6: PACKAGE LEVEL THERMAL MANAGEMENT
    >
    > Description
    >


    --
    <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

    Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
    <http://twitter.com/#!/linaroorg> Twitter |
    <http://www.linaro.org/linaro-blog/> Blog

    \
     
     \ /
      Last update: 2021-06-12 21:09    [W:4.828 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site