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 <[email protected]>
> > > wrote:
> > >
> > > On Wed, 30 Sep 2026 12:56:29 +0000, Christian Hewitt
> > > <[email protected]> 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
