All of lore.kernel.org
 help / color / mirror / Atom feed
* questions about 8250 uart support for adhoc boards
@ 2007-02-23 17:05 Rob Prowel
  2007-02-23 20:21 ` Russell King
  0 siblings, 1 reply; 11+ messages in thread
From: Rob Prowel @ 2007-02-23 17:05 UTC (permalink / raw)
  To: linux-kernel

I have a PC104 embedded system and am trying to make a Diamond 
Emerald-mm-opto four port serial board work in a recent kernel version 
(>=2.6.17).  The vendor only validates the board against 2.6.11: a 
kernel nearly two years old and several serial kernel config parameters 
have changed in that time period.

the board uses two 16c2850 uarts and has four ports.  It supports 
interrupt sharing through an ISR bitmask.

since the recent 2.6.x kernels now break down the non-standard uart 
support into specific hardware groups I cannot figure out how to get the 
blasted thing to register/recognize with setserial.  the MULTIPORT 
option no longer exists in the kernel code so I had to explicitly 
compile in "fourport" support just so ttyS4 through ttyS7 would be 
accessible...and yes, you can assume that I've increased the available 
ports using 8250.nr_uarts=16

At least now, with fourport compiled into the kernel, I can use 
setserial to see the uarts and correctly identify them...but the shared 
interrupt vector doesn't seem to work.  I haven't even attempted yet to 
try stty or echoing data our to an o-scope.

Here is the setserial dialog

# for i in 0 1 2 3 4 5 6 7; do setserial /dev/ttyS$i; 
done                          
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x01a0, IRQ: 2, Flags: Fourport
/dev/ttyS5, UART: unknown, Port: 0x01a8, IRQ: 2, Flags: Fourport
/dev/ttyS6, UART: unknown, Port: 0x01b0, IRQ: 2, Flags: Fourport
/dev/ttyS7, UART: unknown, Port: 0x01b8, IRQ: 2, Flags: Fourport

# sh /root/setserial
+ SS=/bin/setserial
++ /bin/setserial /dev/ttyS4 port 0x120 irq 12 autoconfig '^fourport'
++ /bin/setserial /dev/ttyS5 port 0x128 irq 12 autoconfig '^fourport'
++ /bin/setserial /dev/ttyS6 port 0x130 irq 12 autoconfig '^fourport'
++ /bin/setserial /dev/ttyS7 port 0x138 irq 12 autoconfig '^fourport'
++ /bin/setserial /dev/ttyS4 set_multiport port1 0x244 mask1 0x0f match1 0
Cannot get multiport config: Invalid argument

# for i in 0 1 2 3 4 5 6 7; do setserial /dev/ttyS$i; done             
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: 16850, Port: 0x0120, IRQ: 12
/dev/ttyS5, UART: 16850, Port: 0x0128, IRQ: 12
/dev/ttyS6, UART: 16850, Port: 0x0130, IRQ: 12
/dev/ttyS7, UART: 16850, Port: 0x0138, IRQ: 12
-bash-3.1#

and the isadump shows that the ports are visible

# # dump uart registers
# isadump -f -y 0x120 32
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 10 01 00 00 60 00 00 00 10 01 00 00 60 00 00
10: 00 10 01 00 00 60 00 00 00 10 01 00 00 60 00 80

# # dump ISR at 0x244
# isadump -f -y 0x240 16
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff
-bash-3.1#



I would so much appreciate if someone intimately familiar with the 
serial drivers could enlighten me as to what is going on here.

I'm not registered on the kernel list so CC to my email address would be 
appreciated.


Thanks,
Rob Prowel
Kuchera Defense Systems




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: questions about 8250 uart support for adhoc boards
  2007-02-23 17:05 questions about 8250 uart support for adhoc boards Rob Prowel
@ 2007-02-23 20:21 ` Russell King
  2007-02-23 20:48   ` Rob Prowel
  0 siblings, 1 reply; 11+ messages in thread
From: Russell King @ 2007-02-23 20:21 UTC (permalink / raw)
  To: Rob Prowel; +Cc: linux-kernel

On Fri, Feb 23, 2007 at 12:05:48PM -0500, Rob Prowel wrote:
> At least now, with fourport compiled into the kernel,

You don't even need to do that.  Just configure SERIAL_8250_NR_UARTS
and SERIAL_8250_RUNTIME_UARTS appropriately for your system.  There's
absolutely no need to build any of the additional modules.

> I can use 
> setserial to see the uarts and correctly identify them...but the shared 
> interrupt vector doesn't seem to work.  I haven't even attempted yet to 
> try stty or echoing data our to an o-scope.

I dropped support for the shared interrupt vector - having multiple
different ISRs depending on the way the wind was blowing was extremely
complex, and in this day and age of GHz CPUs rather silly.

The serial driver can still share interrupts just fine.  Just omit
configuring the multiport address and masks.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: questions about 8250 uart support for adhoc boards
  2007-02-23 20:21 ` Russell King
@ 2007-02-23 20:48   ` Rob Prowel
  2007-02-24 20:34     ` Stuart MacDonald
  0 siblings, 1 reply; 11+ messages in thread
From: Rob Prowel @ 2007-02-23 20:48 UTC (permalink / raw)
  To: Rob Prowel, linux-kernel, rmk+lkml

Thanks so much for your followup.


Russell King wrote:
> On Fri, Feb 23, 2007 at 12:05:48PM -0500, Rob Prowel wrote:
>   
>> At least now, with fourport compiled into the kernel,
>>     
>
> You don't even need to do that.  Just configure SERIAL_8250_NR_UARTS
> and SERIAL_8250_RUNTIME_UARTS appropriately for your system.  There's
> absolutely no need to build any of the additional modules.
>
>   
Unfortunately what I'm seeing in 2.6.20.1 seems to differ from this.  If 
I use the options below:

CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=16
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_FOURPORT is not set
# CONFIG_SERIAL_8250_ACCENT is not set
# CONFIG_SERIAL_8250_BOCA is not set
# CONFIG_SERIAL_8250_EXAR_ST16C554 is not set
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# Non-8250 serial port support

Then I can only access ttyS0 through ttyS3 sith setserial.  Only after I add
CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do anything with the 
additional ports.  I would otherwise get the evil setserial: invalid 
parameter error.

If you'd like I can offline you my complete .config file.  lemme know.

>> I can use 
>> setserial to see the uarts and correctly identify them...but the shared 
>> interrupt vector doesn't seem to work.  I haven't even attempted yet to 
>> try stty or echoing data our to an o-scope.
>>     
>
> I dropped support for the shared interrupt vector - having multiple
> different ISRs depending on the way the wind was blowing was extremely
> complex, and in this day and age of GHz CPUs rather silly.
>
> The serial driver can still share interrupts just fine.  Just omit
> configuring the multiport address and masks.
>
>   

OK.  Fair enough.  My question then becomes, how does the driver deal 
with this now? scan all applicable uarts when any relevant interrupt is 
detected (as identified in setserial)?


Thanks.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: questions about 8250 uart support for adhoc boards
  2007-02-23 20:48   ` Rob Prowel
@ 2007-02-24 20:34     ` Stuart MacDonald
  2007-02-26 17:02       ` Rob Prowel
  0 siblings, 1 reply; 11+ messages in thread
From: Stuart MacDonald @ 2007-02-24 20:34 UTC (permalink / raw)
  To: 'Rob Prowel', linux-kernel, rmk+lkml

From: On Behalf Of Rob Prowel
> Russell King wrote:
> > You don't even need to do that.  Just configure SERIAL_8250_NR_UARTS
> > and SERIAL_8250_RUNTIME_UARTS appropriately for your 
> system.  There's
> > absolutely no need to build any of the additional modules.
> >   
> Unfortunately what I'm seeing in 2.6.20.1 seems to differ 
> from this.  If 

PC104 is really an ISA bus. The ISA ports are stored in a table in the
8250 driver (instead of allocated dynamically like PCI ports); the
config option _NR_UARTS just tells the driver how large to make the
table.

> I use the options below:
> 
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_NR_UARTS=32

This makes the internal table be 32 ports big. The first four ports
end up configured for legacy/standard com ports, the rest are
unconfigured. You should be able to see them as unknowns with
setserial.

> CONFIG_SERIAL_8250_RUNTIME_UARTS=16
> CONFIG_SERIAL_8250_EXTENDED=y
> CONFIG_SERIAL_8250_MANY_PORTS=y
> # CONFIG_SERIAL_8250_FOURPORT is not set

All _FOURPORT does is specifically config ports 4-7 in the table to
have specific address/irqs for the FourPort board. What you do with
setserial is then change that config info to match your board.

You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it
looks like you don't. As long as _NR_UARTS is big enough, thus making
the internal table big enough, you should be able to configure, with
setserial, any of the ports in the table, including the first four.

> Then I can only access ttyS0 through ttyS3 sith setserial.  
> Only after I add
> CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do 
> anything with the 
> additional ports.  I would otherwise get the evil setserial: invalid 
> parameter error.

Very odd. You get this error when doing "setserial /dev/ttySxx", no
configuration? If so, that would imply that the table wasn't made big
enough, and the unconfigured ports haven't been registered with the
serial core.

> OK.  Fair enough.  My question then becomes, how does the driver deal 
> with this now? scan all applicable uarts when any relevant 
> interrupt is 
> detected (as identified in setserial)?

With our boards, the multiport is just a status register; it shows
which port has produced the interrupt, so the driver doesn't have to
loop through all the ports on the board looking for the correct one.
It doesn't actually enable/disable the sharing of the interrupt. The
setting of "irq 12" on multiple ports (from your original post) is
what enables the sharing, from the driver-side view. Maybe your
hardware is unusual and requires this ISR port to be set properly to
enable sharing; more likely is that the board itself has one or more
jumpers to set which interrupt it's using, and that's what enables the
sharing from the hardware-side view.

If I get some time tomorrow, I'll set up 2.6.20.1 and see what the
current options are doing.

If you can't get your board working, we have similar boards that do.

..Stu

-- 
We make multiport serial products.
http://www.connecttech.com/
(800) 426-8979


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: questions about 8250 uart support for adhoc boards
  2007-02-24 20:34     ` Stuart MacDonald
@ 2007-02-26 17:02       ` Rob Prowel
  2007-02-26 18:05         ` Russell King
  0 siblings, 1 reply; 11+ messages in thread
From: Rob Prowel @ 2007-02-26 17:02 UTC (permalink / raw)
  To: Stuart MacDonald; +Cc: linux-kernel, rmk+lkml

Stuart MacDonald wrote:
>> I use the options below:
>>
>> CONFIG_SERIAL_8250=y
>> CONFIG_SERIAL_8250_CONSOLE=y
>> CONFIG_SERIAL_8250_PCI=y
>> CONFIG_SERIAL_8250_NR_UARTS=32
>>     
>
> This makes the internal table be 32 ports big. The first four ports
> end up configured for legacy/standard com ports, the rest are
> unconfigured. You should be able to see them as unknowns with
> setserial.
>
>   
I can see them as unknowns with setserial but cannot set any parameters 
for them until a subsequent driver is loaded, like (fourport).

> All _FOURPORT does is specifically config ports 4-7 in the table to
> have specific address/irqs for the FourPort board. What you do with
> setserial is then change that config info to match your board.
>
> You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it
> looks like you don't. 
>   
But I DO HAVE TO to make any configuration changes without getting 
(invalid parameter) errors from setserial.

>> Then I can only access ttyS0 through ttyS3 sith setserial.  
>> Only after I add
>> CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do 
>> anything with the 
>> additional ports.  I would otherwise get the evil setserial: invalid 
>> parameter error.
>>     
>
> Very odd. You get this error when doing "setserial /dev/ttySxx", no
> configuration? If so, that would imply that the table wasn't made big
> enough, and the unconfigured ports haven't been registered with the
> serial core.
>
>   
I can read the ports as unknown/unconfigured.  I just cannot modify them 
until the fourport driver has been loaded.



> If you can't get your board working, we have similar boards that do.
>
>   
your website address didn't work when I tried it...


See below for a (script) dump of that demonstrates the behavior I 
describe.  Additional ports are not configurable until a driver such as 
fourport is loaded.  This is in 2.6.20.1 and 2.6.17 (those versions I 
have tested).

# for i in 0 1 2 3 4 5 6 7; do setserial /dev/ttyS$i; done
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS5, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS6, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS7, UART: unknown, Port: 0x0000, IRQ: 0

# cat /etc/rc.local
#! /bin/sh

SS=/bin/setserial
IRQ="irq 12"
AC="autoconfig ^fourport"

`$SS /dev/ttyS4 port 0x120 $IRQ $AC`
`$SS /dev/ttyS5 port 0x128 $IRQ $AC`
`$SS /dev/ttyS6 port 0x130 $IRQ $AC`
`$SS /dev/ttyS7 port 0x138 $IRQ $AC`

# sh /etc/rc.local
Cannot set serial info: Invalid argument
Cannot set serial info: Invalid argument
Cannot set serial info: Invalid argument
Cannot set serial info: Invalid argument

# modprobe 8250_fourport
# for i in 0 1 2 3 4 5 6 7; do setserial /dev/ttyS$i; done
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x02b8, IRQ: 5, Flags: Fourport
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: 16850, Port: 0x0120, IRQ: 12
/dev/ttyS5, UART: 16850, Port: 0x0128, IRQ: 12
/dev/ttyS6, UART: 16850, Port: 0x0130, IRQ: 12
/dev/ttyS7, UART: 16850, Port: 0x0138, IRQ: 12

# grep 8250 .config
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=8
CONFIG_SERIAL_8250_RUNTIME_UARTS=8
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_FOURPORT=m
# CONFIG_SERIAL_8250_ACCENT is not set
# CONFIG_SERIAL_8250_BOCA is not set
# CONFIG_SERIAL_8250_EXAR_ST16C554 is not set
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
# CONFIG_SERIAL_8250_RSA is not set
# Non-8250 serial port support



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: questions about 8250 uart support for adhoc boards
  2007-02-26 17:02       ` Rob Prowel
@ 2007-02-26 18:05         ` Russell King
  2007-02-27 14:24           ` Rob Prowel
  0 siblings, 1 reply; 11+ messages in thread
From: Russell King @ 2007-02-26 18:05 UTC (permalink / raw)
  To: Rob Prowel; +Cc: Stuart MacDonald, linux-kernel

On Mon, Feb 26, 2007 at 12:02:57PM -0500, Rob Prowel wrote:
> See below for a (script) dump of that demonstrates the behavior I 
> describe.  Additional ports are not configurable until a driver such as 
> fourport is loaded.  This is in 2.6.20.1 and 2.6.17 (those versions I 
> have tested).

Check what /proc/tty/driver/serial contains, rather than relying on
setserial.  setserial distributed by distros hasn't kept up with the
changes in the serial layer.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: questions about 8250 uart support for adhoc boards
  2007-02-26 18:05         ` Russell King
@ 2007-02-27 14:24           ` Rob Prowel
  2007-02-27 17:38             ` Russell King
  0 siblings, 1 reply; 11+ messages in thread
From: Rob Prowel @ 2007-02-27 14:24 UTC (permalink / raw)
  To: Rob Prowel, Stuart MacDonald, linux-kernel

Russell King wrote:
> On Mon, Feb 26, 2007 at 12:02:57PM -0500, Rob Prowel wrote:
>   
>> See below for a (script) dump of that demonstrates the behavior I 
>> describe.  Additional ports are not configurable until a driver such as 
>> fourport is loaded.  This is in 2.6.20.1 and 2.6.17 (those versions I 
>> have tested).
>>     
>
> Check what /proc/tty/driver/serial contains, rather than relying on
> setserial.  setserial distributed by distros hasn't kept up with the
> changes in the serial layer.
>
>   
The setserial being used is the latest one from sourceforge.  Its 
relevant output matches the /proc entries.  The problem still remains 
though.  Entries for ttyS4 and up seem to be read-only until I add a 
supplemental driver such as fourport.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: questions about 8250 uart support for adhoc boards
  2007-02-27 14:24           ` Rob Prowel
@ 2007-02-27 17:38             ` Russell King
  2007-02-27 19:06               ` Stuart MacDonald
  0 siblings, 1 reply; 11+ messages in thread
From: Russell King @ 2007-02-27 17:38 UTC (permalink / raw)
  To: Rob Prowel; +Cc: Stuart MacDonald, linux-kernel

On Tue, Feb 27, 2007 at 09:24:32AM -0500, Rob Prowel wrote:
> Russell King wrote:
> >On Mon, Feb 26, 2007 at 12:02:57PM -0500, Rob Prowel wrote:
> >  
> >>See below for a (script) dump of that demonstrates the behavior I 
> >>describe.  Additional ports are not configurable until a driver such as 
> >>fourport is loaded.  This is in 2.6.20.1 and 2.6.17 (those versions I 
> >>have tested).
> >>    
> >
> >Check what /proc/tty/driver/serial contains, rather than relying on
> >setserial.  setserial distributed by distros hasn't kept up with the
> >changes in the serial layer.
> >
> >  
> The setserial being used is the latest one from sourceforge.  Its 
> relevant output matches the /proc entries.  The problem still remains 
> though.  Entries for ttyS4 and up seem to be read-only until I add a 
> supplemental driver such as fourport.

After experimenting here, it turns out the reason is you're trying to
configure a port with a zero base baud.  Unfortunately, it starts off
as zero.

However, when you try to change a port without specifying the base baud,
it is possible for the port to become "usable" and unless we enforce
the "must not have zero base baud" rule we have the possibility to oops
the kernel via a divide by zero.

So, the answer is to specify the base baud when using setserial to
configure new ports.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: questions about 8250 uart support for adhoc boards
  2007-02-27 17:38             ` Russell King
@ 2007-02-27 19:06               ` Stuart MacDonald
  2007-02-27 20:40                 ` Rob Prowel
  0 siblings, 1 reply; 11+ messages in thread
From: Stuart MacDonald @ 2007-02-27 19:06 UTC (permalink / raw)
  To: 'Russell King', 'Rob Prowel'; +Cc: linux-kernel

From: Russell King [mailto:rmk@arm.linux.org.uk]
> After experimenting here, it turns out the reason is you're trying to
> configure a port with a zero base baud.  Unfortunately, it starts off
> as zero.

That explains why adding the fourport module fixed Rob's issue, as the
fourport code sets a uartclk value for its ports.

> However, when you try to change a port without specifying the 
> base baud,
> it is possible for the port to become "usable" and unless we enforce
> the "must not have zero base baud" rule we have the 
> possibility to oops
> the kernel via a divide by zero.
> 
> So, the answer is to specify the base baud when using setserial to
> configure new ports.

Would it be more intuitive to give ports the default uartclk of
1843200 at init time? That would avoid this issue, but would make the
baud rates come out wrong on hardware with a non-standard clock, if a
base baud wasn't specified.


From: Rob Prowel [mailto:prowel@kuchera.com] 
> your website address didn't work when I tried it...

The website may have been down on the weekend for maintenance. Please
try again.

..Stu

-- 
We make multiport serial products.
http://www.connecttech.com/
(800) 426-8979


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: questions about 8250 uart support for adhoc boards
  2007-02-27 19:06               ` Stuart MacDonald
@ 2007-02-27 20:40                 ` Rob Prowel
  2007-03-08 15:16                   ` Russell King
  0 siblings, 1 reply; 11+ messages in thread
From: Rob Prowel @ 2007-02-27 20:40 UTC (permalink / raw)
  To: Stuart MacDonald; +Cc: 'Russell King', linux-kernel

Stuart MacDonald wrote:
> Would it be more intuitive to give ports the default uartclk of
> 1843200 at init time? That would avoid this issue, but would make the
> baud rates come out wrong on hardware with a non-standard clock, if a
> base baud wasn't specified.
>
>   

I prefer the option to specify the base baud rate in setserial from a 
startup script.  Having the additional ports at BAUD 0 (unusable) until 
some explicit action is taken strikes me as a safer option, provided 
this gets properly documented in the kernel Documentation directory and 
in Linux HOWTO docs.

-Rob Prowel





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: questions about 8250 uart support for adhoc boards
  2007-02-27 20:40                 ` Rob Prowel
@ 2007-03-08 15:16                   ` Russell King
  0 siblings, 0 replies; 11+ messages in thread
From: Russell King @ 2007-03-08 15:16 UTC (permalink / raw)
  To: Rob Prowel; +Cc: Stuart MacDonald, linux-kernel

On Tue, Feb 27, 2007 at 03:40:57PM -0500, Rob Prowel wrote:
> Stuart MacDonald wrote:
> >Would it be more intuitive to give ports the default uartclk of
> >1843200 at init time? That would avoid this issue, but would make the
> >baud rates come out wrong on hardware with a non-standard clock, if a
> >base baud wasn't specified.
> >
> >  
> 
> I prefer the option to specify the base baud rate in setserial from a 
> startup script.  Having the additional ports at BAUD 0 (unusable) until 
> some explicit action is taken strikes me as a safer option, provided 
> this gets properly documented in the kernel Documentation directory and 
> in Linux HOWTO docs.

Is someone going to do that?  Who volunteers?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-03-08 15:16 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-23 17:05 questions about 8250 uart support for adhoc boards Rob Prowel
2007-02-23 20:21 ` Russell King
2007-02-23 20:48   ` Rob Prowel
2007-02-24 20:34     ` Stuart MacDonald
2007-02-26 17:02       ` Rob Prowel
2007-02-26 18:05         ` Russell King
2007-02-27 14:24           ` Rob Prowel
2007-02-27 17:38             ` Russell King
2007-02-27 19:06               ` Stuart MacDonald
2007-02-27 20:40                 ` Rob Prowel
2007-03-08 15:16                   ` Russell King

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.