Message ID | 20230607124628.157465-1-ulf.hansson@linaro.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:3046:b0:115:7a1d:dabb with SMTP id p6csp331132rwl; Wed, 7 Jun 2023 05:49:41 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6SS1i4maplU7ayJqFEeOVEx6dR8gR5CVBqyUWoFUBi1xrzhSWALlqqofdQdqmDD2EtqAYU X-Received: by 2002:a05:6a20:7484:b0:10d:f812:e4b5 with SMTP id p4-20020a056a20748400b0010df812e4b5mr2108078pzd.35.1686142180828; Wed, 07 Jun 2023 05:49:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686142180; cv=none; d=google.com; s=arc-20160816; b=tfh5t1TBl+CfcXFuCr7a5fME+vgKdcJycMPmw1XqCErDhszvSk2stXhJ+yz+Sbcdka sg/csDqDERBfgBdf1tetKcVaOA9mNCnFVkoFiZk97Xbmopn7vBJfrKcd+kHOcxyAoiU+ s4IAgeCF9QRoTYoxMCa1CQ9DPY8diONDPoczO2HteXZmxBRuYu4oubskV/Jyuj8WaOm2 xdRwVp0UWpFn5jn3Hcgk7pFAUzD2SYDVY11XqH1q4cBG20hbnbQXyv3hB8C9+gDuWgl9 rIlsBDWzZo6FZDDiQxWn4xpPiMjbWzKu+ynC2PXvto2lUyinZcyweIERXncdbasywOKV PnNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=M8pnkreZK5j88F8rmiuOcLlKy8lqP5lqOcKSXd8yI1k=; b=F71XgyAacwgDlA8keLl3/dNlYv3SBd2cRMA5sRLiDGs45nrZHA+zgE8n3krkUm5O+N nBWWPla5MLxItrqJ255COjQhgFqj2GnEYMSZ0EgUOxvAoeDW8meuEHKo619MASo1gIVX Yo9Dh7cDI6Zb/0ksqAxaag7b19bYFv1R+4/iS18lmtsVVwzeYWuBgONutLoVFObIRjWK 58mt5MqNZsqqDMfXND4ka9O0qpmzLAcHWc4z93HFU+LErwrJlyaeMmL3DhLXIg7jorUs v5yzYVwDbfK/j3oGtbySr9FIp/hkCBoMGVN2Ex/efAYQIYAjTfocfLS7gI+YRvdXFGUS cBrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=H9L811FP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 189-20020a6206c6000000b00652dc29b5dasi8604300pfg.178.2023.06.07.05.49.25; Wed, 07 Jun 2023 05:49:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=H9L811FP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240944AbjFGMrC (ORCPT <rfc822;literming00@gmail.com> + 99 others); Wed, 7 Jun 2023 08:47:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240352AbjFGMq7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Jun 2023 08:46:59 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5381E198B for <linux-kernel@vger.kernel.org>; Wed, 7 Jun 2023 05:46:56 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4f4db9987f8so663483e87.1 for <linux-kernel@vger.kernel.org>; Wed, 07 Jun 2023 05:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686142014; x=1688734014; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=M8pnkreZK5j88F8rmiuOcLlKy8lqP5lqOcKSXd8yI1k=; b=H9L811FPk662EGACYc/PJ+kN6yEorNVz0rgURrxSVptroj+V7NyicTpne8Shst6xcV NDdRr58V3tjfCyAwB75urA1GtiaWVjdSSmxFEyxoUu7ZASWnRzTRwRbEMV4olpirRcp2 4JV7WIqhQvn2afszGT/s5jPNlOOKN2ORKMeOPJesMzePpKquDh24fkHJc8B1qSduqvsq BdsqIl2RRLELZXhiIOUNJYq6lLqJnAXI7XMRvZ4CkOiKsXRx+L4Paw1dCFpP6BOAKj2J r3dNvFGNj7rhIOE8dlGWQmjNNjxvEDqsQGP9sYWpILZ1OP8+be6ZrobhLzg9a7j5OuEe zIhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686142014; x=1688734014; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=M8pnkreZK5j88F8rmiuOcLlKy8lqP5lqOcKSXd8yI1k=; b=BPuLuiPggiiLAU4PaOVaJheqVC18tJ5ZfIyjyX/j8jWOjZuTwqwU90UXdOPncvbEj1 vK7MtSMyPe/pujA9b+YUwNYc971Ha8DntR81wlcN0yBST9pi0MDjNyPkIN7nPb3dYmtA G7d3/OOmhQ+4v8ZWLGGhj2UD5yFar9/aTgCSy4Dl1PAhdrrgWagmu7DD7FLgkQPxB/hW Qvfp93PG7Q5ToBABUTlWFPUUI9rJShv5T65sZGLJy8QcI82KnGC/vVMXn6gcN/We4v0F 5MnzN22EteFrhHzcIxWUBj0lkGf9aUAimiNUqBfvUbvLRNx46ezY3NxqXxpw58j0w5Bx Z9Bg== X-Gm-Message-State: AC+VfDwj4rQIWk4pywMknTZnOCjGXzXvaSxpRBiyyx7eE9izV+KOaAN3 ZXh9z1i9QuVChBdT5kY8oQR+xw== X-Received: by 2002:a05:6512:402:b0:4f3:89e6:23c0 with SMTP id u2-20020a056512040200b004f389e623c0mr1760313lfk.31.1686142014522; Wed, 07 Jun 2023 05:46:54 -0700 (PDT) Received: from uffe-tuxpro14.. (h-94-254-63-18.NA.cust.bahnhof.se. [94.254.63.18]) by smtp.gmail.com with ESMTPSA id z7-20020a19f707000000b004f4b3e9e0cesm1781708lfe.297.2023.06.07.05.46.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 05:46:53 -0700 (PDT) From: Ulf Hansson <ulf.hansson@linaro.org> To: Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org> Cc: Nikunj Kela <nkela@quicinc.com>, Prasad Sodagudi <psodagud@quicinc.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Ulf Hansson <ulf.hansson@linaro.org>, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH 00/16] arm_scmi/opp/dvfs: Add generic performance scaling support Date: Wed, 7 Jun 2023 14:46:12 +0200 Message-Id: <20230607124628.157465-1-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768048223199734616?= X-GMAIL-MSGID: =?utf-8?q?1768048223199734616?= |
Series |
arm_scmi/opp/dvfs: Add generic performance scaling support
|
|
Message
Ulf Hansson
June 7, 2023, 12:46 p.m. UTC
The current SCMI performance scaling support is limited to cpufreq. This series extends the support, so it can be used for all kind of devices and not only for CPUs. The changes are spread over a couple of different subsystems, although the changes that affects the other subsystems than the arm_scmi directory are mostly smaller. The series is based upon v6.4-rc5. That said, let's figure out on how to best move forward with this. I am of course happy to help in any way. Note that, so far this is only be tested on the Qemu virt platform with Optee running an SCMI server. If you want some more details about my test setup, I am certainly open to share that with you! Looking forward to get your feedback! Kind regards Ulf Hansson Ulf Hansson (16): firmware: arm_scmi: Extend perf protocol ops to get number of domains firmware: arm_scmi: Extend perf protocol ops to get the name of a domain firmware: arm_scmi: Extend perf protocol ops to inform of set level support cpufreq: scmi: Prepare to move OF parsing of domain-id to cpufreq firmware: arm_scmi: Align perf ops to use domain-id as in-parameter firmware: arm_scmi: Drop redundant ->device_domain_id() from perf ops cpufreq: scmi: Avoid one OF parsing in scmi_get_sharing_cpus() PM: domains: Allow genpd providers to manage OPP tables directly by its FW dt-bindings: firmware: arm,scmi: Extend bindings for protocol@13 firmware: arm_scmi: Add the SCMI performance domain OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility OPP: Extend dev_pm_opp_data with performance level OPP: Extend dev_pm_opp_data with OPP provider support firmware: arm_scmi: Simplify error path in scmi_dvfs_device_opps_add() firmware: arm_scmi: Extend perf support with OPP from genpd providers firmware: arm_scmi: Add generic OPP support to the SCMI performance domain .../bindings/firmware/arm,scmi.yaml | 4 +- drivers/base/power/domain.c | 11 +- drivers/cpufreq/scmi-cpufreq.c | 40 ++-- drivers/firmware/arm_scmi/Kconfig | 12 ++ drivers/firmware/arm_scmi/Makefile | 1 + drivers/firmware/arm_scmi/perf.c | 81 ++++---- drivers/firmware/arm_scmi/scmi_perf_domain.c | 189 ++++++++++++++++++ drivers/opp/core.c | 69 ++++++- drivers/opp/of.c | 11 +- drivers/opp/opp.h | 3 +- include/linux/pm_domain.h | 5 + include/linux/pm_opp.h | 27 +++ include/linux/scmi_protocol.h | 14 +- 13 files changed, 388 insertions(+), 79 deletions(-) create mode 100644 drivers/firmware/arm_scmi/scmi_perf_domain.c
Comments
On Wed, Jun 07, 2023 at 02:46:12PM +0200, Ulf Hansson wrote: > The current SCMI performance scaling support is limited to cpufreq. This series > extends the support, so it can be used for all kind of devices and not only for > CPUs. > > The changes are spread over a couple of different subsystems, although the > changes that affects the other subsystems than the arm_scmi directory are > mostly smaller. The series is based upon v6.4-rc5. That said, let's figure out > on how to best move forward with this. I am of course happy to help in any way. > > Note that, so far this is only be tested on the Qemu virt platform with Optee > running an SCMI server. If you want some more details about my test setup, I am > certainly open to share that with you! > > Looking forward to get your feedback! > Hi Ulf, thanks for this first of all. I'll have a look at this properly in the next weeks, in the meantime just a small minor remark after having had a quick look. You expose a few new perf_ops to fit your needs and in fact PERF was still not exposing those data for (apparent) lack of users needing those. (and/or historical reason I think) My concern is that this would lead to a growing number of ops as soon as more data will be needed by future users; indeed other protocols do expose more data but use a different approach: instead of custom ops they let the user access a common static info structure like + int (*num_domains_get)(const struct scmi_protocol_handle *ph); + const struct scmi_perf_dom_info __must_check *(*info_get) + (const struct scmi_protocol_handle *ph, u32 domain); and expose the related common info struct in scmi_protocol.h too. Another reason to stick to this aproach would be consistency with other protos (even though I think PERF is not the only lacking info_get) Now, since really there was already a hidden user for this perf data (that would be me :P ... in terms of an unpublished SCMI test-driver), I happen to have a tested patch that just expose those 2 above ops and exports scmi_perf_dom_info and related structures to scmi_protocol.h If you (and Sudeep) agree with this approach of limiting the number of exposed ops in favour of sharing upfront some static info data, I can quickly cleanup and post this patch for you to pick it up in your next iteration. (really I'd have more conversion of this kind also for other remaining protos but these are unrelated to your series and I'd post it later) Thanks, Cristian
On Wed, 7 Jun 2023 at 16:43, Cristian Marussi <cristian.marussi@arm.com> wrote: > > On Wed, Jun 07, 2023 at 02:46:12PM +0200, Ulf Hansson wrote: > > The current SCMI performance scaling support is limited to cpufreq. This series > > extends the support, so it can be used for all kind of devices and not only for > > CPUs. > > > > The changes are spread over a couple of different subsystems, although the > > changes that affects the other subsystems than the arm_scmi directory are > > mostly smaller. The series is based upon v6.4-rc5. That said, let's figure out > > on how to best move forward with this. I am of course happy to help in any way. > > > > Note that, so far this is only be tested on the Qemu virt platform with Optee > > running an SCMI server. If you want some more details about my test setup, I am > > certainly open to share that with you! > > > > Looking forward to get your feedback! > > > > Hi Ulf, > > thanks for this first of all. > > I'll have a look at this properly in the next weeks, in the meantime > just a small minor remark after having had a quick look. > > You expose a few new perf_ops to fit your needs and in fact PERF was > still not exposing those data for (apparent) lack of users needing > those. (and/or historical reason I think) > > My concern is that this would lead to a growing number of ops as soon as > more data will be needed by future users; indeed other protocols do > expose more data but use a different approach: instead of custom ops > they let the user access a common static info structure like > > > + int (*num_domains_get)(const struct scmi_protocol_handle *ph); > + const struct scmi_perf_dom_info __must_check *(*info_get) > + (const struct scmi_protocol_handle *ph, u32 domain); > > and expose the related common info struct in scmi_protocol.h too. > Another reason to stick to this aproach would be consistency with other > protos (even though I think PERF is not the only lacking info_get) > > Now, since really there was already a hidden user for this perf data > (that would be me :P ... in terms of an unpublished SCMI test-driver), > I happen to have a tested patch that just expose those 2 above ops and > exports scmi_perf_dom_info and related structures to scmi_protocol.h > > If you (and Sudeep) agree with this approach of limiting the number of > exposed ops in favour of sharing upfront some static info data, I can > quickly cleanup and post this patch for you to pick it up in your next > iteration. I think your suggestions make perfect sense to me too. While I was adding the new ops in scmi_perf_proto_ops, I was merely trying to get inspiration from the scmi_power_proto_ops, it seems like those need an update too. Although, there is no need for you to send a patch for "perf" at this moment - as this piece of code is easy for me to put together myself. I will simply replace a few of the patches in the series with a new one, no problem at all. > > (really I'd have more conversion of this kind also for other remaining > protos but these are unrelated to your series and I'd post it later) Yes, that can be handled separately, and I leave that for you to manage. Kind regards Uffe