Message ID | 20230214173145.2482651-7-konrad.dybcio@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp3120521wrn; Tue, 14 Feb 2023 10:02:10 -0800 (PST) X-Google-Smtp-Source: AK7set88e2KoYbmp2GKlG2VXGQr1WeJ8rQbgfuM3n/Oc1fBDuk0vZ6pibsXuYWgRdCCOdeo4fWDf X-Received: by 2002:a17:903:2446:b0:198:fca8:2108 with SMTP id l6-20020a170903244600b00198fca82108mr4308907pls.44.1676397730071; Tue, 14 Feb 2023 10:02:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676397730; cv=none; d=google.com; s=arc-20160816; b=VaW8F4gLTMJFO8bCaiMygsyzJPYf+JjYzKpBBlVq6P6RtFUHZG3BqNGDEWa1gHEdrp hVvHicX7DAnm1qdjGREfMqeD6k0z5LHGZhoSu9QOrgzunMr6rCVFlddM0BtdPsW3aTem 6KKXKc7NuDrX51Y5ipTiRX3yHU3UStb1JXUFFTjsjZeVoqNFKavHwnnS/UcnZ1OcQYJ8 tvhCe/utIomfnrOjJRg4iSBxM+td7NnGvEFB33gh2R/h1pdWqQ+Wr+CAQ/yNH7NhxHP1 RxT80zddMuu3JszB5LH1PT3d4TOFg2U9yVeQ+gNHR5QYHeRS0Pd27FrtBt5ERL3F1kL6 k1Pg== 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=aCCbSlMjNx5L3JbI+yxmCqJTM703drqGHbbH/KoYNcE=; b=iuU/dT9DDYDv4pJhUE1EUXmLTziMk2bInkIobRde/Zpespweks28aRaN8UqwdwNh4d vu8yrUADhCd6LEeq2AMbPOjbyku9sLc8/HmZ2iaDq/MG3pQBJNHeNtPo6o8dPD8inJJS rtPPPflMhh7h0vwMaj6B+kmM3E9f6vSAoRMU1JCFZ/u3m3+iDQeOouSlpu6l6EVBhl8z 5FqzPtWWRq5AVzboYHPoCiQ988rkgEoRZq73W9vJFK/CTJe+K1o5eKplRPMmk6+H9OLS A/HAWpS+AeDbt6H/nKSxldwOYjnjaiEe442cCxYJTYWZ5E/ibkWxraOtU64TaUZJbG8X W8KA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="UB/rfIQ8"; 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 x17-20020a170902e05100b0019a90edaf7asi7884183plx.217.2023.02.14.10.01.57; Tue, 14 Feb 2023 10:02:10 -0800 (PST) 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="UB/rfIQ8"; 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 S232195AbjBNRc2 (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Tue, 14 Feb 2023 12:32:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231359AbjBNRcW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Feb 2023 12:32:22 -0500 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA64E2E806 for <linux-kernel@vger.kernel.org>; Tue, 14 Feb 2023 09:32:12 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id dz21so6457157edb.13 for <linux-kernel@vger.kernel.org>; Tue, 14 Feb 2023 09:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; 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=aCCbSlMjNx5L3JbI+yxmCqJTM703drqGHbbH/KoYNcE=; b=UB/rfIQ8kQgMmMUAWxOZPzuSgFHFDqpMLIMDpHWl7HIegwaxvdZaqGa30kHwfTbeQp 7ZsMd8W+dKrdk+I9p10m1aTphQTC3KM2K7Qavphr4HBOUAusWmL4W3h+HluIsFtPNWeZ Ul6OWFxJxszjGTuWkyjNFyUMuWvFvt8BZx1e8WneRxUXp8XzxW8ynqh7fkiM0H8EulSZ dPS0fxPF4towZpOtmdyNIUFwirKsNqNkiiaJSwj4Gi9BCCPoOnAv14K04jpy3jGav+pK jwbn6j/p095LA+2apeELdP6lbcXngMgtm0gNyHDEILSEQxHBNegYylL2cwYbB6bCSpVl rLeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=aCCbSlMjNx5L3JbI+yxmCqJTM703drqGHbbH/KoYNcE=; b=aOafw/MmOHbV0QvZAi3dI/+kkgI/oa2BBkiWVQCJaEuAjWGwyJkKuFxvJoH9Zel3J+ 5pGq8zLPKSq8j9412mcGFMsrkYIo6ohbYGa11SN1OklvRpgeoQa8qVSAK4/oQcB8Ku2C NCDUOe4MdplkcHy7p9XmlTwX8yS58VzaQhY1Ne6yRIaCkYGFSLqlLyfG8FnjayVWh8cv IDRFLh5sTuzoFH6W6UW4bk9LApv/4Rbr+v7AhjDB/wngU31SfHFVGTEEvgmtKRkYfXvr 2qmRl9onRIaTyzDu36RFHuAvvoq1H9+XswxTdut1mk+zf+4wSsINqnlwWW19bMd3oPXO Budg== X-Gm-Message-State: AO0yUKVJppd+7Md4r55RnJEBddvKuYFCeLDBWL2gVidmqB7tKkKfhyxX xFyHn97ICf2ZhX+/LmJeDzu5nA== X-Received: by 2002:a50:d5de:0:b0:4aa:aaf6:e6be with SMTP id g30-20020a50d5de000000b004aaaaf6e6bemr3648055edj.7.1676395931356; Tue, 14 Feb 2023 09:32:11 -0800 (PST) Received: from localhost.localdomain (abxh117.neoplus.adsl.tpnet.pl. [83.9.1.117]) by smtp.gmail.com with ESMTPSA id w8-20020a50c448000000b0049668426aa6sm8325787edf.24.2023.02.14.09.32.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Feb 2023 09:32:10 -0800 (PST) From: Konrad Dybcio <konrad.dybcio@linaro.org> To: linux-arm-msm@vger.kernel.org, andersson@kernel.org, agross@kernel.org Cc: marijn.suijten@somainline.org, Konrad Dybcio <konrad.dybcio@linaro.org>, Rob Clark <robdclark@gmail.com>, Abhinav Kumar <quic_abhinavk@quicinc.com>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Sean Paul <sean@poorly.run>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Akhil P Oommen <quic_akhilpo@quicinc.com>, Emma Anholt <emma@anholt.net>, Chia-I Wu <olvaffe@gmail.com>, Dan Carpenter <error27@gmail.com>, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 06/14] drm/msm/gpu: Use dev_pm_opp_set_rate for non-GMU GPUs Date: Tue, 14 Feb 2023 18:31:37 +0100 Message-Id: <20230214173145.2482651-7-konrad.dybcio@linaro.org> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230214173145.2482651-1-konrad.dybcio@linaro.org> References: <20230214173145.2482651-1-konrad.dybcio@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 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?1757830426069864025?= X-GMAIL-MSGID: =?utf-8?q?1757830426069864025?= |
Series |
[v2,01/14] drm/msm/a6xx: De-staticize sptprac en/disable functions
|
|
Commit Message
Konrad Dybcio
Feb. 14, 2023, 5:31 p.m. UTC
Currently we only utilize the OPP table connected to the GPU for
getting (available) frequencies. We do however need to scale the
voltage rail(s) accordingly to ensure that we aren't trying to
run the GPU at 1GHz with a VDD_LOW vote, as that would result in
an otherwise inexplainable hang.
Tell the OPP framework that we want to scale the "core" clock
and swap out the clk_set_rate to a dev_pm_opp_set_rate in
msm_devfreq_target() to enable usage of required-opps and by
extension proper voltage level/corner scaling.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++++
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
Comments
On 14/02/2023 19:31, Konrad Dybcio wrote: > Currently we only utilize the OPP table connected to the GPU for > getting (available) frequencies. We do however need to scale the > voltage rail(s) accordingly to ensure that we aren't trying to > run the GPU at 1GHz with a VDD_LOW vote, as that would result in > an otherwise inexplainable hang. > > Tell the OPP framework that we want to scale the "core" clock > and swap out the clk_set_rate to a dev_pm_opp_set_rate in > msm_devfreq_target() to enable usage of required-opps and by > extension proper voltage level/corner scaling. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++++ > drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +- > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c > index ce6b76c45b6f..15e405e4f977 100644 > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c > @@ -1047,6 +1047,10 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, > const char *gpu_name; > u32 speedbin; > > + /* This can only be done here, or devm_pm_opp_set_supported_hw will WARN_ON() */ > + if (!IS_ERR(devm_clk_get(dev, "core"))) > + devm_pm_opp_set_clkname(dev, "core"); Can we instead move a call to a6xx_set_supported_hw() / check_speed_bin after the adreno_gpu_init() ? It will call msm_gpu_init, which in turn sets gpu->core_clk. Ideally you can call devm_pm_opp_set_clkname() from that function. Or maybe completely drop gpu->core_clk and always use devm_pm_opp_set_clk_rate(). > + > adreno_gpu->funcs = funcs; > adreno_gpu->info = adreno_info(config->rev); > adreno_gpu->gmem = adreno_gpu->info->gmem; > diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c > index e27dbf12b5e8..ea70c1c32d94 100644 > --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c > +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c > @@ -48,7 +48,7 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, > gpu->funcs->gpu_set_freq(gpu, opp, df->suspended); > mutex_unlock(&df->lock); > } else { > - clk_set_rate(gpu->core_clk, *freq); > + dev_pm_opp_set_rate(dev, *freq); This is not enough, there are calls to clk_set_rate(gpu->core_clk) in msm_gpu.c which are called from the suspend/resume path. > } > > dev_pm_opp_put(opp);
On 17.02.2023 22:07, Dmitry Baryshkov wrote: > On 14/02/2023 19:31, Konrad Dybcio wrote: >> Currently we only utilize the OPP table connected to the GPU for >> getting (available) frequencies. We do however need to scale the >> voltage rail(s) accordingly to ensure that we aren't trying to >> run the GPU at 1GHz with a VDD_LOW vote, as that would result in >> an otherwise inexplainable hang. >> >> Tell the OPP framework that we want to scale the "core" clock >> and swap out the clk_set_rate to a dev_pm_opp_set_rate in >> msm_devfreq_target() to enable usage of required-opps and by >> extension proper voltage level/corner scaling. >> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> --- >> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++++ >> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +- >> 2 files changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c >> index ce6b76c45b6f..15e405e4f977 100644 >> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c >> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c >> @@ -1047,6 +1047,10 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, >> const char *gpu_name; >> u32 speedbin; >> + /* This can only be done here, or devm_pm_opp_set_supported_hw will WARN_ON() */ >> + if (!IS_ERR(devm_clk_get(dev, "core"))) >> + devm_pm_opp_set_clkname(dev, "core"); > > Can we instead move a call to a6xx_set_supported_hw() / check_speed_bin after the adreno_gpu_init() ? It will call msm_gpu_init, which in turn sets gpu->core_clk. > > Ideally you can call devm_pm_opp_set_clkname() from that function. Or maybe completely drop gpu->core_clk and always use devm_pm_opp_set_clk_rate(). That would break non-OPP targets, last of which were probably added N=big years ago.. I'm not sure these would still work, as I think we've got rid of some ugly clock getters that were looking for both "core" and "core_clk" etc. See 8db0b6c7b636376789e356d861c3c6c35dcb6913 for what seems to be the most recent example of non-OPP. IMX51/53 also have no OPP tables and are using the (AFAIK) now-defunct _clk-suffixed clock-names. I'd be more than happy to rip out some of this legacy code and convert it to something modern like OPP, but I'm not sure you guys would like it considering the breakage on (arguably ancient and borderline retired) platforms. This patch as-is "only" breaks non-OPP a5xx & a6xx (as they have .gpu_busy defined), of which there are none.. > >> + >> adreno_gpu->funcs = funcs; >> adreno_gpu->info = adreno_info(config->rev); >> adreno_gpu->gmem = adreno_gpu->info->gmem; >> diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c >> index e27dbf12b5e8..ea70c1c32d94 100644 >> --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c >> +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c >> @@ -48,7 +48,7 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, >> gpu->funcs->gpu_set_freq(gpu, opp, df->suspended); >> mutex_unlock(&df->lock); >> } else { >> - clk_set_rate(gpu->core_clk, *freq); >> + dev_pm_opp_set_rate(dev, *freq); > > This is not enough, there are calls to clk_set_rate(gpu->core_clk) in msm_gpu.c which are called from the suspend/resume path. Right, good catch. Konrad > >> } >> dev_pm_opp_put(opp); >
On 18/02/2023 13:04, Konrad Dybcio wrote: > > > On 17.02.2023 22:07, Dmitry Baryshkov wrote: >> On 14/02/2023 19:31, Konrad Dybcio wrote: >>> Currently we only utilize the OPP table connected to the GPU for >>> getting (available) frequencies. We do however need to scale the >>> voltage rail(s) accordingly to ensure that we aren't trying to >>> run the GPU at 1GHz with a VDD_LOW vote, as that would result in >>> an otherwise inexplainable hang. >>> >>> Tell the OPP framework that we want to scale the "core" clock >>> and swap out the clk_set_rate to a dev_pm_opp_set_rate in >>> msm_devfreq_target() to enable usage of required-opps and by >>> extension proper voltage level/corner scaling. >>> >>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>> --- >>> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++++ >>> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +- >>> 2 files changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>> index ce6b76c45b6f..15e405e4f977 100644 >>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>> @@ -1047,6 +1047,10 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, >>> const char *gpu_name; >>> u32 speedbin; >>> + /* This can only be done here, or devm_pm_opp_set_supported_hw will WARN_ON() */ >>> + if (!IS_ERR(devm_clk_get(dev, "core"))) >>> + devm_pm_opp_set_clkname(dev, "core"); >> >> Can we instead move a call to a6xx_set_supported_hw() / check_speed_bin after the adreno_gpu_init() ? It will call msm_gpu_init, which in turn sets gpu->core_clk. >> >> Ideally you can call devm_pm_opp_set_clkname() from that function. > > >> Or maybe completely drop gpu->core_clk and always use devm_pm_opp_set_clk_rate(). > That would break non-OPP targets, last of which were probably added N=big years ago.. No. In the lack of OPP tables, dev_pm_opp_clk_set_rate() should behave exactly like the clk_set_rate(). > I'm not sure these would still work, as I think we've got rid of some ugly > clock getters that were looking for both "core" and "core_clk" etc. We still support core vs core_clk, see the get_clocks() at msm_gpu.c and then msm_clk_bulk_get_clock(). However we might mimick this function and call devm_pm_opp_set_clkname() with the proper name ("core" or "core_clk"). > > See 8db0b6c7b636376789e356d861c3c6c35dcb6913 for what seems to be the most recent > example of non-OPP. > > IMX51/53 also have no OPP tables and are using the (AFAIK) now-defunct _clk-suffixed > clock-names. It works, I tested it during this cycle. > > I'd be more than happy to rip out some of this legacy code and convert it > to something modern like OPP, but I'm not sure you guys would like it considering > the breakage on (arguably ancient and borderline retired) platforms. I think, we should try switching to OPP-for-everybody, granted the promise of dev_pm_opp_set_clk_rate() being backwards compatible with bare clk_set_rate(). > > This patch as-is "only" breaks non-OPP a5xx & a6xx (as they have .gpu_busy defined), > of which there are none.. > >> >>> + >>> adreno_gpu->funcs = funcs; >>> adreno_gpu->info = adreno_info(config->rev); >>> adreno_gpu->gmem = adreno_gpu->info->gmem; >>> diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>> index e27dbf12b5e8..ea70c1c32d94 100644 >>> --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>> +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>> @@ -48,7 +48,7 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, >>> gpu->funcs->gpu_set_freq(gpu, opp, df->suspended); >>> mutex_unlock(&df->lock); >>> } else { >>> - clk_set_rate(gpu->core_clk, *freq); >>> + dev_pm_opp_set_rate(dev, *freq); >> >> This is not enough, there are calls to clk_set_rate(gpu->core_clk) in msm_gpu.c which are called from the suspend/resume path. > Right, good catch. > > Konrad >> >>> } >>> dev_pm_opp_put(opp); >>
On 18.02.2023 17:47, Dmitry Baryshkov wrote: > On 18/02/2023 13:04, Konrad Dybcio wrote: >> >> >> On 17.02.2023 22:07, Dmitry Baryshkov wrote: >>> On 14/02/2023 19:31, Konrad Dybcio wrote: >>>> Currently we only utilize the OPP table connected to the GPU for >>>> getting (available) frequencies. We do however need to scale the >>>> voltage rail(s) accordingly to ensure that we aren't trying to >>>> run the GPU at 1GHz with a VDD_LOW vote, as that would result in >>>> an otherwise inexplainable hang. >>>> >>>> Tell the OPP framework that we want to scale the "core" clock >>>> and swap out the clk_set_rate to a dev_pm_opp_set_rate in >>>> msm_devfreq_target() to enable usage of required-opps and by >>>> extension proper voltage level/corner scaling. >>>> >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>> --- >>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++++ >>>> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +- >>>> 2 files changed, 5 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>>> index ce6b76c45b6f..15e405e4f977 100644 >>>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>>> @@ -1047,6 +1047,10 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, >>>> const char *gpu_name; >>>> u32 speedbin; >>>> + /* This can only be done here, or devm_pm_opp_set_supported_hw will WARN_ON() */ >>>> + if (!IS_ERR(devm_clk_get(dev, "core"))) >>>> + devm_pm_opp_set_clkname(dev, "core"); >>> >>> Can we instead move a call to a6xx_set_supported_hw() / check_speed_bin after the adreno_gpu_init() ? It will call msm_gpu_init, which in turn sets gpu->core_clk. >>> >>> Ideally you can call devm_pm_opp_set_clkname() from that function. >> >> >>> Or maybe completely drop gpu->core_clk and always use devm_pm_opp_set_clk_rate(). >> That would break non-OPP targets, last of which were probably added N=big years ago.. > > No. In the lack of OPP tables, dev_pm_opp_clk_set_rate() should behave exactly like the clk_set_rate(). Not sure if that's what you meant, but if a device lacks OPP, devm_pm_opp_set_rate will return -ENODEV. If you meant "if we can't find an opp table, behave as if we called clk_set_rate", a discussion on #freedreno with robclark indicates he'd accept getting rid of non-opp code, provided we construct a table if need be, since we have the data required to do so ([FMIN=27MHz, FMAX=fast_rate]). > >> I'm not sure these would still work, as I think we've got rid of some ugly >> clock getters that were looking for both "core" and "core_clk" etc. > > We still support core vs core_clk, see the get_clocks() at msm_gpu.c and then msm_clk_bulk_get_clock(). However we might mimick this function and call devm_pm_opp_set_clkname() with the proper name ("core" or "core_clk"). > >> >> See 8db0b6c7b636376789e356d861c3c6c35dcb6913 for what seems to be the most recent >> example of non-OPP. >> >> IMX51/53 also have no OPP tables and are using the (AFAIK) now-defunct _clk-suffixed >> clock-names. > > It works, I tested it during this cycle. Oh okay, I had a feeling like that was dropped at one point.. > >> >> I'd be more than happy to rip out some of this legacy code and convert it >> to something modern like OPP, but I'm not sure you guys would like it considering >> the breakage on (arguably ancient and borderline retired) platforms. > > I think, we should try switching to OPP-for-everybody, granted the promise of dev_pm_opp_set_clk_rate() being backwards compatible with bare clk_set_rate(). It's not, but as I mentioned, we can easily work around that. > >> >> This patch as-is "only" breaks non-OPP a5xx & a6xx (as they have .gpu_busy defined), >> of which there are none.. ...but we want to get devfreq everywhere and it's a few LoC away.. Konrad >> >>> >>>> + >>>> adreno_gpu->funcs = funcs; >>>> adreno_gpu->info = adreno_info(config->rev); >>>> adreno_gpu->gmem = adreno_gpu->info->gmem; >>>> diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>>> index e27dbf12b5e8..ea70c1c32d94 100644 >>>> --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>>> +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>>> @@ -48,7 +48,7 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, >>>> gpu->funcs->gpu_set_freq(gpu, opp, df->suspended); >>>> mutex_unlock(&df->lock); >>>> } else { >>>> - clk_set_rate(gpu->core_clk, *freq); >>>> + dev_pm_opp_set_rate(dev, *freq); >>> >>> This is not enough, there are calls to clk_set_rate(gpu->core_clk) in msm_gpu.c which are called from the suspend/resume path. >> Right, good catch. >> >> Konrad >>> >>>> } >>>> dev_pm_opp_put(opp); >>> >
On 20.02.2023 10:59, Konrad Dybcio wrote: > > > On 18.02.2023 17:47, Dmitry Baryshkov wrote: >> On 18/02/2023 13:04, Konrad Dybcio wrote: >>> >>> >>> On 17.02.2023 22:07, Dmitry Baryshkov wrote: >>>> On 14/02/2023 19:31, Konrad Dybcio wrote: >>>>> Currently we only utilize the OPP table connected to the GPU for >>>>> getting (available) frequencies. We do however need to scale the >>>>> voltage rail(s) accordingly to ensure that we aren't trying to >>>>> run the GPU at 1GHz with a VDD_LOW vote, as that would result in >>>>> an otherwise inexplainable hang. >>>>> >>>>> Tell the OPP framework that we want to scale the "core" clock >>>>> and swap out the clk_set_rate to a dev_pm_opp_set_rate in >>>>> msm_devfreq_target() to enable usage of required-opps and by >>>>> extension proper voltage level/corner scaling. >>>>> >>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>>> --- >>>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++++ >>>>> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +- >>>>> 2 files changed, 5 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>>>> index ce6b76c45b6f..15e405e4f977 100644 >>>>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>>>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c >>>>> @@ -1047,6 +1047,10 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, >>>>> const char *gpu_name; >>>>> u32 speedbin; >>>>> + /* This can only be done here, or devm_pm_opp_set_supported_hw will WARN_ON() */ >>>>> + if (!IS_ERR(devm_clk_get(dev, "core"))) >>>>> + devm_pm_opp_set_clkname(dev, "core"); >>>> >>>> Can we instead move a call to a6xx_set_supported_hw() / check_speed_bin after the adreno_gpu_init() ? It will call msm_gpu_init, which in turn sets gpu->core_clk. >>>> >>>> Ideally you can call devm_pm_opp_set_clkname() from that function. >>> >>> >>>> Or maybe completely drop gpu->core_clk and always use devm_pm_opp_set_clk_rate(). >>> That would break non-OPP targets, last of which were probably added N=big years ago.. >> >> No. In the lack of OPP tables, dev_pm_opp_clk_set_rate() should behave exactly like the clk_set_rate(). > Not sure if that's what you meant, but if a device lacks OPP, > devm_pm_opp_set_rate will return -ENODEV. > > If you meant "if we can't find an opp table, behave as if we > called clk_set_rate", a discussion on #freedreno with robclark > indicates he'd accept getting rid of non-opp code, provided we > construct a table if need be, since we have the data required > to do so ([FMIN=27MHz, FMAX=fast_rate]). Actually.. that's what happens for gpu-pwrlevels users already.. Well, use>r<, as apq8064 seems to have been the only user of that upstream, ever.. And for A2XX it looks like it just unconditionally selects 200 MHz.. I think this could be simplified to: if (opp exists) // use opp else if (adreno_is_a2xx) dev_pm_opp_add(dev, 200000000, 0) //device, freq_hz, volt_uV else if (adreno_is_a320) dev_pm_opp_add(dev, 450000000, 0) else // for now the driver sets 200mhz here, but i don't think // it's reasonable to keep carrying that behavior for >a2xx return -EINVAL And then we can yank out all clk_set_rate calls just like that! Konrad > >> >>> I'm not sure these would still work, as I think we've got rid of some ugly >>> clock getters that were looking for both "core" and "core_clk" etc. >> >> We still support core vs core_clk, see the get_clocks() at msm_gpu.c and then msm_clk_bulk_get_clock(). However we might mimick this function and call devm_pm_opp_set_clkname() with the proper name ("core" or "core_clk"). >> >>> >>> See 8db0b6c7b636376789e356d861c3c6c35dcb6913 for what seems to be the most recent >>> example of non-OPP. >>> >>> IMX51/53 also have no OPP tables and are using the (AFAIK) now-defunct _clk-suffixed >>> clock-names. >> >> It works, I tested it during this cycle. > Oh okay, I had a feeling like that was dropped at one point.. > >> >>> >>> I'd be more than happy to rip out some of this legacy code and convert it >>> to something modern like OPP, but I'm not sure you guys would like it considering >>> the breakage on (arguably ancient and borderline retired) platforms. >> >> I think, we should try switching to OPP-for-everybody, granted the promise of dev_pm_opp_set_clk_rate() being backwards compatible with bare clk_set_rate(). > It's not, but as I mentioned, we can easily work around that. > >> >>> >>> This patch as-is "only" breaks non-OPP a5xx & a6xx (as they have .gpu_busy defined), >>> of which there are none.. > ...but we want to get devfreq everywhere and it's a few LoC away.. > > Konrad >>> >>>> >>>>> + >>>>> adreno_gpu->funcs = funcs; >>>>> adreno_gpu->info = adreno_info(config->rev); >>>>> adreno_gpu->gmem = adreno_gpu->info->gmem; >>>>> diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>>>> index e27dbf12b5e8..ea70c1c32d94 100644 >>>>> --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>>>> +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c >>>>> @@ -48,7 +48,7 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, >>>>> gpu->funcs->gpu_set_freq(gpu, opp, df->suspended); >>>>> mutex_unlock(&df->lock); >>>>> } else { >>>>> - clk_set_rate(gpu->core_clk, *freq); >>>>> + dev_pm_opp_set_rate(dev, *freq); >>>> >>>> This is not enough, there are calls to clk_set_rate(gpu->core_clk) in msm_gpu.c which are called from the suspend/resume path. >>> Right, good catch. >>> >>> Konrad >>>> >>>>> } >>>>> dev_pm_opp_put(opp); >>>> >>
On Mon, 20 Feb 2023 at 11:59, Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > On 18.02.2023 17:47, Dmitry Baryshkov wrote: > > On 18/02/2023 13:04, Konrad Dybcio wrote: > >> On 17.02.2023 22:07, Dmitry Baryshkov wrote: > >>> On 14/02/2023 19:31, Konrad Dybcio wrote: > >>>> Currently we only utilize the OPP table connected to the GPU for > >>>> getting (available) frequencies. We do however need to scale the > >>>> voltage rail(s) accordingly to ensure that we aren't trying to > >>>> run the GPU at 1GHz with a VDD_LOW vote, as that would result in > >>>> an otherwise inexplainable hang. > >>>> > >>>> Tell the OPP framework that we want to scale the "core" clock > >>>> and swap out the clk_set_rate to a dev_pm_opp_set_rate in > >>>> msm_devfreq_target() to enable usage of required-opps and by > >>>> extension proper voltage level/corner scaling. > >>>> > >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > >>>> --- > >>>> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++++ > >>>> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 +- > >>>> 2 files changed, 5 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c > >>>> index ce6b76c45b6f..15e405e4f977 100644 > >>>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c > >>>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c > >>>> @@ -1047,6 +1047,10 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, > >>>> const char *gpu_name; > >>>> u32 speedbin; > >>>> + /* This can only be done here, or devm_pm_opp_set_supported_hw will WARN_ON() */ > >>>> + if (!IS_ERR(devm_clk_get(dev, "core"))) > >>>> + devm_pm_opp_set_clkname(dev, "core"); > >>> > >>> Can we instead move a call to a6xx_set_supported_hw() / check_speed_bin after the adreno_gpu_init() ? It will call msm_gpu_init, which in turn sets gpu->core_clk. > >>> > >>> Ideally you can call devm_pm_opp_set_clkname() from that function. > >> > >> > >>> Or maybe completely drop gpu->core_clk and always use devm_pm_opp_set_clk_rate(). > >> That would break non-OPP targets, last of which were probably added N=big years ago.. > > > > No. In the lack of OPP tables, dev_pm_opp_clk_set_rate() should behave exactly like the clk_set_rate(). > Not sure if that's what you meant, but if a device lacks OPP, > devm_pm_opp_set_rate will return -ENODEV. > > If you meant "if we can't find an opp table, behave as if we > called clk_set_rate", a discussion on #freedreno with robclark > indicates he'd accept getting rid of non-opp code, provided we > construct a table if need be, since we have the data required > to do so ([FMIN=27MHz, FMAX=fast_rate]). I was referring to a comment at dev_pm_opp_set_rate(): /* * For IO devices which require an OPP on some platforms/SoCs * while just needing to scale the clock on some others * we look for empty OPP tables with just a clock handle and * scale only the clk. This makes dev_pm_opp_set_rate() * equivalent to a clk_set_rate() */ Maybe we just need to make sure that the OPP table exists (devm_pm_opp_of_add_table) to prevent the function from bailing out early. > > > > >> I'm not sure these would still work, as I think we've got rid of some ugly > >> clock getters that were looking for both "core" and "core_clk" etc. > > > > We still support core vs core_clk, see the get_clocks() at msm_gpu.c and then msm_clk_bulk_get_clock(). However we might mimick this function and call devm_pm_opp_set_clkname() with the proper name ("core" or "core_clk"). > > > >> > >> See 8db0b6c7b636376789e356d861c3c6c35dcb6913 for what seems to be the most recent > >> example of non-OPP. > >> > >> IMX51/53 also have no OPP tables and are using the (AFAIK) now-defunct _clk-suffixed > >> clock-names. > > > > It works, I tested it during this cycle. > Oh okay, I had a feeling like that was dropped at one point.. > > > > >> > >> I'd be more than happy to rip out some of this legacy code and convert it > >> to something modern like OPP, but I'm not sure you guys would like it considering > >> the breakage on (arguably ancient and borderline retired) platforms. > > > > I think, we should try switching to OPP-for-everybody, granted the promise of dev_pm_opp_set_clk_rate() being backwards compatible with bare clk_set_rate(). > It's not, but as I mentioned, we can easily work around that. > > > > >> > >> This patch as-is "only" breaks non-OPP a5xx & a6xx (as they have .gpu_busy defined), > >> of which there are none.. > ...but we want to get devfreq everywhere and it's a few LoC away.. > > Konrad > >> > >>> > >>>> + > >>>> adreno_gpu->funcs = funcs; > >>>> adreno_gpu->info = adreno_info(config->rev); > >>>> adreno_gpu->gmem = adreno_gpu->info->gmem; > >>>> diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c > >>>> index e27dbf12b5e8..ea70c1c32d94 100644 > >>>> --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c > >>>> +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c > >>>> @@ -48,7 +48,7 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, > >>>> gpu->funcs->gpu_set_freq(gpu, opp, df->suspended); > >>>> mutex_unlock(&df->lock); > >>>> } else { > >>>> - clk_set_rate(gpu->core_clk, *freq); > >>>> + dev_pm_opp_set_rate(dev, *freq); > >>> > >>> This is not enough, there are calls to clk_set_rate(gpu->core_clk) in msm_gpu.c which are called from the suspend/resume path. > >> Right, good catch. > >> > >> Konrad > >>> > >>>> } > >>>> dev_pm_opp_put(opp); > >>> > >
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c index ce6b76c45b6f..15e405e4f977 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c @@ -1047,6 +1047,10 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev, const char *gpu_name; u32 speedbin; + /* This can only be done here, or devm_pm_opp_set_supported_hw will WARN_ON() */ + if (!IS_ERR(devm_clk_get(dev, "core"))) + devm_pm_opp_set_clkname(dev, "core"); + adreno_gpu->funcs = funcs; adreno_gpu->info = adreno_info(config->rev); adreno_gpu->gmem = adreno_gpu->info->gmem; diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c b/drivers/gpu/drm/msm/msm_gpu_devfreq.c index e27dbf12b5e8..ea70c1c32d94 100644 --- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c +++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c @@ -48,7 +48,7 @@ static int msm_devfreq_target(struct device *dev, unsigned long *freq, gpu->funcs->gpu_set_freq(gpu, opp, df->suspended); mutex_unlock(&df->lock); } else { - clk_set_rate(gpu->core_clk, *freq); + dev_pm_opp_set_rate(dev, *freq); } dev_pm_opp_put(opp);