linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tixy@linaro.org (Jon Medhurst (Tixy))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] serial: pl011: use port lock to guard control register access
Date: Mon, 09 Dec 2013 17:34:01 +0000	[thread overview]
Message-ID: <1386610441.3380.58.camel@linaro1.home> (raw)
In-Reply-To: <alpine.LFD.2.10.1312041105470.31246@knanqh.ubzr>

On Wed, 2013-12-04 at 11:17 -0500, Nicolas Pitre wrote:
> On Wed, 4 Dec 2013, Jon Medhurst (Tixy) wrote:
> 
> > I can't help but think I've missed something fundamental here as it
> > seems wrong to be in the situation at all where were initialising
> > hardware if it is already being used?
> > 
> > Also, even with this fix I still see spurious/corrupt output on the
> > serial port at the point the port is initialised, so there is obviously
> > some other issues in this area.
> 
> I don't know if this is still the case nowdays, but that might be due to 
> the fact that the tty layer initializes the port speed to 9600 bauds 
> when opened.  So there might be a period when the port goes from 115200 
> bauds (from the serial console setup) to 9600 bauds, to finally go back 
> to 115200 bauds configured by the getty process.  If the serial console 
> is in the middle of outputting something when user space opens the port 
> then you might see garbled output for a brief period.

I've just got back to looking at this and the baud rate and data format
don't get gratuitously changed by the serial framework, just by
pl011_startup which sets the port to max baud rate and shortest bit size
in order to send one character via loopback mode (relevant code copied
below). These values get restored fairly quickly afterwards by a call to
pl011_set_termios, but there is a window where they are wrong, leading
to corruption if console outputs text during this window.

If I save and restore register values in this startup code then that
seems to fix things.

I guess an alternative would be to leave the registers unchanged in this
initialisation code if the port is being used for a console. But I'm
unsure how to reliably detect that is the case or if using the fact that
the port has already been setup once means that it's safe to assume it
stays set up, e.g. state isn't lost though power management actions.

	/*
	 * Provoke TX FIFO interrupt into asserting.
	 */
	cr = UART01x_CR_UARTEN | UART011_CR_TXE | UART011_CR_LBE;
	writew(cr, uap->port.membase + UART011_CR);
	writew(0, uap->port.membase + UART011_FBRD);
	writew(1, uap->port.membase + UART011_IBRD);
	writew(0, uap->port.membase + uap->lcrh_rx);
	if (uap->lcrh_tx != uap->lcrh_rx) {
		int i;
		/*
		 * Wait 10 PCLKs before writing LCRH_TX register,
		 * to get this delay write read only register 10 times
		 */
		for (i = 0; i < 10; ++i)
			writew(0xff, uap->port.membase + UART011_MIS);
		writew(0, uap->port.membase + uap->lcrh_tx);
	}
	writew(0, uap->port.membase + UART01x_DR);
	while (readw(uap->port.membase + UART01x_FR) & UART01x_FR_BUSY)
		barrier();

-- 
Tixy

      reply	other threads:[~2013-12-09 17:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04  9:38 [PATCH] serial: pl011: use port lock to guard control register access Jon Medhurst (Tixy)
2013-12-04 16:17 ` Nicolas Pitre
2013-12-09 17:34   ` Jon Medhurst (Tixy) [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=1386610441.3380.58.camel@linaro1.home \
    --to=tixy@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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 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).