Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	linux-arm-msm@vger.kernel.org, andersson@kernel.org,
	agross@kernel.org
Cc: marijn.suijten@somainline.org, Rob Clark <robdclark@gmail.com>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	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: Re: [PATCH v2 06/14] drm/msm/gpu: Use dev_pm_opp_set_rate for non-GMU GPUs
Date: Sat, 18 Feb 2023 12:04:45 +0100	[thread overview]
Message-ID: <82c84ba4-ca33-3ce0-fe86-efedfce04cda@linaro.org> (raw)
In-Reply-To: <2e129fd6-d4e5-a955-5355-3ca71166fb33@linaro.org>



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);
> 

  reply	other threads:[~2023-02-18 11:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-14 17:31 [PATCH v2 00/14] GMU-less A6xx support (A610, A619_holi) Konrad Dybcio
2023-02-14 17:31 ` [PATCH v2 01/14] drm/msm/a6xx: De-staticize sptprac en/disable functions Konrad Dybcio
2023-02-17 20:41   ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 02/14] drm/msm/a6xx: Extend UBWC config Konrad Dybcio
2023-02-17 20:46   ` Dmitry Baryshkov
2023-02-17 20:51     ` Konrad Dybcio
2023-02-14 17:31 ` [PATCH v2 03/14] drm/msm/a6xx: Introduce GMU wrapper support Konrad Dybcio
2023-02-17 21:37   ` Dmitry Baryshkov
2023-02-17 21:41     ` Konrad Dybcio
2023-02-17 21:44       ` Dmitry Baryshkov
2023-02-17 21:45         ` Konrad Dybcio
2023-02-14 17:31 ` [PATCH v2 04/14] drm/msm/a6xx: Remove both GBIF and RBBM GBIF halt on hw init Konrad Dybcio
2023-02-14 17:31 ` [PATCH v2 05/14] drm/msm/adreno: Disable has_cached_coherent for A610/A619_holi Konrad Dybcio
2023-02-17 20:54   ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 06/14] drm/msm/gpu: Use dev_pm_opp_set_rate for non-GMU GPUs Konrad Dybcio
2023-02-17 21:07   ` Dmitry Baryshkov
2023-02-18 11:04     ` Konrad Dybcio [this message]
2023-02-18 16:47       ` Dmitry Baryshkov
2023-02-20  9:59         ` Konrad Dybcio
2023-02-20 10:12           ` Konrad Dybcio
2023-02-20 10:45           ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 07/14] drm/msm/a6xx: Add support for A619_holi Konrad Dybcio
2023-02-17 21:19   ` Dmitry Baryshkov
2023-02-17 21:21     ` Konrad Dybcio
2023-02-18 13:04       ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 08/14] drm/msm/a6xx: Add A610 support Konrad Dybcio
2023-02-17 21:42   ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 09/14] drm/msm/a6xx: Fix some A619 tunables Konrad Dybcio
2023-02-17 21:42   ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 10/14] drm/msm/a6xx: Fix up A6XX protected registers Konrad Dybcio
2023-02-14 21:56   ` Rob Clark
2023-02-15  0:10     ` Dmitry Baryshkov
2023-02-15  0:38       ` Konrad Dybcio
2023-02-15  1:28         ` Rob Clark
2023-02-14 17:31 ` [PATCH v2 11/14] drm/msm/a6xx: Enable optional icc voting from OPP tables Konrad Dybcio
2023-02-17 21:19   ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 12/14] drm/msm/a6xx: Use "else if" in GPU speedbin rev matching Konrad Dybcio
2023-02-17 21:20   ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 13/14] drm/msm/a6xx: Add A619_holi speedbin support Konrad Dybcio
2023-02-17 21:25   ` Dmitry Baryshkov
2023-02-14 17:31 ` [PATCH v2 14/14] drm/msm/a6xx: Add A610 " Konrad Dybcio
2023-02-17 21:25   ` Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=82c84ba4-ca33-3ce0-fe86-efedfce04cda@linaro.org \
    --to=konrad.dybcio@linaro.org \
    --cc=agross@kernel.org \
    --cc=airlied@gmail.com \
    --cc=andersson@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=error27@gmail.com \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=olvaffe@gmail.com \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_akhilpo@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox