[PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE

[PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE

REPOST: fixed formating problems in original patch

Modifies serial_init to get base baud rate from the rs_table entry instead
of BAUD_BASE.  Will default back to BAUD_BASE if base_baud is not set.

This patch eliminates duplication between the SERIAL_PORT_DFNS macro and
BAUD_BASE.  Without the patch, if a port set the baud rate in
SERIAL_PORT_DFNS, but did not update BASE_BAUD, the BASE_BAUD value
would still be used.

Rather; serial_init() should look first in SERIAL_PORT_DFNS and use
BASE_BAUD as a backup.

Signed-off-by: Grant Likely <redacted>
---

 arch/ppc/boot/common/ns16550.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

8ef971164affa27492e0f4abe73baf9b438575db

diff --git a/arch/ppc/boot/common/ns16550.c b/arch/ppc/boot/common/ns16550.c
--- a/arch/ppc/boot/common/ns16550.c
+++ b/arch/ppc/boot/common/ns16550.c

@@ -25,6 +25,7 @@ unsigned long serial_init(int chan, void
 {
 	unsigned long com_port;
 	unsigned char lcr, dlm;
+	unsigned long baud_base;
 
 	/* We need to find out which type io we're expecting.  If it's
 	 * 'SERIAL_IO_PORT', we get an offset from the isa_io_base.

@@ -43,6 +44,12 @@ unsigned long serial_init(int chan, void
 
 	/* How far apart the registers are. */
 	shift = rs_table[chan].iomem_reg_shift;
+	baud_base = rs_table[chan].baud_base;
+#if defined(BASE_BAUD)
+	if (!baud_base)
+		baud_base = BASE_BAUD;
+#endif
+
 	
 	/* save the LCR */
 	lcr = inb(com_port + (UART_LCR << shift));

@@ -62,9 +69,9 @@ unsigned long serial_init(int chan, void
 	else {
 		/* Input clock. */
 		outb(com_port + (UART_DLL << shift),
-		     (BASE_BAUD / SERIAL_BAUD) & 0xFF);
+		     (baud_base / SERIAL_BAUD) & 0xFF);
 		outb(com_port + (UART_DLM << shift),
-		     (BASE_BAUD / SERIAL_BAUD) >> 8);
+		     (baud_base / SERIAL_BAUD) >> 8);
 		/* 8 data, 1 stop, no parity */
 		outb(com_port + (UART_LCR << shift), 0x03);
 		/* RTS/DTR */

On Tue, Aug 23, 2005 at 04:47:02PM -0600, Grant Likely wrote:

[PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE

REPOST: fixed formating problems in original patch

Modifies serial_init to get base baud rate from the rs_table entry instead
of BAUD_BASE.  Will default back to BAUD_BASE if base_baud is not set.

This patch eliminates duplication between the SERIAL_PORT_DFNS macro and
BAUD_BASE.  Without the patch, if a port set the baud rate in
SERIAL_PORT_DFNS, but did not update BASE_BAUD, the BASE_BAUD value
would still be used.

Rather; serial_init() should look first in SERIAL_PORT_DFNS and use
BASE_BAUD as a backup.

Signed-off-by: Grant Likely <redacted>

With everything in-tree, this is fine as baud_base is always set to
BASE_BAUD, but I'm wondering why this was done.  Did you do a port and
not follow on this?  It looks like today you could get away without
defining BASE_BAUD correctly (8250_early uses and needs this to be
correct, but I don't think this is frequently used, yet).  But I'm not
sure what we gain here.  Thanks.

-- 
Tom Rini
http://gate.crashing.org/~trini/

On Wed, Aug 24, 2005 at 11:35:20AM -0700, Tom Rini wrote:

On Tue, Aug 23, 2005 at 04:47:02PM -0600, Grant Likely wrote:

quoted

[PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE

REPOST: fixed formating problems in original patch

Modifies serial_init to get base baud rate from the rs_table entry instead
of BAUD_BASE.  Will default back to BAUD_BASE if base_baud is not set.

This patch eliminates duplication between the SERIAL_PORT_DFNS macro and
BAUD_BASE.  Without the patch, if a port set the baud rate in
SERIAL_PORT_DFNS, but did not update BASE_BAUD, the BASE_BAUD value
would still be used.

Rather; serial_init() should look first in SERIAL_PORT_DFNS and use
BASE_BAUD as a backup.

Signed-off-by: Grant Likely <redacted>

With everything in-tree, this is fine as baud_base is always set to
BASE_BAUD, but I'm wondering why this was done.  Did you do a port and
not follow on this?  It looks like today you could get away without
defining BASE_BAUD correctly (8250_early uses and needs this to be
correct, but I don't think this is frequently used, yet).  But I'm not
sure what we gain here.  Thanks.

I stumbled across this while working on moving v2pro to the platform
bus.  (I'm also trying to isolate xparameter.h as much as possible to
avoid recompiling the world everytime I get a new bitstream).  I've got
the base baud for each port in the rs_table.

IMHO it doesn't seem right to have part of the serial parameters pulled
from rs_table and the base baud pulled from elseware.  ie. it looked
like a latent bug to me, so I wrote the patch.  I've also got the
impression that the serial subsystem is trying to move away from
depending on BASE_BAUD

Cheers,
g.

On Wed, Aug 24, 2005 at 03:35:21PM -0600, Grant Likely wrote:

On Wed, Aug 24, 2005 at 11:35:20AM -0700, Tom Rini wrote:

quoted

On Tue, Aug 23, 2005 at 04:47:02PM -0600, Grant Likely wrote:

quoted

[PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE

REPOST: fixed formating problems in original patch

Modifies serial_init to get base baud rate from the rs_table entry instead
of BAUD_BASE.  Will default back to BAUD_BASE if base_baud is not set.

This patch eliminates duplication between the SERIAL_PORT_DFNS macro and
BAUD_BASE.  Without the patch, if a port set the baud rate in
SERIAL_PORT_DFNS, but did not update BASE_BAUD, the BASE_BAUD value
would still be used.

Rather; serial_init() should look first in SERIAL_PORT_DFNS and use
BASE_BAUD as a backup.

Signed-off-by: Grant Likely <redacted>

With everything in-tree, this is fine as baud_base is always set to
BASE_BAUD, but I'm wondering why this was done.  Did you do a port and
not follow on this?  It looks like today you could get away without
defining BASE_BAUD correctly (8250_early uses and needs this to be
correct, but I don't think this is frequently used, yet).  But I'm not
sure what we gain here.  Thanks.

I stumbled across this while working on moving v2pro to the platform
bus.  (I'm also trying to isolate xparameter.h as much as possible to
avoid recompiling the world everytime I get a new bitstream).  I've got
the base baud for each port in the rs_table.

I'll buy that, and slightly modify this for 2.6.14, thanks.

IMHO it doesn't seem right to have part of the serial parameters pulled
from rs_table and the base baud pulled from elseware.  ie. it looked
like a latent bug to me, so I wrote the patch.  I've also got the
impression that the serial subsystem is trying to move away from
depending on BASE_BAUD

The general problem here (Holy crap! arch/ppc/boot/common/ns16550.c uses
everything we'd like to kill from <asm*/serial.h>) is come up before,
and is being slowly fixed.

-- 
Tom Rini
http://gate.crashing.org/~trini/

On Wed, Aug 24, 2005 at 02:47:34PM -0700, Tom Rini wrote:

I'll buy that, and slightly modify this for 2.6.14, thanks.

Cool, thanks.

The general problem here (Holy crap! arch/ppc/boot/common/ns16550.c uses
everything we'd like to kill from <asm*/serial.h>) is come up before,
and is being slowly fixed.

:)

Now how do I get ns16550 to use a flattened device tree in a clean way?
:P

g.