Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
PPBUS(4)		 BSD Kernel Interfaces Manual		      PPBUS(4)

     ppbus -- Parallel Port Bus	system

     device ppbus

     device vpo

     device lpt
     device plip
     device ppi
     device pps
     device lpbb

     The ppbus system provides a uniform, modular and architecture-independent
     system for	the implementation of drivers to control various parallel de-
     vices, and	to utilize different parallel port chipsets.

     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

	   o   mechanism to allow various devices to share the same parallel

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

     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 at-
     tach functions to initialize the ppbus system.

     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	ac-

     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

     Many I/O controllers have implemented a mode that uses a FIFO buffer to
     transfer data with	the Compatibility mode protocol.  This mode is re-
     ferred 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.

   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 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
     This standard is also named "IEEE Standard	Signaling Method for a Bidi-
     rectional Parallel	Peripheral Interface for Personal Computers".  It de-
     fines a signaling method for asynchronous,	fully interlocked, bidirec-
     tional parallel communications between hosts and printers or other	pe-
     ripherals.	 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
     more data is available.

     IEEE1284 Standard support has been	implemented at the top of the ppbus
     system as a set of	procedures that	perform	high level functions like ne-
     gotiation,	termination, transfer in any mode without bothering you	with
     low level characteristics of the standard.

     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

   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

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

   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 pp-
     bus request is mandatory in order to call the above functions (see	exist-
     ing drivers for more info).  Note that the	interrupt handler is automati-
     cally released when the ppbus is released.

     Microsequences is a general purpose mechanism to allow fast low-level ma-
     nipulation	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.

     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 mi-
     croseq 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

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

     The ppbus manual page first appeared in FreeBSD 3.0.

     This manual page was written by Nicolas Souchu.

BSD				 March 1, 1998				   BSD


Want to link to this manual page? Use this URL:

home | help