Re: [PATCH v3 04/10] pmdomain: mediatek: Refactor bus protection regmaps retrieval

[AngeloGioacchino Del Regno]

Il 12/02/26 08:58, Macpaul Lin (林智斌) ha scritto:
> On Tue, 2025-10-14 at 11:59 +0200, AngeloGioacchino Del Regno wrote:
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> >
> >
> > Il 13/10/25 15:41, Sjoerd Simons ha scritto:
> > > Hey,
> > >
> > > On Tue, 2025-08-05 at 09:47 +0200, AngeloGioacchino Del Regno
> > > wrote:
> > > > In preparation to add support for new generation SoCs like
> > > > MT8196,
> > > > MT6991 and other variants, which require to set bus protection on
> > > > different busses than the ones found on legacy chips, and to also
> > > > simplify and reduce memory footprint of this driver, refactor the
> > > > mechanism to retrieve and use the bus protection regmaps.
> > > >
> > > > This is done by removing the three pointers to struct regmap from
> > > > struct scpsys_domain (allocated for each power domain) and moving
> > > > them to the main struct scpsys (allocated per driver instance) as
> > > > an array of pointers to regmap named **bus_prot.
> > >
> > > Trying to boot v6.18.0-rc1 on a Genio 700 EVK using the arm64
> > > defconfig,
> > > ends up hanging at boot (seemingly when probing MTU3 and/or mmc,
> > > but that
> > > might be a red herring).
> > >
> > > Either reverting this patch *or* having CONFIG_MTK_MMSYS builtin
> > > rather
> > > then a module seems to solve that.
> >
> > Thanks for the report.
> >
> > This is not a problem with this patch specifically, but surely some
> > race condition
> > that was already present before and that does get uncovered with this
> > one in some
> > conditions.
> >
> > Without the devicetree updates (which are not upstream yet) this
> > patch is
> > fully retaining the legacy functionality 1-to-1.
> >
> > I'll check what's going on ASAP.
> >
> > Cheers,
> > Angelo
>
> This issue also happened on mt8195. I've done bisect on linux-next
> master with mt8195-genio-1200-evk board.
> The result shows c29345fa5f66bea0790cf2219f57b974d4fc177b is the first
> bad commit.
>
> I cannot simply revert this commit since there are some dependencies
> commits.
>
> I'm not sure if there are any API or flag change would
> affect interaction between the pm-domain driver and scp firmware.

I'm 99% sure that the SCP firmware has nothing to do with this - but then
even if it did, there's some quirk to be uncovered and properly handled.

So - if it is (again, most probably not) a firmware issue, it was only a
matter of time until this situation would've happened. It's pretty common
to see two wrongs making one thing right (but in 100% of the cases it does
eventually break).

> Just a remind it is hard for MediaTek to update scp firmware for a
> mass production chip. Each scp firmware seems specifically designed for
> each chip separately which leads the API might be changed between each
> chip.

Adding Louis-Alexis to the loop;

Louis, can you please try to reproduce this one on any of our boards?
I can't seem to be able to reproduce here.

Cheers,
Angelo

> The error log occurs on emmc at first and than rcu_preempt happens.
> [    1.291055] mtk-msdc 11240000.mmc: msdc_track_cmd_data: cmd=8
> arg=000001AA; host->error=0x00000002
> [    1.292775] mtk-msdc 11240000.mmc: msdc_track_cmd_data: cmd=55
> arg=00000000; host->error=0x00000002
> [    1.294539] mtk-msdc 11240000.mmc: msdc_track_cmd_data: cmd=55
> arg=00000000; host->error=0x00000002
> [    1.296293] mtk-msdc 11240000.mmc: msdc_track_cmd_data: cmd=55
> arg=00000000; host->error=0x00000002
> ...
> [    1.430408] mtk-msdc 11240000.mmc: msdc_track_cmd_data: cmd=55
> arg=00000000; host->error=0x00000002
> [    1.433766] mmc0: Failed to initialize a non-removable card
> [   22.297240] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> [   22.298723] rcu:     6-...0: (2 ticks this GP)
> idle=104c/1/0x4000000000000000 softirq=45/45 fqs=37
> [   22.299827] rcu:     (detected by 2, t=5256 jiffies, g=-1051, q=200
> ncpus=8)
> [   22.300689] Sending NMI from CPU 2 to CPUs 6:
> ...
>
> Best regards,
> Macpaul Lin