Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp868873ybn; Tue, 24 Sep 2019 10:47:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqwud/CLTr4HTaWK0eFl+4jBvFoAdTz/Uk3Zj5Wha8ZJy91u0lhWbO0juZzkvDyoQaHWCdb4 X-Received: by 2002:a17:906:6848:: with SMTP id a8mr3786751ejs.104.1569347242205; Tue, 24 Sep 2019 10:47:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569347242; cv=none; d=google.com; s=arc-20160816; b=Q/u+Uf7lqjphkFTQUV7VZljcQhEDPiA4cm4jbt1WA7wqgwfRbqoZY05PJERiz4v3b5 lpfogwIw5qJAODI8ex1vl10sVE8odV/YspGUEQvjo9uDE3WnfII2rZf+x42sMnfYW2JV WtvsnysUPJ53RgB5f3ynJ4W8JQaYFImpRbqHs4DgNDbmqVZFIYwRqfDaAJCtlCv5gvtp V9iFgCOkAS0jg6I1bSb6EnEohkAT8lDMgXVIlVZtXFJ3iopMxz4Hd4n7Z8y/Meh+dINh H/GRAGqZDkXBlTBsyD6Gf5VZazBsVh7TE8gTRvQXdLIAVmaoxlTKaa9x0LVYJPZlDCLa TRbQ== 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=VFXKwOUga7yCsjtUKPwUejKVlSC2hnpsyBVGONtl8Uc=; b=tWhLp8SFamWyVGYJFekViT63OtTuAVibc6nGc1IH0eNqTo9ABb5QATx7ipKjqcxJI8 A2vHn+tYt7WFeujp0vd4bWiWsq4b5XjsfjEjRp7L437YUpaW1ok4+ZcIb2SLD0KCi6+/ FoeIt8Oo7JIkLdVntIfGCvjWLsU5Spd3uveYAxU0M5h3PnEiDU9ZN/w+rfSEVaFBGQQV eB2q7HrXJdTvq7xSo1nbVtuNfmMSrV4LP+T+xjsKvYSoWYqF88WQYYFL6E0acfo3c4cw PJxMVjezv40ddCbnWCqdTTz12FO6C8LSARcmASyYlUEI/IXZrCbNcU9+AC9eX1IADZz4 SW2g== 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 m1si1639510edb.433.2019.09.24.10.46.58; Tue, 24 Sep 2019 10:47:22 -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 S2408333AbfIWN6p (ORCPT + 99 others); Mon, 23 Sep 2019 09:58:45 -0400 Received: from mx1.emlix.com ([188.40.240.192]:42148 "EHLO mx1.emlix.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2408320AbfIWN6o (ORCPT ); Mon, 23 Sep 2019 09:58:44 -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 476D85FBA6; Mon, 23 Sep 2019 15:58:43 +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: Mon, 23 Sep 2019 15:58:42 +0200 Message-Id: <20190923135842.956-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 v4: - fix total buffer size 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 (RX_DMA_PERIODS * PAGE_SIZE / 4) static int imx_uart_start_rx_dma(struct imx_port *sport) { -- 2.23.0