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

[AngeloGioacchino Del Regno]

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

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