From patchwork Wed May 12 12:50:09 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 12253471 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=-19.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 A0F45C43461 for ; Wed, 12 May 2021 12:52:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6FA0061026 for ; Wed, 12 May 2021 12:52:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233235AbhELMxq (ORCPT ); Wed, 12 May 2021 08:53:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:52776 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231676AbhELMxD (ORCPT ); Wed, 12 May 2021 08:53:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7E3C461937; Wed, 12 May 2021 12:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620823903; bh=OVSqy/JSKyWtBY0OErxo4l2GIuXyNKw7839n8D1BuyY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SQTmXH4aLBXFpWGx46uYHjS01fSUGZJomKzH6pcv+Rkv47JgYZg+V1RG/pN5sG+cj RJkxxcLnAa0jVvVlBZwKEDV2Qb/tBqB4lcEYgqGWbnkBYfMx1TZHBFOJZU35o2wemv zbtTSFf2+VRa32d/ri6xuNvs22Y9PiTfXwaf9mmYxiPDdHAqz61TzbHJR/tOLl475P awyx55/ZOlKtNuqtpxjRAqm2tYvTs9cjLJrmTry8MPzTGZZL/mrNMdZT/kVEvhCE0Q C9w9jhf6O4cP815hDSQy/Qe4hal18DwXPXwkVQrz9hJtq76Ag6qWNW8zTE/6Hxi+pt 5+FCjf0vtZFEA== Received: by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1lgoKy-0018h7-8A; Wed, 12 May 2021 14:51:40 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , "Jonathan Corbet" , "Rafael J. Wysocki" , Viresh Kumar , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: [PATCH v2 05/40] docs: admin-guide: pm: Use ASCII subset instead of UTF-8 alternate symbols Date: Wed, 12 May 2021 14:50:09 +0200 Message-Id: X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab Acked-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/intel_idle.rst | 4 ++-- Documentation/admin-guide/pm/intel_pstate.rst | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/pm/intel_idle.rst b/Documentation/admin-guide/pm/intel_idle.rst index 89309e1b0e48..c3c4f5d4c806 100644 --- a/Documentation/admin-guide/pm/intel_idle.rst +++ b/Documentation/admin-guide/pm/intel_idle.rst @@ -28,7 +28,7 @@ logical CPU executing it is idle and so it may be possible to put some of the processor's functional blocks into low-power states. That instruction takes two arguments (passed in the ``EAX`` and ``ECX`` registers of the target CPU), the first of which, referred to as a *hint*, can be used by the processor to -determine what can be done (for details refer to Intel Software Developer’s +determine what can be done (for details refer to Intel Software Developer's Manual [1]_). Accordingly, ``intel_idle`` refuses to work with processors in which the support for the ``MWAIT`` instruction has been disabled (for example, via the platform firmware configuration menu) or which do not support that @@ -261,7 +261,7 @@ restrict the range of permissible idle states to the ones with core-level only References ========== -.. [1] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B*, +.. [1] *Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 2B*, https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-2b-manual.html .. [2] *Advanced Configuration and Power Interface (ACPI) Specification*, diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index df29b4f1f219..d881a32acb6d 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -26,7 +26,7 @@ than just an operating frequency or an operating performance point (see the LinuxCon Europe 2015 presentation by Kristen Accardi [1]_ for more information about that). For this reason, the representation of P-states used by ``intel_pstate`` internally follows the hardware specification (for details -refer to Intel Software Developer’s Manual [2]_). However, the ``CPUFreq`` core +refer to Intel Software Developer's Manual [2]_). However, the ``CPUFreq`` core uses frequencies for identifying operating performance points of CPUs and frequencies are involved in the user space interface exposed by it, so ``intel_pstate`` maps its internal representation of P-states to frequencies too @@ -756,7 +756,7 @@ References .. [1] Kristen Accardi, *Balancing Power and Performance in the Linux Kernel*, https://events.static.linuxfound.org/sites/events/files/slides/LinuxConEurope_2015.pdf -.. [2] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide*, +.. [2] *Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3: System Programming Guide*, https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html .. [3] *Advanced Configuration and Power Interface Specification*, From patchwork Wed May 12 12:50:12 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 12253465 X-Patchwork-Delegate: rui.zhang@intel.com 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=-19.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 98C73C43460 for ; Wed, 12 May 2021 12:51:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 647BE613EE for ; Wed, 12 May 2021 12:51:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231510AbhELMxA (ORCPT ); Wed, 12 May 2021 08:53:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:52514 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231302AbhELMwv (ORCPT ); Wed, 12 May 2021 08:52:51 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 358C1613EE; Wed, 12 May 2021 12:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620823902; bh=rGHnZz0sSHB5d7aG1LRrcHqBY8ZGCas2wbdtc/wHeoE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VxhU+vEzUdpzfB0/Gxa/QVlH0MlsDQDVw0HBZGvdYEjSX8PSosKE5ViYj3++hNQfP UhDB06S4PbYz5LngiXFO3NZnuEAuEQCzc65lHh6EU6hQAMx6EK5N5J34bZoA7P+PAp M+agXs6/f/4xK+aaJxaha1Djnq28h/Zy/KubrzLmVqqp4NVP+yOQSfwtX21KfcMMMZ Xc9ut4MytSk4BsjBZ3qMgeUnkU4RNmoJPBlStTCyfnJkrzn7l0K0yNQ7WMejQkIQFa CVDdGz2EL4R6MlRZLllKmlnwwzmxxy+OchQ1kV3FabuBHu+k1Qlvm2rgoDl9Hzcvli gOpmjJxov8/uA== Received: by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1lgoKy-0018hJ-BG; Wed, 12 May 2021 14:51:40 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , "Jonathan Corbet" , Amit Daniel Kachhap , Daniel Lezcano , Lukasz Luba , Viresh Kumar , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: [PATCH v2 08/40] docs: driver-api: thermal: Use ASCII subset instead of UTF-8 alternate symbols Date: Wed, 12 May 2021 14:50:12 +0200 Message-Id: <6866f10fbfbe599448fafa0ca35f1b5b262ce60f.1620823573.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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 Acked-by: Daniel Lezcano --- .../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 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 From patchwork Wed May 12 12:50:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 12253469 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=-19.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 AFEAFC433B4 for ; Wed, 12 May 2021 12:52:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7E91B61175 for ; Wed, 12 May 2021 12:52:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232580AbhELMxV (ORCPT ); Wed, 12 May 2021 08:53:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:52774 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231314AbhELMxD (ORCPT ); Wed, 12 May 2021 08:53:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 214F2615FF; Wed, 12 May 2021 12:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620823903; bh=Ietk1mvu5UTwTosaWKv7VqqVrUmF5h4a2pda5HT4aXM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jZXhQWhUjqDlWBhz6FktXImmQEM3OKSdB1HsSYulHGRKDXCvKyZ8bursTEJCkNIXc dhfzHTiUD/tKWIKnqTgfmgD4fLInwjU095+Y7QfD5NlsF5pFqpSNRUJVqApKp02ZPz ItSJ9nwoiqQkRKZd+VOaT+9YtoHKzUGj0h0NKldgJwiUeEFj5goUZANKOwEMqPEkkn uzJXGOwIoKBQHdv2XacqJdC169zrnJ9GiSYZ5KZDd9OWl2QJ35T/5GVyx9SEiCTnpI ogS9g2dCAgOhgfer4nk5khFIJYwN5npaW8EEFEGMDcKCQPuM7qESKeg991WPC0enwC pYfgVI4YakIdg== Received: by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1lgoKz-0018ig-A9; Wed, 12 May 2021 14:51:41 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , "Jonathan Corbet" , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Srinivas Pandruvada , Sumeet Pawnikar , Zhang Rui , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: [PATCH v2 29/40] docs: power: powercap: powercap.rst: Use ASCII subset instead of UTF-8 alternate symbols Date: Wed, 12 May 2021 14:50:33 +0200 Message-Id: <55d3ee048747fa5ad5f7eeacd4cdc2e3d83927b7.1620823573.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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+00a0 (' '): NO-BREAK SPACE Signed-off-by: Mauro Carvalho Chehab Acked-by: Rafael J. Wysocki --- Documentation/power/powercap/powercap.rst | 210 +++++++++++----------- 1 file changed, 105 insertions(+), 105 deletions(-) diff --git a/Documentation/power/powercap/powercap.rst b/Documentation/power/powercap/powercap.rst index e75d12596dac..c99122e0a1c8 100644 --- a/Documentation/power/powercap/powercap.rst +++ b/Documentation/power/powercap/powercap.rst @@ -34,113 +34,113 @@ Example sysfs interface tree:: /sys/devices/virtual/powercap └──intel-rapl ├──intel-rapl:0 - │   ├──constraint_0_name - │   ├──constraint_0_power_limit_uw - │   ├──constraint_0_time_window_us - │   ├──constraint_1_name - │   ├──constraint_1_power_limit_uw - │   ├──constraint_1_time_window_us - │   ├──device -> ../../intel-rapl - │   ├──energy_uj - │   ├──intel-rapl:0:0 - │   │   ├──constraint_0_name - │   │   ├──constraint_0_power_limit_uw - │   │   ├──constraint_0_time_window_us - │   │   ├──constraint_1_name - │   │   ├──constraint_1_power_limit_uw - │   │   ├──constraint_1_time_window_us - │   │   ├──device -> ../../intel-rapl:0 - │   │   ├──energy_uj - │   │   ├──max_energy_range_uj - │   │   ├──name - │   │   ├──enabled - │   │   ├──power - │   │   │   ├──async - │   │   │   [] - │   │   ├──subsystem -> ../../../../../../class/power_cap - │   │   └──uevent - │   ├──intel-rapl:0:1 - │   │   ├──constraint_0_name - │   │   ├──constraint_0_power_limit_uw - │   │   ├──constraint_0_time_window_us - │   │   ├──constraint_1_name - │   │   ├──constraint_1_power_limit_uw - │   │   ├──constraint_1_time_window_us - │   │   ├──device -> ../../intel-rapl:0 - │   │   ├──energy_uj - │   │   ├──max_energy_range_uj - │   │   ├──name - │   │   ├──enabled - │   │   ├──power - │   │   │   ├──async - │   │   │   [] - │   │   ├──subsystem -> ../../../../../../class/power_cap - │   │   └──uevent - │   ├──max_energy_range_uj - │   ├──max_power_range_uw - │   ├──name - │   ├──enabled - │   ├──power - │   │   ├──async - │   │   [] - │   ├──subsystem -> ../../../../../class/power_cap - │   ├──enabled - │   ├──uevent + │ ├──constraint_0_name + │ ├──constraint_0_power_limit_uw + │ ├──constraint_0_time_window_us + │ ├──constraint_1_name + │ ├──constraint_1_power_limit_uw + │ ├──constraint_1_time_window_us + │ ├──device -> ../../intel-rapl + │ ├──energy_uj + │ ├──intel-rapl:0:0 + │ │ ├──constraint_0_name + │ │ ├──constraint_0_power_limit_uw + │ │ ├──constraint_0_time_window_us + │ │ ├──constraint_1_name + │ │ ├──constraint_1_power_limit_uw + │ │ ├──constraint_1_time_window_us + │ │ ├──device -> ../../intel-rapl:0 + │ │ ├──energy_uj + │ │ ├──max_energy_range_uj + │ │ ├──name + │ │ ├──enabled + │ │ ├──power + │ │ │ ├──async + │ │ │ [] + │ │ ├──subsystem -> ../../../../../../class/power_cap + │ │ └──uevent + │ ├──intel-rapl:0:1 + │ │ ├──constraint_0_name + │ │ ├──constraint_0_power_limit_uw + │ │ ├──constraint_0_time_window_us + │ │ ├──constraint_1_name + │ │ ├──constraint_1_power_limit_uw + │ │ ├──constraint_1_time_window_us + │ │ ├──device -> ../../intel-rapl:0 + │ │ ├──energy_uj + │ │ ├──max_energy_range_uj + │ │ ├──name + │ │ ├──enabled + │ │ ├──power + │ │ │ ├──async + │ │ │ [] + │ │ ├──subsystem -> ../../../../../../class/power_cap + │ │ └──uevent + │ ├──max_energy_range_uj + │ ├──max_power_range_uw + │ ├──name + │ ├──enabled + │ ├──power + │ │ ├──async + │ │ [] + │ ├──subsystem -> ../../../../../class/power_cap + │ ├──enabled + │ ├──uevent ├──intel-rapl:1 - │   ├──constraint_0_name - │   ├──constraint_0_power_limit_uw - │   ├──constraint_0_time_window_us - │   ├──constraint_1_name - │   ├──constraint_1_power_limit_uw - │   ├──constraint_1_time_window_us - │   ├──device -> ../../intel-rapl - │   ├──energy_uj - │   ├──intel-rapl:1:0 - │   │   ├──constraint_0_name - │   │   ├──constraint_0_power_limit_uw - │   │   ├──constraint_0_time_window_us - │   │   ├──constraint_1_name - │   │   ├──constraint_1_power_limit_uw - │   │   ├──constraint_1_time_window_us - │   │   ├──device -> ../../intel-rapl:1 - │   │   ├──energy_uj - │   │   ├──max_energy_range_uj - │   │   ├──name - │   │   ├──enabled - │   │   ├──power - │   │   │   ├──async - │   │   │   [] - │   │   ├──subsystem -> ../../../../../../class/power_cap - │   │   └──uevent - │   ├──intel-rapl:1:1 - │   │   ├──constraint_0_name - │   │   ├──constraint_0_power_limit_uw - │   │   ├──constraint_0_time_window_us - │   │   ├──constraint_1_name - │   │   ├──constraint_1_power_limit_uw - │   │   ├──constraint_1_time_window_us - │   │   ├──device -> ../../intel-rapl:1 - │   │   ├──energy_uj - │   │   ├──max_energy_range_uj - │   │   ├──name - │   │   ├──enabled - │   │   ├──power - │   │   │   ├──async - │   │   │   [] - │   │   ├──subsystem -> ../../../../../../class/power_cap - │   │   └──uevent - │   ├──max_energy_range_uj - │   ├──max_power_range_uw - │   ├──name - │   ├──enabled - │   ├──power - │   │   ├──async - │   │   [] - │   ├──subsystem -> ../../../../../class/power_cap - │   ├──uevent + │ ├──constraint_0_name + │ ├──constraint_0_power_limit_uw + │ ├──constraint_0_time_window_us + │ ├──constraint_1_name + │ ├──constraint_1_power_limit_uw + │ ├──constraint_1_time_window_us + │ ├──device -> ../../intel-rapl + │ ├──energy_uj + │ ├──intel-rapl:1:0 + │ │ ├──constraint_0_name + │ │ ├──constraint_0_power_limit_uw + │ │ ├──constraint_0_time_window_us + │ │ ├──constraint_1_name + │ │ ├──constraint_1_power_limit_uw + │ │ ├──constraint_1_time_window_us + │ │ ├──device -> ../../intel-rapl:1 + │ │ ├──energy_uj + │ │ ├──max_energy_range_uj + │ │ ├──name + │ │ ├──enabled + │ │ ├──power + │ │ │ ├──async + │ │ │ [] + │ │ ├──subsystem -> ../../../../../../class/power_cap + │ │ └──uevent + │ ├──intel-rapl:1:1 + │ │ ├──constraint_0_name + │ │ ├──constraint_0_power_limit_uw + │ │ ├──constraint_0_time_window_us + │ │ ├──constraint_1_name + │ │ ├──constraint_1_power_limit_uw + │ │ ├──constraint_1_time_window_us + │ │ ├──device -> ../../intel-rapl:1 + │ │ ├──energy_uj + │ │ ├──max_energy_range_uj + │ │ ├──name + │ │ ├──enabled + │ │ ├──power + │ │ │ ├──async + │ │ │ [] + │ │ ├──subsystem -> ../../../../../../class/power_cap + │ │ └──uevent + │ ├──max_energy_range_uj + │ ├──max_power_range_uw + │ ├──name + │ ├──enabled + │ ├──power + │ │ ├──async + │ │ [] + │ ├──subsystem -> ../../../../../class/power_cap + │ ├──uevent ├──power - │   ├──async - │   [] + │ ├──async + │ [] ├──subsystem -> ../../../../class/power_cap ├──enabled └──uevent