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

Tue Feb 17 09:00:01 PST 2026

Hi Angelo and Macpaul,

On Fri, 2026-02-13 at 16:07 +0000, Macpaul Lin (林智斌) wrote:
> 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. 
> 
This issue was indeed fixed by commit c1bac49fe91f ("pmdomains: mtk-pm-
domains: Fix spinlock recursion in probe"), that was merged for v6.18
release.
I did not reproduce it with stable or linux-next tags since then, on
the Genio boards I'm using.

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

There are still some error logs related to mtk-msdc on Genio 1200-EVK
board like those but unrelated to this issue. They appear during boot
when no sdcard is inserted in the micro sd connector.
It seems there is no card detection GPIO present on the board that
could be used to prevent those log occurrences.

There is also cases when emmc is enumerated as mmc1 (and sd as mmc0),
as no mmc alias is declared in this board devicetree.
I'll send a patch to add them.

Regards,
Louis-Alexis

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