From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84121C432BE for ; Thu, 2 Sep 2021 06:37:04 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4962060F21 for ; Thu, 2 Sep 2021 06:37:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4962060F21 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=siemens.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4E7588329C; Thu, 2 Sep 2021 08:37:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=siemens.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 12D0A83291; Thu, 2 Sep 2021 08:36:58 +0200 (CEST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 171EC8324E for ; Thu, 2 Sep 2021 08:36:54 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=siemens.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 1826aq3Y023719 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Sep 2021 08:36:52 +0200 Received: from [167.87.3.52] ([167.87.3.52]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 1826apEj005970; Thu, 2 Sep 2021 08:36:52 +0200 Subject: Re: [u-boot PATCH] arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge From: Jan Kiszka To: Lokesh Vutla Cc: u-boot@lists.denx.de, Grygorii Strashko , trini@konsulko.com, "Su, Bao Cheng (RC-CN DF FA R&D)" References: <20200130080503.28657-1-rogerq@ti.com> <3ff739a1-9e7b-4136-70f7-063ac6a21350@siemens.com> Message-ID: <99a3fa4a-adc4-3e0b-a0df-5996b80e47b5@siemens.com> Date: Thu, 2 Sep 2021 08:36:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <3ff739a1-9e7b-4136-70f7-063ac6a21350@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 28.07.21 11:10, Jan Kiszka wrote: > On 30.01.20 09:05, Roger Quadros wrote: >> NB0 is bridge to SRAM and NB1 is bridge to DDR. >> >> To ensure that SRAM transfers are not stalled due to >> delays during DDR refreshes, SRAM traffic should be higher >> priority (threadmap=2) than DDR traffic (threadmap=0). >> >> This patch does just that. >> >> This is required to fix ICSSG TX lock-ups due to delays in >> MSMC transfers due to incorrect Northbridge configuration. >> >> Signed-off-by: Roger Quadros >> Acked-by: Andrew F. Davis >> Acked-by: Tomi Valkeinen >> Acked-by: Benoit Parrot >> --- >> arch/arm/mach-k3/am6_init.c | 14 ++++++++++++++ >> arch/arm/mach-k3/include/mach/am6_hardware.h | 7 +++++++ >> 2 files changed, 21 insertions(+) >> >> diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c >> index 8d107b870b..9379b95bdb 100644 >> --- a/arch/arm/mach-k3/am6_init.c >> +++ b/arch/arm/mach-k3/am6_init.c >> @@ -86,6 +86,18 @@ static void store_boot_index_from_rom(void) >> bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX); >> } >> >> +static void setup_am654_navss_northbridge(void) >> +{ >> + /* >> + * NB0 is bridge to SRAM and NB1 is bridge to DDR. >> + * To ensure that SRAM transfers are not stalled due to >> + * delays during DDR refreshes, SRAM traffic should be higher >> + * priority (threadmap=2) than DDR traffic (threadmap=0). >> + */ >> + writel(0x2, NAVSS0_NBSS_NB0_CFG_BASE + NAVSS_NBSS_THREADMAP); >> + writel(0x0, NAVSS0_NBSS_NB1_CFG_BASE + NAVSS_NBSS_THREADMAP); >> +} >> + >> void board_init_f(ulong dummy) >> { >> #if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS) >> @@ -101,6 +113,8 @@ void board_init_f(ulong dummy) >> /* Make all control module registers accessible */ >> ctrl_mmr_unlock(); >> >> + setup_am654_navss_northbridge(); >> + >> #ifdef CONFIG_CPU_V7R >> disable_linefill_optimization(); >> setup_k3_mpu_regions(); >> diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h b/arch/arm/mach-k3/include/mach/am6_hardware.h >> index 6df7631545..45a5b31c52 100644 >> --- a/arch/arm/mach-k3/include/mach/am6_hardware.h >> +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h >> @@ -47,4 +47,11 @@ >> /* MCU SCRATCHPAD usage */ >> #define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE >> >> +/* NAVSS Northbridge config */ >> +#define NAVSS0_NBSS_NB0_CFG_BASE 0x03802000 >> +#define NAVSS0_NBSS_NB1_CFG_BASE 0x03803000 >> + >> +#define NAVSS_NBSS_PID 0x0 >> +#define NAVSS_NBSS_THREADMAP 0x10 >> + >> #endif /* __ASM_ARCH_AM6_HARDWARE_H */ >> > > This was never merged, not even commented on (only apparently rejected > in patchwork) - but it is crucial as we now found out: > > prueth will quickly stall when these priorities are not applied, at > least with SR1.0-based AM65x designs. And you probably know what else > could go wrong. Please clarify and merge, possibly reducing the scope to > SR1.0 if you can confirm that SR2.0 cannot be affected by design (I can > only say this based on few practical experiments here). > > If it was good for several TI SDK releases by now, at least something > similar should be good for upstream as well, I believe. > Ping. We need at least some confirmation on what is actually needed. Then, if you do not like to add it to the generic path, it would be easy for us to carry it in the IOT2050 board init only - with the appropriate condition check. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux