linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: RFC: delete UART current-speed from 4xx DTS?
Date: Wed, 23 Sep 2009 14:15:46 -0400	[thread overview]
Message-ID: <20090923181546.GI14261@zod.rchland.ibm.com> (raw)
In-Reply-To: <20090916131943.GA14261@zod.rchland.ibm.com>

On Wed, Sep 16, 2009 at 09:19:43AM -0400, Josh Boyer wrote:
>On Wed, Sep 16, 2009 at 07:44:07AM +1000, Benjamin Herrenschmidt wrote:
>>On Tue, 2009-09-15 at 11:32 -0400, Josh Boyer wrote:
>Ok, so I think that is related to what I originally hit.
>
>I played around with removing the current-speed property on canyonlands today,
>and noticed that I would get no console output at all unless I specified a
>baudrate with console=ttyS0,115200.  That was sort of contrary to what I found
>with bamboo, so I diffed the configs to see why.  Bamboo has udbg enabled and
>hence has legacy_serial builtin, whereas canyonlands just has of_serial.

Correcting myself again, there really isn't any difference from a driver
perspective at a build level.  Both Cayonlands and Bamboo have udbg selected.
The difference is that Bamboo has linux,stdout-path specified in the choosen
node and Caynonlands does not.  Udbg looks for that, etc etc.

>Alternatively, we could try patching of_serial.c to do the baudrate probe
>as well.

I looked at this.  It's rather ugly, because of_serial.c doesn't really do
anything from a hardware perspective.  It simply binds to the device nodes
and lets the underlying serial driver do all the hardware handling.  We'd
need to have it ioremap, probe, iounmap and that all seems rather silly.

Looking at the 8250 driver, there is a place we could autoprobe it.  Something
like the ugly patch below.  It would probably need to be wrapped in a CONFIG
option, but you get the idea.

Overall, I'm not sure having either is a requirement for removing the
current-speed properties from the DTS files.  The only thing I could see
needing is telling of_serial.c to ignore a current-speed=0 property, as that
seems to be pretty invalid, but what some versions of U-Boot do.

josh

---

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 2209620..0cced56 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2778,7 +2778,7 @@ serial8250_console_write(struct console *co, const char *s, unsigned int count)
 static int __init serial8250_console_setup(struct console *co, char *options)
 {
 	struct uart_port *port;
-	int baud = 9600;
+	int baud = 0;
 	int bits = 8;
 	int parity = 'n';
 	int flow = 'n';
@@ -2797,6 +2797,26 @@ static int __init serial8250_console_setup(struct console *co, char *options)
 	if (options)
 		uart_parse_options(options, &baud, &parity, &bits, &flow);
 
+	if (baud == 0) {
+		unsigned char old_lcr, div, pre;
+		struct uart_8250_port *up = (struct uart_8250_port *) port;
+
+		old_lcr = serial_inp(up, UART_LCR);
+		serial_outp(up, UART_LCR, UART_LCR_DLAB);
+		div = serial_dl_read(up);
+		if (serial_inp(up, UART_MCR) & 0x80)
+			pre = 4;
+		else
+			pre = 1;
+
+		serial_outp(up, UART_LCR, old_lcr);
+
+		baud = (port->uartclk / pre) / (div * 16);
+
+		if (baud > (port->uartclk / 16))
+			baud = 9600;
+	}
+
 	return uart_set_options(port, co, baud, parity, bits, flow);
 }
 

      parent reply	other threads:[~2009-09-23 18:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15 14:31 RFC: delete UART current-speed from 4xx DTS? Paul Gortmaker
2009-09-15 15:32 ` Josh Boyer
2009-09-15 19:32   ` Paul Gortmaker
2009-09-15 20:02     ` Josh Boyer
2009-09-15 20:44       ` Paul Gortmaker
2009-09-15 21:44   ` Benjamin Herrenschmidt
2009-09-16 13:19     ` Josh Boyer
2009-09-16 14:57       ` Paul Gortmaker
2009-09-16 21:31       ` Benjamin Herrenschmidt
2009-09-17  1:44         ` Josh Boyer
2009-09-23 18:15       ` Josh Boyer [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=20090923181546.GI14261@zod.rchland.ibm.com \
    --to=jwboyer@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paul.gortmaker@windriver.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).