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

PATCH In review Grant Likely 2 participants 5 messages Aug 23, 2005 – Aug 24, 2005

lore

Share & tools

lore

Grant Likely

author

2005-08-23 22:50 UTC #0 lore raw

PATCH 1/1 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 <[email protected]>

---

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

8ef971164affa27492e0f4abe73baf9b438575db

arch/ppc/boot/common/ns16550.c +9 -2

@@ -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 */

Tom Rini

2005-08-24 18:35 UTC #1 lore raw

Quoted 12 lines · Grant Likely

[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.

Quoted 4 lines

Rather; serial_init() should look first in SERIAL_PORT_DFNS and use BASE_BAUD as a backup.
Signed-off-by Grant Likely <[email protected]>

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.

Signature · 2 lines

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

Grant Likely

author

2005-08-24 21:39 UTC #2 lore raw

Quoted 17 lines · Tom Rini

Quoted 15 lines · Grant Likely
[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.

Quoted 8 lines

Quoted 1 line
Signed-off-by Grant Likely <[email protected]>
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.

Tom Rini

2005-08-24 21:47 UTC #3 lore raw

Quoted 26 lines · Grant Likely

Quoted 17 lines · Tom Rini
Quoted 15 lines · Grant Likely
[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.
Quoted 8 lines
Quoted 1 line
Signed-off-by Grant Likely <[email protected]>
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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Signature · 2 lines

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

Grant Likely

author

2005-08-24 22:20 UTC #4 lore raw

Quoted 1 line · Tom Rini

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

Cool, thanks.

Quoted 3 lines

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