From: Akhil P Oommen <quic_akhilpo@quicinc.com>
To: Rob Clark <robdclark@gmail.com>
Cc: freedreno <freedreno@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>,
<linux-arm-msm@vger.kernel.org>,
"Bjorn Andersson" <bjorn.andersson@linaro.org>,
Jordan Crouse <jordan@cosmicpenguin.net>,
Jonathan Marek <jonathan@marek.ca>,
"Douglas Anderson" <dianders@chromium.org>,
Matthias Kaehlcke <mka@chromium.org>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Chia-I Wu <olvaffe@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
David Airlie <airlied@linux.ie>,
"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
Sean Paul <sean@poorly.run>, Stephen Boyd <swboyd@chromium.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 4/8] drm/msm: Fix cx collapse issue during recovery
Date: Mon, 1 Aug 2022 20:40:07 +0530 [thread overview]
Message-ID: <e18b057b-f5da-48a4-7086-9bc64d3819fb@quicinc.com> (raw)
In-Reply-To: <CAF6AEGuqptUzOtcjG+oA4BQha3Jk-UzDK-8SF_8v5A+8Dg71uQ@mail.gmail.com>
On 7/31/2022 9:52 PM, Rob Clark wrote:
> On Sat, Jul 30, 2022 at 2:41 AM Akhil P Oommen <quic_akhilpo@quicinc.com> wrote:
>> There are some hardware logic under CX domain. For a successful
>> recovery, we should ensure cx headswitch collapses to ensure all the
>> stale states are cleard out. This is especially true to for a6xx family
>> where we can GMU co-processor.
>>
>> Currently, cx doesn't collapse due to a devlink between gpu and its
>> smmu. So the *struct gpu device* needs to be runtime suspended to ensure
>> that the iommu driver removes its vote on cx gdsc.
>>
>> Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
>> ---
>>
>> Changes in v3:
>> - Simplied the pm refcount drop since we have just a single refcount now
>> for all active submits
>>
>> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 24 +++++++++++++++++++++---
>> drivers/gpu/drm/msm/msm_gpu.c | 4 +---
>> 2 files changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> index 42ed9a3..1b049c5 100644
>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
>> @@ -1193,7 +1193,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
>> {
>> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
>> struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
>> - int i;
>> + int i, active_submits;
>>
>> adreno_dump_info(gpu);
>>
>> @@ -1210,8 +1210,26 @@ static void a6xx_recover(struct msm_gpu *gpu)
>> */
>> gmu_write(&a6xx_gpu->gmu, REG_A6XX_GMU_GMU_PWR_COL_KEEPALIVE, 0);
>>
>> - gpu->funcs->pm_suspend(gpu);
>> - gpu->funcs->pm_resume(gpu);
>> + pm_runtime_dont_use_autosuspend(&gpu->pdev->dev);
>> +
>> + /* active_submit won't change until we make a submission */
>> + mutex_lock(&gpu->active_lock);
>> + active_submits = gpu->active_submits;
>> + mutex_unlock(&gpu->active_lock);
>> +
>> + /* Drop the rpm refcount from active submits */
>> + if (active_submits)
>> + pm_runtime_put(&gpu->pdev->dev);
> Couldn't this race with an incoming submit triggering active_submits
> to transition 0 -> 1? Moving the mutex_unlock() would solve this.
>
> Actually, maybe just move the mutex_unlock() to the end of the entire
> sequence. You could also clear gpu->active_submits and restore it
> before unlocking, so you can drop the removal of the WARN_ON_ONCE
> (patch 6/8) which should otherwise be squashed into this patch to keep
> things bisectable
Because we are holding gpu->lock, there won't be any new submissions to
gpu. But I agree with your both suggestions.
-Akhil.
>
>> +
>> + /* And the final one from recover worker */
>> + pm_runtime_put_sync(&gpu->pdev->dev);
>> +
>> + pm_runtime_use_autosuspend(&gpu->pdev->dev);
>> +
>> + if (active_submits)
>> + pm_runtime_get(&gpu->pdev->dev);
>> +
>> + pm_runtime_get_sync(&gpu->pdev->dev);
>>
>> msm_gpu_hw_init(gpu);
>> }
>> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
>> index 1945efb..07e55a6 100644
>> --- a/drivers/gpu/drm/msm/msm_gpu.c
>> +++ b/drivers/gpu/drm/msm/msm_gpu.c
>> @@ -426,9 +426,7 @@ static void recover_worker(struct kthread_work *work)
>> /* retire completed submits, plus the one that hung: */
>> retire_submits(gpu);
>>
>> - pm_runtime_get_sync(&gpu->pdev->dev);
>> gpu->funcs->recover(gpu);
>> - pm_runtime_put_sync(&gpu->pdev->dev);
> Hmm, could this have some fallout on earlier gens?
>
> I guess I should extend the igt msm_recovery test to run on things
> prior to a6xx..
>
> BR,
> -R
No, because of patch 3/8 in this series.
-Akhil.
>
>> /*
>> * Replay all remaining submits starting with highest priority
>> @@ -445,7 +443,7 @@ static void recover_worker(struct kthread_work *work)
>> }
>> }
>>
>> - pm_runtime_put_sync(&gpu->pdev->dev);
>> + pm_runtime_put(&gpu->pdev->dev);
>>
>> mutex_unlock(&gpu->lock);
>>
>> --
>> 2.7.4
>>
next prev parent reply other threads:[~2022-08-01 15:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-30 9:40 [PATCH v3 0/8] Improve GPU Recovery Akhil P Oommen
2022-07-30 9:40 ` [PATCH v3 1/8] drm/msm: Remove unnecessary pm_runtime_get/put Akhil P Oommen
2022-07-31 15:55 ` Rob Clark
2022-08-01 14:32 ` Akhil P Oommen
2022-07-30 9:40 ` [PATCH v3 2/8] drm/msm: Take single rpm refcount on behalf of all submits Akhil P Oommen
2022-07-31 15:56 ` Rob Clark
2022-07-31 16:32 ` Akhil P Oommen
2022-07-31 22:15 ` Rob Clark
2022-08-01 14:35 ` Akhil P Oommen
2022-07-30 9:40 ` [PATCH v3 3/8] drm/msm: Correct pm_runtime votes in recover worker Akhil P Oommen
2022-07-30 9:40 ` [PATCH v3 4/8] drm/msm: Fix cx collapse issue during recovery Akhil P Oommen
2022-07-31 16:22 ` Rob Clark
2022-08-01 15:10 ` Akhil P Oommen [this message]
2022-07-30 9:40 ` [PATCH v3 5/8] drm/msm/a6xx: Ensure CX collapse during gpu recovery Akhil P Oommen
2022-08-02 7:14 ` Dmitry Baryshkov
2022-08-03 10:15 ` Akhil P Oommen
2022-08-03 11:09 ` Dmitry Baryshkov
2022-07-30 9:40 ` [PATCH v3 6/8] drm/msm/adreno: Remove a WARN() during runtime_suspend Akhil P Oommen
2022-07-30 9:40 ` [PATCH v3 7/8] drm/msm/a6xx: Improve gpu recovery sequence Akhil P Oommen
2022-07-30 9:40 ` [PATCH v3 8/8] drm/msm/a6xx: Handle GMU prepare-slumber hfi failure Akhil P Oommen
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=e18b057b-f5da-48a4-7086-9bc64d3819fb@quicinc.com \
--to=quic_akhilpo@quicinc.com \
--cc=airlied@linux.ie \
--cc=bjorn.andersson@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jonathan@marek.ca \
--cc=jordan@cosmicpenguin.net \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mka@chromium.org \
--cc=olvaffe@gmail.com \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=swboyd@chromium.org \
/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
all inboxes | Powered by JetHome®