From: Boris Brezillon <boris.brezillon@collabora.com>
To: Karunika Choo <karunika.choo@arm.com>
Cc: Ketil Johnsen <ketil.johnsen@arm.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>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
nd@arm.com
Subject: Re: [PATCH] drm/panthor: Ensure MCU is disabled on suspend
Date: Thu, 9 Oct 2025 11:39:14 +0200 [thread overview]
Message-ID: <20251009113914.665a2c25@fedora> (raw)
In-Reply-To: <30b8b782-1bf9-43bd-9022-67851ccef7a6@arm.com>
On Thu, 9 Oct 2025 09:42:08 +0100
Karunika Choo <karunika.choo@arm.com> wrote:
> On 08/10/2025 12:32, Boris Brezillon wrote:
> > On Wed, 8 Oct 2025 12:51:11 +0200
> > Ketil Johnsen <ketil.johnsen@arm.com> wrote:
> >
> >> Currently the Panthor driver needs the GPU to be powered down
> >> between suspend and resume. If this is not done, then the
> >> MCU_CONTROL register will be preserved as AUTO, which again will
> >> cause a premature FW boot on resume. The FW will go directly into
> >> fatal state in this case.
> >>
> >> This case needs to be handled as there is no guarantee that the
> >> GPU will be powered down after the suspend callback on all platforms.
> >>
> >> The fix is to call panthor_fw_stop() in "pre-reset" path to ensure
> >> the MCU_CONTROL register is cleared (set DISABLE). This matches
> >> well with the already existing call to panthor_fw_start() from the
> >> "post-reset" path.
> >>
> >> Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
> >> ---
> >> drivers/gpu/drm/panthor/panthor_fw.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c b/drivers/gpu/drm/panthor/panthor_fw.c
> >> index 9bf06e55eaee..df767e82148a 100644
> >> --- a/drivers/gpu/drm/panthor/panthor_fw.c
> >> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
> >> @@ -1099,6 +1099,7 @@ void panthor_fw_pre_reset(struct panthor_device *ptdev, bool on_hang)
> >> }
> >>
> >> panthor_job_irq_suspend(&ptdev->fw->irq);
> >> + panthor_fw_stop(ptdev);
> >
> > Is this not preventing fast resets? My understanding was that
> > MCU_CONTROL shouldn't be touched if the MCU was halted from the FW, but
> > maybe I got that wrong. If it's just for the MCU crash case, we can
> > have:
> >
> > if (on_hang)
> > panthor_fw_stop(ptdev);
> >
>
> Hi Boris, I think as long as the FW is properly halted, we can safely
> disable the MCU. In fact, because of the ptdev->reset.fast tracking, we
> can call panthor_fw_stop() in both cases, as the flag allows us to
> handle the resume path correctly.
>
> As per Ketil's commit message, if we don't clear the HALT bit on L2
> power on, the MCU can start booting the FW with the bit enabled, which
> in certain cases can make it fail to boot. So this patch fixes that by
> gating when the FW is allowed to boot.
>
> I also believe this behaviour will be better aligned with the expected
> behaviour from the FW of newer GPUs (Mali-G1 for example).
Okay, as long as you're sure it doesn't screw up the fast reset, I'm
happy to get that in.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
next prev parent reply other threads:[~2025-10-09 9:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 10:51 [PATCH] drm/panthor: Ensure MCU is disabled on suspend Ketil Johnsen
2025-10-08 11:32 ` Boris Brezillon
2025-10-09 8:42 ` Karunika Choo
2025-10-09 9:39 ` Boris Brezillon [this message]
2025-10-09 10:29 ` Steven Price
2025-10-09 11:45 ` Boris Brezillon
2025-10-09 12:51 ` 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=20251009113914.665a2c25@fedora \
--to=boris.brezillon@collabora.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=karunika.choo@arm.com \
--cc=ketil.johnsen@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nd@arm.com \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.