diff options
Diffstat (limited to 'Documentation/parport.txt')
-rw-r--r-- | Documentation/parport.txt | 268 |
1 files changed, 268 insertions, 0 deletions
diff --git a/Documentation/parport.txt b/Documentation/parport.txt new file mode 100644 index 000000000000..93a7ceef398d --- /dev/null +++ b/Documentation/parport.txt | |||
@@ -0,0 +1,268 @@ | |||
1 | The `parport' code provides parallel-port support under Linux. This | ||
2 | includes the ability to share one port between multiple device | ||
3 | drivers. | ||
4 | |||
5 | You can pass parameters to the parport code to override its automatic | ||
6 | detection of your hardware. This is particularly useful if you want | ||
7 | to use IRQs, since in general these can't be autoprobed successfully. | ||
8 | By default IRQs are not used even if they _can_ be probed. This is | ||
9 | because there are a lot of people using the same IRQ for their | ||
10 | parallel port and a sound card or network card. | ||
11 | |||
12 | The parport code is split into two parts: generic (which deals with | ||
13 | port-sharing) and architecture-dependent (which deals with actually | ||
14 | using the port). | ||
15 | |||
16 | |||
17 | Parport as modules | ||
18 | ================== | ||
19 | |||
20 | If you load the parport code as a module, say | ||
21 | |||
22 | # insmod parport | ||
23 | |||
24 | to load the generic parport code. You then must load the | ||
25 | architecture-dependent code with (for example): | ||
26 | |||
27 | # insmod parport_pc io=0x3bc,0x378,0x278 irq=none,7,auto | ||
28 | |||
29 | to tell the parport code that you want three PC-style ports, one at | ||
30 | 0x3bc with no IRQ, one at 0x378 using IRQ 7, and one at 0x278 with an | ||
31 | auto-detected IRQ. Currently, PC-style (parport_pc), Sun `bpp', | ||
32 | Amiga, Atari, and MFC3 hardware is supported. | ||
33 | |||
34 | PCI parallel I/O card support comes from parport_pc. Base I/O | ||
35 | addresses should not be specified for supported PCI cards since they | ||
36 | are automatically detected. | ||
37 | |||
38 | |||
39 | KMod | ||
40 | ---- | ||
41 | |||
42 | If you use kmod, you will find it useful to edit /etc/modprobe.conf. | ||
43 | Here is an example of the lines that need to be added: | ||
44 | |||
45 | alias parport_lowlevel parport_pc | ||
46 | options parport_pc io=0x378,0x278 irq=7,auto | ||
47 | |||
48 | KMod will then automatically load parport_pc (with the options | ||
49 | "io=0x378,0x278 irq=7,auto") whenever a parallel port device driver | ||
50 | (such as lp) is loaded. | ||
51 | |||
52 | Note that these are example lines only! You shouldn't in general need | ||
53 | to specify any options to parport_pc in order to be able to use a | ||
54 | parallel port. | ||
55 | |||
56 | |||
57 | Parport probe [optional] | ||
58 | ------------- | ||
59 | |||
60 | In 2.2 kernels there was a module called parport_probe, which was used | ||
61 | for collecting IEEE 1284 device ID information. This has now been | ||
62 | enhanced and now lives with the IEEE 1284 support. When a parallel | ||
63 | port is detected, the devices that are connected to it are analysed, | ||
64 | and information is logged like this: | ||
65 | |||
66 | parport0: Printer, BJC-210 (Canon) | ||
67 | |||
68 | The probe information is available from files in /proc/sys/dev/parport/. | ||
69 | |||
70 | |||
71 | Parport linked into the kernel statically | ||
72 | ========================================= | ||
73 | |||
74 | If you compile the parport code into the kernel, then you can use | ||
75 | kernel boot parameters to get the same effect. Add something like the | ||
76 | following to your LILO command line: | ||
77 | |||
78 | parport=0x3bc parport=0x378,7 parport=0x278,auto,nofifo | ||
79 | |||
80 | You can have many `parport=...' statements, one for each port you want | ||
81 | to add. Adding `parport=0' to the kernel command-line will disable | ||
82 | parport support entirely. Adding `parport=auto' to the kernel | ||
83 | command-line will make parport use any IRQ lines or DMA channels that | ||
84 | it auto-detects. | ||
85 | |||
86 | |||
87 | Files in /proc | ||
88 | ============== | ||
89 | |||
90 | If you have configured the /proc filesystem into your kernel, you will | ||
91 | see a new directory entry: /proc/sys/dev/parport. In there will be a | ||
92 | directory entry for each parallel port for which parport is | ||
93 | configured. In each of those directories are a collection of files | ||
94 | describing that parallel port. | ||
95 | |||
96 | The /proc/sys/dev/parport directory tree looks like: | ||
97 | |||
98 | parport | ||
99 | |-- default | ||
100 | | |-- spintime | ||
101 | | `-- timeslice | ||
102 | |-- parport0 | ||
103 | | |-- autoprobe | ||
104 | | |-- autoprobe0 | ||
105 | | |-- autoprobe1 | ||
106 | | |-- autoprobe2 | ||
107 | | |-- autoprobe3 | ||
108 | | |-- devices | ||
109 | | | |-- active | ||
110 | | | `-- lp | ||
111 | | | `-- timeslice | ||
112 | | |-- base-addr | ||
113 | | |-- irq | ||
114 | | |-- dma | ||
115 | | |-- modes | ||
116 | | `-- spintime | ||
117 | `-- parport1 | ||
118 | |-- autoprobe | ||
119 | |-- autoprobe0 | ||
120 | |-- autoprobe1 | ||
121 | |-- autoprobe2 | ||
122 | |-- autoprobe3 | ||
123 | |-- devices | ||
124 | | |-- active | ||
125 | | `-- ppa | ||
126 | | `-- timeslice | ||
127 | |-- base-addr | ||
128 | |-- irq | ||
129 | |-- dma | ||
130 | |-- modes | ||
131 | `-- spintime | ||
132 | |||
133 | |||
134 | File: Contents: | ||
135 | |||
136 | devices/active A list of the device drivers using that port. A "+" | ||
137 | will appear by the name of the device currently using | ||
138 | the port (it might not appear against any). The | ||
139 | string "none" means that there are no device drivers | ||
140 | using that port. | ||
141 | |||
142 | base-addr Parallel port's base address, or addresses if the port | ||
143 | has more than one in which case they are separated | ||
144 | with tabs. These values might not have any sensible | ||
145 | meaning for some ports. | ||
146 | |||
147 | irq Parallel port's IRQ, or -1 if none is being used. | ||
148 | |||
149 | dma Parallel port's DMA channel, or -1 if none is being | ||
150 | used. | ||
151 | |||
152 | modes Parallel port's hardware modes, comma-separated, | ||
153 | meaning: | ||
154 | |||
155 | PCSPP PC-style SPP registers are available. | ||
156 | TRISTATE Port is bidirectional. | ||
157 | COMPAT Hardware acceleration for printers is | ||
158 | available and will be used. | ||
159 | EPP Hardware acceleration for EPP protocol | ||
160 | is available and will be used. | ||
161 | ECP Hardware acceleration for ECP protocol | ||
162 | is available and will be used. | ||
163 | DMA DMA is available and will be used. | ||
164 | |||
165 | Note that the current implementation will only take | ||
166 | advantage of COMPAT and ECP modes if it has an IRQ | ||
167 | line to use. | ||
168 | |||
169 | autoprobe Any IEEE-1284 device ID information that has been | ||
170 | acquired from the (non-IEEE 1284.3) device. | ||
171 | |||
172 | autoprobe[0-3] IEEE 1284 device ID information retrieved from | ||
173 | daisy-chain devices that conform to IEEE 1284.3. | ||
174 | |||
175 | spintime The number of microseconds to busy-loop while waiting | ||
176 | for the peripheral to respond. You might find that | ||
177 | adjusting this improves performance, depending on your | ||
178 | peripherals. This is a port-wide setting, i.e. it | ||
179 | applies to all devices on a particular port. | ||
180 | |||
181 | timeslice The number of milliseconds that a device driver is | ||
182 | allowed to keep a port claimed for. This is advisory, | ||
183 | and driver can ignore it if it must. | ||
184 | |||
185 | default/* The defaults for spintime and timeslice. When a new | ||
186 | port is registered, it picks up the default spintime. | ||
187 | When a new device is registered, it picks up the | ||
188 | default timeslice. | ||
189 | |||
190 | Device drivers | ||
191 | ============== | ||
192 | |||
193 | Once the parport code is initialised, you can attach device drivers to | ||
194 | specific ports. Normally this happens automatically; if the lp driver | ||
195 | is loaded it will create one lp device for each port found. You can | ||
196 | override this, though, by using parameters either when you load the lp | ||
197 | driver: | ||
198 | |||
199 | # insmod lp parport=0,2 | ||
200 | |||
201 | or on the LILO command line: | ||
202 | |||
203 | lp=parport0 lp=parport2 | ||
204 | |||
205 | Both the above examples would inform lp that you want /dev/lp0 to be | ||
206 | the first parallel port, and /dev/lp1 to be the _third_ parallel port, | ||
207 | with no lp device associated with the second port (parport1). Note | ||
208 | that this is different to the way older kernels worked; there used to | ||
209 | be a static association between the I/O port address and the device | ||
210 | name, so /dev/lp0 was always the port at 0x3bc. This is no longer the | ||
211 | case - if you only have one port, it will default to being /dev/lp0, | ||
212 | regardless of base address. | ||
213 | |||
214 | Also: | ||
215 | |||
216 | * If you selected the IEEE 1284 support at compile time, you can say | ||
217 | `lp=auto' on the kernel command line, and lp will create devices | ||
218 | only for those ports that seem to have printers attached. | ||
219 | |||
220 | * If you give PLIP the `timid' parameter, either with `plip=timid' on | ||
221 | the command line, or with `insmod plip timid=1' when using modules, | ||
222 | it will avoid any ports that seem to be in use by other devices. | ||
223 | |||
224 | * IRQ autoprobing works only for a few port types at the moment. | ||
225 | |||
226 | Reporting printer problems with parport | ||
227 | ======================================= | ||
228 | |||
229 | If you are having problems printing, please go through these steps to | ||
230 | try to narrow down where the problem area is. | ||
231 | |||
232 | When reporting problems with parport, really you need to give all of | ||
233 | the messages that parport_pc spits out when it initialises. There are | ||
234 | several code paths: | ||
235 | |||
236 | o polling | ||
237 | o interrupt-driven, protocol in software | ||
238 | o interrupt-driven, protocol in hardware using PIO | ||
239 | o interrupt-driven, protocol in hardware using DMA | ||
240 | |||
241 | The kernel messages that parport_pc logs give an indication of which | ||
242 | code path is being used. (They could be a lot better actually..) | ||
243 | |||
244 | For normal printer protocol, having IEEE 1284 modes enabled or not | ||
245 | should not make a difference. | ||
246 | |||
247 | To turn off the 'protocol in hardware' code paths, disable | ||
248 | CONFIG_PARPORT_PC_FIFO. Note that when they are enabled they are not | ||
249 | necessarily _used_; it depends on whether the hardware is available, | ||
250 | enabled by the BIOS, and detected by the driver. | ||
251 | |||
252 | So, to start with, disable CONFIG_PARPORT_PC_FIFO, and load parport_pc | ||
253 | with 'irq=none'. See if printing works then. It really should, | ||
254 | because this is the simplest code path. | ||
255 | |||
256 | If that works fine, try with 'io=0x378 irq=7' (adjust for your | ||
257 | hardware), to make it use interrupt-driven in-software protocol. | ||
258 | |||
259 | If _that_ works fine, then one of the hardware modes isn't working | ||
260 | right. Enable CONFIG_PARPORT_PC_FIFO (no, it isn't a module option, | ||
261 | and yes, it should be), set the port to ECP mode in the BIOS and note | ||
262 | the DMA channel, and try with: | ||
263 | |||
264 | io=0x378 irq=7 dma=none (for PIO) | ||
265 | io=0x378 irq=7 dma=3 (for DMA) | ||
266 | -- | ||
267 | philb@gnu.org | ||
268 | tim@cyberelk.net | ||