Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

NetBSD 6.1.5 - man page for ppbus (netbsd section 4)

PPBUS(4)			   BSD Kernel Interfaces 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 fol-
     lowing 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 gpio(4) interface to access the individual pins

	   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

     Driver    Description It uses standard and non-standard parallel port accesses.
     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 requests/releases.

     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:

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

	   o   Nibble mode, input 4-bits

	   o   Byte (PS/2) mode, input byte

	   o   Extended Capability Port (ECP) mode, bidirectional byte

	   o   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 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''.

   Nibble mode
     The Nibble mode is the most common way to get reverse channel data from a printer or periph-
     eral.  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 opera-

   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 bidirec-
     tional 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

	   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 hard-
     ware level is the strobe of the byte placed on the data lines.  Data are strobed with nAut-
     ofeed, 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 pro-
     tocol 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 asynchro-
     nous, 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 com-
     puter 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 underly-
     ing 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 layer.

     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 inter-
     rupt 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 level.

     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

   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 number-
     ing 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.

BSD					 August 19, 2009				      BSD

All times are GMT -4. The time now is 08:23 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password