linux-kernel - [PATCHv5 2/2] ARM: dts: imx53-ppd: add dma-info nodes

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]

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