Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <20220214213020.685-1-tharvey@gateworks.com> <9d5cff18-5493-f6dd-4bd6-9bafa2a503a7@camlingroup.com>
 <CAJ+vNU0sWGsQa=YwLE9Ng34-DhJF=YR3oTV+q--KcgTMCjBa2w@mail.gmail.com> <378824ab-3cc9-dcf5-b9ea-5e49b57792a6@camlingroup.com>
In-Reply-To: <378824ab-3cc9-dcf5-b9ea-5e49b57792a6@camlingroup.com>
From:   Tim Harvey <tharvey@gateworks.com>
Date:   Thu, 17 Feb 2022 08:22:07 -0800
Message-ID: <CAJ+vNU2JbRm2SPQTPC7J-E0PGc0tuzd-9-=MFsRSWKEu8ti9aA@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 Tue, Feb 15, 2022 at 9:45 PM Tomasz Mo=C5=84 <tomasz.mon@camlingroup.com=
> wrote:
>
> On 15.02.2022 18:26, Tim Harvey wrote:
> > On Mon, Feb 14, 2022 at 10:03 PM Tomasz Mo=C5=84 <tomasz.mon@camlingrou=
p.com> wrote:
> >> 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 bes=
t
> >> 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 th=
e
> >> actual pin? If so, then controlling UCR2_IRTS based on CTS gpio could
> >> halt the transmission when the TxFIFO is not empty.
> >>> 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.
>
> I think I didn't write the message clear enough. I agree, that the GPIO
> handling time is something the user has to accept. Usually this part
> alone is not that bad though, as many receivers are capable of receiving
> more than one character after deasserting their RTS output (transmitter
> CTS input).
>
> The general expectation is that the transmitter will output maximum one
> more character *after* CTS GPIO change is handled by software. This is
> not the case with current version of the patch.
>
> With current version of the patch, after CTS GPIO handler finishes, the
> UART will continue to transmit up to 32 characters if not using DMA.
> When DMA is active it is much worse, as it will keep transmitting all
> data already submitted to dmaengine.
>
> As the internal RTS defaults to inactive when its not pinmuxed, the
> software is able to freeze the TxFIFO (and thus DMA if enabled). To
> freeze TxFIFO when using CTS GPIO, the software has to clear IRTS bit in
> UCR2 register. Setting IRTS will thaw the TxFIFO.
>

Tomasz,

Ok - I understand what you are saying. Yes, I should be able to use
IRTS to freeze/thaw the transmitter based on it being inactive when
not pinmuxed. I will work on a v2.

Thanks for the explanation!

Best Regards,

Tim