Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp249082ybj; Thu, 19 Sep 2019 13:49:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqwGHMF8SB46edvvrGcVGkFcTnjeg0iT0GE0+Ey7WzWkjRmTVwP0UfhMnOls8O5ON2j409O4 X-Received: by 2002:a50:cfc7:: with SMTP id i7mr17747491edk.89.1568926148936; Thu, 19 Sep 2019 13:49:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568926148; cv=none; d=google.com; s=arc-20160816; b=enbmuX6u7V2t/AHcR3Ndhcp6DT2ja0cKKnDydjdpqj4G/D2w15QjbVTCecmOalj/wY TvrVlKC6pcHChqdj+zgzUOIWYqROqHCqWg+M+rZLqRGfz00dAxHviz9A8L9pFo4UV9AD q8HemRdryXFu1mcBE42RYiE+0ZUJfTNQeVs4KSOqOaHoKaoFenE4rhrfOIeWBAQWsHuK hzjOaFBHO30ID80a1E1E0d1eicnzM8ZQzyJXNdxJT7CVt/oKJFgcSszAaw8vhKjyvmoN sXMSMo9EU7C9Bbbn+SxJ5shl0lE4NOrgMZpKvP4PUccrtEjwwBWlAHKMAVOQ2fgMS4te 7BnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=gI0UY6tKZKlhRenzFWml2ZMgb1iX5xGJo+xpL98XDxs=; b=FpkpVDdfgYv21srvpryO6NEmMGNxrsm49+UTxajWiEoEsb6EjCsEB2xC/CAnCU9bvV xRKdtYJfXQCm3DD7qncVV6LrJWQXeWSPMT2kNhRrByaDYlspLzZUemJ5tjrQtM+lUAhF FaegcmKfZF9gy7ly8KITaJw2LnNCDhxiWg0o3ySW0YRqzuH5FgGR7yubhUnYwHxIWFiO 9+96Izt8FtUB9outSXWjTE04jPizEuf29nRavW2fXylFDsVReGP0LFUO6Mus3e7tun7o s0vci+22E50SRTdfYmuSuLbRb/8yc7iVd2Ajz8C8JeOgaKcfIEVhhcqP5AiamYXHxHK9 HSIw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v26si4772425eja.230.2019.09.19.13.48.45; Thu, 19 Sep 2019 13:49:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390395AbfISOvU (ORCPT + 99 others); Thu, 19 Sep 2019 10:51:20 -0400 Received: from mx1.emlix.com ([188.40.240.192]:58704 "EHLO mx1.emlix.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388551AbfISOvU (ORCPT ); Thu, 19 Sep 2019 10:51:20 -0400 Received: from mailer.emlix.com (unknown [81.20.119.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.emlix.com (Postfix) with ESMTPS id 213045FD85; Thu, 19 Sep 2019 16:51:18 +0200 (CEST) From: Philipp Puschmann To: linux-kernel@vger.kernel.org Cc: u.kleine-koenig@pengutronix.de, gregkh@linuxfoundation.org, yibin.gong@nxp.com, fugang.duan@nxp.com, l.stach@pengutronix.de, jslaby@suse.com, shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, linux-serial@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Philipp Puschmann Subject: [PATCH v3] serial: imx: adapt rx buffer and dma periods Date: Thu, 19 Sep 2019 16:51:14 +0200 Message-Id: <20190919145114.13006-1-philipp.puschmann@emlix.com> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Using only 4 DMA periods for UART RX is very few if we have a high frequency of small transfers - like in our case using Bluetooth with many small packets via UART - causing many dma transfers but in each only filling a fraction of a single buffer. Such a case may lead to the situation that DMA RX transfer is triggered but no free buffer is available. When this happens dma channel ist stopped - with the patch "dmaengine: imx-sdma: fix dma freezes" temporarily only - with the possible consequences that: with disabled hw flow control: If enough data is incoming on UART port the RX FIFO runs over and characters will be lost. What then happens depends on upper layer. with enabled hw flow control: If enough data is incoming on UART port the RX FIFO reaches a level where CTS is deasserted and remote device sending the data stops. If it fails to stop timely the i.MX' RX FIFO may run over and data get lost. Otherwise it's internal TX buffer may getting filled to a point where it runs over and data is again lost. It depends on the remote device how this case is handled and if it is recoverable. Obviously we want to avoid having no free buffers available. So we decrease the size of the buffers and increase their number and the total buffer size. Signed-off-by: Philipp Puschmann Reviewed-by: Lucas Stach --- Changelog v3: - enhance description Changelog v2: - split this patch from series "Fix UART DMA freezes for iMX6" - add Reviewed-by tag drivers/tty/serial/imx.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 87c58f9f6390..51dc19833eab 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -1034,8 +1034,6 @@ static void imx_uart_timeout(struct timer_list *t) } } -#define RX_BUF_SIZE (PAGE_SIZE) - /* * There are two kinds of RX DMA interrupts(such as in the MX6Q): * [1] the RX DMA buffer is full. @@ -1118,7 +1116,8 @@ static void imx_uart_dma_rx_callback(void *data) } /* RX DMA buffer periods */ -#define RX_DMA_PERIODS 4 +#define RX_DMA_PERIODS 16 +#define RX_BUF_SIZE (PAGE_SIZE / 4) static int imx_uart_start_rx_dma(struct imx_port *sport) { -- 2.23.0