From: Steven Price <steven.price@arm.com>
To: "Adrián Larumbe" <adrian.larumbe@collabora.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Rob Herring" <robh@kernel.org>,
"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>,
Neil Armstrong <neil.armstrong@linaro.org>
Subject: Re: [PATCH v12 12/15] drm/panfrost: Skip cache flush/invalidate when enabling perfcnt
Date: Fri, 2 Oct 2026 16:14:38 +0100 [thread overview]
Message-ID: <95174a67-0eee-4bf7-b883-9f1138c74a6f@arm.com> (raw)
In-Reply-To: <20260929-claude-fixes-v12-12-62beb08de207@collabora.com>
On 29/09/2026 04:44, Adrián Larumbe wrote:
> The GPU cache flush/invalidate operation is unnecessary. First off, the
> GPU doesn't read off the perfcnt sample buffer, only writes into it, so
I don't think this is entirely true. The GPU performance counter unit
only writes the counters that are enabled, counters that share a cache
line but are not enabled are not written by the performance counter
unit, but if the L2 contains that cache line then the write can hit in
the L2 and dirty the entire line including stale data where the
unwritten cache line is.
The upshot is that if the CPU has cleared a block of memory which the
GPU happens to have cached, then the "unused" counters may end up
showing the old data before the CPU cleared it (if they share a cache
line with an active counter).
I have to admit it's probably somewhat academic given that Panfrost
doesn't expose the ability to control which counters are enabled...
Is there a good reason for this patch (i.e. have you seen a performance
problem with doing the invalidate)? Otherwise I'd prefer we keep to the
safe route rather than trying to over optimise cache maintenance.
Obviously in the fully coherent case the invalidate could be skipped (as
in the next patch).
Thanks,
Steve
> an invalidate doesn't make a difference. Then flushing GPU caches after
> each sample has been written is enough for the CPU to see updated values.
>
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
> ---
> drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 15 ++-------------
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
> index f71534e741b6..ffc77121070e 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
> @@ -124,21 +124,10 @@ static int panfrost_perfcnt_enable_locked(struct panfrost_device *pfdev,
> panfrost_gem_internal_set_label(&bo->base, "Perfcnt sample buffer");
>
> /*
> - * Invalidate the cache and clear the counters to start from a fresh
> - * state.
> + * Clear the counters to start from a fresh state.
> */
> - reinit_completion(&pfdev->perfcnt->dump_comp);
> - gpu_write(pfdev, GPU_INT_CLEAR,
> - GPU_IRQ_CLEAN_CACHES_COMPLETED |
> - GPU_IRQ_PERFCNT_SAMPLE_COMPLETED);
> + gpu_write(pfdev, GPU_INT_CLEAR, GPU_IRQ_PERFCNT_SAMPLE_COMPLETED);
> gpu_write(pfdev, GPU_CMD, GPU_CMD_PERFCNT_CLEAR);
> - gpu_write(pfdev, GPU_CMD, GPU_CMD_CLEAN_INV_CACHES);
> - ret = wait_for_completion_timeout(&pfdev->perfcnt->dump_comp,
> - msecs_to_jiffies(1000));
> - if (!ret) {
> - ret = -ETIMEDOUT;
> - goto err_vunmap;
> - }
>
> ret = panfrost_mmu_as_get(pfdev, perfcnt->mapping->mmu);
> if (ret < 0)
>
next prev parent reply other threads:[~2026-10-02 15:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 3:44 [PATCH v12 00/15] Collection of fixes for Panfrost: Perfcnt, RPM, refactorings Adrián Larumbe
2026-09-29 3:44 ` [PATCH v12 01/15] drm/panfrost: Move shrinker initialization and unplug one level down Adrián Larumbe
2026-10-02 13:58 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 02/15] drm/panfrost: Move lock and modparam initialisations into their subsystems Adrián Larumbe
2026-10-02 14:06 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 03/15] drm/panfrost: Move debugfs initialisation to relevant subsystems Adrián Larumbe
2026-10-02 14:10 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 04/15] drm/panfrost: Skip NULL checks for clock enable/disabling Adrián Larumbe
2026-10-02 14:14 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 05/15] drm/panfrost: Consolidate device clock management and reset Adrián Larumbe
2026-10-02 14:20 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 06/15] drm/panfrost: Fix PM refcnt and autosuspend issues at device probe/remove Adrián Larumbe
2026-10-02 14:21 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 07/15] drm/panfrost: Explicitly enable MMU interrupts at device init Adrián Larumbe
2026-10-02 14:26 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 08/15] drm/panfrost: Move all DRM device initialisation into device_init() Adrián Larumbe
2026-10-02 14:37 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 09/15] drm/panfrost: Add warning messages to fatal error conditions Adrián Larumbe
2026-10-02 14:59 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 10/15] drm/panfrost: Add debugfs knob for manually triggering a GPU reset Adrián Larumbe
2026-10-02 15:10 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 11/15] drm/panfrost: Move perfcnt GPU disable sequence into a helper Adrián Larumbe
2026-09-29 3:44 ` [PATCH v12 12/15] drm/panfrost: Skip cache flush/invalidate when enabling perfcnt Adrián Larumbe
2026-10-02 15:14 ` Steven Price [this message]
2026-09-29 3:44 ` [PATCH v12 13/15] drm/panfrost: Avoid cache flush after perfcnt sample in fully coherent systems Adrián Larumbe
2026-10-02 15:28 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 14/15] drm/panfrost: Introduce a reset lock Adrián Larumbe
2026-10-02 15:34 ` Steven Price
2026-09-29 3:44 ` [PATCH v12 15/15] drm/panfrost: Fix races between perfcnt and reset sequence Adrián Larumbe
2026-10-02 15:44 ` Steven Price
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=95174a67-0eee-4bf7-b883-9f1138c74a6f@arm.com \
--to=steven.price@arm.com \
--cc=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=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®