Re: [PATCH v2 08/40] docs: driver-api: thermal: Use ASCII subset instead of UTF-8 alternate symbols

[Daniel Lezcano]

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@xxxxxxxxxx>

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

> ---
>  .../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@xxxxxxxxxxxxxxx>
>  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