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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E6FF2C83F1A for ; Fri, 11 Jul 2025 10:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vAwz9VEcVoGTEWC7hvIYLB6gYXgNjSsl+blGys6F9pY=; b=MDmInhbA+bpwh+Klvs3D31yzUW rKvICt5rLfPUA/eDT42Sxi56g4f81UaZc0fjVQf5yCgglkVPJbfXP6m4oJrN541rpg7VCwqZo/M/O MOxPiUHTQDsfpdEQjuAWW06FidnFxmpj5lcTYqWredsr+FHA+REFCSn9Wg+cIDOUGvJQoRuNf1PTP fSCeB2gyVDaP5Yekh3YH5sL7iixkM3iAOH1DGwA5TTAbR5SceamBNnjBzrdXLh26tLipCXOvzmpjh aeNh+qSATEGULZzPp6WzsDAA4hIyr3VdFoAoOUW5juTDryY2YC1BOvsK3n49dfgbKAP03fqheTGHB 3NwmuUFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uaBSL-0000000EXkj-0UCd; Fri, 11 Jul 2025 10:58:17 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uaAOg-0000000ENQX-3BPZ for linux-arm-kernel@lists.infradead.org; Fri, 11 Jul 2025 09:50:28 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 70BB216F2; Fri, 11 Jul 2025 02:50:15 -0700 (PDT) Received: from localhost (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B26EC3F6A8; Fri, 11 Jul 2025 02:50:25 -0700 (PDT) Date: Fri, 11 Jul 2025 10:50:23 +0100 From: Leo Yan To: Breno Leitao Cc: Mark Rutland , ankita@nvidia.com, bwicaksono@nvidia.com, rmk+kernel@armlinux.org.uk, catalin.marinas@arm.com, linux-serial@vger.kernel.org, rmikey@meta.com, linux-arm-kernel@lists.infradead.org, usamaarif642@gmail.com, linux-kernel@vger.kernel.org, paulmck@kernel.org Subject: Re: arm64: csdlock at early boot due to slow serial (?) Message-ID: <20250711095023.GB1093654@e132581.arm.com> References: <20250710133557.GA1093654@e132581.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250711_025026_892679_FDBCD96F X-CRM114-Status: GOOD ( 23.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Breno, On Thu, Jul 10, 2025 at 10:30:45AM -0700, Breno Leitao wrote: [...] > > The atomic path is introduced recently by the commit: > > > > 2eb2608618ce ("serial: amba-pl011: Implement nbcon console") > > > > My conclusion is that changing the initcall will not disable the atomic > > path, changing to console_initcall() will cause AMBA device init > > failure, and as a result, the clock operations will not be invoked. > > Thus, I am curious if you have ruled out the issue is caused by the UART > > clock (as I mentioned in another reply). > > > > BTW, since the atomic path is enabled in the commit 2eb2608618ce, what > > is the result after reverting the commit? > > I've reverted commit 2eb2608618ce ("serial: amba-pl011: Implement nbcon > console"), and I don't see the CSD locks anymoer. The serial speed is > the same and continue to be slow, but, the CSD lock is not there. Here > is the time spent on the serial flush when reverting the commit above > > [ 0.309561] printk: legacy console [ttyAMA0] enabled > [ 8.657938] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-ff]) >From this result, we can know both the atomic path and the thread path take a long time polling. Since both paths configure the UART clock, I'm curious about the behaviour if the UART clock is untouched. The relevant code is shown below. I may seem a bit stubborn in suspecting a clock issue :) But if you have confirmed that a standard pl011 UART IP is being used, then the only external factor I am aware of is the clock. Thanks, Leo ---8<--- diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c index 71482d639a6d..b04773ba2602 100644 --- a/drivers/amba/bus.c +++ b/drivers/amba/bus.c @@ -64,6 +64,8 @@ static int amba_get_enable_pclk(struct amba_device *pcdev) { int ret; + return 0; + pcdev->pclk = clk_get(&pcdev->dev, "apb_pclk"); if (IS_ERR(pcdev->pclk)) return PTR_ERR(pcdev->pclk); @@ -77,8 +79,8 @@ static int amba_get_enable_pclk(struct amba_device *pcdev) static void amba_put_disable_pclk(struct amba_device *pcdev) { - clk_disable_unprepare(pcdev->pclk); - clk_put(pcdev->pclk); + //clk_disable_unprepare(pcdev->pclk); + //clk_put(pcdev->pclk); } diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c index 22939841b1de..9ba24afb6e4f 100644 --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -1777,7 +1777,7 @@ static int pl011_hwinit(struct uart_port *port) /* * Try to enable the clock producer. */ - retval = clk_prepare_enable(uap->clk); + retval = clk_prepare(uap->clk); if (retval) return retval; @@ -1934,7 +1934,7 @@ static int pl011_startup(struct uart_port *port) return 0; clk_dis: - clk_disable_unprepare(uap->clk); + //clk_disable_unprepare(uap->clk); return retval; } @@ -2025,7 +2025,7 @@ static void pl011_shutdown(struct uart_port *port) /* * Shut down the clock producer */ - clk_disable_unprepare(uap->clk); + //clk_disable_unprepare(uap->clk); /* Optionally let pins go into sleep states */ pinctrl_pm_select_sleep_state(port->dev); @@ -2524,7 +2524,7 @@ pl011_console_write_atomic(struct console *co, struct nbcon_write_context *wctxt if (!nbcon_enter_unsafe(wctxt)) return; - clk_enable(uap->clk); + //clk_enable(uap->clk); if (!uap->vendor->always_enabled) { old_cr = pl011_read(uap, REG_CR); @@ -2542,7 +2542,7 @@ pl011_console_write_atomic(struct console *co, struct nbcon_write_context *wctxt if (!uap->vendor->always_enabled) pl011_write(old_cr, uap, REG_CR); - clk_disable(uap->clk); + //clk_disable(uap->clk); nbcon_exit_unsafe(wctxt); } @@ -2556,7 +2556,7 @@ pl011_console_write_thread(struct console *co, struct nbcon_write_context *wctxt if (!nbcon_enter_unsafe(wctxt)) return; - clk_enable(uap->clk); + //clk_enable(uap->clk); if (!uap->vendor->always_enabled) { old_cr = pl011_read(uap, REG_CR); @@ -2586,7 +2586,7 @@ pl011_console_write_thread(struct console *co, struct nbcon_write_context *wctxt if (!uap->vendor->always_enabled) pl011_write(old_cr, uap, REG_CR); - clk_disable(uap->clk); + //clk_disable(uap->clk); nbcon_exit_unsafe(wctxt); }