Message ID | 20230607124628.157465-14-ulf.hansson@linaro.org |
---|---|
State | New |
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 p6csp331373rwl; Wed, 7 Jun 2023 05:50:05 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4Y+BdKyX6AU4uwuC85VI/StfbmoY5NrLOGsB/MjthFyCLwtPfQVAgzd7LdJZFyrzh/EgmU X-Received: by 2002:a05:6a00:13a0:b0:653:de9a:d933 with SMTP id t32-20020a056a0013a000b00653de9ad933mr2592827pfg.17.1686142205565; Wed, 07 Jun 2023 05:50:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686142205; cv=none; d=google.com; s=arc-20160816; b=lgTwSU5TaN2jvQ3aw7sS163ZZk/05VKfE8FD8pIy8Kc3+S/8ULz0FT5ux9gADGDgBc 2upVS1GrurAEC9vQcz1Qb0iot9xCoqtBnUPsDIZjb5TbR/vl/+cSUJ6cvgkhIhRAn+Qn ieGNzEc/dmiPNrQmhxQst6s/K0icKyyeH6n03pu4t/7JC2kZ8jpFQCvExjKj+ovEZiwj oR1Jjc2dMD9ERaiMpvG9e3khiZZFW5rvADRTfaG49YwU00jrS+GHAv+ejJWreo+JbHDv ufIDNQF4a8O3i2ac/450ctV1XNCkWm7DFx1vYO/WNK5u50Q8Q45u4ttsmZP9kWW0559U j+MQ== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=hmd8HT7dYpFwRTq0How6UAlKRFjjp2QQNX4mDltPGDc=; b=p8nUzTiQkUOzZGH17GSmC3ANbdrjUX6fSzFv2xDb4vwbeCtbZNu2s64kEGa9LuLB/2 h78XjcG6kHVkIIVHNp/Jv/oHP92T1mN2hftLuimbYd195fq3/TraqtM/+9mZ+8ofqR+S XIj5EXB8Q79p809AUX39+ldrote6mU6JzdMfPz8VGKCbkUL2AKvQWUbUN3QI3OBUpHdn FbbH+MGewJC1fGe7jQtD0m+ohfmHdqjfZ/3+5CrVC4sTxgRMkfdM/G1hxp1AxXUZv5uq CrUllPT3bU/qaRHTk/YBr+ZuDJ0WlA57b+YLOK3vSLLrCeO7MPagH1/lo6Ap/BxOYr9b 9Lzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=HBg+TlFM; 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 15-20020a63020f000000b00543ad8b8807si5197501pgc.826.2023.06.07.05.49.51; Wed, 07 Jun 2023 05:50:05 -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=HBg+TlFM; 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 S239346AbjFGMrw (ORCPT <rfc822;literming00@gmail.com> + 99 others); Wed, 7 Jun 2023 08:47:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241077AbjFGMr0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Jun 2023 08:47:26 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D8961FDD for <linux-kernel@vger.kernel.org>; Wed, 7 Jun 2023 05:47:14 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-4f6148f9679so6776882e87.3 for <linux-kernel@vger.kernel.org>; Wed, 07 Jun 2023 05:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686142032; x=1688734032; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hmd8HT7dYpFwRTq0How6UAlKRFjjp2QQNX4mDltPGDc=; b=HBg+TlFMgB3o6cTaUfYJew1Qay1qLLHcPyGSbprNVTSjMoblHCrw2ugrurnH+Kbw8l IwOFLfw+Qq9upy6zJyu5GVl0exUC0n2iozSCQiUmAKH96nQj4rAm4wIdzJHZqlbpU/8e LqmFvnXGNhsuiVg4HGdKAQpXz5dWxvV8MLeFIkdUfy8EnPHGpU/tZ3y8hRdySi4kI3Ni pyOAK730tqsq/MgHOezVmFrkrstPc4JQZGog3gMwuVwQa0BCnPNqNDEN6wgDZNsWN4uK DOSQZA8ClDAvkIx/j7qgtkhWH9ScHebJJVtbj08nli8fTLgSqfKP/EFhtNQsR3snjyIm UI3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686142032; x=1688734032; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hmd8HT7dYpFwRTq0How6UAlKRFjjp2QQNX4mDltPGDc=; b=UIthONZSePzHG11DRgns1gej9yrU0vIrIsfwastqjpdnUb6B2VbJOyhJUVq1M8qg0c zAs3j4Dj2YuaTj1DIBJAWIWmAN1Wvy5qz2ywvOg95BrzEuBl6YPk1chADhw4pqXO1Y/V X1l4AwUIAXbGyQOsPPyr0NXeIjKm6QyccaR+TFI5ZYlk3uZUx/cjmt8tmsmGiri3kXM5 4mYVefneCvDWfFu9FI6+AH4608cM0jF49BqRcqYmti5wN4jY6ydf11DMHk84LqgbjDD0 RtzPQSbbzMR3BGfFNZ5/tbh501lr65/MXSCEus+5mxGUnMS28IRDoPZH50Qy4kFTtODJ tVgw== X-Gm-Message-State: AC+VfDydWSSzl+fxRO4SAeXBrufOamE235WKxpyZgUzIJvsiCDoRb68X K3GzwmWHC4wCtxnoX+wmP4IAug== X-Received: by 2002:ac2:47eb:0:b0:4f3:87d7:f7a4 with SMTP id b11-20020ac247eb000000b004f387d7f7a4mr2294228lfp.62.1686142032391; Wed, 07 Jun 2023 05:47:12 -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.47.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 05:47:11 -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 13/16] OPP: Extend dev_pm_opp_data with OPP provider support Date: Wed, 7 Jun 2023 14:46:25 +0200 Message-Id: <20230607124628.157465-14-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230607124628.157465-1-ulf.hansson@linaro.org> References: <20230607124628.157465-1-ulf.hansson@linaro.org> 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?1768048249378311037?= X-GMAIL-MSGID: =?utf-8?q?1768048249378311037?= |
Series |
arm_scmi/opp/dvfs: Add generic performance scaling support
|
|
Commit Message
Ulf Hansson
June 7, 2023, 12:46 p.m. UTC
To allow a dynamically added OPP to be coupled with a specific OPP provider
type, let's add a new enum variable in the struct dev_pm_opp_data.
Moreover, let's add support for a DEV_PM_OPP_TYPE_GENPD type, corresponding
to genpd's performance states support.
More precisely, this allows a genpd provider to dynamically add OPPs when a
device gets attached to it, that later can be used by a consumer driver
when it needs to change the performance level for its corresponding device.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/opp/core.c | 19 +++++++++++++++++++
drivers/opp/opp.h | 1 +
include/linux/pm_opp.h | 7 +++++++
3 files changed, 27 insertions(+)
Comments
On 07-06-23, 14:46, Ulf Hansson wrote: > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index 79b4b44ced3e..81a3418e2eaf 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -1112,6 +1112,15 @@ static int _set_opp(struct device *dev, struct opp_table *opp_table, > return ret; > } > > + if (opp->provider == DEV_PM_OPP_TYPE_GENPD) { > + ret = dev_pm_genpd_set_performance_state(dev, opp->level); > + if (ret) { > + dev_err(dev, "Failed to set performance level: %d\n", > + ret); > + return ret; > + } > + } > + I don't like this :) We already have these calls in place from within _set_required_opps(), and we should try to get this done in a way that those calls themselves get the performance state configured.
On Thu, 8 Jun 2023 at 07:34, Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 07-06-23, 14:46, Ulf Hansson wrote: > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > > index 79b4b44ced3e..81a3418e2eaf 100644 > > --- a/drivers/opp/core.c > > +++ b/drivers/opp/core.c > > @@ -1112,6 +1112,15 @@ static int _set_opp(struct device *dev, struct opp_table *opp_table, > > return ret; > > } > > > > + if (opp->provider == DEV_PM_OPP_TYPE_GENPD) { > > + ret = dev_pm_genpd_set_performance_state(dev, opp->level); > > + if (ret) { > > + dev_err(dev, "Failed to set performance level: %d\n", > > + ret); > > + return ret; > > + } > > + } > > + > > I don't like this :) > > We already have these calls in place from within _set_required_opps(), and we > should try to get this done in a way that those calls themselves get the > performance state configured. I was looking at that, but wanted to keep things as simple as possible in the $subject series. The required opps are also different, as it's getting parsed from DT both for the genpd provider and the consumer. The point is, there are more code involved but just _set_required_opps(). For example, _set_performance_state() (which is the one that calls dev_pm_genpd_set_performance_state()) is designed to be used for required opps. Does it really make sense to rework _set_performance_state() so it can be used for this case too, just to avoid another call to dev_pm_genpd_set_performance_state() somewhere in the code? One improvement we can make though, is to add a helper function, "_set_opp_level()", which we call from _set_opp(). This can then replace the call to _set_required_opps() and the code above that I am adding for DEV_PM_OPP_TYPE_GENPD. At least that should keep the code _set_opp() a bit more readable. What do you think? Kind regards Uffe
On 08-06-23, 11:37, Ulf Hansson wrote: > The required opps are also different, as it's getting parsed from DT > both for the genpd provider and the consumer. The point is, there are > more code involved but just _set_required_opps(). > > For example, _set_performance_state() (which is the one that calls > dev_pm_genpd_set_performance_state()) is designed to be used for > required opps. Does it really make sense to rework > _set_performance_state() so it can be used for this case too, just to > avoid another call to dev_pm_genpd_set_performance_state() somewhere > in the code? What we need here, in you case, is really the required-opp thing, without the DT parsing. The genpd will have an OPP table here, and devices (you are adding OPP table dynamically for) shall have the genpd's OPPs as their required OPPs, since for setting OPPs of the device, it is *required* to have OPP of the genpd set too. Just like how it happens with DT. No special handling will be required in dev_pm_opp_set_opp() path in this case and existing code will just work. You just need to set the required-opp tables properly.
On Thu, 8 Jun 2023 at 12:45, Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 08-06-23, 11:37, Ulf Hansson wrote: > > The required opps are also different, as it's getting parsed from DT > > both for the genpd provider and the consumer. The point is, there are > > more code involved but just _set_required_opps(). > > > > For example, _set_performance_state() (which is the one that calls > > dev_pm_genpd_set_performance_state()) is designed to be used for > > required opps. Does it really make sense to rework > > _set_performance_state() so it can be used for this case too, just to > > avoid another call to dev_pm_genpd_set_performance_state() somewhere > > in the code? > > What we need here, in you case, is really the required-opp thing, without the > DT parsing. The genpd will have an OPP table here, and devices (you are adding > OPP table dynamically for) shall have the genpd's OPPs as their required OPPs, > since for setting OPPs of the device, it is *required* to have OPP of the genpd > set too. Just like how it happens with DT. No special handling will be required > in dev_pm_opp_set_opp() path in this case and existing code will just work. You > just need to set the required-opp tables properly. Okay, if I understand your point you want to avoid creating OPPs for each device, but rather coupling them with the genpd provider's OPP table. Right? Note that, there is no such thing as a "required opp" in the SCMI performance protocol case. A device is compatible to use all of the OPPs that its corresponding SCMI performance domain provides. Should we rename the required opp things in the OPP core to better reflect this too? That said, we still need to be able to add OPPs dynamically when not based on DT. The difference would be that we add the OPPs when initializing the genpd provider instead of when attaching the devices. In other words, we still need something along the lines of the new dev_pm_opp_add_dynamic() API that $subject series is introducing, I think. Moreover, to tie the consumer device's OPP table to their genpd provider's OPP table (call it required-opp or whatever), we need another OPP helper function that we can call from the genpd provider's ->attach_dev() callback. Similarly, we need to be able to remove this connection when genpd's ->detach_dev() callback is invoked. I will think of something here. Finally, I want to point out that there is work going on in parallel with this, that is adding performance state support for the ACPI PM domain. The ACPI PM domain, isn't a genpd provider but implements it's own PM domain. The important point is, that it will have its own variant of the dev_pm_genpd_set_performance_state() that we may need to call from the OPP library. Kind regards Uffe
On 08-06-23, 13:45, Ulf Hansson wrote: > Okay, if I understand your point you want to avoid creating OPPs for > each device, but rather coupling them with the genpd provider's OPP > table. Right? Not exactly :) > Note that, there is no such thing as a "required opp" in the SCMI > performance protocol case. A device is compatible to use all of the > OPPs that its corresponding SCMI performance domain provides. Should > we rename the required opp things in the OPP core to better reflect > this too? Not really :) > That said, we still need to be able to add OPPs dynamically when not > based on DT. The difference would be that we add the OPPs when > initializing the genpd provider instead of when attaching the devices. > In other words, we still need something along the lines of the new > dev_pm_opp_add_dynamic() API that $subject series is introducing, I > think. That's fine. > Moreover, to tie the consumer device's OPP table to their genpd > provider's OPP table (call it required-opp or whatever), we need > another OPP helper function that we can call from the genpd provider's > ->attach_dev() callback. Similarly, we need to be able to remove this > connection when genpd's ->detach_dev() callback is invoked. I will > think of something here. Something like set/link/config_required_opp().. > Finally, I want to point out that there is work going on in parallel > with this, that is adding performance state support for the ACPI PM > domain. The ACPI PM domain, isn't a genpd provider but implements it's > own PM domain. The important point is, that it will have its own > variant of the dev_pm_genpd_set_performance_state() that we may need > to call from the OPP library. Okay. Let me explain how structures are linked currently with help of below (badly made) drawing. The 'level' fields are only set for Genpd's OPP entries and not devices. The genpd OPP table normally has only this information, where it presents all the possible level values, separate OPP for each of them. Now the devices don't have `level` set in their OPP table, DT or in C structures. All they have are links for required OPPs, which help us find the required level or performance state for a particular genpd. +-----------------+ +------------------+ | Device A | | GENPD OPP Table | +-----------------+ required-opps +------------------+ required-opps |OPP1: freq: x1 +--------------------+ OPP1: +--------------+ +-----------------+ | level: 1 | | |OPP2: freq: y1 +-----------+ +------------------+ | +-----------------+ | | OPP2: +---------+ | |OPP3: freq: z1 +--------+ +--------+ level: 2 | | | +-----------------+ | +------------------+ | | | | OPP3: +--+ | | | | level: 3 | | | | | +------------------+ | | | +-----------------+ | | OPP4: | | | | | Device B | +-----------+ level: 4 | | | | +-----------------+ +------------------+ | | | |OPP1: freq: x2 +------------------------------------------+ | | +-----------------+ | | |OPP2: freq: y2 +-------------------------------------------------+ | +-----------------+ | |OPP3: freq: z2 +------------------------------------------------------+ +-----------------+ What I am asking you to do now is, create an OPP table for the Genpd first, with OPPs for each possible level. Now the Genpd layer creates the OPP table for Device A, where it won't fill the levels, but all other fields and then use a new API to add required OPPs for the device's OPP, which will point into Genpd's OPP entries. And with that the existing code will work fine without any other modifications. Does this help ? -- viresh
On Fri, 9 Jun 2023 at 07:10, Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 08-06-23, 13:45, Ulf Hansson wrote: > > Okay, if I understand your point you want to avoid creating OPPs for > > each device, but rather coupling them with the genpd provider's OPP > > table. Right? > > Not exactly :) > > > Note that, there is no such thing as a "required opp" in the SCMI > > performance protocol case. A device is compatible to use all of the > > OPPs that its corresponding SCMI performance domain provides. Should > > we rename the required opp things in the OPP core to better reflect > > this too? > > Not really :) I think it may be confusing, but okay, let's leave it as is. > > > That said, we still need to be able to add OPPs dynamically when not > > based on DT. The difference would be that we add the OPPs when > > initializing the genpd provider instead of when attaching the devices. > > In other words, we still need something along the lines of the new > > dev_pm_opp_add_dynamic() API that $subject series is introducing, I > > think. > > That's fine. > > > Moreover, to tie the consumer device's OPP table to their genpd > > provider's OPP table (call it required-opp or whatever), we need > > another OPP helper function that we can call from the genpd provider's > > ->attach_dev() callback. Similarly, we need to be able to remove this > > connection when genpd's ->detach_dev() callback is invoked. I will > > think of something here. > > Something like set/link/config_required_opp().. > > > Finally, I want to point out that there is work going on in parallel > > with this, that is adding performance state support for the ACPI PM > > domain. The ACPI PM domain, isn't a genpd provider but implements it's > > own PM domain. The important point is, that it will have its own > > variant of the dev_pm_genpd_set_performance_state() that we may need > > to call from the OPP library. > > Okay. > > Let me explain how structures are linked currently with help of below (badly > made) drawing. The 'level' fields are only set for Genpd's OPP entries and not > devices. The genpd OPP table normally has only this information, where it > presents all the possible level values, separate OPP for each of them. > > Now the devices don't have `level` set in their OPP table, DT or in C > structures. All they have are links for required OPPs, which help us find the > required level or performance state for a particular genpd. > > +-----------------+ +------------------+ > | Device A | | GENPD OPP Table | > +-----------------+ required-opps +------------------+ required-opps > |OPP1: freq: x1 +--------------------+ OPP1: +--------------+ > +-----------------+ | level: 1 | | > |OPP2: freq: y1 +-----------+ +------------------+ | > +-----------------+ | | OPP2: +---------+ | > |OPP3: freq: z1 +--------+ +--------+ level: 2 | | | > +-----------------+ | +------------------+ | | > | | OPP3: +--+ | | > | | level: 3 | | | | > | +------------------+ | | | > +-----------------+ | | OPP4: | | | | > | Device B | +-----------+ level: 4 | | | | > +-----------------+ +------------------+ | | | > |OPP1: freq: x2 +------------------------------------------+ | | > +-----------------+ | | > |OPP2: freq: y2 +-------------------------------------------------+ | > +-----------------+ | > |OPP3: freq: z2 +------------------------------------------------------+ > +-----------------+ > Thanks for taking the time to explain things further! It's not entirely easy to follow all the things in the OPP library. However, I think you are mixing up the "level" field with the "pstate" field in the struct dev_pm_opp. The pstate field is solely for genpd and the required opps, while level is *generic* for all types of devices. Right? More precisely, _read_opp_key() parses for the "opp-level" property from DT to set the ->level field. Additionally, the generic OPP helpers functions, like dev_pm_opp_get_level(), dev_pm_opp_find_level_exact(), dev_pm_opp_find_level_ceil() allows any type of consumer driver to operate on the level for an OPP for its device. Please have a look at the apple-soc-cpufreq, for example. > > What I am asking you to do now is, create an OPP table for the Genpd first, with > OPPs for each possible level. Now the Genpd layer creates the OPP table for > Device A, where it won't fill the levels, but all other fields and then use a > new API to add required OPPs for the device's OPP, which will point into Genpd's > OPP entries. And with that the existing code will work fine without any other > modifications. > > Does this help ? Well, I think what you propose may be doable, but I fail to understand the benefit of implementing it like that. As I said earlier, there is no such thing as a required OPP for the SCMI performance domain and neither are the OPP tables described in DT. Moreover, as I understand it, we already have the generic "level" to use, why not use it here? Kind regards Uffe
diff --git a/drivers/opp/core.c b/drivers/opp/core.c index 79b4b44ced3e..81a3418e2eaf 100644 --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -1112,6 +1112,15 @@ static int _set_opp(struct device *dev, struct opp_table *opp_table, return ret; } + if (opp->provider == DEV_PM_OPP_TYPE_GENPD) { + ret = dev_pm_genpd_set_performance_state(dev, opp->level); + if (ret) { + dev_err(dev, "Failed to set performance level: %d\n", + ret); + return ret; + } + } + ret = _set_opp_bw(opp_table, opp, dev); if (ret) { dev_err(dev, "Failed to set bw: %d\n", ret); @@ -1155,6 +1164,15 @@ static int _set_opp(struct device *dev, struct opp_table *opp_table, return ret; } + if (opp->provider == DEV_PM_OPP_TYPE_GENPD) { + ret = dev_pm_genpd_set_performance_state(dev, opp->level); + if (ret) { + dev_err(dev, "Failed to set performance level: %d\n", + ret); + return ret; + } + } + ret = _set_required_opps(dev, opp_table, opp, false); if (ret) { dev_err(dev, "Failed to set required opps: %d\n", ret); @@ -1955,6 +1973,7 @@ int _opp_add_v1(struct opp_table *opp_table, struct device *dev, /* populate the opp table */ new_opp->rates[0] = opp->freq; new_opp->level = opp->level; + new_opp->provider = opp->provider; tol = u_volt * opp_table->voltage_tolerance_v1 / 100; new_opp->supplies[0].u_volt = u_volt; new_opp->supplies[0].u_volt_min = u_volt - tol; diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h index b15770b2305e..ee2b3bd89213 100644 --- a/drivers/opp/opp.h +++ b/drivers/opp/opp.h @@ -104,6 +104,7 @@ struct dev_pm_opp { unsigned int pstate; unsigned long *rates; unsigned int level; + enum dev_pm_opp_provider_type provider; struct dev_pm_opp_supply *supplies; struct dev_pm_opp_icc_bw *bandwidth; diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h index 2c6f67736579..4c40199c7728 100644 --- a/include/linux/pm_opp.h +++ b/include/linux/pm_opp.h @@ -26,6 +26,11 @@ enum dev_pm_opp_event { OPP_EVENT_ADJUST_VOLTAGE, }; +enum dev_pm_opp_provider_type { + DEV_PM_OPP_TYPE_NONE = 0, + DEV_PM_OPP_TYPE_GENPD, +}; + /** * struct dev_pm_opp_supply - Power supply voltage/current values * @u_volt: Target voltage in microvolts corresponding to this OPP @@ -97,11 +102,13 @@ struct dev_pm_opp_config { * @level: The performance level for the OPP. * @freq: The clock rate in Hz for the OPP. * @u_volt: The voltage in uV for the OPP. + * @provider: The type of provider for the OPP. */ struct dev_pm_opp_data { unsigned int level; unsigned long freq; unsigned long u_volt; + enum dev_pm_opp_provider_type provider; }; #if defined(CONFIG_PM_OPP)