From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Ulf Hansson <ulf.hansson@oss.qualcomm.com>,
Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: Ulf Hansson <ulfh@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v1] pmdomain: mediatek: Fix MT8183 hang on boot
Date: Mon, 27 Jul 2026 13:04:37 +0200 [thread overview]
Message-ID: <3130633c-fbff-4b1a-a127-bd4eb678c3f6@collabora.com> (raw)
In-Reply-To: <CAPx+jO-1_ZpYcnPtoYxRn5vv34tiP7TXnjKZ3SaWkEzdeTfXpA@mail.gmail.com>
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.
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...
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.
Cheers,
Angelo
>> happening, the sync_state() functionality must be obliterated on all of
>> the MFG domains: while this guarantees a power leakage if the bootloader
>> boots the kernel with MFG PDs partially powered on, this is the only way
>> to ensure stable operation of the SoC during boot on devices with such
>> firmware because, of course, those will never officially receive a
>> firmware update.
>>
>> Fixes Kappa Chromebook hanging during system boot.
>>
>> Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state")
>> Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>
> Kind regards
> Uffe
>
>> ---
>> drivers/pmdomain/mediatek/mt8183-pm-domains.h | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pmdomain/mediatek/mt8183-pm-domains.h b/drivers/pmdomain/mediatek/mt8183-pm-domains.h
>> index 3742782a2702..5e33b8628e85 100644
>> --- a/drivers/pmdomain/mediatek/mt8183-pm-domains.h
>> +++ b/drivers/pmdomain/mediatek/mt8183-pm-domains.h
>> @@ -47,7 +47,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = 0,
>> .sram_pdn_ack_bits = 0,
>> - .caps = MTK_SCPD_DOMAIN_SUPPLY,
>> + .caps = MTK_SCPD_DOMAIN_SUPPLY | MTK_SCPD_KEEP_DEFAULT_OFF,
>> },
>> [MT8183_POWER_DOMAIN_MFG] = {
>> .name = "mfg",
>> @@ -57,7 +57,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> - .caps = MTK_SCPD_DOMAIN_SUPPLY,
>> + .caps = MTK_SCPD_DOMAIN_SUPPLY | MTK_SCPD_KEEP_DEFAULT_OFF,
>> },
>> [MT8183_POWER_DOMAIN_MFG_CORE0] = {
>> .name = "mfg_core0",
>> @@ -67,6 +67,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>> },
>> [MT8183_POWER_DOMAIN_MFG_CORE1] = {
>> .name = "mfg_core1",
>> @@ -76,6 +77,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>> },
>> [MT8183_POWER_DOMAIN_MFG_2D] = {
>> .name = "mfg_2d",
>> @@ -85,6 +87,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>> .bp_cfg = {
>> BUS_PROT_WR(INFRA,
>> MT8183_TOP_AXI_PROT_EN_1_MFG,
>> --
>> 2.54.0
>>
next prev parent reply other threads:[~2026-07-27 11:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 13:27 [PATCH v1] pmdomain: mediatek: Fix MT8183 hang on boot Dmitry Osipenko
2026-07-22 14:31 ` AngeloGioacchino Del Regno
2026-07-24 15:01 ` Ulf Hansson
2026-07-27 11:04 ` AngeloGioacchino Del Regno [this message]
2026-07-27 16:48 ` Ulf Hansson
2026-07-25 5:11 ` Brady Norander
2026-07-27 10:57 ` AngeloGioacchino Del Regno
2026-07-27 17:38 ` Brady Norander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3130633c-fbff-4b1a-a127-bd4eb678c3f6@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=dmitry.osipenko@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=ulf.hansson@oss.qualcomm.com \
--cc=ulfh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox