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;
Message-ID: <378824ab-3cc9-dcf5-b9ea-5e49b57792a6@camlingroup.com>
Date:   Wed, 16 Feb 2022 06:45:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH] serial: imx: leave IRTS disabled if using modem-control
 CTS
To:     Tim Harvey <tharvey@gateworks.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>,
        =?UTF-8?Q?Tomasz_Mo=c5=84?= <tomasz.mon@camlingroup.com>
References: <20220214213020.685-1-tharvey@gateworks.com>
 <9d5cff18-5493-f6dd-4bd6-9bafa2a503a7@camlingroup.com>
 <CAJ+vNU0sWGsQa=YwLE9Ng34-DhJF=YR3oTV+q--KcgTMCjBa2w@mail.gmail.com>
From:   =?UTF-8?Q?Tomasz_Mo=c5=84?= <tomasz.mon@camlingroup.com>
In-Reply-To: <CAJ+vNU0sWGsQa=YwLE9Ng34-DhJF=YR3oTV+q--KcgTMCjBa2w@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?4I19ylRA8C0Qf++kJIov8htgrm256J/K6XfnontnJPhb/DM4DaD6RKqCSUHf?=
 =?us-ascii?Q?seVEK+bfFr6McyhDOOw5a6J2NNekuP5iQzz0rG9X2nbOboPVEdgr4Uu9+pmu?=
 =?us-ascii?Q?BU2KT1cMq4niisX7RZTxa6gbfFpOdhEi5Fq3XcmVek7nvRkHkeQq23l0Rjqe?=
 =?us-ascii?Q?idtAJX2W4k8sUIIGGq77UNc88BucSxp+E0DPmraAj4dD5s8xPhU9X1EJEeCT?=
 =?us-ascii?Q?OHHQUFF7Yl9qX418rojxaecALErwS9kf+1M2Bors+NmuEe61atDA7FIPKOhm?=
 =?us-ascii?Q?aGzLrYiEhma3Lf+bYb1ixvkOgAEE5wb+uh73hOO1t2tDHqgQZ0irCjR4qgiZ?=
 =?us-ascii?Q?R6jYVPPSZPbU3AJQaADMYLvO2UnYrgW1AeA7HTr4E5PcCWYw+YLs/tzkber5?=
 =?us-ascii?Q?HlDIFqu6wI4EckfkWbLiNLUE5Cmid7/vDJkTxUl2acJH6BqrZMwgeIvFIK7O?=
 =?us-ascii?Q?RTBEeE81LM5qiwCfoiFhieuR7+kiFjYPPp3UfjWPVMHTZ3gTPhWxJcZGEuJf?=
 =?us-ascii?Q?M1nLswoH3MvFGRu7zS0gvbbYBxwx2SK4RfMOKx+g5WHPDX1Nwar57oOAbhRV?=
 =?us-ascii?Q?vt9Z1fsa36bFBFeJIoGDxpJPhubXZS5bE9DwfHGOwChtvkNx/VnzMC9Hn2Wb?=
 =?us-ascii?Q?6950sf5fqKGNcPGV8m4aIc56IjZW1kNVu0yRstehExGFaDzOB7/5lwQhcNnm?=
 =?us-ascii?Q?aQRwP5pmdAv528lcEwDIAleZT1XMkVkUVou/SOG/Qnfd9gOITxkON0sQW9BQ?=
 =?us-ascii?Q?2q0GN7aRtcuJ1eeevOG/q0TPZDdbzoOOB4GIBE7JDGMsi7+pIs6J82q7IDmy?=
 =?us-ascii?Q?Ak/WXohSEv8mJMPL91KvOH5j1+dh6XY8XPaUKJI9SUfHpU/ZG8jo/Qan6UgQ?=
 =?us-ascii?Q?gGpIY9oESGi78L5UOwVSsXZxk/UV9Cu/Phw/fVglE/jrKsc4yLK+QghfUZi1?=
 =?us-ascii?Q?Mavrh0Rjs/O79L09p3elnQQ4DO5urfiqYacWqkxgNKJBu15hO8vbALfcEJ5f?=
 =?us-ascii?Q?e55yH6mnUg+JkkcFJpXpp6ogG3jl5X80VAeJLeDDQ8PfpD8Wmq8w6xu8FhV2?=
 =?us-ascii?Q?AMyrmupaC4iUhLU5g6qa9sCxiia6ufKOJ4t82wZ43prF5H2QTgCAcd4oXImC?=
 =?us-ascii?Q?KSxNfxnFSz06R+Uq62Q1Z6co8NTNdCJhuiwquWSbwSOnyQ+teEa21v37+lNu?=
 =?us-ascii?Q?BpjZUbVWYxTf+U0tQXW7D9gBvs1FtbUkcSAf/uVnPLpvK19JeuensUOQggX1?=
 =?us-ascii?Q?05at0xJEz2X1jZ8j0pL/hSGjAistNp1X/T4/l0A19WqZlRIX1wpftO3aCkZS?=
 =?us-ascii?Q?xEs1LFUluA1CiJtdtWe97MGwP0EfSri06JG/WkOAFJ/jZTEkC6vE+zZ8fd/t?=
 =?us-ascii?Q?0f2tXh3IqtIa91cfkkhglG0JpO2HmMnXZSEVD/LD/3HDKv2jwx3P0f2D6wsH?=
 =?us-ascii?Q?O11b/mLpLj7j6JXCPABd9DxrJsyH4RBZQEJHosTTIgu4wusLcWmclS58C1it?=
 =?us-ascii?Q?ZnjXP95F6CHlY+xMHH+MhAg/tn8SyQ+z9lzjylroE4yv5eQlrl5i7FLsiL+r?=
 =?us-ascii?Q?vO8wH4rERWHQ/ba3fFuJJ92+Z94VjtaappfOX+H8AtC6/KuWu0+c5B6Z81K6?=
 =?us-ascii?Q?WZKv+JzHm47/3H+IDcxE7mU+pVzH3BGN/9f2gxls3NGBUPJ7CVSs66T7EHiS?=
 =?us-ascii?Q?z0uAHQ=3D=3D?=
X-OriginatorOrg: camlingroup.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c2821fa5-297c-4312-3587-08d9f10f81c3
X-MS-Exchange-CrossTenant-AuthSource: CWLP123MB5572.GBRP123.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2022 05:45:15.6474
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: fd4b1729-b18d-46d2-9ba0-2717b852b252
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: OjqG8WIS9sWPmIjdMTInneOI5Dm7cjIQgxZrewHgYzMQvPNgOL/vBYj+idvm90tjZ551Y+3no9NWJXDGKlwdfiVvihUhfJI8Tk0DpcnSKQk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO4P123MB6370
Authentication-Results: relay.mimecast.com;
        auth=pass smtp.auth=CUK97A341 smtp.mailfrom=tomasz.mon@camlingroup.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: camlingroup.com
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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

Best Regards,
Tomasz Mon