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

["Adrián Larumbe" <adrian.larumbe@collabora.com>]

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