Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
MIME-Version: 1.0
References: <ZQH2dG+l/dONUsyi@p14s> <20230918103141.126271-1-laura.nao@collabora.com>
 <CAGXv+5Esi=G0xgkP=+Bhf39Xs3gMN1PBzarxKBKduOjgwDijAA@mail.gmail.com> <ZQj2lSl47qZQv8fX@p14s>
In-Reply-To: <ZQj2lSl47qZQv8fX@p14s>
From:   Chen-Yu Tsai <wenst@chromium.org>
Date:   Tue, 19 Sep 2023 13:07:26 +0800
Message-ID: <CAGXv+5Gj5rERcX6uxVUUq8beM4k4ogXnuh_86piyGw1oVrbyvg@mail.gmail.com>
Subject: Re: [PATCH v17 00/14] Add support for MT8195 SCP 2nd core
To:     Mathieu Poirier <mathieu.poirier@linaro.org>
Cc:     Laura Nao <laura.nao@collabora.com>, tinghan.shen@mediatek.com,
        angelogioacchino.delregno@collabora.com,
        Project_Global_Chrome_Upstream_Group@mediatek.com,
        andersson@kernel.org, conor+dt@kernel.org,
        devicetree@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-mediatek@lists.infradead.org,
        linux-remoteproc@vger.kernel.org, matthias.bgg@gmail.com,
        robh+dt@kernel.org, kernel@collabora.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Sep 19, 2023 at 9:17=E2=80=AFAM Mathieu Poirier
<mathieu.poirier@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=E2=80=AFPM Laura Nao <laura.nao@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 asur=
ada (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 an=
d MT8183 are multicore, leading to the following errors during initializati=
on:
> > >
> > > 10696 04:33:59.126671  <3>[   15.465714] platform 10500000.scp:cros-e=
c: invalid resource (null)
> > > 10697 04:33:59.142855  <3>[   15.478560] platform 10500000.scp:cros-e=
c: 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://storage.kernelci.org/next/master/next-20230914/arm=
64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt=
8192-asurada-spherion-r0.html
> > > - kukui: https://storage.kernelci.org/next/master/next-20230914/arm64=
/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt81=
83-kukui-jacuzzi-juniper-sku16.html
> > >
> > > Reporting the issue so that patch 2 and 14 can be resent and merged s=
oon.
> >
> > This being a backward incompatible DT binding change, maybe we should r=
evert
> > the node name change. Or, the driver could simply count the number of c=
hild
> > nodes that have the "mediatek,rpmsg-name" property, which is required.
> >
>
> You have a point.  Can someone send a patch that makes this patchset back=
ward
> 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/