|Main index||Section 4||日本語||한국인||Options|
device lpt device plip device ppi device pps device lpbb
|vpo||VPI0 parallel to Adaptec AIC-7110 SCSI controller driver.It uses standard and non-standard parallel port accesses.|
|ppi||Parallel port interface for general I/O|
|pps||Pulse per second Timing Interface|
|lpbb||Philips official parallel port I2C bit-banging interface|
|lpt||lpt printer driver|
|plip||lp parallel network interface driver|
ppbus should let you port any other software even from other operating systems that provide similar services.
The ppbus system provides functions and macros to allocate a new parallel port bus, then initialize it and upper peripheral device drivers.
ppc makes chipset detection and initialization and then calls ppbus attach functions to initialize the ppbus system.
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".
In this mode, outputs are 8-bits long. Inputs are accomplished by reading 4 of the 8 bits of the status register.
ECP protocol features include:
|Run_Length_Encoding (RLE) data compression for host adapters|
|FIFOs for both the forward and reverse channels|
|DMA as well as programmed I/O for the host register interface.|
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.
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.
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.
At any time, the peripheral may interrupt the host with the nAck signal without disturbing the current transfer.
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.
The IEEE1284 protocol is fully oriented with all supported parallel port modes. The computer acts as master and the peripheral as slave.
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.
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.
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.
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.
Secondly, there is the ppbus layer that provides functions to:
Finally, the device layer gathers the parallel peripheral device drivers.
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.
This architecture should support IEEE1284-1994 modes.
ppbus attachment tries to detect any PnP parallel peripheral (according to Plug and Play Parallel Port Devices draft from (c)1993-4 Microsoft Corporation) then probes and attaches known device drivers.
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.
High level interrupt handlers are connected to the ppbus system thanks to the newbus BUS_SETUP_INTR() and 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.
A microsequence is an array of opcodes and parameters. Each opcode codes an operation (opcodes are described in 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.
As an example, the vpo(4) driver uses microsequences to implement:
|PPBUS (4)||March 1, 1998|
|Main index||Section 4||日本語||한국인||Options|
|“||The most horrifying thing about Unix is that, no matter how many times you hit yourself over the head with it, you never quite manage to lose consciousness. It just goes on and on.||”|
|— Patrick Sobalvarro|