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@xxxxxxxxxxxxx> wrote:
> > > 
> > > On Wed, 30 Sep 2026 12:56:29 +0000, Christian Hewitt <christianshewitt@xxxxxxxxx> 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