lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210430175038.103226-3-sebastian.reichel@collabora.com>
Date:   Fri, 30 Apr 2021 19:50:38 +0200
From:   Sebastian Reichel <sebastian.reichel@...labora.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh@...nel.org>
Cc:     Jiri Slaby <jirislaby@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Sebastian Reichel <sebastian.reichel@...labora.com>,
        Ian Ray <ian.ray@...com>, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org, kernel@...labora.com
Subject: [PATCHv5 2/2] ARM: dts: imx53-ppd: add dma-info nodes

From: Fabien Lahoudere <fabien.lahoudere@...labora.com>

GEHC CS ONE (codename is PPD), has multiple microcontrollers connected
via UART controlling. UART2 is connected to an on-board microcontroller
at 19200 baud, which constantly pushes critical data (so aging character
detect interrupt will never trigger). This data must be processed at
50-200 Hz, so UART should return data in less than 5-20ms. With 1024
byte DMA buffer (and a constant data stream) the read operation instead
needs 1024 byte / 19200 baud = 53.333ms, which is way too long (note:
Worst case would be remote processor sending data with short pauses <=
7 characters, which would further increase this number). The current
downstream kernel instead configures 24 bytes resulting in 1.25ms, but
that is obviously not sensible for normal UART use cases and cannot be
used as new default.

The same device also has another microcontroller with a 4M baud connected
to UART5 exchanging lots of data. For this the same mechanism can be used
to increase the buffer size (downstream uses 4K instead of the default 1K)
with potentially slightly reduced buffer count. At this baud rate latency
is not an issue (4096 byte / 4M baud = 0.977 ms). Before increasing the
default buffer count from 4 to 16 in 76c38d30fee7, this was required to
avoid data loss. With the changed default it's a performance optimization.

Signed-off-by: Fabien Lahoudere <fabien.lahoudere@...labora.com>
[replace commit message]
Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
---
 arch/arm/boot/dts/imx53-ppd.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/imx53-ppd.dts b/arch/arm/boot/dts/imx53-ppd.dts
index be040b6a02fa..5a5fa6190a52 100644
--- a/arch/arm/boot/dts/imx53-ppd.dts
+++ b/arch/arm/boot/dts/imx53-ppd.dts
@@ -651,6 +651,7 @@ &uart1 {
 &uart2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart2>;
+	fsl,dma-info = <24 20>;
 	status = "okay";
 };
 
@@ -670,6 +671,7 @@ &uart4 {
 &uart5 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart5>;
+	fsl,dma-info = <4096 4>;
 	status = "okay";
 };
 
-- 
2.30.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ