forked from torvalds/linux
/
sx.txt
294 lines (219 loc) · 11.3 KB
/
sx.txt
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
sx.txt -- specialix SX/SI 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 support@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.
(History)
There used to be an SI driver by Simon Allan. This is a complete
rewrite from scratch. Just a few lines-of-code have been snatched.
(Sources)
Specialix document number 6210028: SX Host Card and Download Code
Software Functional Specification.
(Copying)
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.
(Addendum)
I'd appreciate it that if you have fixes, that you send them
to me first.
Introduction
============
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?
Theory of operation
===================
An important thing to know is that the driver itself doesn't have the
firmware for the card. This means that you need the separate package
"sx_firmware". For now you can get the source at
ftp://ftp.bitwizard.nl/specialix/sx_firmware_<version>.tgz
The firmware load needs a "misc" device, so you'll need to enable the
"Support for user misc device modules" in your kernel configuration.
The misc device needs to be called "/dev/specialix_sxctl". It needs
misc major 10, and minor number 167 (assigned by HPA). The section
on creating device files below also creates this device.
After loading the sx.o module into your kernel, the driver will report
the number of cards detected, but because it doesn't have any
firmware, it will not be able to determine the number of ports. Only
when you then run "sx_firmware" will the firmware be downloaded and
the rest of the driver initialized. At that time the sx_firmware
program will report the number of ports installed.
In contrast with many other multi port serial cards, some of the data
structures are only allocated when the card knows the number of ports
that are connected. This means we won't waste memory for 120 port
descriptor structures when you only have 8 ports. If you experience
problems due to this, please report them: I haven't seen any.
Interrupts
==========
A multi port serial card, would generate a horrendous amount of
interrupts if it would interrupt the CPU for every received
character. Even more than 10 years ago, the trick not to use
interrupts but to poll the serial cards was invented.
The SX card allow us to do this two ways. First the card limits its
own interrupt rate to a rate that won't overwhelm the CPU. Secondly,
we could forget about the cards interrupt completely and use the
internal timer for this purpose.
Polling the card can take up to a few percent of your CPU. Using the
interrupts would be better if you have most of the ports idle. Using
timer-based polling is better if your card almost always has work to
do. You save the separate interrupt in that case.
In any case, it doesn't really matter all that much.
The most common problem with interrupts is that for ISA cards in a PCI
system the BIOS has to be told to configure that interrupt as "legacy
ISA". Otherwise the card can pull on the interrupt line all it wants
but the CPU won't see this.
If you can't get the interrupt to work, remember that polling mode is
more efficient (provided you actually use the card intensively).
Allowed Configurations
======================
Some configurations are disallowed. Even though at a glance they might
seem to work, they are known to lockup the bus between the host card
and the device concentrators. You should respect the drivers decision
not to support certain configurations. It's there for a reason.
Warning: Seriously technical stuff ahead. Executive summary: Don't use
SX cards except configured at a 64k boundary. Skip the next paragraph.
The SX cards can theoretically be placed at a 32k boundary. So for
instance you can put an SX card at 0xc8000-0xd7fff. This is not a
"recommended configuration". ISA cards have to tell the bus controller
how they like their timing. Due to timing issues they have to do this
based on which 64k window the address falls into. This means that the
32k window below and above the SX card have to use exactly the same
timing as the SX card. That reportedly works for other SX cards. But
you're still left with two useless 32k windows that should not be used
by anybody else.
Configuring the driver
======================
PCI cards are always detected. The driver auto-probes for ISA cards at
some sensible addresses. Please report if the auto-probe causes trouble
in your system, or when a card isn't detected.
I'm afraid I haven't implemented "kernel command line parameters" yet.
This means that if the default doesn't work for you, you shouldn't use
the compiled-into-the-kernel version of the driver. Use a module
instead. If you convince me that you need this, I'll make it for
you. Deal?
I'm afraid that the module parameters are a bit clumsy. If you have a
better idea, please tell me.
You can specify several parameters:
sx_poll: number of jiffies between timer-based polls.
Set this to "0" to disable timer based polls.
Initialization of cards without a working interrupt
will fail.
Set this to "1" if you want a polling driver.
(on Intel: 100 polls per second). If you don't use
fast baud rates, you might consider a value like "5".
(If you don't know how to do the math, use 1).
sx_slowpoll: Number of jiffies between timer-based polls.
Set this to "100" to poll once a second.
This should get the card out of a stall if the driver
ever misses an interrupt. I've never seen this happen,
and if it does, that's a bug. Tell me.
sx_maxints: Number of interrupts to request from the card.
The card normally limits interrupts to about 100 per
second to offload the host CPU. You can increase this
number to reduce latency on the card a little.
Note that if you give a very high number you can overload
your CPU as well as the CPU on the host card. This setting
is inaccurate and not recommended for SI cards (But it
works).
sx_irqmask: The mask of allowable IRQs to use. I suggest you set
this to 0 (disable IRQs all together) and use polling if
the assignment of IRQs becomes problematic. This is defined
as the sum of (1 << irq) 's that you want to allow. So
sx_irqmask of 8 (1 << 3) specifies that only irq 3 may
be used by the SX driver. If you want to specify to the
driver: "Either irq 11 or 12 is ok for you to use", then
specify (1 << 11) | (1 << 12) = 0x1800 .
sx_debug: You can enable different sorts of debug traces with this.
At "-1" all debugging traces are active. You'll get several
times more debugging output than you'll get characters
transmitted.
Baud rates
==========
Theoretically new SXDCs should be capable of more than 460k
baud. However the line drivers usually give up before that. Also the
CPU on the card may not be able to handle 8 channels going at full
blast at that speed. Moreover, the buffers are not large enough to
allow operation with 100 interrupts per second. You'll have to realize
that the card has a 256 byte buffer, so you'll have to increase the
number of interrupts per second if you have more than 256*100 bytes
per second to transmit. If you do any performance testing in this
area, I'd be glad to hear from you...
(Psst Linux users..... I think the Linux driver is more efficient than
the driver for other OSes. If you can and want to benchmark them
against each other, be my guest, and report your findings...... :-)
Ports and devices
=================
Port 0 is the top connector on the module closest to the host
card. Oh, the ports on the SXDCs and TAs are labelled from 1 to 8
instead of from 0 to 7, as they are numbered by linux. I'm stubborn in
this: I know for sure that I wouldn't be able to calculate which port
is which anymore if I would change that....
Devices:
You should make the device files as follows:
#!/bin/sh
# (I recommend that you cut-and-paste this into a file and run that)
cd /dev
t=0
mknod specialix_sxctl c 10 167
while [ $t -lt 64 ]
do
echo -n "$t "
mknod ttyX$t c 32 $t
mknod cux$t c 33 $t
t=`expr $t + 1`
done
echo ""
rm /etc/psdevtab
ps > /dev/null
This creates 64 devices. If you have more, increase the constant on
the line with "while". The devices start at 0, as is customary on
Linux. Specialix seems to like starting the numbering at 1.
If your system doesn't come with these devices pre-installed, bug your
linux-vendor about this. They should have these devices
"pre-installed" before the new millennium. The "ps" stuff at the end
is to "tell" ps that the new devices exist.
Officially the maximum number of cards per computer is 4. This driver
however supports as many cards in one machine as you want. You'll run
out of interrupts after a few, but you can switch to polled operation
then. At about 256 ports (More than 8 cards), we run out of minor
device numbers. Sorry. I suggest you buy a second computer.... (Or
switch to RIO).
------------------------------------------------------------------------
Fixed bugs and restrictions:
- Hangup processing.
-- Done.
- the write path in generic_serial (lockup / oops).
-- Done (Ugly: not the way I want it. Copied from serial.c).
- write buffer isn't flushed at close.
-- Done. I still seem to lose a few chars at close.
Sorry. I think that this is a firmware issue. (-> Specialix)
- drain hardware before changing termios
- Change debug on the fly.
- ISA free irq -1. (no firmware loaded).
- adding c8000 as a probe address. Added warning.
- Add a RAMtest for the RAM on the card.c
- Crash when opening a port "way" of the number of allowed ports.
(for example opening port 60 when there are only 24 ports attached)
- Sometimes the use-count strays a bit. After a few hours of
testing the use count is sometimes "3". If you are not like
me and can remember what you did to get it that way, I'd
appreciate an Email. Possibly fixed. Tell me if anyone still
sees this.
- TAs don't work right if you don't connect all the modem control
signals. SXDCs do. T225 firmware problem -> Specialix.
(Mostly fixed now, I think. Tell me if you encounter this!)
Bugs & restrictions:
- Arbitrary baud rates. Requires firmware update. (-> Specialix)
- Low latency (mostly firmware, -> Specialix)