[linux-2.6-block.git] / Documentation / specialix.txt


      specialix.txt  -- specialix IO8+ multiport serial driver readme.


      Copyright (C) 1997  Roger Wolff (R.E.Wolff@BitWizard.nl)

      Specialix pays for the development and support of this driver.
      Please DO contact io8-linux@specialix.co.uk if you require
      support.

      This driver was developed in the BitWizard linux device
      driver service. If you require a linux device driver for your
      product, please contact devices@BitWizard.nl for a quote.

      This code is firmly based on the riscom/8 serial driver,
      written by Dmitry Gorodchanin. The specialix IO8+ card
      programming information was obtained from the CL-CD1865 Data
      Book, and Specialix document number 6200059: IO8+ Hardware
      Functional Specification, augmented by document number 6200088:
      Merak Hardware Functional Specification. (IO8+/PCI is also 
      called Merak)


      This program is free software; you can redistribute it and/or
      modify it under the terms of the GNU General Public License as
      published by the Free Software Foundation; either version 2 of
      the License, or (at your option) any later version.

      This program is distributed in the hope that it will be
      useful, but WITHOUT ANY WARRANTY; without even the implied
      warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
      PURPOSE.  See the GNU General Public License for more details.

      You should have received a copy of the GNU General Public
      License along with this program; if not, write to the Free
      Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
      USA.


Intro
=====

 
This file contains some random information, that I like to have online
instead of in a manual that can get lost. Ever misplace your Linux
kernel sources?  And the manual of one of the boards in your computer?


Addresses and interrupts
========================

Address dip switch settings:
The dip switch sets bits 2-9 of the IO address. 

       9 8 7 6 5 4 3 2 
     +-----------------+
   0 | X   X X X X X X |
     |                 |    =   IoBase = 0x100 
   1 |   X             |
     +-----------------+          ------ RS232 connectors ---->
         
         |    |    |
       edge connector
         |    |    |
         V    V    V

Base address 0x100 caused a conflict in one of my computers once.  I
haven't the foggiest why. My Specialix card is now at 0x180.  My
other computer runs just fine with the Specialix card at 0x100....
The card occupies 4 addresses, but actually only two are really used.

The PCI version doesn't have any dip switches. The BIOS assigns
an IO address. 

The driver now still autoprobes at 0x100, 0x180, 0x250 and 0x260.  If
that causes trouble for you, please report that. I'll remove
autoprobing then.

The driver will tell the card what IRQ to use, so you don't have to
change any jumpers to change the IRQ. Just use a command line
argument (irq=xx) to the insmod program to set the interrupt.

The BIOS assigns the IRQ on the PCI version. You have no say in what
IRQ to use in that case. 

If your specialix cards are not at the default locations, you can use
the kernel command line argument "specialix=io0,irq0,io1,irq1...".
Here "io0" is the io address for the first card, and "irq0" is the
irq line that the first card should use. And so on. 

Examples. 

You use the driver as a module and have three cards at 0x100, 0x250
and 0x180. And some way or another you want them detected in that
order. Moreover irq 12 is taken (e.g. by your PS/2 mouse).

  insmod specialix.o iobase=0x100,0x250,0x180 irq=9,11,15

The same three cards, but now in the kernel would require you to
add 

   specialix=0x100,9,0x250,11,0x180,15

to the command line. This would become 

   append="specialix=0x100,9,0x250,11,0x180,15" 

in your /etc/lilo.conf file if you use lilo. 

The Specialix driver is slightly odd: It allows you to have the second
or third card detected without having a first card. This has
advantages and disadvantages. A slot that isn't filled by an ISA card,
might be filled if a PCI card is detected. Thus if you have an ISA
card at 0x250 and a PCI card, you would get:

sx0: specialix IO8+ Board at 0x100 not found.
sx1: specialix IO8+ Board at 0x180 not found.
sx2: specialix IO8+ board detected at 0x250, IRQ 12, CD1865 Rev. B.
sx3: specialix IO8+ Board at 0x260 not found.
sx0: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B.

This would happen if you don't give any probe hints to the driver. 
If you would specify:

   specialix=0x250,11

you'd get the following messages:

sx0: specialix IO8+ board detected at 0x250, IRQ 11, CD1865 Rev. B.
sx1: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B.

ISA probing is aborted after the IO address you gave is exhausted, and
the PCI card is now detected as the second card. The ISA card is now
also forced to IRQ11....


Baud rates
==========

The rev 1.2 and below boards use a CL-CD1864. These chips can only 
do 64kbit. The rev 1.3 and newer boards use a CL-CD1865. These chips
are officially capable of 115k2.

The Specialix card uses a 25MHz crystal (in times two mode, which in
fact is a divided by two mode). This is not enough to reach the rated
115k2 on all ports at the same time. With this clock rate you can only
do 37% of this rate. This means that at 115k2 on all ports you are
going to lose characters (The chip cannot handle that many incoming
bits at this clock rate.) (Yes, you read that correctly: there is a
limit to the number of -=bits=- per second that the chip can handle.)

If you near the "limit" you will first start to see a graceful
degradation in that the chip cannot keep the transmitter busy at all
times. However with a central clock this slow, you can also get it to
miss incoming characters. The driver will print a warning message when
you are outside the official specs. The messages usually show up in
the file /var/log/messages .

The specialix card cannot reliably do 115k2. If you use it, you have
to do "extensive testing" (*) to verify if it actually works.

When "mgetty" communicates with my modem at 115k2 it reports:
got: +++[0d]ATQ0V1H0[0d][0d][8a]O[cb][0d][8a]
                            ^^^^ ^^^^    ^^^^ 

The three characters that have the "^^^" under them have suffered a
bit error in the highest bit. In conclusion: I've tested it, and found
that it simply DOESN'T work for me. I also suspect that this is also
caused by the baud rate being just a little bit out of tune. 

I upgraded the crystal to 66Mhz on one of my Specialix cards. Works
great! Contact me for details. (Voids warranty, requires a steady hand
and more such restrictions....)


(*) Cirrus logic CD1864 databook, page 40.


Cables for the Specialix IO8+
=============================

The pinout of the connectors on the IO8+ is:

     pin    short    direction    long name
            name
    Pin 1   DCD      input        Data Carrier Detect
    Pin 2   RXD      input        Receive
    Pin 3   DTR/RTS  output       Data Terminal Ready/Ready To Send
    Pin 4   GND      -            Ground
    Pin 5   TXD      output       Transmit
    Pin 6   CTS      input        Clear To Send
        
    
             -- 6  5  4  3  2  1 --
             |                    |
             |                    |
             |                    |
             |                    |
             +-----          -----+
                  |__________|
                      clip
    
    Front view of an RJ12 connector. Cable moves "into" the paper.
    (the plug is ready to plug into your mouth this way...)

    
    NULL cable. I don't know who is going to use these except for
    testing purposes, but I tested the cards with this cable. (It 
    took quite a while to figure out, so I'm not going to delete
    it. So there! :-)
    
    
    This end goes               This end needs
    straight into the           some twists in
    RJ12 plug.                  the wiring.
       IO8+ RJ12                   IO8+ RJ12
        1  DCD       white          -
        -             -             1 DCD
        2  RXD       black          5 TXD
        3  DTR/RTS   red            6 CTS
        4  GND       green          4 GND
        5  TXD       yellow         2 RXD
        6  CTS       blue           3 DTR/RTS
    

    Same NULL cable, but now sorted on the second column.
 
        1  DCD       white          -
        -             -             1 DCD
        5  TXD       yellow         2 RXD
        6  CTS       blue           3 DTR/RTS
        4  GND       green          4 GND
        2  RXD       black          5 TXD
        3  DTR/RTS   red            6 CTS
    
    
    This is a modem cable usable for hardware handshaking:
        RJ12                        DB25           DB9
        1   DCD      white          8 DCD          1 DCD
        2   RXD      black          3 RXD          2 RXD
        3   DTR/RTS  red            4 RTS          7 RTS
        4   GND      green          7 GND          5 GND
        5   TXD      yellow         2 TXD          3 TXD
        6   CTS      blue           5 CTS          8 CTS
                            +----   6 DSR          6 DSR
                            +----  20 DTR          4 DTR

    This is a modem cable usable for software handshaking:
    It allows you to reset the modem using the DTR ioctls.
    I (REW) have never tested this, "but xxxxxxxxxxxxx
    says that it works." If you test this, please
    tell me and I'll fill in your name on the xxx's.

        RJ12                        DB25           DB9
        1   DCD      white          8 DCD          1 DCD
        2   RXD      black          3 RXD          2 RXD
        3   DTR/RTS  red           20 DTR          4 DTR
        4   GND      green          7 GND          5 GND
        5   TXD      yellow         2 TXD          3 TXD
        6   CTS      blue           5 CTS          8 CTS
                            +----   6 DSR          6 DSR
                            +----   4 RTS          7 RTS

   I bought a 6 wire flat cable. It was colored as indicated.
   Check that yours is the same before you trust me on this.
   
 
Hardware handshaking issues.
============================

The driver can be compiled in two different ways. The default
("Specialix DTR/RTS pin is RTS" is off) the pin behaves as DTR when
hardware handshaking is off. It behaves as the RTS hardware
handshaking signal when hardware handshaking is selected.

When you use this, you have to use the appropriate cable. The
cable will either be compatible with hardware handshaking or with
software handshaking. So switching on the fly is not really an
option.

I actually prefer to use the "Specialix DTR/RTS pin is RTS" option.
This makes the DTR/RTS pin always an RTS pin, and ioctls to
change DTR are always ignored. I have a cable that is configured
for this. 


Ports and devices
=================

Port 0 is the one furthest from the card-edge connector.

Devices:

You should make the devices as follows:

bash
cd /dev
for i in  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 \
         16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
do
  echo -n "$i "
  mknod /dev/ttyW$i c 75 $i
  mknod /dev/cuw$i c 76 $i
done
echo ""

If your system doesn't come with these devices preinstalled, bug your
linux-vendor about this. They have had ample time to get this
implemented by now.

You cannot have more than 4 boards in one computer. The card only
supports 4 different interrupts. If you really want this, contact me
about this and I'll give you a few tips (requires soldering iron)....

If you have enough PCI slots, you can probably use more than 4 PCI
versions of the card though.... 

The PCI version of the card cannot adhere to the mechanical part of
the PCI spec because the 8 serial connectors are simply too large. If
it doesn't fit in your computer, bring back the card.


------------------------------------------------------------------------


  Fixed bugs and restrictions:
       - During initialization, interrupts are blindly turned on.
            Having a shadow variable would cause an extra memory
            access on every IO instruction. 
       - The interrupt (on the card) should be disabled when we
         don't allocate the Linux end of the interrupt. This allows 
         a different driver/card to use it while all ports are not in
         use..... (a la standard serial port)
       == An extra _off variant of the sx_in and sx_out macros are
          now available. They don't set the interrupt enable bit.
          These are used during initialization. Normal operation uses
          the old variant which enables the interrupt line.
       - RTS/DTR issue needs to be implemented according to 
         specialix' spec.
            I kind of like the "determinism" of the current 
            implementation. Compile time flag?
       == Ok. Compile time flag! Default is how Specialix likes it.
       == Now a config time flag! Gets saved in your config file. Neat!
       - Can you set the IO address from the lilo command line?
            If you need this, bug me about it, I'll make it. 
       == Hah! No bugging needed. Fixed! :-)
       - Cirrus logic hasn't gotten back to me yet why the CD1865 can
            and the CD1864 can't do 115k2. I suspect that this is
            because the CD1864 is not rated for 33MHz operation.
            Therefore the CD1864 versions of the card can't do 115k2 on 
            all ports just like the CD1865 versions. The driver does
            not block 115k2 on CD1864 cards. 
        == I called the Cirrus Logic representative here in Holland.
           The CD1864 databook is identical to the CD1865 databook, 
           except for an extra warning at the end. Similar Bit errors
           have been observed in testing at 115k2 on both an 1865 and
           a 1864 chip. I see no reason why I would prohibit 115k2 on
           1864 chips and not do it on 1865 chips. Actually there is
           reason to prohibit it on BOTH chips. I print a warning.
           If you use 115k2, you're on your own. 
       - A spiky CD may send spurious HUPs. Also in CLOCAL???
         -- A fix for this turned out to be counter productive. 
            Different fix? Current behaviour is acceptable?
         -- Maybe the current implementation is correct. If anybody
            gets bitten by this, please report, and it will get fixed.

         -- Testing revealed that when in CLOCAL, the problem doesn't
            occur. As warned for in the CD1865 manual, the chip may
            send modem intr's on a spike. We could filter those out,
            but that would be a cludge anyway (You'd still risk getting
            a spurious HUP when two spikes occur.).....
 

  Bugs & restrictions:
       - This is a difficult card to autoprobe.
            You have to WRITE to the address register to even 
            read-probe a CD186x register. Disable autodetection?
         -- Specialix: any suggestions?
       - Arbitrary baud rates are not implemented yet. 
            If you need this, bug me about it.
Commit	Line	Data
1da177e4 LT	1
	2	specialix.txt -- specialix IO8+ multiport serial driver readme.
	3
	4
	5
	6	Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl)
	7
	8	Specialix pays for the development and support of this driver.
	9	Please DO contact io8-linux@specialix.co.uk if you require
	10	support.
	11
	12	This driver was developed in the BitWizard linux device
	13	driver service. If you require a linux device driver for your
	14	product, please contact devices@BitWizard.nl for a quote.
	15
	16	This code is firmly based on the riscom/8 serial driver,
	17	written by Dmitry Gorodchanin. The specialix IO8+ card
	18	programming information was obtained from the CL-CD1865 Data
	19	Book, and Specialix document number 6200059: IO8+ Hardware
	20	Functional Specification, augmented by document number 6200088:
	21	Merak Hardware Functional Specification. (IO8+/PCI is also
	22	called Merak)
	23
	24
	25	This program is free software; you can redistribute it and/or
	26	modify it under the terms of the GNU General Public License as
	27	published by the Free Software Foundation; either version 2 of
	28	the License, or (at your option) any later version.
	29
	30	This program is distributed in the hope that it will be
	31	useful, but WITHOUT ANY WARRANTY; without even the implied
	32	warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
	33	PURPOSE. See the GNU General Public License for more details.
	34
	35	You should have received a copy of the GNU General Public
	36	License along with this program; if not, write to the Free
	37	Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
	38	USA.
	39
	40
	41	Intro
	42	=====
	43
	44
	45	This file contains some random information, that I like to have online
	46	instead of in a manual that can get lost. Ever misplace your Linux
	47	kernel sources? And the manual of one of the boards in your computer?
	48
	49
	50	Addresses and interrupts
	51	========================
	52
	53	Address dip switch settings:
	54	The dip switch sets bits 2-9 of the IO address.
	55
	56	9 8 7 6 5 4 3 2
	57	+-----------------+
	58	0 \| X X X X X X X \|
	59	\| \| = IoBase = 0x100
	60	1 \| X \|
	61	+-----------------+ ------ RS232 connectors ---->
	62
	63	\| \| \|
	64	edge connector
65	\| \| \|
66	V V V
67
68	Base address 0x100 caused a conflict in one of my computers once. I
69	haven't the foggiest why. My Specialix card is now at 0x180. My
70	other computer runs just fine with the Specialix card at 0x100....
71	The card occupies 4 addresses, but actually only two are really used.
72
73	The PCI version doesn't have any dip switches. The BIOS assigns
74	an IO address.
75
76	The driver now still autoprobes at 0x100, 0x180, 0x250 and 0x260. If
77	that causes trouble for you, please report that. I'll remove
78	autoprobing then.
79
80	The driver will tell the card what IRQ to use, so you don't have to
81	change any jumpers to change the IRQ. Just use a command line
82	argument (irq=xx) to the insmod program to set the interrupt.
83
84	The BIOS assigns the IRQ on the PCI version. You have no say in what
85	IRQ to use in that case.
86
87	If your specialix cards are not at the default locations, you can use
88	the kernel command line argument "specialix=io0,irq0,io1,irq1...".
89	Here "io0" is the io address for the first card, and "irq0" is the
90	irq line that the first card should use. And so on.
91
92	Examples.
93
94	You use the driver as a module and have three cards at 0x100, 0x250
95	and 0x180. And some way or another you want them detected in that
96	order. Moreover irq 12 is taken (e.g. by your PS/2 mouse).
97
98	insmod specialix.o iobase=0x100,0x250,0x180 irq=9,11,15
99
100	The same three cards, but now in the kernel would require you to
101	add
102
103	specialix=0x100,9,0x250,11,0x180,15
104
105	to the command line. This would become
106
107	append="specialix=0x100,9,0x250,11,0x180,15"
108
109	in your /etc/lilo.conf file if you use lilo.
110
111	The Specialix driver is slightly odd: It allows you to have the second
112	or third card detected without having a first card. This has
113	advantages and disadvantages. A slot that isn't filled by an ISA card,
114	might be filled if a PCI card is detected. Thus if you have an ISA
115	card at 0x250 and a PCI card, you would get:
116
117	sx0: specialix IO8+ Board at 0x100 not found.
118	sx1: specialix IO8+ Board at 0x180 not found.
119	sx2: specialix IO8+ board detected at 0x250, IRQ 12, CD1865 Rev. B.
120	sx3: specialix IO8+ Board at 0x260 not found.
121	sx0: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B.
122
123	This would happen if you don't give any probe hints to the driver.
124	If you would specify:
125
126	specialix=0x250,11
127
128	you'd get the following messages:
129
130	sx0: specialix IO8+ board detected at 0x250, IRQ 11, CD1865 Rev. B.
131	sx1: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B.
132
133	ISA probing is aborted after the IO address you gave is exhausted, and
134	the PCI card is now detected as the second card. The ISA card is now
135	also forced to IRQ11....
136
137
138	Baud rates
139	==========
140
141	The rev 1.2 and below boards use a CL-CD1864. These chips can only
142	do 64kbit. The rev 1.3 and newer boards use a CL-CD1865. These chips
143	are officially capable of 115k2.
144
145	The Specialix card uses a 25MHz crystal (in times two mode, which in
146	fact is a divided by two mode). This is not enough to reach the rated
147	115k2 on all ports at the same time. With this clock rate you can only
148	do 37% of this rate. This means that at 115k2 on all ports you are
149	going to lose characters (The chip cannot handle that many incoming
150	bits at this clock rate.) (Yes, you read that correctly: there is a
151	limit to the number of -=bits=- per second that the chip can handle.)
152
153	If you near the "limit" you will first start to see a graceful
154	degradation in that the chip cannot keep the transmitter busy at all
155	times. However with a central clock this slow, you can also get it to
156	miss incoming characters. The driver will print a warning message when
157	you are outside the official specs. The messages usually show up in
158	the file /var/log/messages .
159
160	The specialix card cannot reliably do 115k2. If you use it, you have
161	to do "extensive testing" (*) to verify if it actually works.
162
163	When "mgetty" communicates with my modem at 115k2 it reports:
164	got: +++[0d]ATQ0V1H0[0d][0d][8a]O[cb][0d][8a]
165	^^^^ ^^^^ ^^^^
166
167	The three characters that have the "^^^" under them have suffered a
168	bit error in the highest bit. In conclusion: I've tested it, and found
169	that it simply DOESN'T work for me. I also suspect that this is also
170	caused by the baud rate being just a little bit out of tune.
171
172	I upgraded the crystal to 66Mhz on one of my Specialix cards. Works
173	great! Contact me for details. (Voids warranty, requires a steady hand
174	and more such restrictions....)
175
176
177	(*) Cirrus logic CD1864 databook, page 40.
178
179
180	Cables for the Specialix IO8+
181	=============================
182
183	The pinout of the connectors on the IO8+ is:
184
185	pin short direction long name
186	name
187	Pin 1 DCD input Data Carrier Detect
188	Pin 2 RXD input Receive
189	Pin 3 DTR/RTS output Data Terminal Ready/Ready To Send
190	Pin 4 GND - Ground
191	Pin 5 TXD output Transmit
192	Pin 6 CTS input Clear To Send
193
194
195	-- 6 5 4 3 2 1 --
196	\| \|
197	\| \|
198	\| \|
199	\| \|
200	+----- -----+
201	\|__________\|
202	clip
203
204	Front view of an RJ12 connector. Cable moves "into" the paper.
205	(the plug is ready to plug into your mouth this way...)
206
207
208	NULL cable. I don't know who is going to use these except for
209	testing purposes, but I tested the cards with this cable. (It
210	took quite a while to figure out, so I'm not going to delete
211	it. So there! :-)
212
213
214	This end goes This end needs
215	straight into the some twists in
216	RJ12 plug. the wiring.
217	IO8+ RJ12 IO8+ RJ12
218	1 DCD white -
219	- - 1 DCD
220	2 RXD black 5 TXD
221	3 DTR/RTS red 6 CTS
222	4 GND green 4 GND
223	5 TXD yellow 2 RXD
224	6 CTS blue 3 DTR/RTS
225
226
227	Same NULL cable, but now sorted on the second column.
228
229	1 DCD white -
230	- - 1 DCD
231	5 TXD yellow 2 RXD
232	6 CTS blue 3 DTR/RTS
233	4 GND green 4 GND
234	2 RXD black 5 TXD
235	3 DTR/RTS red 6 CTS
236
237
238
239	This is a modem cable usable for hardware handshaking:
240	RJ12 DB25 DB9
241	1 DCD white 8 DCD 1 DCD
242	2 RXD black 3 RXD 2 RXD
243	3 DTR/RTS red 4 RTS 7 RTS
244	4 GND green 7 GND 5 GND
245	5 TXD yellow 2 TXD 3 TXD
246	6 CTS blue 5 CTS 8 CTS
247	+---- 6 DSR 6 DSR
248	+---- 20 DTR 4 DTR
249
250	This is a modem cable usable for software handshaking:
251	It allows you to reset the modem using the DTR ioctls.
252	I (REW) have never tested this, "but xxxxxxxxxxxxx
253	says that it works." If you test this, please
254	tell me and I'll fill in your name on the xxx's.
255
256	RJ12 DB25 DB9
257	1 DCD white 8 DCD 1 DCD
258	2 RXD black 3 RXD 2 RXD
259	3 DTR/RTS red 20 DTR 4 DTR
260	4 GND green 7 GND 5 GND
261	5 TXD yellow 2 TXD 3 TXD
262	6 CTS blue 5 CTS 8 CTS
263	+---- 6 DSR 6 DSR
264	+---- 4 RTS 7 RTS
265
266	I bought a 6 wire flat cable. It was colored as indicated.
267	Check that yours is the same before you trust me on this.
268
269
270	Hardware handshaking issues.
271	============================
272
273	The driver can be compiled in two different ways. The default
274	("Specialix DTR/RTS pin is RTS" is off) the pin behaves as DTR when
275	hardware handshaking is off. It behaves as the RTS hardware
276	handshaking signal when hardware handshaking is selected.
277
278	When you use this, you have to use the appropriate cable. The
279	cable will either be compatible with hardware handshaking or with
280	software handshaking. So switching on the fly is not really an
281	option.
282
283	I actually prefer to use the "Specialix DTR/RTS pin is RTS" option.
284	This makes the DTR/RTS pin always an RTS pin, and ioctls to
285	change DTR are always ignored. I have a cable that is configured
286	for this.
287
288
289	Ports and devices
290	=================
291
292	Port 0 is the one furthest from the card-edge connector.
293
294	Devices:
295
296	You should make the devices as follows:
297
298	bash
299	cd /dev
300	for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \
301	16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
302	do
303	echo -n "$i "
304	mknod /dev/ttyW$i c 75 $i
305	mknod /dev/cuw$i c 76 $i
306	done
307	echo ""
308
309	If your system doesn't come with these devices preinstalled, bug your
310	linux-vendor about this. They have had ample time to get this
311	implemented by now.
312
313	You cannot have more than 4 boards in one computer. The card only
314	supports 4 different interrupts. If you really want this, contact me
315	about this and I'll give you a few tips (requires soldering iron)....
316
317	If you have enough PCI slots, you can probably use more than 4 PCI
318	versions of the card though....
319
320	The PCI version of the card cannot adhere to the mechanical part of
321	the PCI spec because the 8 serial connectors are simply too large. If
322	it doesn't fit in your computer, bring back the card.
323
324
325	------------------------------------------------------------------------
326
327
328	Fixed bugs and restrictions:
329	- During initialization, interrupts are blindly turned on.
330	Having a shadow variable would cause an extra memory
331	access on every IO instruction.
332	- The interrupt (on the card) should be disabled when we
333	don't allocate the Linux end of the interrupt. This allows
334	a different driver/card to use it while all ports are not in
335	use..... (a la standard serial port)
336	== An extra _off variant of the sx_in and sx_out macros are
337	now available. They don't set the interrupt enable bit.
338	These are used during initialization. Normal operation uses
339	the old variant which enables the interrupt line.
340	- RTS/DTR issue needs to be implemented according to
341	specialix' spec.
342	I kind of like the "determinism" of the current
343	implementation. Compile time flag?
344	== Ok. Compile time flag! Default is how Specialix likes it.
345	== Now a config time flag! Gets saved in your config file. Neat!
346	- Can you set the IO address from the lilo command line?
347	If you need this, bug me about it, I'll make it.
348	== Hah! No bugging needed. Fixed! :-)
349	- Cirrus logic hasn't gotten back to me yet why the CD1865 can
350	and the CD1864 can't do 115k2. I suspect that this is
351	because the CD1864 is not rated for 33MHz operation.
352	Therefore the CD1864 versions of the card can't do 115k2 on
353	all ports just like the CD1865 versions. The driver does
354	not block 115k2 on CD1864 cards.
355	== I called the Cirrus Logic representative here in Holland.
356	The CD1864 databook is identical to the CD1865 databook,
357	except for an extra warning at the end. Similar Bit errors
358	have been observed in testing at 115k2 on both an 1865 and
359	a 1864 chip. I see no reason why I would prohibit 115k2 on
360	1864 chips and not do it on 1865 chips. Actually there is
361	reason to prohibit it on BOTH chips. I print a warning.
362	If you use 115k2, you're on your own.
363	- A spiky CD may send spurious HUPs. Also in CLOCAL???
364	-- A fix for this turned out to be counter productive.
365	Different fix? Current behaviour is acceptable?
366	-- Maybe the current implementation is correct. If anybody
367	gets bitten by this, please report, and it will get fixed.
368
369	-- Testing revealed that when in CLOCAL, the problem doesn't
370	occur. As warned for in the CD1865 manual, the chip may
371	send modem intr's on a spike. We could filter those out,
372	but that would be a cludge anyway (You'd still risk getting
373	a spurious HUP when two spikes occur.).....
374
375
376
377	Bugs & restrictions:
378	- This is a difficult card to autoprobe.
379	You have to WRITE to the address register to even
380	read-probe a CD186x register. Disable autodetection?
381	-- Specialix: any suggestions?
382	- Arbitrary baud rates are not implemented yet.
383	If you need this, bug me about it.
384
385