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.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 6343CC43457 for ; Tue, 13 Oct 2020 22:02:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1B4982177B for ; Tue, 13 Oct 2020 22:02:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="grqoU3dS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728562AbgJMWC0 (ORCPT ); Tue, 13 Oct 2020 18:02:26 -0400 Received: from m42-4.mailgun.net ([69.72.42.4]:63617 "EHLO m42-4.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725935AbgJMWC0 (ORCPT ); Tue, 13 Oct 2020 18:02:26 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1602626544; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: From: References: Cc: To: Subject: Sender; bh=j2wvnj3QXykcXdMcqTw76Kbrt7Uu3aOrgnn6+mk+B20=; b=grqoU3dSxOR2pTa87+sAKrq8r1WUGY/yq6hLDTIX68mvtZnXZeifdfi7BIx8t9oXx56VLQb7 KLC215ioPLVCJWP+dFys/lGsfrcHozSJmLHt/rhs09LWrSO62fsoQ3UUZN2G+N9ZAP6St5Li EYlp5JB2JRT7ZUf8TET8VevRX0A= X-Mailgun-Sending-Ip: 69.72.42.4 X-Mailgun-Sid: WyI5ZDFmMiIsICJsaW51eC1wbUB2Z2VyLmtlcm5lbC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n02.prod.us-east-1.postgun.com with SMTP id 5f8623cf588858a30411cafa (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 13 Oct 2020 22:01:51 GMT Sender: rkumbako=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id B2081C433CB; Tue, 13 Oct 2020 22:01:50 +0000 (UTC) Received: from [192.168.1.64] (unknown [209.131.238.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rkumbako) by smtp.codeaurora.org (Postfix) with ESMTPSA id A608CC433F1; Tue, 13 Oct 2020 22:01:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A608CC433F1 Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=rkumbako@codeaurora.org Subject: Re: [PATCH 2/4] Documentation/powercap/dtpm: Add documentation for dtpm To: Daniel Lezcano , rafael@kernel.org, srinivas.pandruvada@linux.intel.com Cc: lukasz.luba@arm.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rui.zhang@intel.com, "Rafael J. Wysocki" , Len Brown , Pavel Machek References: <20201006122024.14539-1-daniel.lezcano@linaro.org> <20201006122024.14539-3-daniel.lezcano@linaro.org> From: Ram Chandrasekar Message-ID: <35e0775c-f86c-6040-7194-5b8032e92b30@codeaurora.org> Date: Tue, 13 Oct 2020 16:01:47 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <20201006122024.14539-3-daniel.lezcano@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 10/6/2020 6:20 AM, 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. > > Signed-off-by: Daniel Lezcano > --- > Documentation/power/powercap/dtpm.rst | 222 ++++++++++++++++++++++++++ > 1 file changed, 222 insertions(+) > create mode 100644 Documentation/power/powercap/dtpm.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 > +=========== > + > +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) > + > +* 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. > + > + SoC (600mW - 5900mW) > + | > + |-- pkg (400mW - 3100mW) > + | | > + | |-- pd0 (100mW - 700mW) > + | | > + | `-- pd1 (300mW - 2400mW) > + | > + `-- pd2 (200mW - 2800mW) > + > +* Each node have a weight on a 2^10 basis reflecting the percentage of > + power consumption along the siblings. > + > + SoC (w=1024) > + | > + |-- pkg (w=538) > + | | > + | |-- pd0 (w=231) > + | | > + | `-- pd1 (w=794) > + | > + `-- pd2 (w=486) > + > + Note the sum of weights at the same level are equal to 1024. > + > +* When a power limitation is applied to a node, then it is distributed > + along the children given their weights. For example, if we set a > + power limitation of 3200mW at the 'SoC' root node, the resulting > + tree will be. > + > + SoC (w=1024) <--- power_limit = 3200mW > + | > + |-- pkg (w=538) --> power_limit = 1681mW > + | | > + | |-- pd0 (w=231) --> power_limit = 378mW > + | | > + | `-- pd1 (w=794) --> power_limit = 1303mW > + | > + `-- pd2 (w=486) --> power_limit = 1519mW > + > +==================== > +1.1 Flat description > +==================== > + > +A root node is created and it is the parent of all the nodes. This > +description is the simplest one and it is supposed to give to > +userspace a flat representation of all the devices supporting the > +power limitation without any power limitation distribution. > + > +============================ > +1.2 Hierarchical description > +============================ > + > +The different devices supporting the power limitation are represented > +hierarchically. There is one root node, all intermediate nodes are > +grouping the child nodes which can be intermediate nodes also or real > +devices. > + > +The intermediate nodes aggregate the power information and allows to > +set the power limit given the weight of the nodes. > + > +================ > +2. Userspace API > +================ > + > +As stated in the overview, the DTPM framework is built on top of the > +powercap framework. Thus the sysfs interface is the same, please refer > +to the powercap documentation for further details. > + > + * power_uw: Instantaneous power consumption. If the node is an > + intermediate node, then the power consumption will be the sum of all > + children power consumption. > + > + * max_power_range_uw: The power range resulting of the maximum power > + minus the minimum power. > + > + * name: The name of the node. This is implementation dependant. Even > + if it is not recommended for the userspace, several nodes can have > + the same name. > + > + * constraint_X_name: The name of the constraint. > + > + * constraint_X_max_power_uw: The maximum power limit to be applicable > + to the node. > + > + * constraint_X_power_limit_uw: The power limit to be applied to the > + node. If the value contained in constraint_X_max_power_uw is set, > + the constraint will be removed. How is power_limit_uW different from max_power_uW? > + > + * constraint_X_time_window_us: The meaning of this file will depend > + on the constraint number. > + > +=============== > +2.1 Constraints > +=============== > + > + * Constraint 0: The power limitation is immediately applied, without > + limitation in time. > + > +============= > +3. Kernel API > +============= > + > +============ > +3.1 Overview > +============ > + > +The DTPM framework has no power limiting backend support. It is > +generic and provides a set of API to let the different drivers to > +implement the backend part for the power limitation and create a the create a the -> create a > +power constraints tree. > + > +It is up to the platform to provide the initialization function to > +allocate and link the different nodes of the tree. > + > +A special macro has the role of declaring a node and the corresponding > +initialization function via a description structure. This one contains > +an optional parent field allowing to hook different devices to an > +already existing tree at boot time. > + > +struct dtpm_descr my_descr = { > + .name = "my_name", > + .init = my_init_func, > +}; > + > +DTPM_DECLARE(my_descr); > + > +The nodes of the DTPM tree are described with dtpm structure. The > +steps to add a new power limitable device is done in three steps: > + > + * Allocate the dtpm node > + * Set the power number of the dtpm node > + * Register the dtpm node > + > +The registration of the dtpm node is done with the powercap > +ops. Basically, it must implements the callbacks to get and set the implements -> implement > +power and the limit. > + > +Alternatively, if the node to be inserted is an intermediate one, then > +a simple function to insert it as a future parent is available. > + > +If a device has its power characteristics changing, then the tree must > +be updated with the new power numbers and weights. > + > +================ > +3.2 Nomenclature > +================ > + > + * dtpm_alloc() : Allocate and initialize a dtpm structure > + > + * dtpm_register() : Add the dtpm node to the tree > + > + * dtpm_register_parent() : Add an intermediate node > + > + * dtpm_unregister() : Remove the dtpm node from the tree > + > + * dtpm_update_power() : Update the power characteristics of the dtpm node >