Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp776149ybn; Wed, 25 Sep 2019 07:34:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzqzT5z22/RLPbHJseOHqGPtmbxktaiUT+v1Xmqzf5XgPJpOanw/Oueiezdiq40H3rWlrs X-Received: by 2002:aa7:c657:: with SMTP id z23mr3276692edr.234.1569422063754; Wed, 25 Sep 2019 07:34:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569422063; cv=none; d=google.com; s=arc-20160816; b=RGGX5uT0HWqOJfQ/M8SxuY14wVzXNZzvw2XLUNjK1h0GrsynznHpar1bC+1I1i22mH NRnQNzryrlBkUktMGCPZqle19ta0rCCOmnxRJYoVkjCem487KYKXRryGa/+gIyLj8wNS t8bqCI+NWj0HkvRoNpHtkwHumvE5P4UHaNmvxSsUbOmIDO3733QZxX18hb/j9duPLlS5 Kc3kSvNndPYQ8mtQV1qAN0Ve/Y+1a1XF+6xiwxohcgcb30mnlj1SFim0maanYZIuF49r 7vdifReXxRp0unn9o4vnrCX3sBp/ekaQ84Kd51zsuD6zeVuaKnXG9mKyR48hGN6ws4HS VbGQ== 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=Vjgia0nB9o/LSRw5TUVsZBybjJyKnEC1mBipc/4yp+dTeTp4xOg18Qku4eZVdrtMr6 Yj0OBRQRcbz35+mT2B/FVQXrAZ+wPpLIZPfD6pg2qsWhZPqb+O3FruOhuuin2fJwzN6g hnfAdBb2DdVz5TIhRD3c6fcFQLbhMCUqn34dCdTPQq3K22iU1fmdmcm9YRhZtU7O2ApB +6SAfuCVFlD1U+WdkAJP7uR2BPUSpRGRN2Svxq8VOoruMEci4EbPfoqAv1LSIXrstn99 yX1QPCqq3LPdSumEtSYtcfhRoMYWvS3OYAyFCrhoZmEVFoUgT1g5gOMI2IR15ezJNjWe 25HA== 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 y44si3402530edb.251.2019.09.25.07.33.59; Wed, 25 Sep 2019 07:34:23 -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 S2439800AbfIWN7V (ORCPT + 99 others); Mon, 23 Sep 2019 09:59:21 -0400 Received: from mx1.emlix.com ([188.40.240.192]:42162 "EHLO mx1.emlix.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2437346AbfIWN7V (ORCPT ); Mon, 23 Sep 2019 09:59:21 -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 081BB5FBA6; Mon, 23 Sep 2019 15:59:19 +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 v4] serial: imx: adapt rx buffer and dma periods Date: Mon, 23 Sep 2019 15:59:16 +0200 Message-Id: <20190923135916.1212-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