linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
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
Subject: Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core
Date: Thu, 28 Mar 2024 08:38:52 -0600	[thread overview]
Message-ID: <ZgWA/E46i/CaoM74@p14s> (raw)
In-Reply-To: <9ef4e974-740e-4698-bb38-f236521a425c@collabora.com>

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. 

> P.S.: The reason why platforms don't crash without the scp_adsp clock controller
>       as a child of SCP is that the bootloader is actually doing basic init for
>       the SCP, hence the block is powered on when booting ;-)
> 
> Cheers,
> Angelo
> 
> > Thanks,
> > Mathieu
> > 
> > >   		if (!cluster_of_data[core_id]) {
> > >   			ret = -EINVAL;
> > >   			dev_err(dev, "Not support core %d\n", core_id);
> > > -- 
> > > 2.44.0
> > > 
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-03-28 14:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-21  8:46 [PATCH 0/2] MediaTek SCP: Urgent fixes for all MTK SoCs AngeloGioacchino Del Regno
2024-03-21  8:46 ` [PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM AngeloGioacchino Del Regno
2024-03-21 15:25   ` Mathieu Poirier
2024-03-27 12:40     ` AngeloGioacchino Del Regno
2024-03-22  6:16   ` Tzung-Bi Shih
2024-03-21  8:46 ` [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core AngeloGioacchino Del Regno
2024-03-21 15:27   ` Mathieu Poirier
2024-03-27 12:49     ` AngeloGioacchino Del Regno
2024-03-28 14:38       ` Mathieu Poirier [this message]
2024-04-02  9:56         ` AngeloGioacchino Del Regno
2024-04-02 14:23           ` Mathieu Poirier
2024-04-02 14:33             ` AngeloGioacchino Del Regno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZgWA/E46i/CaoM74@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=andersson@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=tinghan.shen@mediatek.com \
    --cc=tzungbi@kernel.org \
    --cc=wenst@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).