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

["Macpaul Lin (林智斌)" <Macpaul.Lin@mediatek.com>]

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
> 

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

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

[    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