From: "Adrián Larumbe" <adrian.larumbe@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>,
Rob Herring <robh@kernel.org>,
Steven Price <steven.price@arm.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
Faith Ekstrand <faith.ekstrand@collabora.com>,
"Marty E. Plummer" <hanetzer@startmail.com>,
Tomeu Vizoso <tomeu@tomeuvizoso.net>,
Eric Anholt <eric@anholt.net>,
Robin Murphy <robin.murphy@arm.com>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Collabora Kernel Team" <kernel@collabora.com>,
"Adrián Larumbe" <adrian.larumbe@collabora.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>
Subject: [PATCH v15 14/15] drm/panfrost: Introduce a reset lock
Date: Mon, 12 Oct 2026 15:48:06 +0100 [thread overview]
Message-ID: <20261012-claude-fixes-v15-14-bc0a6c498553@collabora.com> (raw)
In-Reply-To: <20261012-claude-fixes-v15-0-bc0a6c498553@collabora.com>
In order to avoid accessing HW register while a reset is ongoing, a
read/write semaphore that envelopes the reset sequence will help driver
entry points avoid racing with it. For now, the only such racy entry
point is the ioctl that returns the current GPU timestamp.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
---
drivers/gpu/drm/panfrost/panfrost_device.c | 2 ++
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 9 ++++++---
drivers/gpu/drm/panfrost/panfrost_job.c | 1 +
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c b/drivers/gpu/drm/panfrost/panfrost_device.c
index b3dae6ce3eb0..5718e8185427 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -509,6 +509,8 @@ bool panfrost_exception_needs_reset(const struct panfrost_device *pfdev,
void panfrost_device_reset(struct panfrost_device *pfdev, bool enable_job_int)
{
+ guard(rwsem_write)(&pfdev->reset.lock);
+
panfrost_gpu_soft_reset(pfdev);
panfrost_gpu_power_on(pfdev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h b/drivers/gpu/drm/panfrost/panfrost_device.h
index a0b9a2145fc9..63452febb1cf 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -165,6 +165,7 @@ struct panfrost_device {
struct {
struct workqueue_struct *wq;
struct work_struct work;
+ struct rw_semaphore lock;
atomic_t pending;
} reset;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
index da10eee85ca2..a141a41e224b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -41,9 +41,12 @@ static int panfrost_ioctl_query_timestamp(struct panfrost_device *pfdev,
if (ret)
return ret;
- panfrost_cycle_counter_get(pfdev);
- *arg = panfrost_timestamp_read(pfdev);
- panfrost_cycle_counter_put(pfdev);
+ /* We should not read timestamp register while the GPU is being reset */
+ scoped_guard(rwsem_read, &pfdev->reset.lock) {
+ panfrost_cycle_counter_get(pfdev);
+ *arg = panfrost_timestamp_read(pfdev);
+ panfrost_cycle_counter_put(pfdev);
+ }
pm_runtime_put(pfdev->base.dev);
return 0;
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c
index ab65786bf63b..4ddf4b722ddf 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -877,6 +877,7 @@ int panfrost_jm_init(struct panfrost_device *pfdev)
INIT_WORK(&pfdev->reset.work, panfrost_reset_work);
spin_lock_init(&js->job_lock);
mutex_init(&pfdev->sched_lock);
+ init_rwsem(&pfdev->reset.lock);
js->irq = platform_get_irq_byname(to_platform_device(pfdev->base.dev), "job");
if (js->irq < 0)
--
2.55.0
next prev parent reply other threads:[~2026-10-12 14:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 14:47 [PATCH v15 00/15] Collection of fixes for Panfrost: Perfcnt, RPM, refactorings Adrián Larumbe
2026-10-12 14:47 ` [PATCH v15 01/15] drm/panfrost: Move shrinker initialization and unplug one level down Adrián Larumbe
2026-10-12 14:47 ` [PATCH v15 02/15] drm/panfrost: Move lock and modparam initialisations into their subsystems Adrián Larumbe
2026-10-12 14:47 ` [PATCH v15 03/15] drm/panfrost: Move debugfs initialisation to relevant subsystems Adrián Larumbe
2026-10-12 14:47 ` [PATCH v15 04/15] drm/panfrost: Skip NULL checks for clock enable/disabling Adrián Larumbe
2026-10-12 14:47 ` [PATCH v15 05/15] drm/panfrost: Consolidate device clock management and reset Adrián Larumbe
2026-10-12 14:47 ` [PATCH v15 06/15] drm/panfrost: Fix PM refcnt and autosuspend issues at device probe/remove Adrián Larumbe
2026-10-12 14:47 ` [PATCH v15 07/15] drm/panfrost: Explicitly enable MMU interrupts at device init Adrián Larumbe
2026-10-12 14:48 ` [PATCH v15 08/15] drm/panfrost: Move all DRM device initialisation into device_init() Adrián Larumbe
2026-10-12 14:48 ` [PATCH v15 09/15] drm/panfrost: Warn of RPM get failure at device remove time Adrián Larumbe
2026-10-12 14:48 ` [PATCH v15 10/15] drm/panfrost: Add debugfs knob for manually triggering a GPU reset Adrián Larumbe
2026-10-12 14:48 ` [PATCH v15 11/15] drm/panfrost: Move perfcnt GPU disable sequence into a helper Adrián Larumbe
2026-10-12 14:48 ` [PATCH v15 12/15] drm/panfrost: Skip cache flush/invalidate when enabling perfcnt Adrián Larumbe
2026-10-12 14:48 ` [PATCH v15 13/15] drm/panfrost: Avoid cache flush after perfcnt sample in fully coherent systems Adrián Larumbe
2026-10-12 14:48 ` Adrián Larumbe [this message]
2026-10-12 14:48 ` [PATCH v15 15/15] drm/panfrost: Fix races between perfcnt and reset sequence Adrián Larumbe
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=20261012-claude-fixes-v15-14-bc0a6c498553@collabora.com \
--to=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=faith.ekstrand@collabora.com \
--cc=hanetzer@startmail.com \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tomeu@tomeuvizoso.net \
--cc=tzimmermann@suse.de \
/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®