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

[AngeloGioacchino Del Regno]

Il 29/10/25 05:11, 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

Hello Macpaul,

> I did a git bisect on linux-next master branch and
> the result shows c29345fa5f66bea0790cf2219f57b974d4fc177b is the first
> bad commit. This change also affect MT8195.
>
> This patch couldn't be simply reverted because there are some dependent
> commits follows this change.
> I'm not sure it this refactor causes API or flag not synced with the
> SCP firmware.

There's no interaction with the SCP on this patch.

> Just a remind that it is hard for MediaTek to update scp firmware for
> an already in mass production state chip.
> Each scp firmware and the pm-domain interface are designed specifically
> for 'that' chip only. So it is difficult to adopt pm-domain refactor
> by only reviewing the patch.

There's no need to update the SCP firmware at all - the pmdomain driver
does not communicate with that - infact, you can keep using all of the
pmdomains without ever loading any SCP firmware from the kernel.

> Here are the error logs with latest linux-next master on mt8395-genio-
> 1200-evk. Hope this could help on futher debugging.

Thanks for the logs! Getting issues on MSDC is really odd because the MSDC
controller does *not* use nor have any power domain...

I'll take a look at this as soon as I can, anyway.

Thanks again,
Angelo

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