Updated: 2021/Apr/14

PPBUS(4)                     Device Drivers Manual                    PPBUS(4)

     ppbus - Parallel Port Bus system with GPIO

     ppbus* at atppc?
     options PPBUS_VERBOSE
     options PPBUS_DEBUG
     options DEBUG_1284

     gpio* at ppbus?
     lpt* at ppbus?
     plip* at ppbus?
     pps* at ppbus?

     The ppbus system provides a uniform, modular, and architecture-
     independent system for the implementation of drivers to control various
     parallel devices, and to use different parallel port chip sets.

     In order to write new drivers or port existing drivers, the ppbus system
     provides the following facilities:

              architecture-independent macros or functions to access parallel

              mechanism to allow various devices to share the same parallel

              a gpio(4) interface to access the individual pins

              a user interface named ppi(4) that allows parallel port access
               from outside the kernel without conflicting with kernel-in

   Developing new drivers
     The ppbus system has been designed to support the development of standard
     and non-standard software:

     Driver    Description It uses standard and non-standard parallel port
     ppi       Parallel port interface for general I/O
     pps       Pulse per second Timing Interface

   Porting existing drivers
     Another approach to the ppbus system is to port existing drivers.
     Various drivers have already been ported:

     Driver    Description
     lpt       lpt printer driver
     lp        plip network interface driver

     ppbus should let you port any other software even from other operating
     systems that provide similar services.

     Parallel port chip set support is provided by atppc(4).

     The ppbus system provides functions and macros to request service from
     the ppbus including reads, writes, setting of parameters, and bus

     atppc(4) detects chip set and capabilities and sets up interrupt
     handling.  It makes methods available for use to the ppbus system.

     The logical parallel port model chosen for the ppbus system is the AT
     parallel port model.  Consequently, for the atppc implementation of
     ppbus, most of the services provided by ppbus will translate into I/O
     instructions on actual registers.  However, other parallel port
     implementations may require more than one I/O instruction to do a single
     logical register operation on data, status and control virtual registers.

     The parallel port may operate in the following modes:

              Compatible (Centronics -- the standard parallel port mode)
               mode, output byte

              Nibble mode, input 4-bits

              Byte (PS/2) mode, input byte

              Extended Capability Port (ECP) mode, bidirectional byte

              Enhanced Parallel Port (EPP) mode, bidirectional byte

   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

     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".

   Nibble mode
     The Nibble mode is the most common way to get reverse channel data from a
     printer or peripheral.  When combined with the standard host to printer
     mode, a bidirectional data channel is created.  Inputs are accomplished
     by reading 4 of the 8 bits of the status register.

   Byte mode
     In this mode, the data register is used either for outputs and inputs.
     All transfers are 8-bits long.  Channel direction must be negotiated when
     doing IEEE 1248 compliant operations.

   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.

     ECP protocol features include:

           Run_Length_Encoding (RLE) data compression for host adapters (not
           supported in these drivers)

           FIFO's for both the forward and reverse channels

           DMA or programmed I/O for the host register interface.

   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.

     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 IEEE 1284 compatible
     part.  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.

   Mixed modes
     Some manufacturers, like SMC, have implemented chip sets that support
     mixed modes.  With such chip sets, mode switching is available at any
     time by accessing the extended control register.  All ECP-capable chip
     sets can switch between standard, byte, fast centronics, and ECP modes.
     Some ECP chip sets also support switching to EPP mode.

IEEE 1284 1994 Standard
     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.

     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 IEEE 1284 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 automate.  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 the default, backward-compatible transfer mode.  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.  The host must
     negotiate to permit the peripheral to complete the transfer.  Interrupt
     lines may be dedicated to the requesting signals to prevent time
     consuming polling methods.

     If the host accepts the transfer, it must firstly negotiate the reverse
     mode and then start 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.

     IEEE 1284 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.

     IEEE 1284 interacts with the ppbus system as little as possible.  That
     means you still have to request the ppbus when you want to access it, and
     of course, release it when finished.

   Chip set, ppbus and device layers
     First, there is the chip set layer, the lowest of the ppbus system.  It
     provides chip set abstraction through a set of low level functions that
     maps the logical model to the underlying hardware.

     Secondly, there is the ppbus layer that provides functions to:

           1.   share the parallel port bus among the daisy-chain like
                connected devices

           2.   manage devices linked to ppbus

           3.   propose an arch-independent interface to access the hardware

     Finally, the device layer represents the traditional device drivers such
     as lpt(4) which now use an abstraction instead of real hardware.

   Parallel port mode management
     Operating modes are differentiated at various ppbus system layers.  There
     is a difference between a capability and a mode.  A chip set may have a
     combination of capabilities, but at any one time the ppbus system
     operates in a single mode.

     Nibble mode is a virtual mode: the actual chip set would be in standard
     mode and the driver would change its behavior to drive the right lines on
     the parallel port.

     Each child device of ppbus must set its operating mode and other
     parameters whenever it requests and gets access to its parent ppbus.

   The boot process
     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 should request the ppbus and try to
     determine if the right capabilities are present in the system.

   Bus request and interrupts
     ppbus reservation via a bus request is mandatory not to corrupt I/O of
     other devices.  For example, when the lpt(4) device is opened, the bus
     will be "allocated" to the device driver and attempts to reserve the bus
     for another device will fail until the lpt(4) driver releases the bus.

     Child devices can also register interrupt handlers to be called when a
     hardware interrupt occurs.  In order to attach a handler, drivers must
     own the bus.  Drivers should have interrupt handlers that check to see if
     the device still owns the bus when they are called and/or ensure that
     these handlers are removed whenever the device does not own the bus.

     Micro-sequences are a general purpose mechanism to allow fast low-level
     manipulation of the parallel port.  Micro-sequences may be used to do
     either standard (in IEEE 1284 modes) or non-standard transfers.  The
     philosophy of micro-sequences is to avoid the overhead of the ppbus layer
     for a sequence of operations and do most of the job at the chip set

     A micro-sequence 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.

   GPIO interface
     Pins 1 through 17 of the parallel port can be controlled through the
     gpio(4) interface, pins 18 through 25 are hardwired to ground.  Pins 10
     through 13 and pin 15 are input pins, the others are output pins.  Some
     of the pins are inverted by the hardware, the values read or written are
     adjusted accordingly.  Note that the gpio(4) interface starts at 0 when
     numbering pins.

     atppc(4), gpio(4), lpt(4), plip(4), ppi(4), microseq(9)

     The ppbus system first appeared in FreeBSD 3.0.

     This manual page is based on the FreeBSD ppbus manual page.  The
     information has been updated for the NetBSD port by Gary Thorpe.

     The ppbus framework is still experimental and not enabled by default yet.

NetBSD 9.99                     August 19, 2009                    NetBSD 9.99