On Tue, 2023-09-19 at 13:07 +0800, Chen-Yu Tsai wrote: > On Tue, Sep 19, 2023 at 9:17 AM Mathieu Poirier > <mathieu.poir...@linaro.org> wrote: > > > > On Mon, Sep 18, 2023 at 06:44:25PM +0800, Chen-Yu Tsai wrote: > > > On Mon, Sep 18, 2023 at 6:32 PM Laura Nao <laura....@collabora.com> wrote: > > > > > > > > > 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-we...@chromium.org/
My version[1] is inspired by Angelo's work[2]. [1] https://lore.kernel.org/all/20230920084611.30890-1-tinghan.s...@mediatek.com/ [2] https://lore.kernel.org/all/20230919092336.51007-1-angelogioacchino.delre...@collabora.com/ Best regards, TingHan
