From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Tim Kryger <tim.kryger@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
patches@linaro.org
Subject: Re: [PATCH] serial: 8250_dw: Improve unwritable LCR workaround
Date: Wed, 25 Sep 2013 14:42:32 +0300 [thread overview]
Message-ID: <20130925114232.GA26259@xps8300> (raw)
In-Reply-To: <1380069549-9176-1-git-send-email-tim.kryger@linaro.org>
Hi Tim,
On Tue, Sep 24, 2013 at 05:39:09PM -0700, Tim Kryger wrote:
> The Designware UART has a limitation where it ignores writes into the
> LCR if the UART is busy. The current workaround stashes a copy of the
> last written LCR and writes it back down to the hardware if it receives
> a special busy interrupt which is raised when a write was ignored.
>
> Unfortunately, interrupts are typically disabled prior to performing a
> sequence of register writes that include the LCR so the point at which
> the retry occurs is too late. An example is serial8250_do_set_termios()
> where an ignored LCR write results in the baud divisor not being set and
> instead a garbage character is sent out the transmitter.
>
> Furthermore, since serial_port_out() offers no way to indicate failure,
> a serious effort must be made to ensure that the LCR is actually updated
> before returning back to the caller. This is difficult, however, as a
> UART that was busy during the first attempt is likely to still be busy
> when a subsequent attempt is made unless some extra action is taken.
>
> This updated workaround takes the extreme action of clearing the TX/RX
> FIFOs and reading the receive buffer before writing down the LCR in the
> hope that doing so will force the UART into an idle state. While this
> may seem unnecessarily aggressive, writes to the LCR are used to change
> the baud rate, parity, stop bit, or data length so the data that may be
> lost is likely not important. Admittedly, this is far from ideal but it
> seems to be the best that can be done given the hardware limitations.
<snip>
> @@ -76,17 +75,35 @@ static inline int dw8250_modify_msr(struct uart_port *p, int offset, int value)
> return value;
> }
>
> +/* The UART will ignore writes to LCR when busy we take aggressive steps
> + * to ensure that it is idle before attempting to write to LCR */
> +static void dw8250_force_idle(struct uart_port *p)
> +{
> + serial8250_clear_and_reinit_fifos(container_of
> + (p, struct uart_8250_port, port));
> + (void)p->serial_in(p, UART_LSR);
> + (void)p->serial_in(p, UART_MSR);
> + (void)p->serial_in(p, UART_RX);
> +}
This looks pretty brutal. Is it really necessary?
> static void dw8250_serial_out(struct uart_port *p, int offset, int value)
> {
> struct dw8250_data *d = p->private_data;
>
> - if (offset == UART_LCR)
> - d->last_lcr = value;
> -
> - if (offset == UART_MCR)
> - d->last_mcr = value;
> -
> - writeb(value, p->membase + (offset << p->regshift));
> + if (offset == UART_LCR) {
> + int tries = 1000;
> + while (tries--) {
> + if (value == p->serial_in(p, UART_LCR))
> + return;
> + dw8250_force_idle(p);
> + writeb(value, p->membase + (UART_LCR << p->regshift));
> + }
> + dev_err(p->dev, "Couldn't set LCR to %d\n", value);
Is it not enough to simply poll USR[0] to see when the UART becomes
free?
--
heikki
next prev parent reply other threads:[~2013-09-25 11:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 0:39 [PATCH] serial: 8250_dw: Improve unwritable LCR workaround Tim Kryger
2013-09-25 11:42 ` Heikki Krogerus [this message]
2013-09-25 22:47 ` Tim Kryger
2013-09-27 7:49 ` Heikki Krogerus
2013-10-01 17:13 ` Tim Kryger
2013-09-26 22:46 ` Greg Kroah-Hartman
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=20130925114232.GA26259@xps8300 \
--to=heikki.krogerus@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=patches@linaro.org \
--cc=tim.kryger@linaro.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.