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