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

[Christian Hewitt <christianshewitt@gmail.com>]

> 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