From nobody Thu Nov 14 06:35:17 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 2A4F8C05027 for ; Mon, 13 Feb 2023 03:38:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229714AbjBMDiT (ORCPT ); Sun, 12 Feb 2023 22:38:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229589AbjBMDiM (ORCPT ); Sun, 12 Feb 2023 22:38:12 -0500 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D252ACC1F; Sun, 12 Feb 2023 19:38:10 -0800 (PST) X-UUID: d34c24c2ab4f11ed945fc101203acc17-20230213 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=2rYTw18c4aYuvwIDBQWVHIIYrCaRjebbMG5AwF0hk9M=; b=m0AOGGLUXYpo/jqtV4F2trgq2aPJZUIWhBzIFjs1OD45vb6wtwP8lv1WnNj3BNuBQUjJgUV5vUfIoSBrLTm7JrTU1dfMTqPRvXvfm8MWTD2HC5A1iZRBEQYcEZxwnBxsqM274EBnoioMzj0aArYNHowcCrH7lerUJ8WFDPJmRj8=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.19,REQID:ddb1a504-f2e9-4f7b-95da-a6e785fdff33,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:ddb1a504-f2e9-4f7b-95da-a6e785fdff33,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:7f6ead8e-8530-4eff-9f77-222cf6e2895b,B ulkID:230213113807QI6OC0RT,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: d34c24c2ab4f11ed945fc101203acc17-20230213 Received: from mtkmbs10n1.mediatek.inc [(172.21.101.34)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 401231307; Mon, 13 Feb 2023 11:38:05 +0800 Received: from mtkmbs13n2.mediatek.inc (172.21.101.108) by mtkmbs13n2.mediatek.inc (172.21.101.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 13 Feb 2023 11:38:03 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by mtkmbs13n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.15 via Frontend Transport; Mon, 13 Feb 2023 11:38:03 +0800 From: Tinghan Shen To: Bjorn Andersson , Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Matthias Brugger , AngeloGioacchino Del Regno , Tinghan Shen CC: , , , , , Subject: [PATCH v6 09/12] remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offset Date: Mon, 13 Feb 2023 11:37:55 +0800 Message-ID: <20230213033758.16681-10-tinghan.shen@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20230213033758.16681-1-tinghan.shen@mediatek.com> References: <20230213033758.16681-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 f1943b2457f9..50eea0eb1fb9 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->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