From nobody Sat Sep 21 08:26:11 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 8F1D6C636D7 for ; Thu, 9 Feb 2023 07:41:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229871AbjBIHla (ORCPT ); Thu, 9 Feb 2023 02:41:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46288 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229944AbjBIHlR (ORCPT ); Thu, 9 Feb 2023 02:41:17 -0500 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDE0F43470; Wed, 8 Feb 2023 23:40:57 -0800 (PST) X-UUID: 1306b3c6a84d11ed945fc101203acc17-20230209 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=dVz6vc3eyai2hn+5fD9Ytby63sjqKarwLIkq8BPsPkM=; b=EE2LOh0YbJAvSP6/d9A6UxSvrvLSx4IDri0gHqSY/7EIdZhj81kBR9z4RUSY2EaEFXlx8iRZxziUzivxuL6Zc5xbOi/f0K1DvEj1fFCyD9mgkopBcoGJMfZw/2hpzvEL2fjsIRCrJjnCkKEmsHGwpc44TJSk8ixSJltk9XXXHOA=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.19,REQID:fe7891a0-21a9-4b63-8388-e25ffbdd9fa2,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:95,FILE:0,BULK:0,RULE:Release_Ham,ACTION :release,TS:95 X-CID-INFO: VERSION:1.1.19,REQID:fe7891a0-21a9-4b63-8388-e25ffbdd9fa2,IP:0,URL :0,TC:0,Content:0,EDM:0,RT:0,SF:95,FILE:0,BULK:0,RULE:Spam_GS981B3D,ACTION :quarantine,TS:95 X-CID-META: VersionHash:885ddb2,CLOUDID:5f05608e-8530-4eff-9f77-222cf6e2895b,B ulkID:230209154050KQ4I27VN,BulkQuantity:0,Recheck:0,SF:38|29|28|17|19|48,T C:nil,Content:0,EDM:-3,IP:nil,URL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0 ,OSI:0,OSA:0,AV:0 X-CID-BVR: 0 X-UUID: 1306b3c6a84d11ed945fc101203acc17-20230209 Received: from mtkmbs13n1.mediatek.inc [(172.21.101.193)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 2083672243; Thu, 09 Feb 2023 15:40:50 +0800 Received: from mtkmbs13n1.mediatek.inc (172.21.101.193) 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; Thu, 9 Feb 2023 15:40:49 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by mtkmbs13n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.15 via Frontend Transport; Thu, 9 Feb 2023 15:40:49 +0800 From: Tinghan Shen To: Bjorn Andersson , Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , AngeloGioacchino Del Regno , Tinghan Shen CC: , , , , , Subject: [PATCH v4 09/12] remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offset Date: Thu, 9 Feb 2023 15:40:18 +0800 Message-ID: <20230209074021.13936-10-tinghan.shen@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20230209074021.13936-1-tinghan.shen@mediatek.com> References: <20230209074021.13936-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 e7d4f279c55e..cfcb719ba50b 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