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 conflicting 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 initialization 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 software 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.Pp 159The EPP mode has two types of cycle: address and data. What makes the 160difference at hardware level is the strobe of the byte placed on the data 161lines. Data are strobed with nAutofeed, addresses are strobed with 162nSelectin signals. 163.Pp 164A particularity of the ISA implementation of the EPP protocol is that an 165EPP cycle fits in an ISA cycle. In this fashion, parallel port peripherals can 166operate at close to the same performance levels as an equivalent ISA plug-in 167card. 168.Pp 169At software level, you may implement the protocol you wish, using data and 170address cycles as you want. This is for the IEEE1284 compatible part. Then, 171peripheral vendors may implement protocol handshake with the following 172status lines: PError, nFault and Select. Try to know how these lines toggle 173with your peripheral, allowing the peripheral to request more data, stop the 174transfer and so on. 175.Pp 176At any time, the peripheral may interrupt the host with the nAck signal without 177disturbing the current transfer. 178.Ss Mixed modes 179Some manufacturers, like SMC, have implemented chipsets that support mixed 180modes. With such chipsets, mode switching is available at any time by 181accessing the extended control register. 182.Sh IEEE1284-1994 Standard 183.Ss Background 184This standard is also named "IEEE Standard Signaling Method for a 185Bidirectional Parallel Peripheral Interface for Personal Computers". It 186defines a signaling method for asynchronous, fully interlocked, bidirectional 187parallel communications between hosts and printers or other peripherals. It 188also specifies a format for a peripheral identification string and a method of 189returning this string to the host outside of the bidirectional data stream. 190.Pp 191This standard is architecture independent and only specifies dialog handshake 192at signal level. One should refer to architecture specific documentation in 193order to manipulate machine dependent registers, mapped memory or other 194methods to control these signals. 195.Pp 196The IEEE1284 protocol is fully oriented with all supported parallel port 197modes. The computer acts as master and the peripheral as slave. 198.Pp 199Any transfer is defined as a finite state automate. It allows software to 200properly manage the fully interlocked scheme of the signaling method. 201The compatible mode is supported "as is" without any negotiation because it 202is compatible. Any other mode must be firstly negotiated by the host to check 203it is supported by the peripheral, then to enter one of the forward idle 204states. 205.Pp 206At any time, the slave may want to send data to the host. This is only 207possible from forward idle states (nibble, byte, ecp...). So, the 208host must have previously negotiated to permit the peripheral to 209request transfer. Interrupt lines may be dedicated to the requesting signals 210to prevent time consuming polling methods. 211.Pp 212But peripheral requests are only a hint to the master host. If the host 213accepts the transfer, it must firstly negotiate the reverse mode and then 214starts the transfer. At any time during reverse transfer, the host may 215terminate the transfer or the slave may drive wires to signal that no more 216data is available. 217.Ss Implementation 218IEEE1284 Standard support has been implemented at the top of the ppbus system 219as a set of procedures that perform high level functions like negotiation, 220termination, transfer in any mode without bothering you with low level 221characteristics of the standard. 222.Pp 223IEEE1284 interacts with the ppbus system as least as possible. That means 224you still have to request the ppbus when you want to access it, the negotiate 225function doesn't do it for you. And of course, release it later. 226.Sh ARCHITECTURE 227.Ss adapter, ppbus and device layers 228First, there is the 229.Em adapter 230layer, the lowest of the ppbus system. It provides 231chipset abstraction throw a set of low level functions that maps the logical 232model to the underlying hardware. 233.Pp 234Secondly, there is the 235.Em ppbus 236layer that provides functions to: 237.Bl -enum -offset indent 238.It 239share the parallel port bus among the daisy-chain like connected devices 240.It 241manage devices linked to ppbus 242.It 243propose an arch-independent interface to access the hardware layer. 244.El 245.Pp 246Finally, the 247.Em device 248layer gathers the parallel peripheral device drivers. 249.Pp 250Each layer has its own C structure respectively ppb_adapter, ppb_data and 251ppb_device. The ppb_link structure gathers pointers to other structures and 252info shared among different layers. 253.Pp 254See description of these structures in 255.Xr ppbconf 9 . 256.Ss Parallel modes management 257We have to differentiate operating modes at various ppbus system layers. 258Actually, ppbus and adapter operating modes on one hands and for each 259one, current and available modes are separated. 260.Pp 261With this level of abstraction a particular chipset may commute from any 262native mode the any other mode emulated with extended modes without 263disturbing upper layers. For example, most chipsets support NIBBLE mode as 264native and emulated with ECP and/or EPP. 265.Pp 266This architecture should support IEEE1284-1994 modes. 267.Sh FEATURES 268.Ss The boot process 269The boot process starts with the probe phasis of the 270.Xr ppc 4 271driver during ISA bus (PC architecture) initialization. During attachment of 272the ppc driver, a new ppbus structure is allocated, initialized 273(linked to the adapter structure) then passed to the function 274.Fn ppb_attachdevs "struct ppb_data *ppb" . 275.Pp 276.Fn ppb_attachdevs "" 277tries to detect any PnP parallel peripheral (according to 278.%T "Plug and Play Parallel Port Devices" 279draft from (c)1993-4 Microsoft Corporation) 280then probes and attaches known device drivers. 281.Pp 282During probe, device drivers are supposed to request the ppbus and try to 283set their operating mode. This mode will be saved in the context structure and 284returned each time the driver requests the ppbus. 285.Ss Bus allocation and interrupts 286ppbus allocation is mandatory not to corrupt I/O of other devices. An other 287usage of ppbus allocation is to reserve the port and receive incoming 288interrupts. 289.Pp 290Interrupts are connected to the 291.Fn ppcintr "" 292function which delivers them to ppbus directly with a 293.Fn ppb_intr "struct ppb_link *pl" 294call. ppbus redirects the 295interrupt to the bus owner's handler if defined. Consequently, if a device 296wants to be delivered an interrupt, it must own the ppbus. 297.Ss Microsequences 298.Em Microsequences 299is a general purpose mechanism to allow fast low-level 300manipulation of the parallel port. Microsequences may be used to do either 301standard (in IEEE1284 modes) or non-standard transfers. The philosophy of 302microsequences is to avoid the overhead of the ppbus layer and do most of 303the job at adapter level. 304.Pp 305A microsequence is an array of opcodes and parameters. Each opcode codes an 306operation (opcodes are described in 307.Xr microseq 9 ). 308Standard I/O operations are implemented at ppbus level whereas basic I/O 309operations and microseq language are coded at adapter level for efficiency. 310.Pp 311As an example, the 312.Xr vpo 4 313driver uses microsequences to implement: 314.Bl -bullet -offset indent 315.It 316a modified version of the NIBBLE transfer mode 317.It 318various I/O sequences to initialize, select and allocate the peripheral 319.El 320.Sh SEE ALSO 321.Xr ppbconf 9 , 322.Xr ppc 4 , 323.Xr ppi 4 , 324.Xr vpo 4 , 325.Xr nlpt 4 , 326.Xr plip 4 327.Sh HISTORY 328The 329.Nm 330manual page first appeared in 331.Fx 3.0 . 332.Sh AUTHOR 333This 334manual page was written by 335.An Nicolas Souchu . 336