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=-8.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,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 9A690C4363C for ; Thu, 8 Oct 2020 13:42:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 59A2420754 for ; Thu, 8 Oct 2020 13:42:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730372AbgJHNmH (ORCPT ); Thu, 8 Oct 2020 09:42:07 -0400 Received: from foss.arm.com ([217.140.110.172]:58262 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725871AbgJHNmF (ORCPT ); Thu, 8 Oct 2020 09:42:05 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5A55C1063; Thu, 8 Oct 2020 06:42:04 -0700 (PDT) Received: from localhost (unknown [10.1.199.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EDFF33F71F; Thu, 8 Oct 2020 06:42:03 -0700 (PDT) Date: Thu, 8 Oct 2020 14:42:02 +0100 From: Ionela Voinescu To: Nicola Mazzucato Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org, daniel.lezcano@linaro.org, chris.redpath@arm.com, morten.rasmussen@arm.com Subject: Re: [PATCH v2 1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Message-ID: <20201008134153.GA20268@arm.com> References: <20200924095347.32148-1-nicola.mazzucato@arm.com> <20200924095347.32148-2-nicola.mazzucato@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200924095347.32148-2-nicola.mazzucato@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi guys, On Thursday 24 Sep 2020 at 10:53:46 (+0100), Nicola Mazzucato wrote: [..] > diff --git a/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml > new file mode 100644 > index 000000000000..c7a577236cd6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml > @@ -0,0 +1,48 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/cpu-perf-dependencies.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: CPU Performance Dependencies > + > +maintainers: > + - Nicola Mazzucato > + > +description: |+ > + This optional node provides information to OSPM of cpu performance > + dependencies. > + Each list represents a set of CPUs which have performance level > + dependencies and can assumed to be roughly at the same performance > + level coordinated by hardware and/or firmware. > + Example: Describing CPUs in the same clock domain. I'm continuing here a conversation started in v1 on the characteristics of cpu-perf-dependencies and whether this binding actually describes the hardware. In the way I see this, the answer is clearly yes and it is information that we need in the device tree, beyond the presence of SCMI as cpufreq driver, and beyond the way it will be consumed by EAS/thermal/etc. I link this to whether software will do the aggregation of per CPU information in establishing the next frequency to be requested from the driver/hardware for all dependent CPUs, or whether hardware is able to receive the per CPU information on different channels and do the aggregation itself. This software aggregation is the typical way currently supported in cpufreq, but hardware aggregation will be needed the more we see hardware features for performance/power control. But support for hardware aggregation involves having per-cpu channels to convey the frequency request for that CPU. But currently the device tree only gives us the ability to describe the information to be used for sending frequency requests and as a result the kernel considers CPUs as dependent only if they use the same controls for those CPUs. So we currently can have hardware aggregation, but we lose all information about what CPUs actually ended up having the same frequency, because they are actually using the same clocks. Therefore this new binding is needed for when hardware/firmware is better equipped to make a decision about the clock rate for a group of CPUs, when information is given about each CPU. The usefulness comes from informing the software that some CPUs will have the same clock and therefore it does describe a hardware characteristic of the system. In some cases counters will help observe what was the frequency that was eventually granted by hardware. Knowing what CPUs actually use the same clock is very useful for the scheduler (EAS, frequency invariance) and thermal. Hope it helps, Ionela. 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=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,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 BDCD3C4363A for ; Thu, 8 Oct 2020 13:44:03 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4A6D720782 for ; Thu, 8 Oct 2020 13:44:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="s+6vnpjc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A6D720782 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yUBV8ouRG0PHFvGsezzSzGgWqzSipdoCCm+DY58D0aA=; b=s+6vnpjc7Ah++cFsGxBPCW2Aj VC8d0iuCSAb0Xb3Xa0u9gzglVKIMTvgYW8z50n05dpEQD01jG/5uUweMY/gOJEEDPdcQstYQWx8kd Rd0H6qtY7KB4AU5bT1QV96VjJFdm+VXft4MQv9VmmJ67kUrPgMKz4ZLlpqlBINrsTZ+4PAD9ITy02 jxifgilLMSWjwBnXVkbYuBiLg1ArrA+k7ohiGk79uV62hK9IoT6plM3210Y2wj4HbZHg09nIMeag6 2wYxl9Tqbi8iqZbb0gt0cZC+/Z73Wn9vFYAJXVcCEORq1twzuizpqQzooiRMNAPRpLpu9x133mYHL mwFu4lkig==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQWBQ-0003yB-DP; Thu, 08 Oct 2020 13:42:12 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQWBN-0003xc-PZ for linux-arm-kernel@lists.infradead.org; Thu, 08 Oct 2020 13:42:10 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5A55C1063; Thu, 8 Oct 2020 06:42:04 -0700 (PDT) Received: from localhost (unknown [10.1.199.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EDFF33F71F; Thu, 8 Oct 2020 06:42:03 -0700 (PDT) Date: Thu, 8 Oct 2020 14:42:02 +0100 From: Ionela Voinescu To: Nicola Mazzucato Subject: Re: [PATCH v2 1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Message-ID: <20201008134153.GA20268@arm.com> References: <20200924095347.32148-1-nicola.mazzucato@arm.com> <20200924095347.32148-2-nicola.mazzucato@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200924095347.32148-2-nicola.mazzucato@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201008_094209_921096_987B7258 X-CRM114-Status: GOOD ( 20.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, linux-pm@vger.kernel.org, vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, sudeep.holla@arm.com, chris.redpath@arm.com, morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi guys, On Thursday 24 Sep 2020 at 10:53:46 (+0100), Nicola Mazzucato wrote: [..] > diff --git a/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml > new file mode 100644 > index 000000000000..c7a577236cd6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml > @@ -0,0 +1,48 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/cpu-perf-dependencies.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: CPU Performance Dependencies > + > +maintainers: > + - Nicola Mazzucato > + > +description: |+ > + This optional node provides information to OSPM of cpu performance > + dependencies. > + Each list represents a set of CPUs which have performance level > + dependencies and can assumed to be roughly at the same performance > + level coordinated by hardware and/or firmware. > + Example: Describing CPUs in the same clock domain. I'm continuing here a conversation started in v1 on the characteristics of cpu-perf-dependencies and whether this binding actually describes the hardware. In the way I see this, the answer is clearly yes and it is information that we need in the device tree, beyond the presence of SCMI as cpufreq driver, and beyond the way it will be consumed by EAS/thermal/etc. I link this to whether software will do the aggregation of per CPU information in establishing the next frequency to be requested from the driver/hardware for all dependent CPUs, or whether hardware is able to receive the per CPU information on different channels and do the aggregation itself. This software aggregation is the typical way currently supported in cpufreq, but hardware aggregation will be needed the more we see hardware features for performance/power control. But support for hardware aggregation involves having per-cpu channels to convey the frequency request for that CPU. But currently the device tree only gives us the ability to describe the information to be used for sending frequency requests and as a result the kernel considers CPUs as dependent only if they use the same controls for those CPUs. So we currently can have hardware aggregation, but we lose all information about what CPUs actually ended up having the same frequency, because they are actually using the same clocks. Therefore this new binding is needed for when hardware/firmware is better equipped to make a decision about the clock rate for a group of CPUs, when information is given about each CPU. The usefulness comes from informing the software that some CPUs will have the same clock and therefore it does describe a hardware characteristic of the system. In some cases counters will help observe what was the frequency that was eventually granted by hardware. Knowing what CPUs actually use the same clock is very useful for the scheduler (EAS, frequency invariance) and thermal. Hope it helps, Ionela. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel