Deleted Added
full compact
ppbus.4 (57695) ppbus.4 (70466)
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.\"
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.\" $FreeBSD: head/share/man/man4/ppbus.4 57695 2000-03-02 14:54:02Z sheldonh $
25.\" $FreeBSD: head/share/man/man4/ppbus.4 70466 2000-12-29 09:18:45Z ru $
26.\"
27.Dd March 1, 1998
28.Dt PPBUS 4
29.Os FreeBSD
30.Sh NAME
31.Nm ppbus
32.Nd
33Parallel port bus system
34.Sh SYNOPSIS
35.Cd "device ppbus"
36.Pp
37.Cd "device vpo"
38.Pp
39.Cd "device lpt"
40.Cd "device plip"
41.Cd "device ppi"
42.Cd "device pps"
43.Cd "device lpbb"
44.Sh DESCRIPTION
45The
46.Em ppbus
47system provides a uniform, modular and architecture-independent
48system for the implementation of drivers to control various parallel devices,
49and to utilize different parallel port chipsets.
50.Sh DEVICE DRIVERS
51In order to write new drivers or port existing drivers, the ppbus system
52provides the following facilities:
26.\"
27.Dd March 1, 1998
28.Dt PPBUS 4
29.Os FreeBSD
30.Sh NAME
31.Nm ppbus
32.Nd
33Parallel port bus system
34.Sh SYNOPSIS
35.Cd "device ppbus"
36.Pp
37.Cd "device vpo"
38.Pp
39.Cd "device lpt"
40.Cd "device plip"
41.Cd "device ppi"
42.Cd "device pps"
43.Cd "device lpbb"
44.Sh DESCRIPTION
45The
46.Em ppbus
47system provides a uniform, modular and architecture-independent
48system for the implementation of drivers to control various parallel devices,
49and to utilize different parallel port chipsets.
50.Sh DEVICE DRIVERS
51In order to write new drivers or port existing drivers, the ppbus system
52provides the following facilities:
53.Bl -bullet -item -offset indent
53.Bl -bullet -offset indent
54.It
55architecture-independent macros or functions to access parallel ports
56.It
57mechanism to allow various devices to share the same parallel port
58.It
59a user interface named
60.Xr ppi 4
61that allows parallel port access from outside the kernel without conflicting
62with kernel-in drivers.
63.El
64.Ss Developing new drivers
65.Pp
66The ppbus system has been designed to support the development of standard
67and non-standard software:
68.Pp
69.Bl -column "Driver" -compact
70.It Em Driver Ta Em Description
71.It Sy vpo Ta "VPI0 parallel to Adaptec AIC-7110 SCSI controller driver."
72It uses standard and non-standard parallel port accesses.
73.It Sy ppi Ta "Parallel port interface for general I/O"
74.It Sy pps Ta "Pulse per second Timing Interface"
75.It Sy lpbb Ta "Philips official parallel port I2C bit-banging interface"
76.El
77.Ss Porting existing drivers
78.Pp
79Another approach to the ppbus system is to port existing drivers.
80Various drivers have already been ported:
81.Pp
82.Bl -column "Driver" -compact
83.It Em Driver Ta Em Description
84.It Sy lpt Ta "lpt printer driver"
85.It Sy plip Ta "lp parallel network interface driver"
86.El
87.Pp
88ppbus should let you port any other software even from other operating systems
89that provide similar services.
90.Sh PARALLEL PORT CHIPSETS
91Parallel port chipset support is provided by
92.Xr ppc 4 .
93.Pp
94The ppbus system provides functions and macros to allocate a new
95parallel port bus, then initialize it and upper peripheral device drivers.
96.Pp
97ppc makes chipset detection and initialization and then calls ppbus attach
98functions to initialize the ppbus system.
99.Sh PARALLEL PORT MODEL
100The logical parallel port model chosen for the ppbus system is the PC's
101parallel port model.
102Consequently, for the i386 implementation of ppbus,
103most of the services provided by ppc are macros for inb()
104and outb() calls.
105But, for an other architecture, accesses to one of our logical
106registers (data, status, control...) may require more than one I/O access.
107.Ss Description
108The parallel port may operate in the following modes:
54.It
55architecture-independent macros or functions to access parallel ports
56.It
57mechanism to allow various devices to share the same parallel port
58.It
59a user interface named
60.Xr ppi 4
61that allows parallel port access from outside the kernel without conflicting
62with kernel-in drivers.
63.El
64.Ss Developing new drivers
65.Pp
66The ppbus system has been designed to support the development of standard
67and non-standard software:
68.Pp
69.Bl -column "Driver" -compact
70.It Em Driver Ta Em Description
71.It Sy vpo Ta "VPI0 parallel to Adaptec AIC-7110 SCSI controller driver."
72It uses standard and non-standard parallel port accesses.
73.It Sy ppi Ta "Parallel port interface for general I/O"
74.It Sy pps Ta "Pulse per second Timing Interface"
75.It Sy lpbb Ta "Philips official parallel port I2C bit-banging interface"
76.El
77.Ss Porting existing drivers
78.Pp
79Another approach to the ppbus system is to port existing drivers.
80Various drivers have already been ported:
81.Pp
82.Bl -column "Driver" -compact
83.It Em Driver Ta Em Description
84.It Sy lpt Ta "lpt printer driver"
85.It Sy plip Ta "lp parallel network interface driver"
86.El
87.Pp
88ppbus should let you port any other software even from other operating systems
89that provide similar services.
90.Sh PARALLEL PORT CHIPSETS
91Parallel port chipset support is provided by
92.Xr ppc 4 .
93.Pp
94The ppbus system provides functions and macros to allocate a new
95parallel port bus, then initialize it and upper peripheral device drivers.
96.Pp
97ppc makes chipset detection and initialization and then calls ppbus attach
98functions to initialize the ppbus system.
99.Sh PARALLEL PORT MODEL
100The logical parallel port model chosen for the ppbus system is the PC's
101parallel port model.
102Consequently, for the i386 implementation of ppbus,
103most of the services provided by ppc are macros for inb()
104and outb() calls.
105But, for an other architecture, accesses to one of our logical
106registers (data, status, control...) may require more than one I/O access.
107.Ss Description
108The parallel port may operate in the following modes:
109.Bl -bullet -item -offset indent
109.Bl -bullet -offset indent
110.It
111compatible mode, also called Centronics mode
112.It
113bidirectional 8/4-bits mode, also called NIBBLE mode
114.It
115byte mode, also called PS/2 mode
116.It
117Extended Capability Port mode, ECP
118.It
119Enhanced Parallel Port mode, EPP
120.It
121mixed ECP+EPP or ECP+PS/2 modes
122.El
123.Ss Compatible mode
124This mode defines the protocol used by most PCs to transfer data to a printer.
125In this mode, data is placed on the port's data lines, the printer status is
126checked for no errors and that it is not busy, and then a data Strobe is
127generated by the software to clock the data to the printer.
128.Pp
129Many I/O controllers have implemented a mode that uses a FIFO buffer to
130transfer data with the Compatibility mode protocol.
131This mode is referred to as
132"Fast Centronics" or "Parallel Port FIFO mode".
133.Ss Bidirectional mode
134The NIBBLE mode is the most common way to get reverse channel data from a
135printer or peripheral.
136Combined with the standard host to printer mode, it
137provides a complete bidirectional channel.
138.Pp
139In this mode, outputs are 8-bits long.
140Inputs are accomplished by reading
1414 of the 8 bits of the status register.
142.Ss Byte mode
143In this mode, the data register is used either for outputs and inputs.
144Then,
145any transfer is 8-bits long.
146.Ss Extended Capability Port mode
147The ECP protocol was proposed as an advanced mode for communication with
148printer and scanner type peripherals.
149Like the EPP protocol, ECP mode provides
150for a high performance bidirectional communication path between the host
151adapter and the peripheral.
152.Pp
153ECP protocol features include:
154.Bl -item -offset indent
155.It
156Run_Length_Encoding (RLE) data compression for host adapters
157.It
158FIFOs for both the forward and reverse channels
159.It
160DMA as well as programmed I/O for the host register interface.
161.El
162.Ss Enhanced Parallel Port mode
163The EPP protocol was originally developed as a means to provide a high
164performance parallel port link that would still be compatible with the
165standard parallel port.
166.Pp
167The EPP mode has two types of cycle: address and data.
168What makes the
169difference at hardware level is the strobe of the byte placed on the data
170lines.
171Data are strobed with nAutofeed, addresses are strobed with
172nSelectin signals.
173.Pp
174A particularity of the ISA implementation of the EPP protocol is that an
175EPP cycle fits in an ISA cycle.
176In this fashion, parallel port peripherals can
177operate at close to the same performance levels as an equivalent ISA plug-in
178card.
179.Pp
180At software level, you may implement the protocol you wish, using data and
181address cycles as you want.
182This is for the IEEE1284 compatible part.
183Then,
184peripheral vendors may implement protocol handshake with the following
185status lines: PError, nFault and Select.
186Try to know how these lines toggle
187with your peripheral, allowing the peripheral to request more data, stop the
188transfer and so on.
189.Pp
190At any time, the peripheral may interrupt the host with the nAck signal without
191disturbing the current transfer.
192.Ss Mixed modes
193Some manufacturers, like SMC, have implemented chipsets that support mixed
194modes.
195With such chipsets, mode switching is available at any time by
196accessing the extended control register.
197.Sh IEEE1284-1994 Standard
198.Ss Background
199This standard is also named "IEEE Standard Signaling Method for a
200Bidirectional Parallel Peripheral Interface for Personal Computers". It
201defines a signaling method for asynchronous, fully interlocked, bidirectional
202parallel communications between hosts and printers or other peripherals.
203It
204also specifies a format for a peripheral identification string and a method of
205returning this string to the host outside of the bidirectional data stream.
206.Pp
207This standard is architecture independent and only specifies dialog handshake
208at signal level.
209One should refer to architecture specific documentation in
210order to manipulate machine dependent registers, mapped memory or other
211methods to control these signals.
212.Pp
213The IEEE1284 protocol is fully oriented with all supported parallel port
214modes.
215The computer acts as master and the peripheral as slave.
216.Pp
217Any transfer is defined as a finite state automate.
218It allows software to
219properly manage the fully interlocked scheme of the signaling method.
220The compatible mode is supported "as is" without any negotiation because it
221is compatible.
222Any other mode must be firstly negotiated by the host to check
223it is supported by the peripheral, then to enter one of the forward idle
224states.
225.Pp
226At any time, the slave may want to send data to the host.
227This is only
228possible from forward idle states (nibble, byte, ecp...).
229So, the
230host must have previously negotiated to permit the peripheral to
231request transfer.
232Interrupt lines may be dedicated to the requesting signals
233to prevent time consuming polling methods.
234.Pp
235But peripheral requests are only a hint to the master host.
236If the host
237accepts the transfer, it must firstly negotiate the reverse mode and then
238starts the transfer.
239At any time during reverse transfer, the host may
240terminate the transfer or the slave may drive wires to signal that no more
241data is available.
242.Ss Implementation
243IEEE1284 Standard support has been implemented at the top of the ppbus system
244as a set of procedures that perform high level functions like negotiation,
245termination, transfer in any mode without bothering you with low level
246characteristics of the standard.
247.Pp
248IEEE1284 interacts with the ppbus system as least as possible.
249That means
250you still have to request the ppbus when you want to access it, the negotiate
251function doesn't do it for you.
252And of course, release it later.
253.Sh ARCHITECTURE
254.Ss adapter, ppbus and device layers
255First, there is the
256.Em adapter
257layer, the lowest of the ppbus system.
258It provides
259chipset abstraction throw a set of low level functions that maps the logical
260model to the underlying hardware.
261.Pp
262Secondly, there is the
263.Em ppbus
264layer that provides functions to:
265.Bl -enum -offset indent
266.It
267share the parallel port bus among the daisy-chain like connected devices
268.It
269manage devices linked to ppbus
270.It
271propose an arch-independent interface to access the hardware layer.
272.El
273.Pp
274Finally, the
275.Em device
276layer gathers the parallel peripheral device drivers.
277.Pp
278.Ss Parallel modes management
279We have to differentiate operating modes at various ppbus system layers.
280Actually, ppbus and adapter operating modes on one hands and for each
281one, current and available modes are separated.
282.Pp
283With this level of abstraction a particular chipset may commute from any
284native mode the any other mode emulated with extended modes without
285disturbing upper layers.
286For example, most chipsets support NIBBLE mode as
287native and emulated with ECP and/or EPP.
288.Pp
289This architecture should support IEEE1284-1994 modes.
290.Sh FEATURES
291.Ss The boot process
292The boot process starts with the probe phasis of the
293.Xr ppc 4
294driver during ISA bus (PC architecture) initialization.
295During attachment of
296the ppc driver, a new ppbus structure is allocated, then probe and attachment
297for this new bus node are called.
298.Pp
299ppbus attachment tries to detect any PnP parallel peripheral (according to
300.%T "Plug and Play Parallel Port Devices"
301draft from (c)1993-4 Microsoft Corporation)
302then probes and attaches known device drivers.
303.Pp
304During probe, device drivers are supposed to request the ppbus and try to
305set their operating mode.
306This mode will be saved in the context structure and
307returned each time the driver requests the ppbus.
308.Ss Bus allocation and interrupts
309ppbus allocation is mandatory not to corrupt I/O of other devices.
310An other
311usage of ppbus allocation is to reserve the port and receive incoming
312interrupts.
313.Pp
314High level interrupt handlers are connected to the ppbus system thanks to the
315newbus
316.Fn BUS_SETUP_INTR
317and
318.Fn BUS_TEARDOWN_INTR
319functions.
320But, in order to attach a handler, drivers must
321own the bus.
322Consequently, a ppbus request is mandatory in order to call the above
323functions (see existing drivers for more info). Note that the interrupt handler
324is automatically released when the ppbus is released.
325.Ss Microsequences
326.Em Microsequences
327is a general purpose mechanism to allow fast low-level
328manipulation of the parallel port.
329Microsequences may be used to do either
330standard (in IEEE1284 modes) or non-standard transfers.
331The philosophy of
332microsequences is to avoid the overhead of the ppbus layer and do most of
333the job at adapter level.
334.Pp
335A microsequence is an array of opcodes and parameters.
336Each opcode codes an
337operation (opcodes are described in
338.Xr microseq 9 ).
339Standard I/O operations are implemented at ppbus level whereas basic I/O
340operations and microseq language are coded at adapter level for efficiency.
341.Pp
342As an example, the
343.Xr vpo 4
344driver uses microsequences to implement:
345.Bl -bullet -offset indent
346.It
347a modified version of the NIBBLE transfer mode
348.It
349various I/O sequences to initialize, select and allocate the peripheral
350.El
351.Sh SEE ALSO
352.Xr lpt 4 ,
353.Xr plip 4 ,
354.Xr ppc 4 ,
355.Xr ppi 4 ,
356.Xr vpo 4
357.Sh HISTORY
358The
359.Nm
360manual page first appeared in
361.Fx 3.0 .
362.Sh AUTHORS
363This
364manual page was written by
365.An Nicolas Souchu .
110.It
111compatible mode, also called Centronics mode
112.It
113bidirectional 8/4-bits mode, also called NIBBLE mode
114.It
115byte mode, also called PS/2 mode
116.It
117Extended Capability Port mode, ECP
118.It
119Enhanced Parallel Port mode, EPP
120.It
121mixed ECP+EPP or ECP+PS/2 modes
122.El
123.Ss Compatible mode
124This mode defines the protocol used by most PCs to transfer data to a printer.
125In this mode, data is placed on the port's data lines, the printer status is
126checked for no errors and that it is not busy, and then a data Strobe is
127generated by the software to clock the data to the printer.
128.Pp
129Many I/O controllers have implemented a mode that uses a FIFO buffer to
130transfer data with the Compatibility mode protocol.
131This mode is referred to as
132"Fast Centronics" or "Parallel Port FIFO mode".
133.Ss Bidirectional mode
134The NIBBLE mode is the most common way to get reverse channel data from a
135printer or peripheral.
136Combined with the standard host to printer mode, it
137provides a complete bidirectional channel.
138.Pp
139In this mode, outputs are 8-bits long.
140Inputs are accomplished by reading
1414 of the 8 bits of the status register.
142.Ss Byte mode
143In this mode, the data register is used either for outputs and inputs.
144Then,
145any transfer is 8-bits long.
146.Ss Extended Capability Port mode
147The ECP protocol was proposed as an advanced mode for communication with
148printer and scanner type peripherals.
149Like the EPP protocol, ECP mode provides
150for a high performance bidirectional communication path between the host
151adapter and the peripheral.
152.Pp
153ECP protocol features include:
154.Bl -item -offset indent
155.It
156Run_Length_Encoding (RLE) data compression for host adapters
157.It
158FIFOs for both the forward and reverse channels
159.It
160DMA as well as programmed I/O for the host register interface.
161.El
162.Ss Enhanced Parallel Port mode
163The EPP protocol was originally developed as a means to provide a high
164performance parallel port link that would still be compatible with the
165standard parallel port.
166.Pp
167The EPP mode has two types of cycle: address and data.
168What makes the
169difference at hardware level is the strobe of the byte placed on the data
170lines.
171Data are strobed with nAutofeed, addresses are strobed with
172nSelectin signals.
173.Pp
174A particularity of the ISA implementation of the EPP protocol is that an
175EPP cycle fits in an ISA cycle.
176In this fashion, parallel port peripherals can
177operate at close to the same performance levels as an equivalent ISA plug-in
178card.
179.Pp
180At software level, you may implement the protocol you wish, using data and
181address cycles as you want.
182This is for the IEEE1284 compatible part.
183Then,
184peripheral vendors may implement protocol handshake with the following
185status lines: PError, nFault and Select.
186Try to know how these lines toggle
187with your peripheral, allowing the peripheral to request more data, stop the
188transfer and so on.
189.Pp
190At any time, the peripheral may interrupt the host with the nAck signal without
191disturbing the current transfer.
192.Ss Mixed modes
193Some manufacturers, like SMC, have implemented chipsets that support mixed
194modes.
195With such chipsets, mode switching is available at any time by
196accessing the extended control register.
197.Sh IEEE1284-1994 Standard
198.Ss Background
199This standard is also named "IEEE Standard Signaling Method for a
200Bidirectional Parallel Peripheral Interface for Personal Computers". It
201defines a signaling method for asynchronous, fully interlocked, bidirectional
202parallel communications between hosts and printers or other peripherals.
203It
204also specifies a format for a peripheral identification string and a method of
205returning this string to the host outside of the bidirectional data stream.
206.Pp
207This standard is architecture independent and only specifies dialog handshake
208at signal level.
209One should refer to architecture specific documentation in
210order to manipulate machine dependent registers, mapped memory or other
211methods to control these signals.
212.Pp
213The IEEE1284 protocol is fully oriented with all supported parallel port
214modes.
215The computer acts as master and the peripheral as slave.
216.Pp
217Any transfer is defined as a finite state automate.
218It allows software to
219properly manage the fully interlocked scheme of the signaling method.
220The compatible mode is supported "as is" without any negotiation because it
221is compatible.
222Any other mode must be firstly negotiated by the host to check
223it is supported by the peripheral, then to enter one of the forward idle
224states.
225.Pp
226At any time, the slave may want to send data to the host.
227This is only
228possible from forward idle states (nibble, byte, ecp...).
229So, the
230host must have previously negotiated to permit the peripheral to
231request transfer.
232Interrupt lines may be dedicated to the requesting signals
233to prevent time consuming polling methods.
234.Pp
235But peripheral requests are only a hint to the master host.
236If the host
237accepts the transfer, it must firstly negotiate the reverse mode and then
238starts the transfer.
239At any time during reverse transfer, the host may
240terminate the transfer or the slave may drive wires to signal that no more
241data is available.
242.Ss Implementation
243IEEE1284 Standard support has been implemented at the top of the ppbus system
244as a set of procedures that perform high level functions like negotiation,
245termination, transfer in any mode without bothering you with low level
246characteristics of the standard.
247.Pp
248IEEE1284 interacts with the ppbus system as least as possible.
249That means
250you still have to request the ppbus when you want to access it, the negotiate
251function doesn't do it for you.
252And of course, release it later.
253.Sh ARCHITECTURE
254.Ss adapter, ppbus and device layers
255First, there is the
256.Em adapter
257layer, the lowest of the ppbus system.
258It provides
259chipset abstraction throw a set of low level functions that maps the logical
260model to the underlying hardware.
261.Pp
262Secondly, there is the
263.Em ppbus
264layer that provides functions to:
265.Bl -enum -offset indent
266.It
267share the parallel port bus among the daisy-chain like connected devices
268.It
269manage devices linked to ppbus
270.It
271propose an arch-independent interface to access the hardware layer.
272.El
273.Pp
274Finally, the
275.Em device
276layer gathers the parallel peripheral device drivers.
277.Pp
278.Ss Parallel modes management
279We have to differentiate operating modes at various ppbus system layers.
280Actually, ppbus and adapter operating modes on one hands and for each
281one, current and available modes are separated.
282.Pp
283With this level of abstraction a particular chipset may commute from any
284native mode the any other mode emulated with extended modes without
285disturbing upper layers.
286For example, most chipsets support NIBBLE mode as
287native and emulated with ECP and/or EPP.
288.Pp
289This architecture should support IEEE1284-1994 modes.
290.Sh FEATURES
291.Ss The boot process
292The boot process starts with the probe phasis of the
293.Xr ppc 4
294driver during ISA bus (PC architecture) initialization.
295During attachment of
296the ppc driver, a new ppbus structure is allocated, then probe and attachment
297for this new bus node are called.
298.Pp
299ppbus attachment tries to detect any PnP parallel peripheral (according to
300.%T "Plug and Play Parallel Port Devices"
301draft from (c)1993-4 Microsoft Corporation)
302then probes and attaches known device drivers.
303.Pp
304During probe, device drivers are supposed to request the ppbus and try to
305set their operating mode.
306This mode will be saved in the context structure and
307returned each time the driver requests the ppbus.
308.Ss Bus allocation and interrupts
309ppbus allocation is mandatory not to corrupt I/O of other devices.
310An other
311usage of ppbus allocation is to reserve the port and receive incoming
312interrupts.
313.Pp
314High level interrupt handlers are connected to the ppbus system thanks to the
315newbus
316.Fn BUS_SETUP_INTR
317and
318.Fn BUS_TEARDOWN_INTR
319functions.
320But, in order to attach a handler, drivers must
321own the bus.
322Consequently, a ppbus request is mandatory in order to call the above
323functions (see existing drivers for more info). Note that the interrupt handler
324is automatically released when the ppbus is released.
325.Ss Microsequences
326.Em Microsequences
327is a general purpose mechanism to allow fast low-level
328manipulation of the parallel port.
329Microsequences may be used to do either
330standard (in IEEE1284 modes) or non-standard transfers.
331The philosophy of
332microsequences is to avoid the overhead of the ppbus layer and do most of
333the job at adapter level.
334.Pp
335A microsequence is an array of opcodes and parameters.
336Each opcode codes an
337operation (opcodes are described in
338.Xr microseq 9 ).
339Standard I/O operations are implemented at ppbus level whereas basic I/O
340operations and microseq language are coded at adapter level for efficiency.
341.Pp
342As an example, the
343.Xr vpo 4
344driver uses microsequences to implement:
345.Bl -bullet -offset indent
346.It
347a modified version of the NIBBLE transfer mode
348.It
349various I/O sequences to initialize, select and allocate the peripheral
350.El
351.Sh SEE ALSO
352.Xr lpt 4 ,
353.Xr plip 4 ,
354.Xr ppc 4 ,
355.Xr ppi 4 ,
356.Xr vpo 4
357.Sh HISTORY
358The
359.Nm
360manual page first appeared in
361.Fx 3.0 .
362.Sh AUTHORS
363This
364manual page was written by
365.An Nicolas Souchu .