diff options
Diffstat (limited to 'share/man/man4/ppbus.4')
| -rw-r--r-- | share/man/man4/ppbus.4 | 363 |
1 files changed, 363 insertions, 0 deletions
diff --git a/share/man/man4/ppbus.4 b/share/man/man4/ppbus.4 new file mode 100644 index 0000000..327b7c9 --- /dev/null +++ b/share/man/man4/ppbus.4 @@ -0,0 +1,363 @@ +.\" Copyright (c) 1998, 1999 Nicolas Souchu +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd March 1, 1998 +.Dt PPBUS 4 +.Os +.Sh NAME +.Nm ppbus +.Nd Parallel Port Bus system +.Sh SYNOPSIS +.Cd "device ppbus" +.Pp +.Cd "device vpo" +.Pp +.Cd "device lpt" +.Cd "device plip" +.Cd "device ppi" +.Cd "device pps" +.Cd "device lpbb" +.Sh DESCRIPTION +The +.Em ppbus +system provides a uniform, modular and architecture-independent +system for the implementation of drivers to control various parallel devices, +and to utilize different parallel port chipsets. +.Sh DEVICE DRIVERS +In order to write new drivers or port existing drivers, the ppbus system +provides the following facilities: +.Bl -bullet -offset indent +.It +architecture-independent macros or functions to access parallel ports +.It +mechanism to allow various devices to share the same parallel port +.It +a user interface named +.Xr ppi 4 +that allows parallel port access from outside the kernel without conflicting +with kernel-in drivers. +.El +.Ss Developing new drivers +The ppbus system has been designed to support the development of standard +and non-standard software: +.Pp +.Bl -column "Driver" -compact +.It Em Driver Ta Em Description +.It Sy vpo Ta "VPI0 parallel to Adaptec AIC-7110 SCSI controller driver" . +It uses standard and non-standard parallel port accesses. +.It Sy ppi Ta "Parallel port interface for general I/O" +.It Sy pps Ta "Pulse per second Timing Interface" +.It Sy lpbb Ta "Philips official parallel port I2C bit-banging interface" +.El +.Ss Porting existing drivers +Another approach to the ppbus system is to port existing drivers. +Various drivers have already been ported: +.Pp +.Bl -column "Driver" -compact +.It Em Driver Ta Em Description +.It Sy lpt Ta "lpt printer driver" +.It Sy plip Ta "lp parallel network interface driver" +.El +.Pp +ppbus should let you port any other software even from other operating systems +that provide similar services. +.Sh PARALLEL PORT CHIPSETS +Parallel port chipset support is provided by +.Xr ppc 4 . +.Pp +The ppbus system provides functions and macros to allocate a new +parallel port bus, then initialize it and upper peripheral device drivers. +.Pp +ppc makes chipset detection and initialization and then calls ppbus attach +functions to initialize the ppbus system. +.Sh PARALLEL PORT MODEL +The logical parallel port model chosen for the ppbus system is the PC's +parallel port model. +Consequently, for the i386 implementation of ppbus, +most of the services provided by ppc are macros for inb() +and outb() calls. +But, for an other architecture, accesses to one of our logical +registers (data, status, control...) may require more than one I/O access. +.Ss Description +The parallel port may operate in the following modes: +.Bl -bullet -offset indent +.It +compatible mode, also called Centronics mode +.It +bidirectional 8/4-bits mode, also called NIBBLE mode +.It +byte mode, also called PS/2 mode +.It +Extended Capability Port mode, ECP +.It +Enhanced Parallel Port mode, EPP +.It +mixed ECP+EPP or ECP+PS/2 modes +.El +.Ss Compatible mode +This mode defines the protocol used by most PCs to transfer data to a printer. +In this mode, data is placed on the port's data lines, the printer status is +checked for no errors and that it is not busy, and then a data Strobe is +generated by the software to clock the data to the printer. +.Pp +Many I/O controllers have implemented a mode that uses a FIFO buffer to +transfer data with the Compatibility mode protocol. +This mode is referred to as +"Fast Centronics" or "Parallel Port FIFO mode". +.Ss Bidirectional mode +The NIBBLE mode is the most common way to get reverse channel data from a +printer or peripheral. +Combined with the standard host to printer mode, it +provides a complete bidirectional channel. +.Pp +In this mode, outputs are 8-bits long. +Inputs are accomplished by reading +4 of the 8 bits of the status register. +.Ss Byte mode +In this mode, the data register is used either for outputs and inputs. +Then, +any transfer is 8-bits long. +.Ss Extended Capability Port mode +The ECP protocol was proposed as an advanced mode for communication with +printer and scanner type peripherals. +Like the EPP protocol, ECP mode provides +for a high performance bidirectional communication path between the host +adapter and the peripheral. +.Pp +ECP protocol features include: +.Bl -item -offset indent +.It +Run_Length_Encoding (RLE) data compression for host adapters +.It +FIFOs for both the forward and reverse channels +.It +DMA as well as programmed I/O for the host register interface. +.El +.Ss Enhanced Parallel Port mode +The EPP protocol was originally developed as a means to provide a high +performance parallel port link that would still be compatible with the +standard parallel port. +.Pp +The EPP mode has two types of cycle: address and data. +What makes the +difference at hardware level is the strobe of the byte placed on the data +lines. +Data are strobed with nAutofeed, addresses are strobed with +nSelectin signals. +.Pp +A particularity of the ISA implementation of the EPP protocol is that an +EPP cycle fits in an ISA cycle. +In this fashion, parallel port peripherals can +operate at close to the same performance levels as an equivalent ISA plug-in +card. +.Pp +At software level, you may implement the protocol you wish, using data and +address cycles as you want. +This is for the IEEE1284 compatible part. +Then, +peripheral vendors may implement protocol handshake with the following +status lines: PError, nFault and Select. +Try to know how these lines toggle +with your peripheral, allowing the peripheral to request more data, stop the +transfer and so on. +.Pp +At any time, the peripheral may interrupt the host with the nAck signal without +disturbing the current transfer. +.Ss Mixed modes +Some manufacturers, like SMC, have implemented chipsets that support mixed +modes. +With such chipsets, mode switching is available at any time by +accessing the extended control register. +.Sh IEEE1284-1994 Standard +.Ss Background +This standard is also named "IEEE Standard Signaling Method for a +Bidirectional Parallel Peripheral Interface for Personal Computers". +It +defines a signaling method for asynchronous, fully interlocked, bidirectional +parallel communications between hosts and printers or other peripherals. +It +also specifies a format for a peripheral identification string and a method of +returning this string to the host outside of the bidirectional data stream. +.Pp +This standard is architecture independent and only specifies dialog handshake +at signal level. +One should refer to architecture specific documentation in +order to manipulate machine dependent registers, mapped memory or other +methods to control these signals. +.Pp +The IEEE1284 protocol is fully oriented with all supported parallel port +modes. +The computer acts as master and the peripheral as slave. +.Pp +Any transfer is defined as a finite state automaton. +It allows software to +properly manage the fully interlocked scheme of the signaling method. +The compatible mode is supported "as is" without any negotiation because it +is compatible. +Any other mode must be firstly negotiated by the host to check +it is supported by the peripheral, then to enter one of the forward idle +states. +.Pp +At any time, the slave may want to send data to the host. +This is only +possible from forward idle states (nibble, byte, ecp...). +So, the +host must have previously negotiated to permit the peripheral to +request transfer. +Interrupt lines may be dedicated to the requesting signals +to prevent time consuming polling methods. +.Pp +But peripheral requests are only a hint to the master host. +If the host +accepts the transfer, it must firstly negotiate the reverse mode and then +starts the transfer. +At any time during reverse transfer, the host may +terminate the transfer or the slave may drive wires to signal that no more +data is available. +.Ss Implementation +IEEE1284 Standard support has been implemented at the top of the ppbus system +as a set of procedures that perform high level functions like negotiation, +termination, transfer in any mode without bothering you with low level +characteristics of the standard. +.Pp +IEEE1284 interacts with the ppbus system as little as possible. +That means +you still have to request the ppbus when you want to access it, the negotiate +function does not do it for you. +And of course, release it later. +.Sh ARCHITECTURE +.Ss adapter, ppbus and device layers +First, there is the +.Em adapter +layer, the lowest of the ppbus system. +It provides +chipset abstraction throw a set of low level functions that maps the logical +model to the underlying hardware. +.Pp +Secondly, there is the +.Em ppbus +layer that provides functions to: +.Bl -enum -offset indent +.It +share the parallel port bus among the daisy-chain like connected devices +.It +manage devices linked to ppbus +.It +propose an arch-independent interface to access the hardware layer. +.El +.Pp +Finally, the +.Em device +layer gathers the parallel peripheral device drivers. +.Ss Parallel modes management +We have to differentiate operating modes at various ppbus system layers. +Actually, ppbus and adapter operating modes on one hands and for each +one, current and available modes are separated. +.Pp +With this level of abstraction a particular chipset may commute from any +native mode to any other mode emulated with extended modes without +disturbing upper layers. +For example, most chipsets support NIBBLE mode as +native and emulated with ECP and/or EPP. +.Pp +This architecture should support IEEE1284-1994 modes. +.Sh FEATURES +.Ss The boot process +The boot process starts with the probe stage of the +.Xr ppc 4 +driver during ISA bus (PC architecture) initialization. +During attachment of +the ppc driver, a new ppbus structure is allocated, then probe and attachment +for this new bus node are called. +.Pp +ppbus attachment tries to detect any PnP parallel peripheral (according to +.%T "Plug and Play Parallel Port Devices" +draft from (c)1993-4 Microsoft Corporation) +then probes and attaches known device drivers. +.Pp +During probe, device drivers are supposed to request the ppbus and try to +set their operating mode. +This mode will be saved in the context structure and +returned each time the driver requests the ppbus. +.Ss Bus allocation and interrupts +ppbus allocation is mandatory not to corrupt I/O of other devices. +Another +usage of ppbus allocation is to reserve the port and receive incoming +interrupts. +.Pp +High level interrupt handlers are connected to the ppbus system thanks to the +newbus +.Fn BUS_SETUP_INTR +and +.Fn BUS_TEARDOWN_INTR +functions. +But, in order to attach a handler, drivers must +own the bus. +Consequently, a ppbus request is mandatory in order to call the above +functions (see existing drivers for more info). +Note that the interrupt handler +is automatically released when the ppbus is released. +.Ss Microsequences +.Em Microsequences +is a general purpose mechanism to allow fast low-level +manipulation of the parallel port. +Microsequences may be used to do either +standard (in IEEE1284 modes) or non-standard transfers. +The philosophy of +microsequences is to avoid the overhead of the ppbus layer and do most of +the job at adapter level. +.Pp +A microsequence is an array of opcodes and parameters. +Each opcode codes an +operation (opcodes are described in +.Xr microseq 9 ) . +Standard I/O operations are implemented at ppbus level whereas basic I/O +operations and microseq language are coded at adapter level for efficiency. +.Pp +As an example, the +.Xr vpo 4 +driver uses microsequences to implement: +.Bl -bullet -offset indent +.It +a modified version of the NIBBLE transfer mode +.It +various I/O sequences to initialize, select and allocate the peripheral +.El +.Sh SEE ALSO +.Xr lpt 4 , +.Xr plip 4 , +.Xr ppc 4 , +.Xr ppi 4 , +.Xr vpo 4 +.Sh HISTORY +The +.Nm +manual page first appeared in +.Fx 3.0 . +.Sh AUTHORS +This +manual page was written by +.An Nicolas Souchu . |
