Date:   Sat, 1 Feb 2020 20:59:14 +0800
From:   Changbin Du <changbin.du@...il.com>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     Changbin Du <changbin.du@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Vinod Koul <vkoul@...nel.org>,
        Amit Daniel Kachhap <amit.kachhap@...il.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Javi Merino <javi.merino@...nel.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH] Documentation: Fix build error for cpu-idle-cooling.rst
 and client.rst

Hi,
On Fri, Jan 31, 2020 at 10:33:30PM -0800, Randy Dunlap wrote:
> On 1/31/20 10:25 PM, Changbin Du wrote:
> > This fixed some errors and warnings in cpu-idle-cooling.rst and client.rst.
> > 
> > Sphinx parallel build error:
> > docutils.utils.SystemMessage: ...Documentation/driver-api/thermal/cpu-idle-cooling.rst:96: (SEVERE/4) Unexpected section title.
> > 
> > Sphinx parallel build error:
> > docutils.utils.SystemMessage: ...Documentation/driver-api/dmaengine/client.rst:155: (SEVERE/4) Unexpected section title.
> > 
> > Signed-off-by: Changbin Du <changbin.du@...il.com>
> 
> Hi,
> This commit has been merged:
> commit fe27f13d677ccd826386094df6977cfbc13ccf5e
> Author: Randy Dunlap <rdunlap@...radead.org>
> Date:   Mon Jan 20 14:33:16 2020 -0800
> 
>     Documentation: cpu-idle-cooling: fix a SEVERE docs build failure
> 
> Feel free to send patches against current Linus git tree.
> 
Seems it is not in Linus's tree yet. But is it in Jonathan's tree now? I could
rebase to the doc tree instead.

> Thanks.
> 
> > ---
> >  Documentation/driver-api/dmaengine/client.rst | 14 ++++++---
> >  .../driver-api/thermal/cpu-idle-cooling.rst   | 29 +++++++++++--------
> >  Documentation/driver-api/thermal/index.rst    |  1 +
> >  3 files changed, 28 insertions(+), 16 deletions(-)
> > 
> > diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst
> > index a9a7a3c84c63..2104830a99ae 100644
> > --- a/Documentation/driver-api/dmaengine/client.rst
> > +++ b/Documentation/driver-api/dmaengine/client.rst
> > @@ -151,8 +151,8 @@ The details of these operations are:
> >       Note that callbacks will always be invoked from the DMA
> >       engines tasklet, never from interrupt context.
> >  
> > -  Optional: per descriptor metadata
> > -  ---------------------------------
> > +  **Optional: per descriptor metadata**
> > +
> >    DMAengine provides two ways for metadata support.
> >  
> >    DESC_METADATA_CLIENT
> > @@ -199,12 +199,15 @@ The details of these operations are:
> >    DESC_METADATA_CLIENT
> >  
> >      - DMA_MEM_TO_DEV / DEV_MEM_TO_MEM:
> > +
> >        1. prepare the descriptor (dmaengine_prep_*)
> >           construct the metadata in the client's buffer
> >        2. use dmaengine_desc_attach_metadata() to attach the buffer to the
> >           descriptor
> >        3. submit the transfer
> > +
> >      - DMA_DEV_TO_MEM:
> > +
> >        1. prepare the descriptor (dmaengine_prep_*)
> >        2. use dmaengine_desc_attach_metadata() to attach the buffer to the
> >           descriptor
> > @@ -215,6 +218,7 @@ The details of these operations are:
> >    DESC_METADATA_ENGINE
> >  
> >      - DMA_MEM_TO_DEV / DEV_MEM_TO_MEM:
> > +
> >        1. prepare the descriptor (dmaengine_prep_*)
> >        2. use dmaengine_desc_get_metadata_ptr() to get the pointer to the
> >           engine's metadata area
> > @@ -222,7 +226,9 @@ The details of these operations are:
> >        4. use dmaengine_desc_set_metadata_len()  to tell the DMA engine the
> >           amount of data the client has placed into the metadata buffer
> >        5. submit the transfer
> > +
> >      - DMA_DEV_TO_MEM:
> > +
> >        1. prepare the descriptor (dmaengine_prep_*)
> >        2. submit the transfer
> >        3. on transfer completion, use dmaengine_desc_get_metadata_ptr() to get
> > @@ -278,8 +284,8 @@ The details of these operations are:
> >  
> >        void dma_async_issue_pending(struct dma_chan *chan);
> >  
> > -Further APIs:
> > --------------
> > +Further APIs
> > +------------
> >  
> >  1. Terminate APIs
> >  
> > diff --git a/Documentation/driver-api/thermal/cpu-idle-cooling.rst b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
> > index e4f0859486c7..d8b522d37eb9 100644
> > --- a/Documentation/driver-api/thermal/cpu-idle-cooling.rst
> > +++ b/Documentation/driver-api/thermal/cpu-idle-cooling.rst
> > @@ -1,6 +1,9 @@
> > +================
> > +CPU Idle Cooling
> > +================
> >  
> > -Situation:
> > -----------
> > +Situation
> > +---------
> >  
> >  Under certain circumstances a SoC can reach a critical temperature
> >  limit and is unable to stabilize the temperature around a temperature
> > @@ -24,8 +27,8 @@ with a power less than the requested power budget and the next OPP
> >  exceeds the power budget. An intermediate OPP could have been used if
> >  it were present.
> >  
> > -Solutions:
> > -----------
> > +Solutions
> > +---------
> >  
> >  If we can remove the static and the dynamic leakage for a specific
> >  duration in a controlled period, the SoC temperature will
> > @@ -45,12 +48,12 @@ 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
> > -coefficient similar to:
> > +coefficient similar to::
> >  
> >  	    Power(IdleCycle) = Coef x Power(OPP)
> >  
> > -Idle Injection:
> > ----------------
> > +Idle Injection
> > +--------------
> >  
> >  The base concept of the idle injection is to force the CPU to go to an
> >  idle state for a specified time each control cycle, it provides
> > @@ -64,6 +67,7 @@ latencies as the CPUs will have to wakeup from a deep sleep state.
> >  We use a fixed duration of idle injection that gives an acceptable
> >  performance penalty and a fixed latency. Mitigation can be increased
> >  or decreased by modulating the duty cycle of the idle injection.
> > +::
> >  
> >       ^
> >       |
> > @@ -90,6 +94,7 @@ computed.
> >  
> >  The governor will change the cooling device state thus the duty cycle
> >  and this variation will modulate the cooling effect.
> > +::
> >  
> >       ^
> >       |
> > @@ -132,7 +137,7 @@ Power considerations
> >  --------------------
> >  
> >  When we reach the thermal trip point, we have to sustain a specified
> > -power for a specific temperature but at this time we consume:
> > +power for a specific temperature but at this time we consume::
> >  
> >   Power = Capacitance x Voltage^2 x Frequency x Utilisation
> >  
> > @@ -141,7 +146,7 @@ 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:
> > +‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have::
> >  
> >   Pdyn = Cdyn x Voltage^2 x Frequency
> >  
> > @@ -150,7 +155,7 @@ in order to target the sustainable power defined in the device
> >  tree. So with the idle injection mechanism, we want an average power
> >  (Ptarget) resulting in an amount of time running at full power on a
> >  specific OPP and idle another amount of time. That could be put in a
> > -equation:
> > +equation::
> >  
> >   P(opp)target = ((Trunning x (P(opp)running) + (Tidle x P(opp)idle)) /
> >  			(Trunning + Tidle)
> > @@ -160,7 +165,7 @@ equation:
> >  
> >  At this point if we know the running period for the CPU, that gives us
> >  the idle injection we need. Alternatively if we have the idle
> > -injection duration, we can compute the running duration with:
> > +injection duration, we can compute the running duration with::
> >  
> >   Trunning = Tidle / ((P(opp)running / P(opp)target) - 1)
> >  
> > @@ -183,7 +188,7 @@ However, in this demonstration we ignore three aspects:
> >     target residency, otherwise we end up consuming more energy and
> >     potentially invert the mitigation effect
> >  
> > -So the final equation is:
> > +So the final equation is::
> >  
> >   Trunning = (Tidle - Twakeup ) x
> >  		(((P(opp)dyn + P(opp)static ) - P(opp)target) / P(opp)target )
> > diff --git a/Documentation/driver-api/thermal/index.rst b/Documentation/driver-api/thermal/index.rst
> > index 5ba61d19c6ae..4cb0b9b6bfb8 100644
> > --- a/Documentation/driver-api/thermal/index.rst
> > +++ b/Documentation/driver-api/thermal/index.rst
> > @@ -8,6 +8,7 @@ Thermal
> >     :maxdepth: 1
> >  
> >     cpu-cooling-api
> > +   cpu-idle-cooling
> >     sysfs-api
> >     power_allocator
> >  
> > 
> 
> 
> -- 
> ~Randy
> 

-- 
Cheers,
Changbin Du

Powered by blists - more mailing lists