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

[Macpaul Lin (林智斌)]

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

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