From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
Can not set baud rates of 230400 and 460800 with stty. The UART is an
Oxsemi 952 which is capable of these speeds (it worked under Fedora
root@zeebee# stty -F/dev/ttyS4 460800
stty: /dev/ttyS4: unable to perform all requested operations
Someone here has looked at the kernel code and reckons it doesn't
touch the prescaler or TCR registers (whereas the 2.4.x kernel
apparently did in char/serial.c).
0000:02:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI952
(Dual 16950 UART) (prog-if 06 )
Subsystem: Oxford Semiconductor Ltd: Unknown device 0001
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at dcf8
Region 1: I/O ports at dce8 [size=8]
Region 2: I/O ports at dcc0 [size=32]
Region 3: Memory at ff6ff000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at ff6fe000 (32-bit, non-prefetchable) [size=4K]
Capabilities:  Power Management version 1
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. stty -F/dev/ttyS4 460800
Actual Results: stty: /dev/ttyS4: unable to perform all requested
Expected Results: No output and the UART speed changed.
This is using an Oxford Semiconductor PCI 952 dual high speed UART.
The way the 2.4 kernel use TCR was broken. It assumed that the TCR was
set to zero in the beginning -- which isn't always the case; sometimes
it's initialised to a different value, to make it _appear_ that
baud_base is 115200.
You can use TCR in that way _only_ if you're going to read the TCR
before resetting the hardware at probe time, and adjust baud_base to
compensate if it _wasn't_ zero.
is this still a problem with the 2.6.9 updates ?
The error doesn't occur when running the stty command. I've done a loop back
test on 952 board and it works. I don't have any external kit to verify that the
speeds are actually 460800 but it is definitely not 115200.
I reported this on behalf of a colleague. He's still using FC2 test1 with a
kernel hacked to do what he wants so he's not interested in upgrading and
testing! I would consider this fixed.
Most PC motherboards are capable of at least 460800 baud. You ought to be able
to test with one of those. Use the 'Shsmod' program (google) to switch into
high-speed mode, then either set the 'magic multiplier' bit with setserial, or
change the baud_base according to which type of superio chip it is.
We really ought to make the kernel do that for itself.
from my experiences with shsmod, its hit or miss whether it works.
When I tested it on a VIA chipset for example the system clock started jumped
back and forth 6 hours. Quite amusing, but not too useful.
Probably better fixed upstream and inherited that way for Fedora.
Agreed. I got the 'magic multiplier' merged upstream but doing the bit that
shsmod does really means we want a proper superio detection and support
library/core instead of dropping bits of it into all the random drivers that
want it (parport, irda, now serial, etc.)