[PATCH] drm/panfrost: reset the Amlogic GXM GPU on runtime resume

[PATCH] drm/panfrost: reset the Amlogic GXM GPU on runtime resume

[Christian Hewitt]

After its first runtime suspend, every power-off of the Mali-T820 in
Amlogic GXM SoCs times out and floods the log with shader, tiler and L2
power transition timeouts. Following a soft reset the cores report not
ready but PWRTRANS never clears, however long the driver waits.

The transitions complete normally when the GPU comes out of a hardware
reset, as it does at probe. Use runtime PM with reset and clock control
for GXM so the GPU is reset on every resume.

Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
 drivers/gpu/drm/panfrost/panfrost_drv.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 36cc2e67a308..df8a41a9a70f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -1092,6 +1092,13 @@ static const struct panfrost_compatible amlogic_data = {
 	.vendor_quirk = panfrost_gpu_amlogic_quirk,
 };
 
+static const struct panfrost_compatible amlogic_gxm_data = {
+	.num_supplies = ARRAY_SIZE(default_supplies) - 1,
+	.supply_names = default_supplies,
+	.vendor_quirk = panfrost_gpu_amlogic_quirk,
+	.pm_features = BIT(GPU_PM_RT),
+};
+
 static const char * const mediatek_pm_domains[] = { "core0", "core1", "core2",
 						    "core3", "core4" };
 /*
@@ -1156,7 +1163,7 @@ static const struct panfrost_compatible mediatek_mt8370_data = {
 static const struct of_device_id dt_match[] = {
 	/* Set first to probe before the generic compatibles */
 	{ .compatible = "amlogic,meson-gxm-mali",
-	  .data = &amlogic_data, },
+	  .data = &amlogic_gxm_data, },
 	{ .compatible = "amlogic,meson-g12a-mali",
 	  .data = &amlogic_data, },
 	{ .compatible = "renesas,r9a08g046-mali", .data = &default_pm_rt_data },
-- 
2.43.0

Re: [PATCH] drm/panfrost: reset the Amlogic GXM GPU on runtime resume

[Adrián Larumbe]

On Wed, 30 Sep 2026 12:56:29 +0000, Christian Hewitt <christianshewitt@gmail.com> wrote:
> After its first runtime suspend, every power-off of the Mali-T820 in
> Amlogic GXM SoCs times out and floods the log with shader, tiler and L2
> power transition timeouts. Following a soft reset the cores report not
> ready but PWRTRANS never clears, however long the driver waits.

Would you mind building the driver from the latest drm-misc-next and testing
whether this is still the case? Today I merged a patch series with a fix
for a long-standing bug that prevented the device from going into suspension
because of mismanagement of the PM refcount. It might be that what you report
as an issue triggered by power transitions is something altogether different.

> 
> The transitions complete normally when the GPU comes out of a hardware
> reset, as it does at probe. Use runtime PM with reset and clock control

panfrost_device_reset() is always called as part of the PM runtime resume
operation, so I'm assuming what you mean here is that reset control is
deasserted at runtime resume when the SoC supports it

-- 
Adrián Larumbe <adrian.larumbe@collabora.com>

Re: [PATCH] drm/panfrost: reset the Amlogic GXM GPU on runtime resume

[Christian Hewitt]

> On 13 Oct 2026, at 1:25 am, Adrián Larumbe <adrian.larumbe@collabora.com> wrote:
> 
> On Wed, 30 Sep 2026 12:56:29 +0000, Christian Hewitt <christianshewitt@gmail.com> wrote:
>> After its first runtime suspend, every power-off of the Mali-T820 in
>> Amlogic GXM SoCs times out and floods the log with shader, tiler and L2
>> power transition timeouts. Following a soft reset the cores report not
>> ready but PWRTRANS never clears, however long the driver waits.
> 
> Would you mind building the driver from the latest drm-misc-next and testing
> whether this is still the case? Today I merged a patch series with a fix
> for a long-standing bug that prevented the device from going into suspension
> because of mismanagement of the PM refcount. It might be that what you report
> as an issue triggered by power transitions is something altogether different.

I’d tested with the v12 iteration of your series in my amlogic-7.3.y [0] tree
before generating the patch I submitted. I’ve now tested with v15 (as merged)
and other recent panfrost patches you submitted (which v15 depends upon) and
with this patch reverted, and the timeout issue with T820 remains. I also saw
a splat that I wasn’t seeing with the v12 iteration [1].

[0] https://github.com/chewitt/linux/commits/amlogic-7.3.y
[1] https://paste.libreelec.tv/desertic-cataleya.log

After reinstating this patch on v15 + dependencies dmesg is clean again [2].

[2] https://paste.libreelec.tv/leptosomatic-cherlyn.log

>> The transitions complete normally when the GPU comes out of a hardware
>> reset, as it does at probe. Use runtime PM with reset and clock control
> 
> panfrost_device_reset() is always called as part of the PM runtime resume
> operation, so I'm assuming what you mean here is that reset control is
> deasserted at runtime resume when the SoC supports it

I’m firmly at the hobbyist end of kernel contributors and I’m not able to
technically explain the patch Claude created. It’s entirely possible that it
pokes around in the right area of code but is not the correct fix, but I lack
the knowledge to dig further without explicit guidance. I can also give you
remote access to a Khadas VIM2 board if that would be easier or useful?

Christian

Re: [PATCH] drm/panfrost: reset the Amlogic GXM GPU on runtime resume

[Adrián Larumbe]

Hi Christian,

On 13.10.2026 09:02, Christian Hewitt wrote:
> > On 13 Oct 2026, at 1:25 am, Adrián Larumbe <adrian.larumbe@collabora.com> wrote:
> > 
> > On Wed, 30 Sep 2026 12:56:29 +0000, Christian Hewitt <christianshewitt@gmail.com> wrote:
> >> After its first runtime suspend, every power-off of the Mali-T820 in
> >> Amlogic GXM SoCs times out and floods the log with shader, tiler and L2
> >> power transition timeouts. Following a soft reset the cores report not
> >> ready but PWRTRANS never clears, however long the driver waits.
> > 
> > Would you mind building the driver from the latest drm-misc-next and testing
> > whether this is still the case? Today I merged a patch series with a fix
> > for a long-standing bug that prevented the device from going into suspension
> > because of mismanagement of the PM refcount. It might be that what you report
> > as an issue triggered by power transitions is something altogether different.
> 
> I’d tested with the v12 iteration of your series in my amlogic-7.3.y [0] tree
> before generating the patch I submitted. I’ve now tested with v15 (as merged)
> and other recent panfrost patches you submitted (which v15 depends upon) and
> with this patch reverted, and the timeout issue with T820 remains. I also saw
> a splat that I wasn’t seeing with the v12 iteration [1].
> 
> [0] https://github.com/chewitt/linux/commits/amlogic-7.3.y
> [1] https://paste.libreelec.tv/desertic-cataleya.log

Turns out I was wrong about having easy access to a Khadas VIM2, so whatever I try to
gather about the existing bug must come from these logs. I see one very interesting
warning in [1]:

WARNING: drivers/gpu/drm/panfrost/panfrost_device.c:490 at panfrost_exception_name+0x1c/0x30 [panfrost], CPU#0: swapper/0/0

Something's causing the GPU to report a fault whose status code is at
present not documented in the driver.

I think that, because this seems like an SoC integration issue, and because of the unknown
exception being reported by the GPU, we should have some further input from an Amlogic SoC
subsystem maintainer, and also Steven Price himself.

> After reinstating this patch on v15 + dependencies dmesg is clean again [2].
> 
> [2] https://paste.libreelec.tv/leptosomatic-cherlyn.log
> 
> >> The transitions complete normally when the GPU comes out of a hardware
> >> reset, as it does at probe. Use runtime PM with reset and clock control
> > 
> > panfrost_device_reset() is always called as part of the PM runtime resume
> > operation, so I'm assuming what you mean here is that reset control is
> > deasserted at runtime resume when the SoC supports it
> 
> I’m firmly at the hobbyist end of kernel contributors and I’m not able to
> technically explain the patch Claude created. It’s entirely possible that it
> pokes around in the right area of code but is not the correct fix, but I lack
> the knowledge to dig further without explicit guidance. I can also give you
> remote access to a Khadas VIM2 board if that would be easier or useful?
> 
> Christian

Adrian Larumbe

Re: [PATCH] drm/panfrost: reset the Amlogic GXM GPU on runtime resume

[Adrián Larumbe]

CC: Neil Armstrong

On 14.10.2026 19:03, Adrián Larumbe wrote:
> Hi Christian,
> 
> On 13.10.2026 09:02, Christian Hewitt wrote:
> > > On 13 Oct 2026, at 1:25 am, Adrián Larumbe <adrian.larumbe@collabora.com> wrote:
> > > 
> > > On Wed, 30 Sep 2026 12:56:29 +0000, Christian Hewitt <christianshewitt@gmail.com> wrote:
> > >> After its first runtime suspend, every power-off of the Mali-T820 in
> > >> Amlogic GXM SoCs times out and floods the log with shader, tiler and L2
> > >> power transition timeouts. Following a soft reset the cores report not
> > >> ready but PWRTRANS never clears, however long the driver waits.
> > > 
> > > Would you mind building the driver from the latest drm-misc-next and testing
> > > whether this is still the case? Today I merged a patch series with a fix
> > > for a long-standing bug that prevented the device from going into suspension
> > > because of mismanagement of the PM refcount. It might be that what you report
> > > as an issue triggered by power transitions is something altogether different.
> > 
> > I’d tested with the v12 iteration of your series in my amlogic-7.3.y [0] tree
> > before generating the patch I submitted. I’ve now tested with v15 (as merged)
> > and other recent panfrost patches you submitted (which v15 depends upon) and
> > with this patch reverted, and the timeout issue with T820 remains. I also saw
> > a splat that I wasn’t seeing with the v12 iteration [1].
> > 
> > [0] https://github.com/chewitt/linux/commits/amlogic-7.3.y
> > [1] https://paste.libreelec.tv/desertic-cataleya.log
> 
> Turns out I was wrong about having easy access to a Khadas VIM2, so whatever I try to
> gather about the existing bug must come from these logs. I see one very interesting
> warning in [1]:
> 
> WARNING: drivers/gpu/drm/panfrost/panfrost_device.c:490 at panfrost_exception_name+0x1c/0x30 [panfrost], CPU#0: swapper/0/0
> 
> Something's causing the GPU to report a fault whose status code is at
> present not documented in the driver.
> 
> I think that, because this seems like an SoC integration issue, and because of the unknown
> exception being reported by the GPU, we should have some further input from an Amlogic SoC
> subsystem maintainer, and also Steven Price himself.
> 
> > After reinstating this patch on v15 + dependencies dmesg is clean again [2].
> > 
> > [2] https://paste.libreelec.tv/leptosomatic-cherlyn.log
> > 
> > >> The transitions complete normally when the GPU comes out of a hardware
> > >> reset, as it does at probe. Use runtime PM with reset and clock control
> > > 
> > > panfrost_device_reset() is always called as part of the PM runtime resume
> > > operation, so I'm assuming what you mean here is that reset control is
> > > deasserted at runtime resume when the SoC supports it
> > 
> > I’m firmly at the hobbyist end of kernel contributors and I’m not able to
> > technically explain the patch Claude created. It’s entirely possible that it
> > pokes around in the right area of code but is not the correct fix, but I lack
> > the knowledge to dig further without explicit guidance. I can also give you
> > remote access to a Khadas VIM2 board if that would be easier or useful?
> > 
> > Christian
> 
> Adrian Larumbe