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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 6DDC2C433EF for ; Tue, 30 Nov 2021 13:39:20 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5B6B4830AD; Tue, 30 Nov 2021 14:39:18 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1638279558; bh=lPrK6dj+MHOoPK86RfNAw36zyQfJSEe4kvYAXNyfsmE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=iALXm34/F8GnNjNZ7xwW89owbJpbnExWSXYdKuhdhzUMafpqt0q8TDA2pPLEIzuwc 5B21YWtrczLr/5RBnu0TQvGPFvisT/diuy41tMA6ZKb2AgynNiBeik36Wq11NC7cDG /Z8GL+LvnRLTK4rY0tLgrrMKGX/J0pk8NSCDFft9Y/2nRxCn3mV/VWmkHuGjLISv/M VX2ZOxtzytF/BJXIZP/YxyXwylSLMRNz2s2SHzPdO7AWeZ4tVzsZ1/gZrwHwP20fwX GLS8zmbzh6X/nCsIs7wdqQVLL7/BoDRGrVqvIj1oIeh69l6VosW1sRE0NQ2Ke7/Gc7 1UHwKfQzt/+4A== Received: by phobos.denx.de (Postfix, from userid 109) id D1A80830AD; Tue, 30 Nov 2021 14:39:11 +0100 (CET) Received: from mout-u-107.mailbox.org (mout-u-107.mailbox.org [91.198.250.252]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 93BE5830A8 for ; Tue, 30 Nov 2021 14:39:04 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=sr@denx.de Received: from smtp102.mailbox.org (unknown [91.198.250.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-107.mailbox.org (Postfix) with ESMTPS id 4J3Nbq4bm4zQlHp; Tue, 30 Nov 2021 14:39:03 +0100 (CET) Message-ID: <6940d3ed-e40a-2204-55a8-3c51d345ee9f@denx.de> Date: Tue, 30 Nov 2021 14:38:59 +0100 MIME-Version: 1.0 Subject: Re: [PATCH] serial: a37xx: Reset whole UART when changing parent clock from TBG to XTAL Content-Language: en-US To: =?UTF-8?Q?Pali_Roh=c3=a1r?= Cc: =?UTF-8?Q?Marek_Beh=c3=ban?= , u-boot@lists.denx.de References: <20211115124806.16122-1-pali@kernel.org> From: Stefan Roese In-Reply-To: <20211115124806.16122-1-pali@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.37 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 11/15/21 13:48, Pali Rohár wrote: > Sometimes UART stops transmitting characters after UART clock is changed > back to XTAL. In this state UART fifo is always full. Kernel during early > boot wants to print output on UART and is waiting for non-empty UART fifo. > Which leads to CPU hangup without any (debug) output on UART. > > Marvell Armada 3700 Functional Specifications says that for programming > fractional divisor registers it is required to disable UART, enable > loopback mode, reset fifos, program registers, disable loopback mode, > release reset of fifos and enable UART. > > But these steps do not fix above mentioned issue that UART hangup. Also > gating UART clock does not help. And even resetting UART state machines do > not help. > > Experiments showed that UART fifo is unblocked after board is being reset > (during board reset UART HW transmit UART fifo even CPU is not executing > kernel/bootloader anymore). > > And another experiments showed that same workaround can be achieved also > by external reset of UART HW (without need to reset board). > > So do not implement any of "Marvell recommended" steps from Functional > Specifications as they do not work. And rather prior changing parent clock > back to XTAL, do external reset of UART HW. This operation also resets all > UART registers, so basically it also sets UART clock to default, which is > XTAL. It is unknown why UART hangups and enters such broken state. > > Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan > --- > drivers/serial/serial_mvebu_a3700.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/serial/serial_mvebu_a3700.c b/drivers/serial/serial_mvebu_a3700.c > index 6bca8e4b7e2d..93e4d38d34c7 100644 > --- a/drivers/serial/serial_mvebu_a3700.c > +++ b/drivers/serial/serial_mvebu_a3700.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > struct mvebu_plat { > void __iomem *base; > @@ -213,6 +214,7 @@ static int mvebu_serial_remove(struct udevice *dev) > u32 new_oversampling; > u32 oversampling; > u32 d1, d2; > + u32 nb_rst; > > /* > * Switch UART base clock back to XTAL because older Linux kernel > @@ -260,12 +262,22 @@ static int mvebu_serial_remove(struct udevice *dev) > return 0; > } > > + /* wait until TX empty */ > while (!(readl(base + UART_STATUS_REG) & UART_STATUS_TX_EMPTY)) > ; > > + /* external reset of UART via North Bridge Peripheral */ > + nb_rst = readl(MVEBU_REGISTER(0x12400)); > + writel(nb_rst & ~BIT(3), MVEBU_REGISTER(0x12400)); > + writel(nb_rst | BIT(3), MVEBU_REGISTER(0x12400)); > + > + /* set baudrate and oversampling */ > writel(new_divider, base + UART_BAUD_REG); > writel(new_oversampling, base + UART_POSSR_REG); > > + /* No Parity, 1 Stop */ > + writel(0, base + UART_CTRL_REG); > + > return 0; > } > > @@ -305,7 +317,6 @@ U_BOOT_DRIVER(serial_mvebu) = { > #ifdef CONFIG_DEBUG_MVEBU_A3700_UART > > #include > -#include > > static inline void _debug_uart_init(void) > { > Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de