Re: [PATCH v1] pmdomain: mediatek: Fix MT8183 hang on boot

[Ulf Hansson]

On Mon, Jul 27, 2026 at 1:04 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@xxxxxxxxxxxxx> wrote:
>
> On 7/24/26 17:01, Ulf Hansson wrote:
> > On Wed, Jul 22, 2026 at 3:28 PM Dmitry Osipenko
> > <dmitry.osipenko@xxxxxxxxxxxxx> wrote:
> >>
> >> Depending on firmware, part of the MFG domains may be left ON at boot
> >> leaving only some MFG cores powered, to let the ACP to prefetch the GPU
> >> region when the display controller is brought up. This doesn't play well
> >> with an eventual delay in probing Panfrost when the display controller is
> >> fully set up, as that would make genpd's sync_state() to power off the
> >> domain while ACP tries to prefetch: this is causing an AXI stall,
> >> effectively freezing the AP indefinitely. In order to prevent this from
> >
> > I haven't made any detailed investigation, but to me, it sounds like
> > there is a missing consumer somewhere.
> >
> > Should the ACP/panfrost devices be a consumer of the MFG domains as
> > well? Or perhaps, if the ACP/panfrost should rely on the display
> > controller to be probed and powered-on, to be able to probe?
> >
>
> This is about how the bootloader is leaving the display controller, the ACP,
> and the MFG registers before booting the kernel.

Right.

>
> The kernel drivers themselves will reset this weird state when the HW gets
> to full probe so there won't be any more issue(s) from that point onwards.
>
> Actually, there would be A LOT to say about this, but I'll be very brief...
>
> Basically, before booting the kernel, the bootloader is leaving a half-assed
> setup to potentially support continuous splash functionality, but without it
> being actually used on the device(s) that we're talking about here...

So does that mean that the print in scpsys_add_one_domain() ("A
default off power domain has been ON") gets printed for these PM
domains?

If so, perhaps it would be better to turn off the PM domains (if
possible) before registering them with genpd?

>
> Again, I should put a remark on every word of that last paragraph, but this
> is the gist of it.
>
> If you're curious or need more information, of course I can expand a bit,
> there's no secret involved here, it's just that I'm avoiding to write a wall
> of text around that...
>
> P.S.: We've been discussing that internally and chasing this issue for months
> before deciding to "solve" it like this.

Huh, I see, thanks for sharing.

I think it would be nice to clarify a little bit more in the commit
message, as it all kind of indicates to me that there is a missing
consumer or that a parent needs to be runtime resumed before a child
is probed.

Or another way of looking at it, that perhaps makes better sense.
Based on your latest information, it seems like the PM domain isn't
really fully powered-on by the bootloader, but still we are telling
genpd that it is, leading to an inconsistent state and errors.

[...]

Kind regards
Uffe