Received-SPF: pass (google.com: domain of linux-kernel+bounces-128127-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240321084614.45253-1-angelogioacchino.delregno@collabora.com>
 <20240321084614.45253-3-angelogioacchino.delregno@collabora.com>
 <ZfxRyMyUqyqtXy8n@p14s> <9ef4e974-740e-4698-bb38-f236521a425c@collabora.com>
 <ZgWA/E46i/CaoM74@p14s> <b6ed8710-1608-4343-8a58-5f8e0e16d10d@collabora.com>
In-Reply-To: <b6ed8710-1608-4343-8a58-5f8e0e16d10d@collabora.com>
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Date: Tue, 2 Apr 2024 08:23:34 -0600
Message-ID: <CANLsYkyu69Pwv094XGfVomuu1Oixw3vxr42q6WOE4F3snATygw@mail.gmail.com>
Subject: Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes
 for multi-core
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: andersson@kernel.org, matthias.bgg@gmail.com, tzungbi@kernel.org, 
	tinghan.shen@mediatek.com, linux-remoteproc@vger.kernel.org, 
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 
	linux-mediatek@lists.infradead.org, wenst@chromium.org, kernel@collabora.com
Content-Type: text/plain; charset="UTF-8"

On Tue, 2 Apr 2024 at 03:56, AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 28/03/24 15:38, Mathieu Poirier ha scritto:
> > On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
> >> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> >>> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> >>>> When probing multi-core SCP, this driver is parsing all sub-nodes of
> >>>> the scp-cluster node, but one of those could be not an actual SCP core
> >>>> and that would make the entire SCP cluster to fail probing for no good
> >>>> reason.
> >>>>
> >>>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> >>>> parsing only available subnodes having compatible "mediatek,scp-core".
> >>>>
> >>>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> >>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> >>>> ---
> >>>>    drivers/remoteproc/mtk_scp.c | 3 +++
> >>>>    1 file changed, 3 insertions(+)
> >>>>
> >>>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> >>>> index 67518291a8ad..fbe1c232dae7 100644
> >>>> --- a/drivers/remoteproc/mtk_scp.c
> >>>> +++ b/drivers/remoteproc/mtk_scp.c
> >>>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
> >>>>            cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
> >>>>            for_each_available_child_of_node(np, child) {
> >>>> +          if (!of_device_is_compatible(child, "mediatek,scp-core"))
> >>>> +                  continue;
> >>>> +
> >>>
> >>> Interesting - what else gets stashed under the remote processor node?  I don't
> >>> see anything specified in the bindings.
> >>>
> >>
> >> Sorry for the late reply - well, in this precise moment in time, upstream,
> >> nothing yet.
> >>
> >> I have noticed this while debugging some lockups and wanted to move the scp_adsp
> >> clock controller node as child of the SCP node (as some of those clocks are located
> >> *into the SCP's CFG register space*, and it's correct for that to be a child as one
> >> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
> >> the unexpected behavior, as the SCP driver was treating those as an SCP core.
> >>
> >> There was no kernel panic, but the SCP would fail probing.
> >>
> >> This is anyway a missed requirement ... for platforms that want *both* two SCP
> >> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
> >> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
> >> lines back.
> >>
> >> ...and that's why this commit was sent :-)
> >>
> >
> > Please update the bindings with the extra clock requirement in your next
> > revision.
> >
>
> Ok.
>
> Can you please take only patch 1/2 of this series so that I can delay this one
> for a bit? I don't have time to work on that exactly right now.
>

It was added to rproc-next last week.

> Thanks,
> Angelo
>
>