From: Martin Kaistra <martin.kaistra@linutronix.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michal Simek <michal.simek@amd.com>,
linux-serial@vger.kernel.org,
Manikanta Guntupalli <manikanta.guntupalli@amd.com>
Subject: Re: [PATCH] serial: uartps: do not deassert RS485 RTS GPIO prematurely
Date: Tue, 19 Aug 2025 17:59:34 +0200 [thread overview]
Message-ID: <2784dfee-a010-426f-a09e-aadc7abe3148@linutronix.de> (raw)
In-Reply-To: <2025081955-debatable-registrar-3c23@gregkh>
Am 19.08.25 um 12:49 schrieb Greg Kroah-Hartman:
> On Mon, Aug 18, 2025 at 02:00:02PM +0200, Martin Kaistra wrote:
>> Am 18.08.25 um 12:02 schrieb Greg Kroah-Hartman:
>>> On Mon, Aug 18, 2025 at 11:52:16AM +0200, Martin Kaistra wrote:
>>>> After all bytes to be transmitted have been written to the FIFO
>>>> register, the hardware might still be busy actually sending them.
>>>>
>>>> Thus, wait for the TX FIFO to be empty before starting the timer for the
>>>> RTS after send delay.
>>>>
>>>> Fixes: fccc9d9233f9 ("tty: serial: uartps: Add rs485 support to uartps driver")
>>>> Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
>>>> ---
>>>> I tried using the TX empty interrupt instead of polling the register,
>>>> but it doesn't seem to be firing reliably, which is why I chose this
>>>> implementation instead.
>>>>
>>>> drivers/tty/serial/xilinx_uartps.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
>>>> index fe457bf1e15bb..38d2b33d0b6c8 100644
>>>> --- a/drivers/tty/serial/xilinx_uartps.c
>>>> +++ b/drivers/tty/serial/xilinx_uartps.c
>>>> @@ -454,6 +454,10 @@ static void cdns_uart_handle_tx(void *dev_id)
>>>> if (cdns_uart->port->rs485.flags & SER_RS485_ENABLED &&
>>>> (kfifo_is_empty(&tport->xmit_fifo) || uart_tx_stopped(port))) {
>>>> + /* Wait for the tx fifo to be actually empty */
>>>> + while (cdns_uart_tx_empty(port) != TIOCSER_TEMT)
>>>> + udelay(1);
>>>
>>> Having a while look that could potentially never exit? What could go
>>> wrong...
>>>
>>> Seriously, what happens if the port never empties due to flow control
>>> stuff?
>>
>> I will add a timeout..
>>
>> Before sending a v2, however, can I ask: will a solution with udelay() even
>> be accepted?
>
> Probably not, would you want that called when waiting like this?
It would look like this:
+ /* Wait for the TX FIFO to be empty */
+ for (tmout = 1000000; tmout; tmout--) {
+ if (cdns_uart_tx_empty(port) == TIOCSER_TEMT)
+ break;
+ udelay(1);
+ }
prev parent reply other threads:[~2025-08-19 15:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 9:52 [PATCH] serial: uartps: do not deassert RS485 RTS GPIO prematurely Martin Kaistra
2025-08-18 10:02 ` Greg Kroah-Hartman
2025-08-18 10:02 ` Greg Kroah-Hartman
2025-08-18 12:00 ` Martin Kaistra
2025-08-19 10:49 ` Greg Kroah-Hartman
2025-08-19 15:59 ` Martin Kaistra [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2784dfee-a010-426f-a09e-aadc7abe3148@linutronix.de \
--to=martin.kaistra@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-serial@vger.kernel.org \
--cc=manikanta.guntupalli@amd.com \
--cc=michal.simek@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).