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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4AA0AC7EE25 for ; Thu, 8 Jun 2023 09:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qol02yFOWmSaFH1qhncwRVT0kmkE3QYbNlQt7P5xhng=; b=fQjvV9LMtY3tEY xdkTXzfehnFB+wQrIjpsY+G5wNyXy1YMLGxtO4iyKOO8Bpy3HiBNXErqxcHNIAT2j6BGhkJcaIvhs KcfBiH2T59OueVWd96fQTZvm2LiwNbXDzVIJHczR65F7SpMQrcReCLfXCNSfFHFvyMjuwseCBcl7X 3h477AYef1UcuZhTieAKZ+K3OV0BMXkqyapBt8LZSluITzqVK86kR0mDJkULdONHQc8Iwkg/Cz4NM P5m17Glwp5yyn+JNV+HdWxK2X778dx7lZbLJw4BMIkBxCanwwA3mGTIeVzBQMlwA/3Oc0MeEnoJvg kSLOsI5s3DIRgJom0kfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q7C5S-008iKg-19; Thu, 08 Jun 2023 09:37:46 +0000 Received: from mail-yw1-x1132.google.com ([2607:f8b0:4864:20::1132]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q7C5P-008iKC-2e for linux-arm-kernel@lists.infradead.org; Thu, 08 Jun 2023 09:37:45 +0000 Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-56ca07b34b1so3384157b3.0 for ; Thu, 08 Jun 2023 02:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686217062; x=1688809062; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=k0aUfso+mqed718DXVZBOh7dWuv36gH3PMUsz0/Om4Y=; b=RR9fneaGbSjT8vSD0NNMv3dAoiwDN/Po6A7iO6KQqhAtQV7KeeXJIdW01wkDjczV27 S/Q85c+80/41rffy1DjN7lKodqzjmCo+scaeyuBhQSs7G0D6JYcIhss3GXHW8imXsP60 bg3KfGqWUsPQn8WY+lmaHOxAYItdjVdfOJWlY++3ZPY0woVVvgKhG00KB9jjtr1dpdTy bGJ5T5sDUJYnSMHNaNhCI4TR09T4Q3xpXhK8/uDmJ4+hB0p/aZEP4dwRe/PQJRoo6Jaq PXw5SSF77ZLkdzz5X+Ow9AUKnE21QtyvkHN4Jq55zrDNLiNIuztFDugBBeQpmWHG77O+ 1LMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686217062; x=1688809062; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=k0aUfso+mqed718DXVZBOh7dWuv36gH3PMUsz0/Om4Y=; b=Xh3S0kz4sHbTfEt5q/jzv608JRCYzFOFXMz1LodEMcGRv3NC0HaF+ujvLxqlMW6nks At5gQJPrlXzukhsFKhUiKmsUAFTd7YfpCuZEOAtfKAfcVhRYsE2N9z6GSOhKW8w7UTNZ dnrDgw9qh7Ey1TY3H6tAOQgaxqlyX6Zfxw1oHLKIgnp/ZL1ET5Dt9pMnEzy6u7s/uJWx ULmHzasmRFLqasNXEepAxuwz4ifuvIXAUeo0H2HUtms9w4p5ef+wR0R+85G/gxuC08xI +AutMhGfs1Mof33VPqi2tOyVp/BPW7L3LpLpsJC2DPLxEo+eI9U6gzU32mAFv4iv4qMh Sp6Q== X-Gm-Message-State: AC+VfDwa8L4YmQ0JemZZmDur9a7s36OiWzPTRB8xn91uo5Ms2sH4u1Je s4Ba9oXwyRI9xxRECZQSgyauP8goVtwE5g3GObIs0w== X-Google-Smtp-Source: ACHHUZ7ax+5DTFnXlFyad+qoF5ItYOEatii5YFpBjAQeo0J9NB8fvXLq0abd1Ja5JDM2gGgJeN3c9yi24RybtdjhXmk= X-Received: by 2002:a81:5b8a:0:b0:561:e724:eb3 with SMTP id p132-20020a815b8a000000b00561e7240eb3mr9721264ywb.17.1686217062552; Thu, 08 Jun 2023 02:37:42 -0700 (PDT) MIME-Version: 1.0 References: <20230607124628.157465-1-ulf.hansson@linaro.org> <20230607124628.157465-14-ulf.hansson@linaro.org> <20230608053446.ngoxh7zo7drnr32z@vireshk-i7> In-Reply-To: <20230608053446.ngoxh7zo7drnr32z@vireshk-i7> From: Ulf Hansson Date: Thu, 8 Jun 2023 11:37:06 +0200 Message-ID: Subject: Re: [PATCH 13/16] OPP: Extend dev_pm_opp_data with OPP provider support To: Viresh Kumar Cc: Sudeep Holla , Cristian Marussi , Viresh Kumar , Nishanth Menon , Stephen Boyd , Nikunj Kela , Prasad Sodagudi , Alexandre Torgue , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230608_023743_884363_11BCB47B X-CRM114-Status: GOOD ( 21.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On Thu, 8 Jun 2023 at 07:34, Viresh Kumar 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel