I'm running an ATCA7101 board. This board has two 16550 ports that get
detected as ttyS4 and ttyS5.
With a much earlier kernel (2.6.14) the serial port base speed is
correctly detected as 230400, which gives the desired 115200 when I
specify that on the kernel commandline.
With 2.6.16 and 2.6.27 (not sure about the intervening kernels) the
serial port base speed is detected as 921600, which means that I need to
specify 460800 on the commandline to get a real speed of 115200 (as
verified by an external terminal server).
Any ideas what could be causing this misdetection? I'm having lab
issues right now so I can't track it down, but I'll have a go at it
eventually.
Thanks,
Chris
On Tue, 04 Nov 2008 12:24:45 -0600
"Chris Friesen" <[email protected]> wrote:
>
> I'm running an ATCA7101 board. This board has two 16550 ports that get
> detected as ttyS4 and ttyS5.
>
> With a much earlier kernel (2.6.14) the serial port base speed is
> correctly detected as 230400, which gives the desired 115200 when I
> specify that on the kernel commandline.
>
> With 2.6.16 and 2.6.27 (not sure about the intervening kernels) the
> serial port base speed is detected as 921600, which means that I need to
> specify 460800 on the commandline to get a real speed of 115200 (as
> verified by an external terminal server).
>
> Any ideas what could be causing this misdetection? I'm having lab
> issues right now so I can't track it down, but I'll have a go at it
> eventually.
If this is a PCI card it may be matching against a PCI entry for a
similar card with different crystals and need the right svid/sdid adding.
Alan Cox wrote:
> On Tue, 04 Nov 2008 12:24:45 -0600
> "Chris Friesen" <[email protected]> wrote:
>
>> I'm running an ATCA7101 board. This board has two 16550 ports that get
>> detected as ttyS4 and ttyS5.
>>
>> With a much earlier kernel (2.6.14) the serial port base speed is
>> correctly detected as 230400, which gives the desired 115200 when I
>> specify that on the kernel commandline.
>>
>> With 2.6.16 and 2.6.27 (not sure about the intervening kernels) the
>> serial port base speed is detected as 921600, which means that I need to
>> specify 460800 on the commandline to get a real speed of 115200 (as
>> verified by an external terminal server).
>>
>> Any ideas what could be causing this misdetection? I'm having lab
>> issues right now so I can't track it down, but I'll have a go at it
>> eventually.
>
> If this is a PCI card it may be matching against a PCI entry for a
> similar card with different crystals and need the right svid/sdid adding.
This is an ATCA board, so it's not a separate PCI card, but it does look
like it's hanging off the PCI bus. The vendor/device matches to an Exar
Corp. XR17C152, which is given a base_baud of 921600 in
drivers/serial/8250_pci.c.
According to the chip specs, 921600 is correct with the default crystal
and control register values. However, other crystals can be used and
there's also a control register bit to enable a prescalar which cuts the
baud rate by a factor of four. I suspect that one of these has been
done on our boards.
The confusing thing is that the 2.6.14 code seems to also use a value of
921600, but somehow it works. I wonder if our kernel vendor has tweaked
something in the code to adjust this value later on.
Chris
> like it's hanging off the PCI bus. The vendor/device matches to an Exar
> Corp. XR17C152, which is given a base_baud of 921600 in
> drivers/serial/8250_pci.c.
>
> According to the chip specs, 921600 is correct with the default crystal
> and control register values. However, other crystals can be used and
> there's also a control register bit to enable a prescalar which cuts the
> baud rate by a factor of four. I suspect that one of these has been
> done on our boards.
Probably. Did your vendor have the sense to set subvendor/subdevice
identifiers that can be used to identify that specific unit ?
Alan Cox wrote:
>> like it's hanging off the PCI bus. The vendor/device matches to an Exar
>> Corp. XR17C152, which is given a base_baud of 921600 in
>> drivers/serial/8250_pci.c.
>>
>> According to the chip specs, 921600 is correct with the default crystal
>> and control register values. However, other crystals can be used and
>> there's also a control register bit to enable a prescalar which cuts the
>> baud rate by a factor of four. I suspect that one of these has been
>> done on our boards.
>
> Probably. Did your vendor have the sense to set subvendor/subdevice
> identifiers that can be used to identify that specific unit ?
No idea, but I'll look into it. Thanks for the help.
Chris