From: Boris Brezillon <boris.brezillon@collabora.com>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Steven Price <steven.price@arm.com>,
Liviu Dudau <liviu.dudau@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>,
Grant Likely <grant.likely@linaro.org>,
Heiko Stuebner <heiko@sntech.de>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
kernel@collabora.com
Subject: Re: [PATCH v2 3/3] drm/panthor: Add tracepoints for cache flushing
Date: Mon, 3 Aug 2026 11:03:58 +0200 [thread overview]
Message-ID: <20260803110358.31afad0b@fedora1.home> (raw)
In-Reply-To: <20260730-panthor-cache-flush-fix-v2-3-28790478bfff@collabora.com>
On Thu, 30 Jul 2026 13:45:16 +0200
Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> Add two new event tracepoints: gpu_cache_flush_start to be emitted after
> acquiring the flush mutex and reqs spinlock, and gpu_cache_flush_end to
> be emitted when leaving the function.
>
> This allows debugging the duration a flush takes irrespective of initial
> function entry lock contention by subtracting the start tracepoint's
> timestamp from the end tracepoint timestamp, and additionally contains
> information such as which caches were flushed.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/panthor/panthor_gpu.c | 3 ++
> drivers/gpu/drm/panthor/panthor_trace.h | 49 +++++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c b/drivers/gpu/drm/panthor/panthor_gpu.c
> index f015bde80abf..a25955ad668b 100644
> --- a/drivers/gpu/drm/panthor/panthor_gpu.c
> +++ b/drivers/gpu/drm/panthor/panthor_gpu.c
> @@ -336,6 +336,7 @@ int panthor_gpu_flush_caches(struct panthor_device *ptdev,
> guard(mutex)(&ptdev->gpu->cache_flush_lock);
>
> spin_lock(&ptdev->gpu->reqs_lock);
> + trace_gpu_cache_flush_start(ptdev->base.dev, l2, lsc, other);
> if (!(ptdev->gpu->pending_reqs & GPU_IRQ_CLEAN_CACHES_COMPLETED)) {
> ptdev->gpu->pending_reqs |= GPU_IRQ_CLEAN_CACHES_COMPLETED;
> gpu_write(gpu->iomem, GPU_CMD, GPU_FLUSH_CACHES(l2, lsc, other));
> @@ -345,6 +346,7 @@ int panthor_gpu_flush_caches(struct panthor_device *ptdev,
>
> if (ret) {
> spin_unlock(&ptdev->gpu->reqs_lock);
> + trace_gpu_cache_flush_end(ptdev->base.dev, l2, lsc, other);
Should we add a status to the end event, so that faulty flushes can
be filtered out (those can be immediate, or timeout=100ms depending on
where the failure happens, but they are not reflecting anything useful,
and would pollute the stats)? Actually, if what we care about is the
time it takes to do a flush, do we even need those start/end events,
can't we pass the time as an argument and do the math in the function
like we do in the job IRQ handler?
> return ret;
> }
>
> @@ -358,6 +360,7 @@ int panthor_gpu_flush_caches(struct panthor_device *ptdev,
> ptdev->gpu->pending_reqs &= ~GPU_IRQ_CLEAN_CACHES_COMPLETED;
> }
> spin_unlock(&ptdev->gpu->reqs_lock);
> + trace_gpu_cache_flush_end(ptdev->base.dev, l2, lsc, other);
>
> if (ret) {
> panthor_device_schedule_reset(ptdev);
> diff --git a/drivers/gpu/drm/panthor/panthor_trace.h b/drivers/gpu/drm/panthor/panthor_trace.h
> index 6ffeb4fe6599..6951b95b1de7 100644
> --- a/drivers/gpu/drm/panthor/panthor_trace.h
> +++ b/drivers/gpu/drm/panthor/panthor_trace.h
> @@ -76,6 +76,55 @@ TRACE_EVENT(gpu_job_irq,
> __entry->events, __entry->duration_ns)
> );
>
> +DECLARE_EVENT_CLASS(gpu_cache_flush_template,
> + TP_PROTO(const struct device *dev, u32 l2, u32 lsc, u32 other),
> + TP_ARGS(dev, l2, lsc, other),
> + TP_STRUCT__entry(
> + __string(dev_name, dev_name(dev))
> + __field(u32, l2)
> + __field(u32, lsc)
> + __field(u32, other)
> + ),
> + TP_fast_assign(
> + __assign_str(dev_name);
> + __entry->l2 = l2;
> + __entry->lsc = lsc;
> + __entry->other = other;
> + ),
> + TP_printk("%s: l2=0x%x lsc=0x%x other=0x%x", __get_str(dev_name),
> + __entry->l2, __entry->lsc, __entry->other)
> +);
> +
> +/**
> + * gpu_cache_flush_start - called after cache flush locks taken, before flush
> + * @dev: pointer to the &struct device, for printing the device name
> + * @l2: "l2" flush flags
> + * @lsc: "lsc" flush flags
> + * @other: "other" flush flags
> + *
> + * Fires after any initial lock contention around the locks needed for flushing
> + * caches, but before the actual cache flush is requested.
> + */
> +DEFINE_EVENT(gpu_cache_flush_template, gpu_cache_flush_start,
> + TP_PROTO(const struct device *dev, u32 l2, u32 lsc, u32 other),
> + TP_ARGS(dev, l2, lsc, other)
> +);
> +
> +/**
> + * gpu_cache_flush_end - called after cache flush
> + * @dev: pointer to the &struct device, for printing the device name
> + * @l2: "l2" flush flags
> + * @lsc: "lsc" flush flags
> + * @other: "other" flush flags
> + *
> + * Fires after either the cache flush is complete, or has failed. Can be used
> + * together with gpu_cache_flush_start to get how long the flush has taken.
> + */
> +DEFINE_EVENT(gpu_cache_flush_template, gpu_cache_flush_end,
> + TP_PROTO(const struct device *dev, u32 l2, u32 lsc, u32 other),
> + TP_ARGS(dev, l2, lsc, other)
> +);
> +
> #endif /* __PANTHOR_TRACE_H__ */
>
> #undef TRACE_INCLUDE_PATH
>
next prev parent reply other threads:[~2026-08-03 9:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 11:45 [PATCH v2 0/3] Rework panthor's cache flush and soft reset locking Nicolas Frattaroli
2026-07-30 11:45 ` [PATCH v2 1/3] wait: Introduce non-irq variants of wait_event_lock_timeout Nicolas Frattaroli
2026-07-30 15:08 ` Liviu Dudau
2026-07-31 8:00 ` Steven Price
2026-07-30 11:45 ` [PATCH v2 2/3] drm/panthor: Revisit reqs_lock handling in flush/reset paths Nicolas Frattaroli
2026-07-30 14:56 ` Liviu Dudau
2026-07-31 8:01 ` Steven Price
2026-08-03 8:53 ` Boris Brezillon
2026-08-03 13:13 ` Nicolas Frattaroli
2026-08-03 13:20 ` Nicolas Frattaroli
2026-08-03 15:59 ` Boris Brezillon
2026-07-30 11:45 ` [PATCH v2 3/3] drm/panthor: Add tracepoints for cache flushing Nicolas Frattaroli
2026-07-30 13:46 ` Steven Rostedt
2026-07-30 15:14 ` Liviu Dudau
2026-07-31 8:03 ` Steven Price
2026-08-03 9:03 ` Boris Brezillon [this message]
2026-08-04 14:44 ` Nicolas Frattaroli
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=20260803110358.31afad0b@fedora1.home \
--to=boris.brezillon@collabora.com \
--cc=airlied@gmail.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=grant.likely@linaro.org \
--cc=heiko@sntech.de \
--cc=juri.lelli@redhat.com \
--cc=kernel@collabora.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mripard@kernel.org \
--cc=nicolas.frattaroli@collabora.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/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