xref: /freebsd/share/man/man4/ppbus.4 (revision 2ad872c5794e4c26fdf6ed219ad3f09ca0d5304a)
1.\" Copyright (c) 1998, 1999 Nicolas Souchu
2.\" All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
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.
12.\"
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
23.\" SUCH DAMAGE.
24.\"
25.\"
26.Dd March 1, 1998
27.Dt PPBUS 4
28.Os FreeBSD
29.Sh NAME
30.Nm ppbus
31.Nd
32Parallel port bus system
33.Sh SYNOPSIS
34.Cd "controller ppbus0"
35.Pp
36.Cd "controller vpo0 at ppbus?"
37.Pp
38.Cd "device nlpt0 at ppbus?"
39.Cd "device plip0 at ppbus?"
40.Cd "device ppi0 at ppbus?"
41.Cd "device pps0 at ppbus?"
42.Cd "device lpbb0 at ppbus?"
43.Sh DESCRIPTION
44The
45.Em ppbus
46system provides a uniform, modular and architecture-independent
47system for the implementation of drivers to control various parallel devices,
48and to utilize different parallel port chipsets.
49.Sh DEVICE DRIVERS
50In order to write new drivers or port existing drivers, the ppbus system
51provides the following facilities:
52.Bl -bullet -item -offset indent
53.It
54architecture-independent macros or functions to access parallel ports
55.It
56mechanism to allow various devices to share the same parallel port
57.It
58a user interface named
59.Xr ppi 4
60that allows parallel port access from outside the kernel without confliting
61with kernel-in drivers.
62.El
63.Ss Developing new drivers
64.Pp
65The ppbus system has been designed to support the development of standard
66and non-standard software:
67.Pp
68.Bl -column "Driver" -compact
69.It Em Driver Ta Em Description
70.It Sy vpo Ta "VPI0 parallel to Adaptec AIC-7110 SCSI controller driver."
71It uses standard and non-standard parallel port accesses
72.It Sy ppi Ta "Parallel port interface for general I/O"
73.It Sy pps Ta "Pulse per second Timing Interface"
74.It Sy lpbb Ta "Philips official parallel port I2C bit-banging interface"
75.El
76.Ss Porting existing drivers
77.Pp
78Another approach to the ppbus system is to port existing drivers.
79Various drivers have already been ported:
80.Pp
81.Bl -column "Driver" -compact
82.It Em Driver Ta Em Description
83.It Sy nlpt Ta "lpt printer driver"
84.It Sy plip Ta "lp parallel network interface driver"
85.El
86.Pp
87ppbus should let you port any other software even from other operating systems
88that provide similar services.
89.Sh PARALLEL PORT CHIPSETS
90Parallel port chipset support is provided by
91.Xr ppc 4 .
92.Pp
93The ppbus system provides functions and macros to allocate a new
94parallel port bus, then initialize it and upper peripheral device drivers.
95.Pp
96ppc makes chipset detection and initialisation and then calls ppbus attach
97functions to initialize the ppbus system.
98.Sh PARALLEL PORT MODEL
99The logical parallel port model chosen for the ppbus system is the PC's
100parallel port model. Consequently, for the i386 implementation of ppbus,
101most of the services provided by ppc are macros for inb()
102and outb() calls. But, for an other architecture, accesses to one of our logical
103registers (data, status, control...) may require more than one I/O access.
104.Ss Description
105The parallel port may operate in the following modes:
106.Bl -bullet -item -offset indent
107.It
108compatible mode, also called Centronics mode
109.It
110bidirectional 8/4-bits mode, also called NIBBLE mode
111.It
112byte mode, also called PS/2 mode
113.It
114Extended Capability Port mode, ECP
115.It
116Enhanced Parallel Port mode, EPP
117.It
118mixed ECP+EPP or ECP+PS/2 modes
119.El
120.Ss Compatible mode
121This mode defines the protocol used by most PCs to transfer data to a printer.
122In this mode, data is placed on the port's data lines, the printer status is
123checked for no errors and that it is not busy, and then a data Strobe is
124generated by the sofware to clock the data to the printer.
125.Pp
126Many I/O controllers have implemented a mode that uses a FIFO buffer to
127transfer data with the Compatibility mode protocol. This mode is referred to as
128"Fast Centronics" or "Parallel Port FIFO mode".
129.Ss Bidirectional mode
130The NIBBLE mode is the most common way to get reverse channel data from a
131printer or peripheral. Combined with the standard host to printer mode, it
132provides a complete bidirectional channel.
133.Pp
134In this mode, outputs are 8-bits long. Inputs are accomplished by reading
1354 of the 8 bits of the status register.
136.Ss Byte mode
137In this mode, the data register is used either for outputs and inputs. Then,
138any transfer is 8-bits long.
139.Ss Extended Capability Port mode
140The ECP protocol was proposed as an advanced mode for communication with
141printer and scanner type peripherals. Like the EPP protocol, ECP mode provides
142for a high performance bidirectional communication path between the host
143adapter and the peripheral.
144.Pp
145ECP protocol features include:
146.Bl -item -offset indent
147.It
148Run_Length_Encoding (RLE) data compression for host adapters
149.It
150FIFOs for both the forward and reverse channels
151.It
152DMA as well as programmed I/O for the host register interface.
153.El
154.Ss Enhanced Parallel Port mode
155The EPP protocol was originally developed as a means to provide a high
156performance parallel port link that would still be compatible with the
157standard parallel port.
158.Ss Mixed modes
159Some manufacturers, like SMC, have implemented chipsets that support mixed
160modes. With such chipsets, mode switching is available at any time by
161accessing the extended control register.
162.Sh IEEE1284-1994 Standard
163.Ss Background
164This standard is also named "IEEE Standard Signaling Method for a
165Bidirectional Parallel Peripheral Interface for Personal Computers". It
166defines a signaling method for asynchroneous, fully interlocked, bidirectional
167parallel communications between hosts and printers or other peripherals. It
168also specifies a format for a peripheral identification string and a method of
169returning this string to the host outside of the bidirectional data stream.
170.Pp
171This standard is architecture independent and only specifiy dialog handshake
172at signal level. One should refer to any architecture specific document in
173order to manipulate machine dependent registers, mapped memory or whatelse
174to control these signals.
175.Pp
176The IEEE1284 protocol is fully oriented with all supported parallel port
177modes. The computer acts as master and the peripheral as slave.
178.Pp
179Any transfer is defined as a finite state automate. It allows software to
180properly manage the fully interlocked scheme of the signaling method.
181The compatible mode is supported "as is" without any negociation because it
182is compatible. Any other mode must be firstly negociated by the host to check
183it is supported by the peripheral, then to enter one of the forward idle
184states.
185.Pp
186At any time, the slave may want to send data to the host. This is only
187possible from forward idle states (nibble, byte, ecp...). So, the
188host must have previously negociated to permit the peripheral to
189request transfer. Interrupt lines may be dedicated to the requesting signals
190to prevent time consuming polling methods.
191.Pp
192But peripheral requests are only a hint to the master host. If the host
193accepts the transfer, it must firstly negociate the reverse mode and then
194starts the transfer. At any time during reverse transfer, the host may
195terminate the transfer or the slave may drive wires to signal that no more
196data is available.
197.Ss Implementation
198IEEE1284 Standard support has been implemented at the top of the ppbus system
199as a set of procedures that perform high level functions like negociation,
200termination, transfer in any mode without bothering you with low level
201caracteristics of the stantdard.
202.Pp
203IEEE1284 interacts with the ppbus system as least as possible. That means
204you still have to request the ppbus when you want to access it, the negociate
205function doesn't do it for you. And of course, release it later.
206.Sh ARCHITECTURE
207.Ss adapter, ppbus and device layers
208First, there is the
209.Em adapter
210layer, the lowest of the ppbus system. It provides
211chipset abstraction throw a set of low level functions that maps the logical
212model to the underlying hardware.
213.Pp
214Secondly, there is the
215.Em ppbus
216layer that provides functions to:
217.Bl -enum -offset indent
218.It
219share the parallel port bus among the daisy-chain like connected devices
220.It
221manage devices linked to ppbus
222.It
223propose an arch-independent interface to access the hardware layer.
224.El
225.Pp
226Finaly, the
227.Em device
228layer gathers the parallel peripheral device drivers.
229.Pp
230Each layer has its own C structure respectively ppb_adapter, ppb_data and
231ppb_device. The ppb_link structure gathers pointers to other structures and
232info shared among different layers.
233.Pp
234See description of these structures in
235.Xr ppbconf 9 .
236.Ss Parallel modes managment
237We have to differenciate operating modes at various ppbus system layers.
238Actually, ppbus and adapter operating modes on one hands and for each
239one, current and available modes are seperated.
240.Pp
241With this level of abstraction a particular chipset may commute from any
242native mode the any other mode emulated with extended modes without
243disturbing upper layers. For example, most chipsets support NIBBLE mode as
244native and emulated with ECP and/or EPP.
245.Pp
246This achitecture should support IEEE1284-1994 modes.
247.Sh FEATURES
248.Ss The boot process
249The boot process starts with the probe phasis of the
250.Xr ppc 4
251driver during ISA bus (PC architecture) initialisation. During attachment of
252the ppc driver, a new ppbus structure is allocated, initialized
253(linked to the adapter structure) then passed to the function
254.Fn ppb_attachdevs "struct ppb_data *ppb" .
255.Pp
256.Fn ppb_attachdevs ""
257tries to detect any PnP parallel peripheral (according to
258.%T "Plug and Play Parallel Port Devices"
259draft from (c)1993-4 Microsoft Corporation)
260then probes and attaches known device drivers.
261.Pp
262During probe, device drivers are supposed to request the ppbus and try to
263set their operating mode. This mode will be saved in the context structure and
264returned each time the driver requests the ppbus.
265.Ss Bus allocation and interrupts
266ppbus allocation is mandatory not to corrupt I/O of other devices. An other
267usage of ppbus allocation is to reserve the port and receive incoming
268interrupts.
269.Pp
270Interrupts are connected to the
271.Fn ppcintr ""
272function which delivers them to ppbus directly with a
273.Fn ppb_intr "struct ppb_link *pl"
274call. ppbus redirects the
275interrupt to the bus owner's handler if defined. Consequently, if a device
276wants to be delivered an interrupt, it must own the ppbus.
277.Ss Microsequences
278.Em Microsequences
279is a general purpose mechanism to allow fast low-level
280manipulation of the parallel port. Microsequences may be used to do either
281standard (in IEEE1284 modes) or non-standard transfers. The philosophy of
282microsequences is to avoid the overhead of the ppbus layer and do most of
283the job at adapter level.
284.Pp
285A microsequence is an array of opcodes and parameters. Each opcode codes an
286operation (opcodes are described in
287.Xr microseq 9 ).
288Standard I/O operations are implemented at ppbus level whereas basic I/O
289operations and microseq langage are coded at adapter level for efficiency.
290.Pp
291As an example, the
292.Xr vpo 4
293driver uses microsequences to implement:
294.Bl -bullet -offset indent
295.It
296a modified version of the NIBBLE transfer mode
297.It
298various I/O sequences to initialize, select and allocate the peripheral
299.El
300.Sh SEE ALSO
301.Xr ppbconf 9 ,
302.Xr ppc 4 ,
303.Xr ppi 4 ,
304.Xr vpo 4 ,
305.Xr nlpt 4 ,
306.Xr plip 4
307.Sh HISTORY
308The
309.Nm
310manual page first appeared in
311.Fx 3.0 .
312.Sh AUTHOR
313This
314manual page was written by
315.An Nicolas Souchu .
316