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: src/share/man/man4/ppbus.4,v 1.14.2.5 2001/08/17 13:08:39 ru Exp $ 26.\" 27.Dd March 1, 1998 28.Dt PPBUS 4 29.Os 30.Sh NAME 31.Nm ppbus 32.Nd Parallel Port Bus system 33.Sh SYNOPSIS 34.Cd "device ppbus" 35.Cd "options DEBUG_1284" 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 -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 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 77Another approach to the ppbus system is to port existing drivers. 78Various drivers have already been ported: 79.Pp 80.Bl -column "Driver" -compact 81.It Em Driver Ta Em Description 82.It Sy lpt Ta "lpt printer driver" 83.It Sy plip Ta "lp parallel network interface driver" 84.El 85.Pp 86ppbus should let you port any other software even from other operating systems 87that provide similar services. 88.Sh PARALLEL PORT CHIPSETS 89Parallel port chipset support is provided by 90.Xr ppc 4 . 91.Pp 92The ppbus system provides functions and macros to allocate a new 93parallel port bus, then initialize it and upper peripheral device drivers. 94.Pp 95ppc makes chipset detection and initialization and then calls ppbus attach 96functions to initialize the ppbus system. 97.Sh PARALLEL PORT MODEL 98The logical parallel port model chosen for the ppbus system is the PC's 99parallel port model. 100Consequently, most of the services provided by ppc are macros for 101.Fn inb 102and 103.Fn outb 104calls. 105But, for another 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 -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.Ss Parallel modes management 278We have to differentiate operating modes at various ppbus system layers. 279Actually, ppbus and adapter operating modes on one hands and for each 280one, current and available modes are separated. 281.Pp 282With this level of abstraction a particular chipset may commute from any 283native mode the any other mode emulated with extended modes without 284disturbing upper layers. 285For example, most chipsets support NIBBLE mode as 286native and emulated with ECP and/or EPP. 287.Pp 288This architecture should support IEEE1284-1994 modes. 289.Sh FEATURES 290.Ss The boot process 291The boot process starts with the probe phasis of the 292.Xr ppc 4 293driver during ISA bus (PC architecture) initialization. 294During attachment of 295the ppc driver, a new ppbus structure is allocated, then probe and attachment 296for this new bus node are called. 297.Pp 298ppbus attachment tries to detect any PnP parallel peripheral (according to 299.%T "Plug and Play Parallel Port Devices" 300draft from (c)1993-4 Microsoft Corporation) 301then probes and attaches known device drivers. 302.Pp 303During probe, device drivers are supposed to request the ppbus and try to 304set their operating mode. 305This mode will be saved in the context structure and 306returned each time the driver requests the ppbus. 307.Ss Bus allocation and interrupts 308ppbus allocation is mandatory not to corrupt I/O of other devices. 309Another 310usage of ppbus allocation is to reserve the port and receive incoming 311interrupts. 312.Pp 313High level interrupt handlers are connected to the ppbus system thanks to the 314newbus 315.Fn BUS_SETUP_INTR 316and 317.Fn BUS_TEARDOWN_INTR 318functions. 319But, in order to attach a handler, drivers must 320own the bus. 321Consequently, a ppbus request is mandatory in order to call the above 322functions (see existing drivers for more info). Note that the interrupt handler 323is automatically released when the ppbus is released. 324.Ss Microsequences 325.Em Microsequences 326is a general purpose mechanism to allow fast low-level 327manipulation of the parallel port. 328Microsequences may be used to do either 329standard (in IEEE1284 modes) or non-standard transfers. 330The philosophy of 331microsequences is to avoid the overhead of the ppbus layer and do most of 332the job at adapter level. 333.Pp 334A microsequence is an array of opcodes and parameters. 335Each opcode codes an 336operation (opcodes are described in 337.Xr microseq 9 ) . 338Standard I/O operations are implemented at ppbus level whereas basic I/O 339operations and microseq language are coded at adapter level for efficiency. 340.Pp 341As an example, the 342.Xr vpo 4 343driver uses microsequences to implement: 344.Bl -bullet -offset indent 345.It 346a modified version of the NIBBLE transfer mode 347.It 348various I/O sequences to initialize, select and allocate the peripheral 349.El 350.Sh SEE ALSO 351.Xr lpt 4 , 352.Xr plip 4 , 353.Xr ppc 4 , 354.Xr ppi 4 , 355.Xr vpo 4 356.Sh HISTORY 357The 358.Nm 359manual page first appeared in 360.Fx 3.0 . 361.Sh AUTHORS 362This 363manual page was written by 364.An Nicolas Souchu . 365