[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9d5cff18-5493-f6dd-4bd6-9bafa2a503a7@camlingroup.com>
Date: Tue, 15 Feb 2022 07:03:18 +0100
From: Tomasz Moń <tomasz.mon@...lingroup.com>
To: Tim Harvey <tharvey@...eworks.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
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>,
linux-serial@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Cc: Richard Genoud <richard.genoud@...il.com>,
Sergey Organov <sorganov@...il.com>
Subject: Re: [PATCH] serial: imx: leave IRTS disabled if using modem-control
CTS
On 14.02.2022 22:30, Tim Harvey wrote:
> If using modem-control gpios for CTS we must leave IRTS disabled
> as otherwise the hardware will only transmit based on the internal RTS
> pin routed to it.
>
> This allows hardware flow control to be used with cts-gpios.
This hardware flow control sounds quite limited. Once CTS becomes
inactive, the transmitter will still output all characters from TxFIFO.
Transmitting whole TxFIFO already sounds quite bad, but that's the best
case scenario where gpio interrupt is handled right away without any
delay (so more than TxFIFO characters can actually be transmitted).
Does the internal RTS default to inactive when it's not pinmuxed to the
actual pin? If so, then controlling UCR2_IRTS based on CTS gpio could
halt the transmission when the TxFIFO is not empty.
Best Regards,
Tomasz Mon
Powered by blists - more mailing lists