linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
	Rob Clark <robdclark@chromium.org>,
	Rob Clark <robdclark@gmail.com>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	linux-kernel@vger.kernel.org (open list)
Subject: [PATCH v5 09/11] drm/msm: Move runpm enable in submit path
Date: Tue, 22 Aug 2023 11:01:56 -0700	[thread overview]
Message-ID: <20230822180208.95556-10-robdclark@gmail.com> (raw)
In-Reply-To: <20230822180208.95556-1-robdclark@gmail.com>

From: Rob Clark <robdclark@chromium.org>

Move runpm enable to just before we enqueue the job to the scheduler,
rather than job_run().  This has the disadvantage of potentially
powering up the GPU before waiting for fences, but it is the only
feasible way to move things like clk_prepare() out of the fence
signalling path.  Ideally runpm would have separate prepare and enable
steps so we could just move the prepare step.  But attempting to
separate these without support in runpm doesn't play nicely with
autosuspend.

Signed-off-by: Rob Clark <robdclark@chromium.org>
---
 drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
 drivers/gpu/drm/msm/msm_gpu.c        | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
index 99744de6c05a..a908373cf34b 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -981,6 +981,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
 
 	msm_rd_dump_submit(priv->rd, submit, NULL);
 
+	pm_runtime_get_sync(&gpu->pdev->dev);
+
 	drm_sched_entity_push_job(&submit->base);
 
 	args->fence = submit->fence_id;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 243f988c65b7..819140d85205 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -751,8 +751,6 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
 
 	WARN_ON(!mutex_is_locked(&gpu->lock));
 
-	pm_runtime_get_sync(&gpu->pdev->dev);
-
 	msm_gpu_hw_init(gpu);
 
 	submit->seqno = submit->hw_fence->seqno;
-- 
2.41.0


  parent reply	other threads:[~2023-08-22 18:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22 18:01 [PATCH v5 00/11] drm/msm+PM+icc: Make job_run() reclaim-safe Rob Clark
2023-08-22 18:01 ` [PATCH v5 01/11] PM / devfreq: Drop unneed locking to appease lockdep Rob Clark
2023-08-22 18:01 ` [PATCH v5 02/11] PM / devfreq: Teach lockdep about locking order Rob Clark
2023-08-22 18:01 ` [PATCH v5 03/11] PM / QoS: Fix constraints alloc vs reclaim locking Rob Clark
2023-08-22 18:47   ` Rafael J. Wysocki
2023-08-22 19:41     ` Rob Clark
2023-08-23 21:01     ` Rob Clark
2023-08-22 18:01 ` [PATCH v5 04/11] PM / QoS: Decouple request alloc from dev_pm_qos_mtx Rob Clark
2023-09-22  7:14   ` kernel test robot
2023-08-22 18:01 ` [PATCH v5 05/11] PM / QoS: Teach lockdep about dev_pm_qos_mtx locking order Rob Clark
2023-08-22 18:01 ` [PATCH v5 06/11] interconnect: Fix locking for runpm vs reclaim Rob Clark
2023-08-22 18:01 ` [PATCH v5 07/11] interconnect: Teach lockdep about icc_bw_lock order Rob Clark
2023-08-22 18:01 ` [PATCH v5 08/11] drm/msm/a6xx: Remove GMU lock from runpm paths Rob Clark
2023-08-22 18:01 ` Rob Clark [this message]
2023-08-22 18:01 ` [PATCH v5 10/11] drm/sched: Add (optional) fence signaling annotation Rob Clark
2023-08-22 18:01 ` [PATCH v5 11/11] drm/msm: Enable fence signalling annotations Rob Clark

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=20230822180208.95556-10-robdclark@gmail.com \
    --to=robdclark@gmail.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=robdclark@chromium.org \
    --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;
as well as URLs for NNTP newsgroup(s).