From nobody Wed Nov 13 07:05:36 2024 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CC3BC636CC for ; Wed, 15 Feb 2023 04:13:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229515AbjBOENi (ORCPT ); Tue, 14 Feb 2023 23:13:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231515AbjBOENL (ORCPT ); Tue, 14 Feb 2023 23:13:11 -0500 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 159AF25E0A; Tue, 14 Feb 2023 20:13:07 -0800 (PST) X-UUID: 0942318cace711eda06fc9ecc4dadd91-20230215 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=Zf8N5vKf+OQiD4FPD+6mWffc+P30ueDh84oUuMSgE2g=; b=Fpk5n6YDjkY8HNU8nwRzyXa44y7iyFysL7zCFdH9dIhsajNvGukyIf2R5yAd5cadNS7ydFLa+n/N1Pfje220XaYkbUp8zsvff8Bezk9P5RCftf9h61a4JiI7qdgc791GnuUPek53u5QXgawUH7mMqyp9hwpccrwnjmq88SgjLik=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.19,REQID:d92c087b-0d29-4891-b234-4f716079f72b,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:885ddb2,CLOUDID:fa197cb0-beed-4dfc-bd9c-e1b22fa6ccc4,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:-3,IP:nil,U RL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0 X-CID-BVR: 0 X-UUID: 0942318cace711eda06fc9ecc4dadd91-20230215 Received: from mtkmbs11n1.mediatek.inc [(172.21.101.185)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 161664218; Wed, 15 Feb 2023 12:13:01 +0800 Received: from mtkmbs11n2.mediatek.inc (172.21.101.187) by mtkmbs11n1.mediatek.inc (172.21.101.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 15 Feb 2023 12:12:59 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by mtkmbs11n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.15 via Frontend Transport; Wed, 15 Feb 2023 12:12:59 +0800 From: Tinghan Shen To: Bjorn Andersson , Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , AngeloGioacchino Del Regno , Tinghan Shen CC: , , , , , Subject: [PATCH v7 09/12] remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offset Date: Wed, 15 Feb 2023 12:12:54 +0800 Message-ID: <20230215041257.14548-10-tinghan.shen@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20230215041257.14548-1-tinghan.shen@mediatek.com> References: <20230215041257.14548-1-tinghan.shen@mediatek.com> MIME-Version: 1.0 X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Because MT8195 SCP core 0 and core 1 both boot from head of SRAM and have the same viewpoint of SRAM, SCP has a "core 1 SRAM offset" configuration to control the access destination of SCP core 1 to boot core 1 from different SRAM location. The "core 1 SRAM offset" configuration is composed by a range and an offset. It works like a simple memory mapped mechanism. When SCP core 1 accesses a SRAM address located in the range, the SCP bus adds the configured offset to the address to shift the physical destination address on SCP SRAM. This shifting is transparent to the software running on SCP core 1. Signed-off-by: Tinghan Shen Reviewed-by: AngeloGioacchino Del Regno --- drivers/remoteproc/mtk_scp.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c index be995c88d333..6d88b53fc07e 100644 --- a/drivers/remoteproc/mtk_scp.c +++ b/drivers/remoteproc/mtk_scp.c @@ -484,6 +484,9 @@ static int mt8195_scp_before_load(struct mtk_scp *scp) =20 static int mt8195_scp_c1_before_load(struct mtk_scp *scp) { + u32 sec_ctrl; + struct mtk_scp *scp_c0; + scp_sram_power_on(scp->reg_base + MT8195_CPU1_SRAM_PD, 0); =20 /* hold SCP in reset while loading FW. */ @@ -492,6 +495,30 @@ static int mt8195_scp_c1_before_load(struct mtk_scp *s= cp) /* enable MPU for all memory regions */ writel(0xff, scp->reg_base + MT8195_CORE1_MEM_ATT_PREDEF); =20 + /* + * The L2TCM_OFFSET_RANGE and L2TCM_OFFSET shift the destination address + * on SRAM when SCP core 1 accesses SRAM. + * + * This configuration solves booting the SCP core 0 and core 1 from + * different SRAM address because core 0 and core 1 both boot from + * the head of SRAM by default. this must be configured before boot SCP c= ore 1. + * + * The value of L2TCM_OFFSET_RANGE is from the viewpoint of SCP core 1. + * When SCP core 1 issues address within the range (L2TCM_OFFSET_RANGE), + * the address will be added with a fixed offset (L2TCM_OFFSET) on the bu= s. + * The shift action is tranparent to software. + */ + writel(0, scp->reg_base + MT8195_L2TCM_OFFSET_RANGE_0_LOW); + writel(scp->sram_size, scp->reg_base + MT8195_L2TCM_OFFSET_RANGE_0_HIGH); + + scp_c0 =3D list_first_entry(scp->cluster, struct mtk_scp, elem); + writel(scp->sram_phys - scp_c0->sram_phys, scp->reg_base + MT8195_L2TCM_O= FFSET); + + /* enable SRAM offset when fetching instruction and data */ + sec_ctrl =3D readl(scp->reg_base + MT8195_SEC_CTRL); + sec_ctrl |=3D MT8195_CORE_OFFSET_ENABLE_I | MT8195_CORE_OFFSET_ENABLE_D; + writel(sec_ctrl, scp->reg_base + MT8195_SEC_CTRL); + return 0; } =20 --=20 2.18.0