FreeBSD Man Pages

ppbus(4)

NAME

     ppbus -- Parallel Port Bus system

SYNOPSIS

     device ppbus

     device vpo

     device lpt
     device plip
     device ppi
     device pps
     device lpbb

DESCRIPTION

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

DEVICE DRIVERS

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

	   o   architecture-independent macros or functions to access parallel
	       ports

	   o   mechanism to allow various devices to share the same parallel
	       port

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

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

     Driver    Description
     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

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

     Driver    Description
     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.

PARALLEL PORT CHIPSETS

     Parallel port chipset support is provided by ppc(4).
     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.

   Description
     The parallel port may operate in the following modes:

	   o   compatible mode, also called Centronics mode

	   o   bidirectional 8/4-bits mode, also called NIBBLE mode

	   o   byte mode, also called PS/2 mode

	   o   Extended Capability Port mode, ECP

	   o   Enhanced Parallel Port mode, EPP

	   o   mixed ECP+EPP or ECP+PS/2 modes

   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.

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

   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.

     In this mode, outputs are 8-bits long.  Inputs are accomplished by read-
     ing 4 of the 8 bits of the status register.

   Byte mode
     In this mode, the data register is used either for outputs and inputs.
     Then, any transfer is 8-bits long.

   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

	   FIFOs for both the forward and reverse channels

	   DMA as well as programmed I/O for the host register interface.
     lines.  Data are strobed with nAutofeed, addresses are strobed with nSe-
     lectin 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 peripher-
     als 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.

   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.

IEEE1284-1994 Standard

   Background
     This standard is also named "IEEE Standard Signaling Method for a Bidi-
     rectional Parallel Peripheral Interface for Personal Computers".  It
     defines a signaling method for asynchronous, fully interlocked, bidirec-
     tional 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.

     This standard is architecture independent and only specifies dialog hand-
     shake at signal level.  One should refer to architecture specific docu-
     mentation in order to manipulate machine dependent registers, mapped mem-
     ory 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 for-
     ward 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
     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 doesn't do it for you.	And of course, release it
     later.

ARCHITECTURE

   adapter, ppbus and device layers
     First, there is the 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.

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

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

	   2.	manage devices linked to ppbus

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

     Finally, the device layer gathers the parallel peripheral device drivers.

   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.

     With this level of abstraction a particular chipset may commute from any
     native mode the any other mode emulated with extended modes without dis-
     turbing 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.

FEATURES

   The boot process
     The boot process starts with the probe stage of the 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.

     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 struc-
     ture and returned each time the driver requests the ppbus.

   Bus allocation and interrupts
     ppbus allocation is mandatory not to corrupt I/O of other devices.  An
     other usage of ppbus allocation is to reserve the port and receive incom-
     ing interrupts.

     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
     losophy of microsequences is to avoid the overhead of the ppbus layer and
     do most of the job at adapter level.

     A microsequence is an array of opcodes and parameters.  Each opcode codes
     an operation (opcodes are described in microseq(9)).  Standard I/O opera-
     tions 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:

	   o   a modified version of the NIBBLE transfer mode

	   o   various I/O sequences to initialize, select and allocate the
	       peripheral

SEE ALSO

     lpt(4), plip(4), ppc(4), ppi(4), vpo(4)

HISTORY

     The ppbus manual page first appeared in FreeBSD 3.0.

AUTHORS

     This manual page was written by Nicolas Souchu.

FreeBSD 5.4			 March 1, 1998			   FreeBSD 5.4

SPONSORED LINKS