Thread (31 messages) 31 messages, 5 authors, 2023-09-20

Re: [PATCH v17 00/14] Add support for MT8195 SCP 2nd core

From: TingHan Shen (沈廷翰) <hidden>
Date: 2023-09-20 08:51:32
Also in: linux-arm-kernel, linux-mediatek, linux-remoteproc, lkml

On Tue, 2023-09-19 at 13:07 +0800, Chen-Yu Tsai wrote:
On Tue, Sep 19, 2023 at 9:17 AM Mathieu Poirier
[off-list ref] wrote:
quoted
On Mon, Sep 18, 2023 at 06:44:25PM +0800, Chen-Yu Tsai wrote:
quoted
On Mon, Sep 18, 2023 at 6:32 PM Laura Nao [off-list ref] wrote:
quoted
quoted
Other than patch 2 and 14, I have applied this set.  The remaining patches will
have to be resent to Matthias.
Thanks,
Mathieu
Hello,

With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:

10696 04:33:59.126671  <3>[   15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
10697 04:33:59.142855  <3>[   15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
10698 04:33:59.149650  <3>[   15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc

The issue was caught by KernelCI, complete logs can be found here:
- asurada: https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html__;Kys!!CTRNKA9wMg0ARbw!iEMruK4bVWfCmhRmyauJtkTioHdQbYP3DwhnGUZNxbKYhMzusmoIjYOnpVNALoMobUdKhooUYw6OxUmrqNE$ 
- kukui: https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html__;Kys!!CTRNKA9wMg0ARbw!iEMruK4bVWfCmhRmyauJtkTioHdQbYP3DwhnGUZNxbKYhMzusmoIjYOnpVNALoMobUdKhooUYw6OhRxz6NQ$ 

Reporting the issue so that patch 2 and 14 can be resent and merged soon.
This being a backward incompatible DT binding change, maybe we should revert
the node name change. Or, the driver could simply count the number of child
nodes that have the "mediatek,rpmsg-name" property, which is required.
You have a point.  Can someone send a patch that makes this patchset backward
compatible?  Please do so as quickly as possible to that it can go in the next
merge window with the rest of this feature.  Otherwize I'll have to back out the
whole thing.
I sent out a patch [1] implementing my proposed change.

ChenYu

[1] https://lore.kernel.org/linux-remoteproc/20230919050305.3817347-1-wenst@chromium.org/ (local)
My version[1] is inspired by Angelo's work[2].

[1] https://lore.kernel.org/all/20230920084611.30890-1-tinghan.shen@mediatek.com/ (local)
[2] https://lore.kernel.org/all/20230919092336.51007-1-angelogioacchino.delregno@collabora.com/ (local)
 
Best regards,
TingHan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help