From: Peter Hurley <peter@hurleysoftware.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Jiri Slaby <jslaby@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] tty: serial: core: Only invoke ->start_tx() if there is data to send
Date: Wed, 10 Sep 2014 15:52:59 -0400 [thread overview]
Message-ID: <5410AC1B.9000700@hurleysoftware.com> (raw)
In-Reply-To: <1410377601-26794-1-git-send-email-bigeasy@linutronix.de>
On 09/10/2014 03:33 PM, Sebastian Andrzej Siewior wrote:
> I noticed that the serial8250_tx_dma() is invoked sometimes while
> uart_circ_empty() says that the buffer is empty.
>
> I tracked one occuring down to:
>
> n_tty_write()
> => O_OPOST(tty))
> => the while loop did something but neither tty's ->write()
> nor its ->uart_put_char() callback was invoked().
> => tty->ops->flush_chars() is invoked with an empty buffer.
>
> For the 8250 uart driver we end up with:
> - DMA enabled
> nothing, just return (except there is DMA_TX bug or runtime-PM then we
> behave like in the no DMA case)
>
> - no DMA
> enable THRI interrupt, wait for it, disable THRI interrupt again
> because there is nothing to be done.
>
> While I don't know if it safe to drop that flush in n_tty if the buffer
> is empty, it should not do any harm in serial's core part to not invoke
> ->start_tx() if the buffer is empty.
The serial core can't assume that start_tx() does not need invoking
because hardware that can stop_tx() with data in the transmitter
won't restart if the ring buffer is empty but data is still in the
transmitter. [Note that the 16C950 port type does this in the 8250 driver.]
So this has to be handled in the 8250 driver.
What is the actual issue? Are you trying not to unnecessarily wake
the omap hardware if runtime-PM is on?
Regards,
Peter Hurley
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> drivers/tty/serial/serial_core.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 5a78f6940760..e55724a911d5 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -90,7 +90,8 @@ static void __uart_start(struct tty_struct *tty)
> struct uart_state *state = tty->driver_data;
> struct uart_port *port = state->uart_port;
>
> - if (!tty->stopped && !tty->hw_stopped)
> + if (!tty->stopped && !tty->hw_stopped &&
> + !uart_circ_empty(&port->state->xmit))
> port->ops->start_tx(port);
> }
>
>
next prev parent reply other threads:[~2014-09-10 19:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 19:33 [RFC PATCH] tty: serial: core: Only invoke ->start_tx() if there is data to send Sebastian Andrzej Siewior
2014-09-10 19:52 ` Peter Hurley [this message]
2014-09-11 8:03 ` Sebastian Andrzej Siewior
2014-09-11 12:48 ` Peter Hurley
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=5410AC1B.9000700@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=bigeasy@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.