From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD5D223D297 for ; Wed, 17 Jun 2026 15:06:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781708791; cv=none; b=eIzckTPYDqTDMGllgPLp5/HejJx32u5GXzCJ6ZfQn0fazYEMpfFN5H+bv69LikDpnXSA5sgsDv7lVfZj7IR3oooryJdFTFvOd/2QGQV93I13JxE/69BFONWVoV7UxknuiqbXoNQD/mND7puqDU50k6atb9ktzeugppWTFeLJnUo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781708791; c=relaxed/simple; bh=E0oT6eCyZM4NVfKkZgPcky76Hvvth3FscTvPO3D6NpY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rO4ssP92b14n1mBqo78tmwhmJtC2jZwhzHNI40Uzr7QDnmXxV4vMCSh4IOBp1Eoc3NA6dhaPEg2Y5Xul7tbbZXcBuA4U3/sJg6DmId+teJc4QSvHbXq07QVdq9tAXDS6Ew+wilo62FzvACu/V8h9cB9YPUum+pPMENRvUFIWKW4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=iCAZvlQ8; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="iCAZvlQ8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1781708788; bh=E0oT6eCyZM4NVfKkZgPcky76Hvvth3FscTvPO3D6NpY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iCAZvlQ8kxuasMtXeV1ib0KE+uxtxh+o51QQAeDeUuzyu0utCk9Flvko7T6at/IL+ 3oRC/u8Cqe7hBqjcB7HnQv6j13M2DwBJRO884FGEhlzB8M17E0o/rO6GlcoMYQ64dp Uv24vEk5dLLRXf8WqgnPd0rcPjeKaXlLvzL28jdzkLZpeDuBUzKSYe4Fh96dDEvKxU LO7lhe9FfaG1h0cNRpBa+cymIhaV2tOc25cM3Ug7yDI0AKOKN7yPAZyVv1/MI6wBIB zVSnO1LKIZLjrHmYc5sXTB4FSIcmI/7RE09DIQ9lv0NK93WH5cpAYZxwXLZRGaYoXM jgwQnFarQHVJQ== Received: from fedora-2.home (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id CC8BF17E0432; Wed, 17 Jun 2026 17:06:27 +0200 (CEST) Date: Wed, 17 Jun 2026 17:06:24 +0200 From: Boris Brezillon To: Rob Herring , Steven Price , =?UTF-8?B?QWRyacOhbg==?= Larumbe Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/panfrost: Enable cycle counting when perfcnt is enabled Message-ID: <20260617170624.344e6924@fedora-2.home> In-Reply-To: <20260617-panfrost-perfcnt-timestamp-fix-v1-1-f215f44b55c0@collabora.com> References: <20260617-panfrost-perfcnt-timestamp-fix-v1-1-f215f44b55c0@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 17 Jun 2026 16:29:46 +0200 Boris Brezillon wrote: > If we don't do that, we end up with invalid timestamps in the > block headers. > > Fixes: 7786fd108777 ("drm/panfrost: Expose performance counters through unstable ioctls") > Signed-off-by: Boris Brezillon > --- > Found while reworking the userside of the perfcnt logic. > Up until now, we were not using the GPU timestamps in the dumps, > but this is going to change, so we need that fix in, and > backported to all stable releases, ideally. > --- > drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c > index 7020c0192e18..63861b4c7d95 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c > +++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c > @@ -15,6 +15,7 @@ > #include "panfrost_device.h" > #include "panfrost_features.h" > #include "panfrost_gem.h" > +#include "panfrost_gpu.h" > #include "panfrost_issues.h" > #include "panfrost_job.h" > #include "panfrost_mmu.h" > @@ -166,6 +167,7 @@ static int panfrost_perfcnt_enable_locked(struct panfrost_device *pfdev, > /* The BO ref is retained by the mapping. */ > drm_gem_object_put(&bo->base); > > + panfrost_cycle_counter_get(pfdev); As shashiko pointed out, the reset logic messes up with the cycle_counter refcounting. Adrian, I believe this is something we can address as part of the perfcnt fixes series you're working on (pre/post reset hooks for perfcnt so we can release/reacquire resources properly). > perfcnt->user = user; > > return 0; > @@ -207,6 +209,7 @@ static int panfrost_perfcnt_disable_locked(struct panfrost_device *pfdev, > panfrost_mmu_as_put(pfdev, perfcnt->mapping->mmu); > panfrost_gem_mapping_put(perfcnt->mapping); > perfcnt->mapping = NULL; > + panfrost_cycle_counter_put(pfdev); > pm_runtime_put_autosuspend(pfdev->base.dev); > > return 0; > > --- > base-commit: 7caf2a2351d4053075670ff3e26a6815da0a9e1e > change-id: 20260617-panfrost-perfcnt-timestamp-fix-51e04002f494 > > Best regards,