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

[Macpaul Lin (林智斌)]

On Thu, 2026-02-12 at 12:15 +0100, AngeloGioacchino Del Regno wrote:
> 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
> 
> 

Angelo and Louis, 
Please put this issue to low priority.
I did reported this issue but it should be quite a while from now.

I'm not sure why and how the mail client or mail server send out this
mail so late, and it has been sent twice until I've discovered right
now.
I guess this issue has been gone during 6.18-rcX period.
However, double check the latest status with latest kernel version is
good. I think it should be fixed already with AFBC patch or something
around that time. 

> > 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
> > 
> 
> 
Best regards,
Macpaul Lin