* [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
@ 2005-08-23 22:07 Grant Likely
0 siblings, 0 replies; 6+ messages in thread
From: Grant Likely @ 2005-08-23 22:07 UTC (permalink / raw)
To: linux-ppc-embedded
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 <grant.likely@gdcanada.com>
---
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 */
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
@ 2005-08-23 22:47 Grant Likely
2005-08-24 18:35 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Grant Likely @ 2005-08-23 22:47 UTC (permalink / raw)
To: linux-ppc-embedded
[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 <grant.likely@gdcanada.com>
---
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 */
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
2005-08-23 22:47 [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE Grant Likely
@ 2005-08-24 18:35 ` Tom Rini
2005-08-24 21:35 ` Grant Likely
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2005-08-24 18:35 UTC (permalink / raw)
To: linux-ppc-embedded
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 <grant.likely@gdcanada.com>
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
2005-08-24 18:35 ` Tom Rini
@ 2005-08-24 21:35 ` Grant Likely
2005-08-24 21:47 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Grant Likely @ 2005-08-24 21:35 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
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:
>
> > [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 <grant.likely@gdcanada.com>
>
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
2005-08-24 21:35 ` Grant Likely
@ 2005-08-24 21:47 ` Tom Rini
2005-08-24 22:17 ` Grant Likely
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2005-08-24 21:47 UTC (permalink / raw)
To: linuxppc-embedded
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:
> > 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 <grant.likely@gdcanada.com>
> >
> > 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE
2005-08-24 21:47 ` Tom Rini
@ 2005-08-24 22:17 ` Grant Likely
0 siblings, 0 replies; 6+ messages in thread
From: Grant Likely @ 2005-08-24 22:17 UTC (permalink / raw)
To: Tom Rini, linuxppc-embedded
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-08-24 22:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-23 22:47 [PATCH] Allow ns16550.c to get base baud from rs_table instead of BAUD_BASE Grant Likely
2005-08-24 18:35 ` Tom Rini
2005-08-24 21:35 ` Grant Likely
2005-08-24 21:47 ` Tom Rini
2005-08-24 22:17 ` Grant Likely
-- strict thread matches above, loose matches on Subject: below --
2005-08-23 22:07 Grant Likely
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).