Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3664290pxu; Mon, 30 Nov 2020 07:51:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJyGQGkbF6LiZc7YHOFXYQC6Pg28svXtjgiZLQ3IXeh5DtgsgM2f+KgJBIvZ2ksXi4vqqith X-Received: by 2002:a17:906:5f92:: with SMTP id a18mr6517341eju.126.1606751465334; Mon, 30 Nov 2020 07:51:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606751465; cv=none; d=google.com; s=arc-20160816; b=YQ1NSavHm9ybvQZxObbhtDHZXQ0NAqHsGJT1k2rq+oSO3nLuo1hosTU+mdQs6OaZPb MwGZZnqqMFEIKrZqA6ePOE2QvFv1iekZ80WgkNRVCtElPKmDhGhePpKP2BFKa0MUQ/My eVyysUeE46MaQPFpglF9T5ubAH9qMkwW12p21tpY+A+scYDWMCoP5R3btbDAb/6di7Qb 2SEV58VK8DFOyVPCvQA9Fl6vrus4/c7jbTKsRwUshMR3+7P/IzeVay53pokXXYphtlE7 Ftd2GZ9nN1VqGwrF4qn7s5cYqkE7Rb5qRoXT6IsGtrGdpvOwYTtu+ctwHiPyncOPJFEr EYfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=jaqodItvDJOrrUHC+0GGevIUvHl4mGUiSAaqLWeN99E=; b=PFKdbjuqD9c4KaHoy170r2jI6C3UIqPlICiNHiAQqo93nRAKMZ20b5ewjaQeVpN3IL 4jV+Srfw5YCW71xhiDR9zoCxEjg6N3CG9kRdQlu+2u9cdzAMyA5uLG8h2cNt6jozoM1Y AvWqFbNarfvaJNkNKwMKJoEhgdZAmI4kus6nC/SDmvpsQurWOHdXJTU4WKTeM03B/Vqu f7KCAax6iReOdSSKNPcf899nvf48AZ0JAxs32S+JidvJhB+SGKTZ6dnxC4kxMwA7Um8c 3ZUclPaBNdy9QXVPhYfhPzJV+wE5Mv/w0fMC1fE0r79qFk+cxpErT1tbT1iSvOMtK4zs Rl1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=Lw8sSrNZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j12si626451eds.530.2020.11.30.07.50.40; Mon, 30 Nov 2020 07:51:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=Lw8sSrNZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726629AbgK3Psu (ORCPT + 99 others); Mon, 30 Nov 2020 10:48:50 -0500 Received: from fllv0016.ext.ti.com ([198.47.19.142]:46220 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbgK3Pst (ORCPT ); Mon, 30 Nov 2020 10:48:49 -0500 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0AUFlqWu040544; Mon, 30 Nov 2020 09:47:52 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1606751272; bh=jaqodItvDJOrrUHC+0GGevIUvHl4mGUiSAaqLWeN99E=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=Lw8sSrNZxm1B9CEG8+KK0/gk/CsHMzvg233vymtiyROqDaTzwim/j3SuzbP6lF2Yj w2JkmXY4yUO9OcCYOCVJ44U/UNcQlIbmHDICvtZ69SeTQ328rthyEndQoIyPIbijNW Cvgsx1px7m325DRIT3cTHtUeyYRw7ojMHWlxMCeU= Received: from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0AUFlqlN035480 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 30 Nov 2020 09:47:52 -0600 Received: from DFLE115.ent.ti.com (10.64.6.36) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Mon, 30 Nov 2020 09:47:52 -0600 Received: from lelv0327.itg.ti.com (10.180.67.183) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Mon, 30 Nov 2020 09:47:52 -0600 Received: from [10.250.38.244] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0AUFlqlL071712; Mon, 30 Nov 2020 09:47:52 -0600 Subject: Re: [PATCH 3/3] remoteproc: k3-r5: Adjust TCM sizes in Split-mode on J7200 SoCs To: Mathieu Poirier CC: Bjorn Andersson , Rob Herring , Lokesh Vutla , linux-remoteproc , , linux-arm-kernel , Linux Kernel Mailing List References: <20201119010531.21083-1-s-anna@ti.com> <20201119010531.21083-4-s-anna@ti.com> <20201123235129.GA529235@xps15> From: Suman Anna Message-ID: <823f82d5-f100-23ed-8f29-73ec8b19ffd7@ti.com> Date: Mon, 30 Nov 2020 09:47:46 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/23/20 6:55 PM, Mathieu Poirier wrote: > On Mon, 23 Nov 2020 at 16:51, Mathieu Poirier > wrote: >> >> Good afternoon Suman, >> >> On Wed, Nov 18, 2020 at 07:05:31PM -0600, Suman Anna wrote: >>> The J7200 SoCs have a revised R5FSS IP that adds a unique feature w.r.t >>> TCM sizing. Each R5F core in a cluster typically has 32 KB each of ATCM >>> and BTCM, with only the Core0 TCMs usable in LockStep mode. This revised >>> IP however doubles the total available TCM in LockStep mode by making the >>> Core1 TCM visible immediately after the corresponding Core0 TCM. >>> >>> The R5F DT nodes on the J7200 SoCs define double (64 KB) the normal TCM >>> size (32 KB) for R5F Core0 for each of ATCM and BTCM to represent the >>> above. This increased TCM memory is only usable in LockStep-mode, and >>> has to be adjusted to the normal 32 KB size in Split mode. Enhance the >>> TI K3 R5F remoteproc for this logic through a new function. The adjustment >>> is a no-op on prior SoCs and relies on the correct DTS node sizes in >>> LockStep-mode on applicable SoCs. >>> >>> Signed-off-by: Suman Anna >>> --- >>> drivers/remoteproc/ti_k3_r5_remoteproc.c | 43 ++++++++++++++++++++++++ >>> 1 file changed, 43 insertions(+) >>> >>> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c >>> index 66a32dcdd7d0..62b5a4c29456 100644 >>> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c >>> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c >>> @@ -71,9 +71,11 @@ enum cluster_mode { >>> >>> /** >>> * struct k3_r5_soc_data - match data to handle SoC variations >>> + * @tcm_is_double: flag to denote the larger unified TCMs in certain modes >>> * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC >>> */ >>> struct k3_r5_soc_data { >>> + bool tcm_is_double; >>> bool tcm_ecc_autoinit; >>> }; >>> >>> @@ -886,6 +888,43 @@ static void k3_r5_reserved_mem_exit(struct k3_r5_rproc *kproc) >>> of_reserved_mem_device_release(kproc->dev); >>> } >>> >>> +/* >>> + * Each R5F core within a typical R5FSS instance has a total of 64 KB of TCMs, >>> + * split equally into two 32 KB banks between ATCM and BTCM. The TCMs from both >>> + * cores are usable in Split-mode, but only the Core0 TCMs can be used in >>> + * LockStep-mode. The newer revisions of the R5FSS IP maximizes these TCMs by >>> + * leveraging the Core1 TCMs as well in certain modes where they would have >>> + * otherwise been unusable (Eg: LockStep-mode on J7200 SoCs). This is done by >>> + * making a Core1 TCM visible immediately after the corresponding Core0 TCM. >>> + * The SoC memory map uses the larger 64 KB sizes for the Core0 TCMs, and the >>> + * dts representation reflects this increased size on supported SoCs. The Core0 >>> + * TCM sizes therefore have to be adjusted to only half the original size in >>> + * Split mode. >>> + */ >>> +static void k3_r5_adjust_tcm_sizes(struct k3_r5_rproc *kproc) >>> +{ >>> + struct k3_r5_cluster *cluster = kproc->cluster; >>> + struct k3_r5_core *core = kproc->core; >>> + struct device *cdev = core->dev; >>> + struct k3_r5_core *core0; >>> + >>> + if (cluster->mode == CLUSTER_MODE_LOCKSTEP || >>> + !cluster->soc_data->tcm_is_double) >>> + return; >> >> Shouldn't this be: >> >> if (cluster->mode == CLUSTER_MODE_SPLIT || >> !cluster->soc_data->tcm_is_double) >> return; >> >> If am wrong then I'm pretty sure other people will be confused and a comment is >> warranted. >> > > Forget the above, I misread the context. The memories are already set > to 64KB so there is nothing to do if in lockstep mode. Yep, thanks for the review. The comments above the function has all the details. regards Suman > >>> + >>> + core0 = list_first_entry(&cluster->cores, struct k3_r5_core, elem); >>> + if (core == core0) { >>> + WARN_ON(core->mem[0].size != SZ_64K); >>> + WARN_ON(core->mem[1].size != SZ_64K); >>> + >>> + core->mem[0].size /= 2; >>> + core->mem[1].size /= 2; >>> + >>> + dev_dbg(cdev, "adjusted TCM sizes, ATCM = 0x%zx BTCM = 0x%zx\n", >>> + core->mem[0].size, core->mem[1].size); >>> + } >>> +} >>> + >>> static int k3_r5_cluster_rproc_init(struct platform_device *pdev) >>> { >>> struct k3_r5_cluster *cluster = platform_get_drvdata(pdev); >>> @@ -933,6 +972,8 @@ static int k3_r5_cluster_rproc_init(struct platform_device *pdev) >>> goto err_config; >>> } >>> >>> + k3_r5_adjust_tcm_sizes(kproc); >>> + >>> ret = k3_r5_reserved_mem_init(kproc); >>> if (ret) { >>> dev_err(dev, "reserved memory init failed, ret = %d\n", >>> @@ -1407,10 +1448,12 @@ static int k3_r5_probe(struct platform_device *pdev) >>> } >>> >>> static const struct k3_r5_soc_data am65_j721e_soc_data = { >>> + .tcm_is_double = false, >>> .tcm_ecc_autoinit = false, >>> }; >>> >>> static const struct k3_r5_soc_data j7200_soc_data = { >>> + .tcm_is_double = true, >>> .tcm_ecc_autoinit = true, >> >> With the above and for the set: >> >> Reviewed-by: Mathieu Poirier >> >>> }; >>> >>> -- >>> 2.28.0 >>>