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

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

Il 29/10/25 05:11, 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
>>
> 

Hello Macpaul,

> I did a git bisect on linux-next master branch and
> the result shows c29345fa5f66bea0790cf2219f57b974d4fc177b is the first
> bad commit. This change also affect MT8195.
> 
> This patch couldn't be simply reverted because there are some dependent
> commits follows this change.
> I'm not sure it this refactor causes API or flag not synced with the
> SCP firmware.

There's no interaction with the SCP on this patch.

> Just a remind that it is hard for MediaTek to update scp firmware for
> an already in mass production state chip.
> Each scp firmware and the pm-domain interface are designed specifically
> for 'that' chip only. So it is difficult to adopt pm-domain refactor
> by only reviewing the patch.

There's no need to update the SCP firmware at all - the pmdomain driver
does not communicate with that - infact, you can keep using all of the
pmdomains without ever loading any SCP firmware from the kernel.

> 
> Here are the error logs with latest linux-next master on mt8395-genio-
> 1200-evk. Hope this could help on futher debugging.
> 

Thanks for the logs! Getting issues on MSDC is really odd because the MSDC
controller does *not* use nor have any power domain...

I'll take a look at this as soon as I can, anyway.

Thanks again,
Angelo

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