Message ID | 20230919050305.3817347-1-wenst@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp3387289vqi; Tue, 19 Sep 2023 06:30:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFc8coaS0WrBnxp96VOxZsS335FBwd4Zda5jMI/BSHucrY7ajbe25JnbTcxHsFWpXo71e2Y X-Received: by 2002:a05:6e02:e41:b0:34d:ee65:a8ce with SMTP id l1-20020a056e020e4100b0034dee65a8cemr12094026ilk.19.1695130204852; Tue, 19 Sep 2023 06:30:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695130204; cv=none; d=google.com; s=arc-20160816; b=CycNL5AA3M0NALFFmjva0pl8743ZDLy3zyUKT5bnlt4jZOdyP2dpwH6l3Sl3XV5T7c sCERBnfkOK/OfBgLuxLHuXO/RJVyIwpt3CW8/1lAfogWf0K7NYlYgKMHZFm5urpgmfNW tR9dTUMOuc8gftMJxD5HEN7tyCBngCdmi8OaW22lQS8LIze/rqmGzyiblpLYUGClmTOb D6PvcGh5QA3iV/W8gE3JbW+JFGS0I8J3gdLRDameRKx3kSC7OqN9U/YDEYVc0pI6vOUo dAyjkrEdeE4kXqwBu/INjfOgr8wzm8SZgl3Cz9oG+N/A08UHSY/wQKSYgxdt8nL1kYuU fshw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=laTm7dnxWOCcW2RIknshlwm/kbQUB6RtmbdVs9LREqk=; fh=F7qbeTNgTF6rBecgimydPSpNb4Hd7Ae41MH2lwqh6GI=; b=nbWrBtYhk9fISVW/W5dNSheVAg8a7QNtKq8Rq6r9MKBzwHmv4BWqFOca5OsBtmmBIn 0uuXGV9i+UOI2vK0KmFSijvgW3yrHQTpzBXUnPPXIAy9qd3KsMXJ4px2zkEPailryMf0 gfYqn3aZLcOr+hGGqYR4aDgkA0mBPWXiz2uIX8rdQ7/Wr8kkjlEaDzvJ+vWE9jJyDg89 D+QWznm/SD7Tj+mvJXmzWKzAcyWu75kCNeaurDHKTx26dYeatBQJW/Do8KWeLka+LtRe pu28CDg5v08oTs9LfkEpYeTiBiagDmZyw3ogmBdgR3HroAIevbA+z79MgUmAVlEmOTQY tfew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=bh838skY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id u38-20020a634566000000b0057776b67494si1488952pgk.887.2023.09.19.06.30.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 06:30:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=bh838skY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id D6DAC8215767; Mon, 18 Sep 2023 22:03:36 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231431AbjISFDT (ORCPT <rfc822;kernel.ruili@gmail.com> + 25 others); Tue, 19 Sep 2023 01:03:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231397AbjISFDR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 19 Sep 2023 01:03:17 -0400 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68C5CFC for <linux-kernel@vger.kernel.org>; Mon, 18 Sep 2023 22:03:11 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-578b407045bso293665a12.0 for <linux-kernel@vger.kernel.org>; Mon, 18 Sep 2023 22:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1695099791; x=1695704591; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=laTm7dnxWOCcW2RIknshlwm/kbQUB6RtmbdVs9LREqk=; b=bh838skYf6q2+kziJFwbN6I9NdK2rrEx14g0w0D7LeYAig8uyCed0K90mzyrD3fn8Q QTUd9N1BoXa5xiuUjcXGWb2VvuolhEftKzoZ0pdM+c0ZGukEZ44C4DunILe37EsH7slz YMLrCQPJfpmA92Ce9fWMeIrdMDwmk7SERw9fA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695099791; x=1695704591; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=laTm7dnxWOCcW2RIknshlwm/kbQUB6RtmbdVs9LREqk=; b=SdKPs/jeb0bwV5altuJ2lLvuxSt0M6OEP+dKJtGhWTnT+IiigAdDmYovuxJ7iSX/UP MyLHXG//+T4qkDBDflncfxWskSeiJdqs1bVcqiXbtoU2I8IpvY550dTmq7kdu+6yWahM Xmklrt+rBc6AMXls/jzdaYdYUonsJBM5WzMzoTD4uWDTBM2Op1HO3vEsSp/rE7kRmD87 aATMFNX9WONeUq56pNB0hLYuMCUbJIQD4w//Vf6SLqWQMegaxYa+tQNvr6z5R6FjLpBj Z/1PL9OmHBVxDIRz/c/uyuvIflQ6JsMoyhMT1j3XGMTp1cFtK50QWKy34wAipLxdYuYo cyzg== X-Gm-Message-State: AOJu0YwET7L8XpGmGRrhI47o9gEC7PSFRdgwLd0O6IYmYGyCCP3PPfr6 nU/mY+WRcumZHVipXJiBJN69mg== X-Received: by 2002:a05:6a20:5611:b0:14e:b4d5:782e with SMTP id ir17-20020a056a20561100b0014eb4d5782emr11869037pzc.29.1695099790851; Mon, 18 Sep 2023 22:03:10 -0700 (PDT) Received: from wenstp920.tpe.corp.google.com ([2401:fa00:1:10:40a:900d:e731:5a43]) by smtp.gmail.com with ESMTPSA id z13-20020aa785cd000000b00686edf28c22sm313169pfn.87.2023.09.18.22.03.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Sep 2023 22:03:10 -0700 (PDT) From: Chen-Yu Tsai <wenst@chromium.org> To: Bjorn Andersson <andersson@kernel.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Chen-Yu Tsai <wenst@chromium.org>, Tinghan Shen <tinghan.shen@mediatek.com>, linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Laura Nao <laura.nao@collabora.com> Subject: [PATCH] remoteproc: mediatek: Detect single/multi core SCP with rpmsg-name property Date: Tue, 19 Sep 2023 13:03:04 +0800 Message-ID: <20230919050305.3817347-1-wenst@chromium.org> X-Mailer: git-send-email 2.42.0.459.ge4e396fd5e-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 18 Sep 2023 22:03:36 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777472849985714706 X-GMAIL-MSGID: 1777472849985714706 |
Series |
remoteproc: mediatek: Detect single/multi core SCP with rpmsg-name property
|
|
Commit Message
Chen-Yu Tsai
Sept. 19, 2023, 5:03 a.m. UTC
In the just landed multi-core SCP work, detection of single/multi core
SCP is done by checking the immediate child node of the SCP complex
device node. In the original work this was done by matching the child
node's name. However the name wasn't previously standardized. This
resulted in breakage on MT8183 and MT8192 Chromebooks while the driver
side changes were picked up and the device tree changes were not picked
up.
Instead, match against the "mediatek,rpmsg-name" property, which is
required to be present in the rpmsg sub-node. This makes the
aforementioned devices running old device trees working again.
Reported-by: Laura Nao <laura.nao@collabora.com>
Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
The patch is based on next-20230918 with a whole bunch of local patches
stacked on top. None of my local patches are related to remoteproc, so
it should be fine.
I tested on both MT8183 Juniper and MT8192 Hayato and on both systems
the SCP successfully probed again.
drivers/remoteproc/mtk_scp.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
Comments
Il 19/09/23 07:03, Chen-Yu Tsai ha scritto: > In the just landed multi-core SCP work, detection of single/multi core > SCP is done by checking the immediate child node of the SCP complex > device node. In the original work this was done by matching the child > node's name. However the name wasn't previously standardized. This > resulted in breakage on MT8183 and MT8192 Chromebooks while the driver > side changes were picked up and the device tree changes were not picked > up. > > Instead, match against the "mediatek,rpmsg-name" property, which is > required to be present in the rpmsg sub-node. This makes the > aforementioned devices running old device trees working again. > > Reported-by: Laura Nao <laura.nao@collabora.com> > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP") > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> > --- > The patch is based on next-20230918 with a whole bunch of local patches > stacked on top. None of my local patches are related to remoteproc, so > it should be fine. > > I tested on both MT8183 Juniper and MT8192 Hayato and on both systems > the SCP successfully probed again. Instead of checking "mediatek,rpmsg-name", I think that a better way of checking if this is single or multi core is to count the number of cores... I've sent my own version of this, please check [1]. [1]: https://lore.kernel.org/linux-remoteproc/20230919092336.51007-1-angelogioacchino.delregno@collabora.com/ Cheers, Angelo
On Tue, Sep 19, 2023 at 5:26 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 19/09/23 07:03, Chen-Yu Tsai ha scritto: > > In the just landed multi-core SCP work, detection of single/multi core > > SCP is done by checking the immediate child node of the SCP complex > > device node. In the original work this was done by matching the child > > node's name. However the name wasn't previously standardized. This > > resulted in breakage on MT8183 and MT8192 Chromebooks while the driver > > side changes were picked up and the device tree changes were not picked > > up. > > > > Instead, match against the "mediatek,rpmsg-name" property, which is > > required to be present in the rpmsg sub-node. This makes the > > aforementioned devices running old device trees working again. > > > > Reported-by: Laura Nao <laura.nao@collabora.com> > > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP") > > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> > > --- > > The patch is based on next-20230918 with a whole bunch of local patches > > stacked on top. None of my local patches are related to remoteproc, so > > it should be fine. > > > > I tested on both MT8183 Juniper and MT8192 Hayato and on both systems > > the SCP successfully probed again. > > Instead of checking "mediatek,rpmsg-name", I think that a better way of checking if > this is single or multi core is to count the number of cores... > > I've sent my own version of this, please check [1]. My version checks the structure of the device node, much like the original code, just against a different property/node name. If it's multi-core, there would be sub-nodes for each core, and the rpmsg property would be under those. Either way works. What we need right now is a quick fix to get things working again. We can discuss how to make things better later. Honestly I think it should just be based on the compatible string. However the current design seems quite fragile. The driver probably can't handle the core device nodes being out of order. ChenYu
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c index ea227b566c54..ca15d9f382a1 100644 --- a/drivers/remoteproc/mtk_scp.c +++ b/drivers/remoteproc/mtk_scp.c @@ -1149,13 +1149,23 @@ static int scp_is_single_core(struct platform_device *pdev) struct device *dev = &pdev->dev; struct device_node *np = dev_of_node(dev); struct device_node *child; + bool has_rpmsg; child = of_get_next_available_child(np, NULL); if (!child) return dev_err_probe(dev, -ENODEV, "No child node\n"); + /* + * On single core SCP systems, the immediate child of the SCP device + * is the rpmsg node; on multi core systems, there's an intermediate + * level node, one describing each core. Instead of matching on the + * node name, which was recently changed in the DT binding in a + * backward incompatible way, match against the "mediatek,rpmsg-name" + * property, which is required in all rpmsg sub-nodes. + */ + has_rpmsg = of_property_present(child, "mediatek,rpmsg-name"); of_node_put(child); - return of_node_name_eq(child, "cros-ec-rpmsg"); + return has_rpmsg; } static int scp_cluster_init(struct platform_device *pdev, struct mtk_scp_of_cluster *scp_cluster)