From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D03AACD1284 for ; Tue, 2 Apr 2024 14:33:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kPrpEM7gPXk7/NdoVPV8pTgvor0FmyAu9uJxb6REe8w=; b=ekZS8Nf7Fphbw0 Eg8EQl3c783Qe3ZWVN3p1r7SICOOrwo+RlE51k4QWfV3Mg50SvVVJET47DoPhvZMNhsNN8owNNPfl abavd6UkSKDc7QUs48VJFYrjucGNV9FAEnwCJsGhVVfo+1CSAqEnv97RUHYnvM8ZfucDd7xI45ZF0 s/a2o1DA+0+aTUQc/B6mhfJ/sPd6uRvxJSfEiX0nmNps6F1vAa4yO30yGFIn4PaSJLcU+CpfJHORE UfIlTee6BY176hERoNinCNqC6k2XBKmKSdterCZTml+bzQOuedftGqEweOJBsohsz0bJ8V2CEFn0f 9YTta+zzdsjrpb6Na11Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrfCM-0000000BatB-0MA4; Tue, 02 Apr 2024 14:33:14 +0000 Received: from madrid.collaboradmins.com ([2a00:1098:ed:100::25]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrfCI-0000000Baqp-3dl2; Tue, 02 Apr 2024 14:33:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1712068387; bh=k9jpeeTQRulLlydfpwC6l14dlccqbsTGqCf2ynVuYi0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fBMTao+x11ZZxsEye6B1rpE+VCfhdJsJEjGqi5K6sYPkJRIsjLpxbcoYZAPt3Lmw3 0Dm5fUPMVs19etqTkb2movClXqHhAgw3RPoMOJa5EjRArLD5N17NNs9SvB7sMYarhu +ruwYVRyPK53FXPcoplIBsC3PBr9n3tLjaiYh+25ATNZaB0+epp7/HqSnBzuJW8PRn xOMVwv3At1j+V8GzryFc0utZGQ0Fttgb4sbcRvKN1frouteerZzW1Y+kEDDWubM1vV 3dR5SeIgeWjBJtAhvclke5ndjcVQ6BtJNewk8BVtkjsUeiK6OQmSHeEBukIMIjos9e n+3AwmaA6htOg== Received: from [100.113.186.2] (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 181A93780624; Tue, 2 Apr 2024 14:33:07 +0000 (UTC) Message-ID: <1f38ce24-83fa-4370-b036-b6c4bcb39fb3@collabora.com> Date: Tue, 2 Apr 2024 16:33:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core To: Mathieu Poirier 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 References: <20240321084614.45253-1-angelogioacchino.delregno@collabora.com> <20240321084614.45253-3-angelogioacchino.delregno@collabora.com> <9ef4e974-740e-4698-bb38-f236521a425c@collabora.com> From: AngeloGioacchino Del Regno Content-Language: en-US In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240402_073311_242855_AA5E6137 X-CRM114-Status: GOOD ( 18.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Il 02/04/24 16:23, Mathieu Poirier ha scritto: > On Tue, 2 Apr 2024 at 03:56, AngeloGioacchino Del Regno > 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 >>>>>> --- >>>>>> 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. > Ah, sorry, didn't notice that. Thanks again! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel