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

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

On 7/27/26 18:48, Ulf Hansson wrote:
> On Mon, Jul 27, 2026 at 1:04 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> On 7/24/26 17:01, Ulf Hansson wrote:
>>> On Wed, Jul 22, 2026 at 3:28 PM Dmitry Osipenko
>>> <dmitry.osipenko@collabora.com> 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?
> 

Yeah...

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

Eh, that's not possible :-(

Doing that would bring us back to square 1. The SoC will lockup.... ACP is still
trying to constantly prefetch, and the issue here is going totally unpowered, as
explained in the commit description - because that's the HW condition that causes
the stall eventually.

To make things "funnier" (in this case) for everyone, the ACP is always-on, of
course, so there's no cleaner way around it.

>>
>> 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.
> 

Eh for both me and Dmitry the commit message looked clear, but yeah, it's surely
just because we bashed our heads over this issue, and our knowledge makes things
look obvious when they are definitely *not*, as you just pointed out - so thanks
for that!

So yeah, Dmitry, if you can please send a v2 with some more clarification in the
commit message (practically, add the information that I shared in this topic),
that would be awesome.

> 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.
> 

Yeah, the bootloader is doing random things, leaving the PDs only partially powered
ON (just the SRAM, which is half of the MFG_ASYNC setup, and 2D accelerator, but
not the rest, which makes little sense because there's another parent in the middle
that is not powered at all...) and that's why this issue is experienced.

I think this is really just a bootloader bug in this case, so if we lived in a
parallel universe where the MediaTek kernel drivers supported continuous splash on
upstream... I'm mostly sure that this issue would still be there, and that this SoC
would still randomly and spectacularly freeze without this commit.

Cheers,
Angelo


> [...]
> 
> Kind regards
> Uffe