Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220214213020.685-1-tharvey@gateworks.com> <9d5cff18-5493-f6dd-4bd6-9bafa2a503a7@camlingroup.com>
In-Reply-To: <9d5cff18-5493-f6dd-4bd6-9bafa2a503a7@camlingroup.com>
From:   Tim Harvey <tharvey@gateworks.com>
Date:   Tue, 15 Feb 2022 09:26:32 -0800
Message-ID: <CAJ+vNU0sWGsQa=YwLE9Ng34-DhJF=YR3oTV+q--KcgTMCjBa2w@mail.gmail.com>
Subject: Re: [PATCH] serial: imx: leave IRTS disabled if using modem-control CTS
To:     =?UTF-8?Q?Tomasz_Mo=C5=84?= <tomasz.mon@camlingroup.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        NXP Linux Team <linux-imx@nxp.com>,
        linux-serial@vger.kernel.org,
        Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
        open list <linux-kernel@vger.kernel.org>,
        Richard Genoud <richard.genoud@gmail.com>,
        Sergey Organov <sorganov@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Feb 14, 2022 at 10:03 PM Tomasz Mo=C5=84 <tomasz.mon@camlingroup.co=
m> wrote:
>
> 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.
>

Tomasz,

I agree that the increased latency makes using a GPIO for CTS
(software controlled) not as good as one pinmuxed into the UART block
directly (hardware controlled) but without this patch GPIO for CTS
does not work at all because the internal RTS defaults to inactive
when its not pinmuxed. For many applications the latency is not an
issue.

Best Regards,

Tim