From patchwork Wed Oct 2 18:40:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Marek Vasut X-Patchwork-Id: 13820233 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 4929CCEACF3 for ; Wed, 2 Oct 2024 18:43:15 +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:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=zuPq8tlRciTxlcbGOB0i7tsntZdMbWeR5LKsvLq22ZU=; b=lMDzM6Z235a1+WC527zxl1oLxz myC01x5Mwbat6khOz/HYmMOCYTEtEYIs3I5T3LR3tYrFkNrd4jmru5y1D1SwRiCGIyYZEYsVvyUG0 OhdpQQYRSQzYpNoSfZqzl2gW7JbO10JHYs3DNolu5V1C16eZ/HZ7T/7aUu4PQ2Ym01mkaknshYfkP EBs4k8Nk7kAZnX+bIWQHa8tC4ZhHK7ddIykG2izg3RDEW8FZX0z3LhNOfDIdK/iWKSTB6RUV97dFb nv0cX76OwgAbhRo0mPp/17KXvXoYjX9xOYXv880TXsRufoblQD+BU7MwympuFM4LoTpPXDzAZ1e6k UmIYvQoA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sw4JV-00000007DCB-2nfT; Wed, 02 Oct 2024 18:43:05 +0000 Received: from phobos.denx.de ([85.214.62.61]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sw4IG-00000007D0l-1YUt for linux-arm-kernel@lists.infradead.org; Wed, 02 Oct 2024 18:41:49 +0000 Received: from tr.lan (ip-86-49-120-218.bb.vodafone.cz [86.49.120.218]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 9ED0A88F44; Wed, 2 Oct 2024 20:41:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1727894506; bh=zuPq8tlRciTxlcbGOB0i7tsntZdMbWeR5LKsvLq22ZU=; h=From:To:Cc:Subject:Date:From; b=dN4eCUGPYJu8qYlYJL8JmdrYPyNZGIpGkOW0kg4oygCoWO78WU+3Sd37CjRO7cj3C pN2LGe8ww3sRrIpR4WNjZ+SMsoHlO2pX4pXW/Svc4Mkxjxc/pMnqHiCdIpcE6S+B1H ZcJj17RerMoso/w/YxW/xhtYbeD+i1yl1K8isq3+L9w+4jJyIdfYbl1yt8dqSB/+Li VmyEX340nleck3tFdpDArZ50wLuCUZ4XV5Mz9wOu5bdheyRhmrQpm0utItzdxhhZxt 6tOHvlQku2IQPD3FGPwSSs60dlSBbPbw0kDEwZ7359VhVgAbVxF4vVsjqbvZIPz/+7 HzAJjwTx2xnQA== From: Marek Vasut To: linux-serial@vger.kernel.org Cc: Marek Vasut , Esben Haabendal , Christoph Niedermaier , Christophe JAILLET , Fabio Estevam , Greg Kroah-Hartman , Jiri Slaby , Lino Sanfilippo , Pengutronix Kernel Team , Rasmus Villemoes , Rickard x Andersson , Sascha Hauer , Shawn Guo , Stefan Eichenberger , =?utf-8?q?Uwe_Kleine?= =?utf-8?q?-K=C3=B6nig?= , imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org Subject: [PATCH v2] serial: imx: Update mctrl old_status on RTSD interrupt Date: Wed, 2 Oct 2024 20:40:38 +0200 Message-ID: <20241002184133.19427-1-marex@denx.de> X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241002_114148_743374_069C9023 X-CRM114-Status: GOOD ( 20.38 ) 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 When sending data using DMA at high baudrate (4 Mbdps in local test case) to a device with small RX buffer which keeps asserting RTS after every received byte, it is possible that the iMX UART driver would not recognize the falling edge of RTS input signal and get stuck, unable to transmit any more data. This condition happens when the following sequence of events occur: - imx_uart_mctrl_check() is called at some point and takes a snapshot of UART control signal status into sport->old_status using imx_uart_get_hwmctrl(). The RTSS/TIOCM_CTS bit is of interest here (*). - DMA transfer occurs, the remote device asserts RTS signal after each byte. The i.MX UART driver recognizes each such RTS signal change, raises an interrupt with USR1 register RTSD bit set, which leads to invocation of __imx_uart_rtsint(), which calls uart_handle_cts_change(). - If the RTS signal is deasserted, uart_handle_cts_change() clears port->hw_stopped and unblocks the port for further data transfers. - If the RTS is asserted, uart_handle_cts_change() sets port->hw_stopped and blocks the port for further data transfers. This may occur as the last interrupt of a transfer, which means port->hw_stopped remains set and the port remains blocked (**). - Any further data transfer attempts will trigger imx_uart_mctrl_check(), which will read current status of UART control signals by calling imx_uart_get_hwmctrl() (***) and compare it with sport->old_status . - If current status differs from sport->old_status for RTS signal, uart_handle_cts_change() is called and possibly unblocks the port by clearing port->hw_stopped . - If current status does not differ from sport->old_status for RTS signal, no action occurs. This may occur in case prior snapshot (*) was taken before any transfer so the RTS is deasserted, current snapshot (***) was taken after a transfer and therefore RTS is deasserted again, which means current status and sport->old_status are identical. In case (**) triggered when RTS got asserted, and made port->hw_stopped set, the port->hw_stopped will remain set because no change on RTS line is recognized by this driver and uart_handle_cts_change() is not called from here to unblock the port->hw_stopped. Update sport->old_status in __imx_uart_rtsint() accordingly to make imx_uart_mctrl_check() detect such RTS change. Note that TIOCM_CAR and TIOCM_RI bits in sport->old_status do not suffer from this problem. Fixes: ceca629e0b48 ("[ARM] 2971/1: i.MX uart handle rts irq") Reviewed-by: Esben Haabendal Signed-off-by: Marek Vasut --- Cc: Christoph Niedermaier Cc: Christophe JAILLET Cc: Esben Haabendal Cc: Fabio Estevam Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Lino Sanfilippo Cc: Pengutronix Kernel Team Cc: Rasmus Villemoes Cc: Rickard x Andersson Cc: Sascha Hauer Cc: Shawn Guo Cc: Stefan Eichenberger Cc: Uwe Kleine-König Cc: imx@lists.linux.dev Cc: linux-arm-kernel@lists.infradead.org Cc: linux-serial@vger.kernel.org Cc: stable@vger.kernel.org --- V2: - Add code comment - Add RB from Esben --- drivers/tty/serial/imx.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 67d4a72eda770..90974d338f3c0 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -762,6 +762,21 @@ static irqreturn_t __imx_uart_rtsint(int irq, void *dev_id) imx_uart_writel(sport, USR1_RTSD, USR1); usr1 = imx_uart_readl(sport, USR1) & USR1_RTSS; + /* + * Update sport->old_status here, so any follow-up calls to + * imx_uart_mctrl_check() will be able to recognize that RTS + * state changed since last imx_uart_mctrl_check() call. + * + * In case RTS has been detected as asserted here and later on + * deasserted by the time imx_uart_mctrl_check() was called, + * imx_uart_mctrl_check() can detect the RTS state change and + * trigger uart_handle_cts_change() to unblock the port for + * further TX transfers. + */ + if (usr1 & USR1_RTSS) + sport->old_status |= TIOCM_CTS; + else + sport->old_status &= ~TIOCM_CTS; uart_handle_cts_change(&sport->port, usr1); wake_up_interruptible(&sport->port.state->port.delta_msr_wait);