1 .\" Copyright (c) 1998, 1999 Nicolas Souchu
2 .\" All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
13 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
14 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
15 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
16 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
17 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
18 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
19 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
20 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
21 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
22 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32 .Nd Parallel Port Bus system
44 system provides a uniform, modular and architecture-independent
45 system for the implementation of drivers to control various parallel devices,
46 and to utilize different parallel port chipsets.
48 In order to write new drivers or port existing drivers, the ppbus system
49 provides the following facilities:
50 .Bl -bullet -offset indent
52 architecture-independent macros or functions to access parallel ports
54 mechanism to allow various devices to share the same parallel port
56 a user interface named
58 that allows parallel port access from outside the kernel without conflicting
59 with kernel-in drivers.
61 .Ss Developing new drivers
62 The ppbus system has been designed to support the development of standard
63 and non-standard software:
65 .Bl -column "Driver" -compact
66 .It Em Driver Ta Em Description
67 .It Sy ppi Ta "Parallel port interface for general I/O"
68 .It Sy pps Ta "Pulse per second Timing Interface"
69 .It Sy lpbb Ta "Philips official parallel port I2C bit-banging interface"
71 .Ss Porting existing drivers
72 Another approach to the ppbus system is to port existing drivers.
73 Various drivers have already been ported:
75 .Bl -column "Driver" -compact
76 .It Em Driver Ta Em Description
77 .It Sy lpt Ta "lpt printer driver"
78 .It Sy plip Ta "lp parallel network interface driver"
81 ppbus should let you port any other software even from other operating systems
82 that provide similar services.
83 .Sh PARALLEL PORT CHIPSETS
84 Parallel port chipset support is provided by
87 The ppbus system provides functions and macros to allocate a new
88 parallel port bus, then initialize it and upper peripheral device drivers.
90 ppc makes chipset detection and initialization and then calls ppbus attach
91 functions to initialize the ppbus system.
92 .Sh PARALLEL PORT MODEL
93 The logical parallel port model chosen for the ppbus system is the PC's
95 Consequently, for the i386 implementation of ppbus,
96 most of the services provided by ppc are macros for inb()
98 But, for another architecture, accesses to one of our logical
99 registers (data, status, control...) may require more than one I/O access.
101 The parallel port may operate in the following modes:
102 .Bl -bullet -offset indent
104 compatible mode, also called Centronics mode
106 bidirectional 8/4-bits mode, also called NIBBLE mode
108 byte mode, also called PS/2 mode
110 Extended Capability Port mode, ECP
112 Enhanced Parallel Port mode, EPP
114 mixed ECP+EPP or ECP+PS/2 modes
117 This mode defines the protocol used by most PCs to transfer data to a printer.
118 In this mode, data is placed on the port's data lines, the printer status is
119 checked for no errors and that it is not busy, and then a data Strobe is
120 generated by the software to clock the data to the printer.
122 Many I/O controllers have implemented a mode that uses a FIFO buffer to
123 transfer data with the Compatibility mode protocol.
124 This mode is referred to as
125 "Fast Centronics" or "Parallel Port FIFO mode".
126 .Ss Bidirectional mode
127 The NIBBLE mode is the most common way to get reverse channel data from a
128 printer or peripheral.
129 Combined with the standard host to printer mode, it
130 provides a complete bidirectional channel.
132 In this mode, outputs are 8-bits long.
133 Inputs are accomplished by reading
134 4 of the 8 bits of the status register.
136 In this mode, the data register is used either for outputs and inputs.
138 any transfer is 8-bits long.
139 .Ss Extended Capability Port mode
140 The ECP protocol was proposed as an advanced mode for communication with
141 printer and scanner type peripherals.
142 Like the EPP protocol, ECP mode provides
143 for a high performance bidirectional communication path between the host
144 adapter and the peripheral.
146 ECP protocol features include:
147 .Bl -item -offset indent
149 Run_Length_Encoding (RLE) data compression for host adapters
151 FIFOs for both the forward and reverse channels
153 DMA as well as programmed I/O for the host register interface.
155 .Ss Enhanced Parallel Port mode
156 The EPP protocol was originally developed as a means to provide a high
157 performance parallel port link that would still be compatible with the
158 standard parallel port.
160 The EPP mode has two types of cycle: address and data.
162 difference at hardware level is the strobe of the byte placed on the data
164 Data are strobed with nAutofeed, addresses are strobed with
167 A particularity of the ISA implementation of the EPP protocol is that an
168 EPP cycle fits in an ISA cycle.
169 In this fashion, parallel port peripherals can
170 operate at close to the same performance levels as an equivalent ISA plug-in
173 At software level, you may implement the protocol you wish, using data and
174 address cycles as you want.
175 This is for the IEEE1284 compatible part.
177 peripheral vendors may implement protocol handshake with the following
178 status lines: PError, nFault and Select.
179 Try to know how these lines toggle
180 with your peripheral, allowing the peripheral to request more data, stop the
183 At any time, the peripheral may interrupt the host with the nAck signal without
184 disturbing the current transfer.
186 Some manufacturers, like SMC, have implemented chipsets that support mixed
188 With such chipsets, mode switching is available at any time by
189 accessing the extended control register.
190 .Sh IEEE1284-1994 Standard
192 This standard is also named "IEEE Standard Signaling Method for a
193 Bidirectional Parallel Peripheral Interface for Personal Computers".
195 defines a signaling method for asynchronous, fully interlocked, bidirectional
196 parallel communications between hosts and printers or other peripherals.
198 also specifies a format for a peripheral identification string and a method of
199 returning this string to the host outside of the bidirectional data stream.
201 This standard is architecture independent and only specifies dialog handshake
203 One should refer to architecture specific documentation in
204 order to manipulate machine dependent registers, mapped memory or other
205 methods to control these signals.
207 The IEEE1284 protocol is fully oriented with all supported parallel port
209 The computer acts as master and the peripheral as slave.
211 Any transfer is defined as a finite state automaton.
212 It allows software to
213 properly manage the fully interlocked scheme of the signaling method.
214 The compatible mode is supported "as is" without any negotiation because it
216 Any other mode must be firstly negotiated by the host to check
217 it is supported by the peripheral, then to enter one of the forward idle
220 At any time, the slave may want to send data to the host.
222 possible from forward idle states (nibble, byte, ecp...).
224 host must have previously negotiated to permit the peripheral to
226 Interrupt lines may be dedicated to the requesting signals
227 to prevent time consuming polling methods.
229 But peripheral requests are only a hint to the master host.
231 accepts the transfer, it must firstly negotiate the reverse mode and then
233 At any time during reverse transfer, the host may
234 terminate the transfer or the slave may drive wires to signal that no more
237 IEEE1284 Standard support has been implemented at the top of the ppbus system
238 as a set of procedures that perform high level functions like negotiation,
239 termination, transfer in any mode without bothering you with low level
240 characteristics of the standard.
242 IEEE1284 interacts with the ppbus system as little as possible.
244 you still have to request the ppbus when you want to access it, the negotiate
245 function does not do it for you.
246 And of course, release it later.
248 .Ss adapter, ppbus and device layers
251 layer, the lowest of the ppbus system.
253 chipset abstraction throw a set of low level functions that maps the logical
254 model to the underlying hardware.
256 Secondly, there is the
258 layer that provides functions to:
259 .Bl -enum -offset indent
261 share the parallel port bus among the daisy-chain like connected devices
263 manage devices linked to ppbus
265 propose an arch-independent interface to access the hardware layer.
270 layer gathers the parallel peripheral device drivers.
271 .Ss Parallel modes management
272 We have to differentiate operating modes at various ppbus system layers.
273 Actually, ppbus and adapter operating modes on one hands and for each
274 one, current and available modes are separated.
276 With this level of abstraction a particular chipset may commute from any
277 native mode to any other mode emulated with extended modes without
278 disturbing upper layers.
279 For example, most chipsets support NIBBLE mode as
280 native and emulated with ECP and/or EPP.
282 This architecture should support IEEE1284-1994 modes.
285 The boot process starts with the probe stage of the
287 driver during ISA bus (PC architecture) initialization.
289 the ppc driver, a new ppbus structure is allocated, then probe and attachment
290 for this new bus node are called.
292 ppbus attachment tries to detect any PnP parallel peripheral (according to
293 .%T "Plug and Play Parallel Port Devices"
294 draft from (c)1993-4 Microsoft Corporation)
295 then probes and attaches known device drivers.
297 During probe, device drivers are supposed to request the ppbus and try to
298 set their operating mode.
299 This mode will be saved in the context structure and
300 returned each time the driver requests the ppbus.
301 .Ss Bus allocation and interrupts
302 ppbus allocation is mandatory not to corrupt I/O of other devices.
304 usage of ppbus allocation is to reserve the port and receive incoming
307 High level interrupt handlers are connected to the ppbus system thanks to the
311 .Fn BUS_TEARDOWN_INTR
313 But, in order to attach a handler, drivers must
315 Consequently, a ppbus request is mandatory in order to call the above
316 functions (see existing drivers for more info).
317 Note that the interrupt handler
318 is automatically released when the ppbus is released.
321 is a general purpose mechanism to allow fast low-level
322 manipulation of the parallel port.
323 Microsequences may be used to do either
324 standard (in IEEE1284 modes) or non-standard transfers.
326 microsequences is to avoid the overhead of the ppbus layer and do most of
327 the job at adapter level.
329 A microsequence is an array of opcodes and parameters.
331 operation (opcodes are described in
333 Standard I/O operations are implemented at ppbus level whereas basic I/O
334 operations and microseq language are coded at adapter level for efficiency.
343 manual page first appeared in
347 manual page was written by