From: Esben Haabendal <esben@geanix.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-rt-users@vger.kernel.org, John Ogness <john.ogness@linutronix.de>
Subject: Re: [RFC PATCH 1/2] serial: imx: Avoid busy polling for transmitter to become empty
Date: Thu, 04 Apr 2024 13:04:27 +0200 [thread overview]
Message-ID: <87bk6pl77o.fsf@geanix.com> (raw)
In-Reply-To: <20240404-wobbling-cyclic-90880ac17562-mkl@pengutronix.de> (Marc Kleine-Budde's message of "Thu, 4 Apr 2024 10:15:17 +0200")
Marc Kleine-Budde <mkl@pengutronix.de> writes:
> On 03.04.2024 17:22:52, Esben Haabendal wrote:
>> Busy polling with readl() is a rather harsh way to wait for a potentially
>> long time.
>
> This read_poll_timeout_atomic() is compiled to an
> imx_uart_readl()/udelay()/cpu_relax() loop. Does the introduction of
> udelay() bring any advantages?
Good point. Probably not. I can set sleep_us 0 to go back to a tight
loop.
>> While there, introduce a 10 ms timeout on this waiting, similar to what
>> many other serial drivers do.
>
> But you don't handle the return value...
True. But this is similar to all the different wait_for_xmitr()
functions, which does basically the same. They are all void, so the
timeout is handled in same happy-go-lucky style.
I think the best we could do would be to show an error message. But
maybe that is not the most sane thing to do to report a problem with
writing error messages. I don't know, but maybe that is why most the
other serial drivers are handling it like this.
In fsl_lpuart.c and uartlite.c a warning message is printed if/when this
timeout occurs. I am fine with doing that here as well...
On a related note. I am unsure if 10 ms is a good choice for timeout. I
picked it because it seems like a common value used in many/most
drivers. But at least some drivers use something like 1 s, which to me
sounds more sane given that we cannot do any meaningful error handling
on timeout.
/Esben
next prev parent reply other threads:[~2024-04-04 11:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-03 15:22 [RFC PATCH 0/2] serial: imx: Switch to nbcon console Esben Haabendal
2024-04-03 15:22 ` [RFC PATCH 1/2] serial: imx: Avoid busy polling for transmitter to become empty Esben Haabendal
2024-04-04 8:15 ` Marc Kleine-Budde
2024-04-04 11:04 ` Esben Haabendal [this message]
2024-04-04 11:33 ` Marc Kleine-Budde
2024-04-04 11:54 ` Esben Haabendal
2024-04-04 16:39 ` Marc Kleine-Budde
2024-04-03 15:22 ` [RFC PATCH 2/2] serial: imx: Switch to nbcon console Esben Haabendal
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=87bk6pl77o.fsf@geanix.com \
--to=esben@geanix.com \
--cc=john.ogness@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=mkl@pengutronix.de \
/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