On Thu, 2026-02-12 at 12:15 +0100, AngeloGioacchino Del Regno wrote:

Il 12/02/26 08:58, Macpaul Lin (林智斌) ha scritto:

quoted

On Tue, 2025-10-14 at 11:59 +0200, AngeloGioacchino Del Regno
wrote:

quoted

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:

quoted

Hey,

On Tue, 2025-08-05 at 09:47 +0200, AngeloGioacchino Del Regno
wrote:

quoted

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

quoted

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. 

quoted

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