From nobody Thu Nov 14 06:56:31 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 4EFE7C636CD for ; Fri, 10 Feb 2023 09:00:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231478AbjBJJA3 (ORCPT ); Fri, 10 Feb 2023 04:00:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231747AbjBJI7x (ORCPT ); Fri, 10 Feb 2023 03:59:53 -0500 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 548425AB23; Fri, 10 Feb 2023 00:59:45 -0800 (PST) X-UUID: 3db6b3d0a92111ed945fc101203acc17-20230210 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=700dFM0xBya4gDvivRWURd2IJ5qIAFFZK66uwVFjox0=; b=IN+kMtJce1Fn330vn4qOStzUdpKJ7TyHq05Uk1/JZkIcypAQh8Rp/r+SZHF9sBzAEq4KVx7lhD5nMD8VUckIMBiEhUWJkmBmVngN/qnBRCtdCFLMy6u33xDmXUW1GbknRZaY0TCwqox1Zt5ZDNigd4m/nEyex9QSZ7PQ4czBuvk=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.19,REQID:743d1c8d-8dd7-4bb4-a30d-dcd738b23099,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:45f8e556-dd49-462e-a4be-2143a3ddc739,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: 3db6b3d0a92111ed945fc101203acc17-20230210 Received: from mtkmbs10n2.mediatek.inc [(172.21.101.183)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1280376781; Fri, 10 Feb 2023 16:59:35 +0800 Received: from mtkmbs11n2.mediatek.inc (172.21.101.187) by mtkmbs13n1.mediatek.inc (172.21.101.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 10 Feb 2023 16:59:34 +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; Fri, 10 Feb 2023 16:59:34 +0800 From: Tinghan Shen To: Bjorn Andersson , Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , AngeloGioacchino Del Regno , Tinghan Shen CC: , , , , , Subject: [PATCH v5 09/12] remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offset Date: Fri, 10 Feb 2023 16:59:28 +0800 Message-ID: <20230210085931.8941-10-tinghan.shen@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20230210085931.8941-1-tinghan.shen@mediatek.com> References: <20230210085931.8941-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 --- 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 f1dfe610dfb1..569e915dfa0f 100644 --- a/drivers/remoteproc/mtk_scp.c +++ b/drivers/remoteproc/mtk_scp.c @@ -477,6 +477,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. */ @@ -485,6 +488,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->cores, 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