From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 987E9C63697 for ; Tue, 17 Nov 2020 16:09:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 557F32467A for ; Tue, 17 Nov 2020 16:09:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727084AbgKQQI7 (ORCPT ); Tue, 17 Nov 2020 11:08:59 -0500 Received: from ms.lwn.net ([45.79.88.28]:39414 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726433AbgKQQI6 (ORCPT ); Tue, 17 Nov 2020 11:08:58 -0500 Received: from lwn.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 237B0221; Tue, 17 Nov 2020 16:08:57 +0000 (UTC) Date: Tue, 17 Nov 2020 09:08:56 -0700 From: Jonathan Corbet To: Daniel Lezcano Cc: rjw@rjwysocki.net, ulf.hansson@linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, ilina@codeaurora.org, lukasz.luba@arm.com, rkumbako@codeaurora.org, rui.zhang@intel.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 2/4] Documentation/powercap/dtpm: Add documentation for dtpm Message-ID: <20201117090856.27eddac7@lwn.net> In-Reply-To: <20201116152649.11482-3-daniel.lezcano@linaro.org> References: <20201116152649.11482-1-daniel.lezcano@linaro.org> <20201116152649.11482-3-daniel.lezcano@linaro.org> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 16 Nov 2020 16:26:47 +0100 Daniel Lezcano wrote: > The dynamic thermal and power management is a technique to dynamically > adjust the power consumption of different devices in order to ensure a > global thermal constraint. > > An userspace daemon is usually monitoring the temperature and the > power to take immediate action on the device. > > The DTPM framework provides an unified API to userspace to act on the > power. > > Document this framework. It's always refreshing to see documentation show up with a new feature! :) That said, it's clear that you haven't built the docs with this new material. There's a couple of little things I would ask you to do... > Signed-off-by: Daniel Lezcano > --- > Documentation/power/powercap/dtpm.rst | 222 ++++++++++++++++++++++++++ > 1 file changed, 222 insertions(+) > create mode 100644 Documentation/power/powercap/dtpm.rst You also need to add this new file to index.rst > diff --git a/Documentation/power/powercap/dtpm.rst b/Documentation/power/powercap/dtpm.rst > new file mode 100644 > index 000000000000..ce11cf183994 > --- /dev/null > +++ b/Documentation/power/powercap/dtpm.rst > @@ -0,0 +1,222 @@ > +========================================== > +Dynamic Thermal Power Management framework > +========================================== > + > +On the embedded world, the complexity of the SoC leads to an > +increasing number of hotspots which need to be monitored and mitigated > +as a whole in order to prevent the temperature to go above the > +normative and legally stated 'skin temperature'. > + > +Another aspect is to sustain the performance for a given power budget, > +for example virtual reality where the user can feel dizziness if the > +performance is capped while a big CPU is processing something else. Or > +reduce the battery charging because the dissipated power is too high > +compared with the power consumed by other devices. > + > +The userspace is the most adequate place to dynamically act on the > +different devices by limiting their power given an application > +profile: it has the knowledge of the platform. > + > +The Dynamic Thermal Power Management (DTPM) is a technique acting on > +the device power by limiting and/or balancing a power budget among > +different devices. > + > +The DTPM framework provides an unified interface to act on the > +device power. > + > +=========== > +1. Overview > +=========== Please follow the sequence of subheading markers described in Documentation/doc-guide/sphinx.rst. This one should be: Overview ======== (I took out the section number because that's not really needed in the RST world, but that's up to you). > +The DTPM framework relies on the powercap framework to create the > +powercap entries in the sysfs directory and implement the backend > +driver to do the connection with the power manageable device. > + > +The DTPM is a tree representation describing the power constraints > +shared between devices, not their physical positions. > + > +The nodes of the tree are a virtual description aggregating the power > +characteristics of the children nodes and their power limitations. > + > +The leaves of the tree are the real power manageable devices. > + > +For instance: > + > + SoC > + | > + `-- pkg > + | > + |-- pd0 (cpu0-3) > + | > + `-- pd1 (cpu4-5) This formatting will throw errors when you try to do the docs build. The easiest solution is to put literal blocks like this into ... a literal block. And that is most easily done by putting a double colon at the end of the leading line: For instance:: The same will need to happen for all the rest of the ascii art. > +* The pkg power will be the sum of pd0 and pd1 power numbers. > + > + SoC (400mW - 3100mW) > + | > + `-- pkg (400mW - 3100mW) > + | > + |-- pd0 (100mW - 700mW) > + | > + `-- pd1 (300mW - 2400mW) > + > +* When the nodes are inserted in the tree, their power characteristics > + are propagated to the parents. I suspect you'll also need to indent the literal block another space or two to separate it from the bulleted list. You don't have any kernel-doc directives to bring in the kerneldoc comments from the code. The code itself *does* have those comments, so you might want to add those. Thanks, jon