path: root/static/netbsd/man4/ppbus.4 4.html

<table class="head">
  <tr>
    <td class="head-ltitle">PPBUS(4)</td>
    <td class="head-vol">Device Drivers Manual</td>
    <td class="head-rtitle">PPBUS(4)</td>
  </tr>
</table>
<div class="manual-text">
<section class="Sh">
<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1>
<p class="Pp"><code class="Nm">ppbus</code> &#x2014; <span class="Nd">Parallel
    Port Bus system with GPIO</span></p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp"><code class="Cd">ppbus* at atppc?</code>
  <br/>
  <code class="Cd">options PPBUS_VERBOSE</code>
  <br/>
  <code class="Cd">options PPBUS_DEBUG</code>
  <br/>
  <code class="Cd">options DEBUG_1284</code></p>
<p class="Pp">
  <br/>
  <code class="Cd">gpio* at ppbus?</code>
  <br/>
  <code class="Cd">lpt* at ppbus?</code>
  <br/>
  <code class="Cd">plip* at ppbus?</code>
  <br/>
  <code class="Cd">pps* at ppbus?</code></p>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp">The <code class="Nm">ppbus</code> 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.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="DEVICE_DRIVERS"><a class="permalink" href="#DEVICE_DRIVERS">DEVICE
  DRIVERS</a></h1>
<p class="Pp">In order to write new drivers or port existing drivers, the
    <code class="Nm">ppbus</code> system provides the following facilities:</p>
<ul class="Bl-bullet Bd-indent">
  <li>architecture-independent macros or functions to access parallel ports</li>
  <li>mechanism to allow various devices to share the same parallel port</li>
  <li>a <a class="Xr">gpio(4)</a> interface to access the individual pins</li>
  <li>a user interface named <a class="Xr">ppi(4)</a> that allows parallel port
      access from outside the kernel without conflicting with kernel-in
    drivers.</li>
</ul>
<section class="Ss">
<h2 class="Ss" id="Developing_new_drivers"><a class="permalink" href="#Developing_new_drivers">Developing
  new drivers</a></h2>
<p class="Pp">The <code class="Nm">ppbus</code> system has been designed to
    support the development of standard and non-standard software:</p>
<p class="Pp"></p>
<table class="Bl-column Bl-compact">
  <tr id="Driver">
    <td><a class="permalink" href="#Driver"><i class="Em">Driver</i></a></td>
    <td><a class="permalink" href="#Description"><i class="Em" id="Description">Description</i></a>
      It uses standard and non-standard parallel port accesses.</td>
  </tr>
  <tr id="ppi">
    <td><a class="permalink" href="#ppi"><b class="Sy">ppi</b></a></td>
    <td>Parallel port interface for general I/O</td>
  </tr>
  <tr id="pps">
    <td><a class="permalink" href="#pps"><b class="Sy">pps</b></a></td>
    <td>Pulse per second Timing Interface</td>
  </tr>
</table>
</section>
<section class="Ss">
<h2 class="Ss" id="Porting_existing_drivers"><a class="permalink" href="#Porting_existing_drivers">Porting
  existing drivers</a></h2>
<p class="Pp">Another approach to the <code class="Nm">ppbus</code> system is to
    port existing drivers. Various drivers have already been ported:</p>
<p class="Pp"></p>
<table class="Bl-column Bl-compact">
  <tr id="Driver~2">
    <td><a class="permalink" href="#Driver~2"><i class="Em">Driver</i></a></td>
    <td><a class="permalink" href="#Description~2"><i class="Em" id="Description~2">Description</i></a></td>
  </tr>
  <tr id="lpt">
    <td><a class="permalink" href="#lpt"><b class="Sy">lpt</b></a></td>
    <td>lpt printer driver</td>
  </tr>
  <tr id="lp">
    <td><a class="permalink" href="#lp"><b class="Sy">lp</b></a></td>
    <td>plip network interface driver</td>
  </tr>
</table>
<p class="Pp"><code class="Nm">ppbus</code> should let you port any other
    software even from other operating systems that provide similar
  services.</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="PARALLEL_PORT_CHIP_SETS"><a class="permalink" href="#PARALLEL_PORT_CHIP_SETS">PARALLEL
  PORT CHIP SETS</a></h1>
<p class="Pp">Parallel port chip set support is provided by
    <a class="Xr">atppc(4)</a>.</p>
<p class="Pp">The <code class="Nm">ppbus</code> system provides functions and
    macros to request service from the <code class="Nm">ppbus</code> including
    reads, writes, setting of parameters, and bus requests/releases.</p>
<p class="Pp"><a class="Xr">atppc(4)</a> detects chip set and capabilities and
    sets up interrupt handling. It makes methods available for use to the
    <code class="Nm">ppbus</code> system.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="PARALLEL_PORT_MODEL"><a class="permalink" href="#PARALLEL_PORT_MODEL">PARALLEL
  PORT MODEL</a></h1>
<p class="Pp">The logical parallel port model chosen for the
    <code class="Nm">ppbus</code> system is the AT parallel port model.
    Consequently, for the
    <a class="permalink" href="#atppc"><i class="Em" id="atppc">atppc</i></a>
    implementation of <code class="Nm">ppbus</code>, most of the services
    provided by <code class="Nm">ppbus</code> 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.</p>
<section class="Ss">
<h2 class="Ss" id="Description~3"><a class="permalink" href="#Description~3">Description</a></h2>
<p class="Pp">The parallel port may operate in the following modes:</p>
<ul class="Bl-bullet Bd-indent">
  <li>Compatible (Centronics -- the standard parallel port mode) mode, output
      byte</li>
  <li>Nibble mode, input 4-bits</li>
  <li>Byte (PS/2) mode, input byte</li>
  <li>Extended Capability Port (ECP) mode, bidirectional byte</li>
  <li>Enhanced Parallel Port (EPP) mode, bidirectional byte</li>
</ul>
</section>
<section class="Ss">
<h2 class="Ss" id="Compatible_mode"><a class="permalink" href="#Compatible_mode">Compatible
  mode</a></h2>
<p class="Pp">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.</p>
<p class="Pp">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 &#x201C;Fast Centronics&#x201D; or &#x201C;Parallel Port FIFO
    mode&#x201D;.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Nibble_mode"><a class="permalink" href="#Nibble_mode">Nibble
  mode</a></h2>
<p class="Pp">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.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Byte_mode"><a class="permalink" href="#Byte_mode">Byte
  mode</a></h2>
<p class="Pp">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.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Extended_Capability_Port_mode"><a class="permalink" href="#Extended_Capability_Port_mode">Extended
  Capability Port mode</a></h2>
<p class="Pp">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.</p>
<p class="Pp">ECP protocol features include:</p>
<ul class="Bl-item Bd-indent">
  <li>Run_Length_Encoding (RLE) data compression for host adapters (not
      supported in these drivers)</li>
  <li>FIFO's for both the forward and reverse channels</li>
  <li>DMA or programmed I/O for the host register interface.</li>
</ul>
</section>
<section class="Ss">
<h2 class="Ss" id="Enhanced_Parallel_Port_mode"><a class="permalink" href="#Enhanced_Parallel_Port_mode">Enhanced
  Parallel Port mode</a></h2>
<p class="Pp">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.</p>
<p class="Pp">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.</p>
<p class="Pp">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.</p>
<p class="Pp">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.</p>
<p class="Pp">At any time, the peripheral may interrupt the host with the nAck
    signal without disturbing the current transfer.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Mixed_modes"><a class="permalink" href="#Mixed_modes">Mixed
  modes</a></h2>
<p class="Pp">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.</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="IEEE_1284_1994_Standard"><a class="permalink" href="#IEEE_1284_1994_Standard">IEEE
  1284 1994 Standard</a></h1>
<section class="Ss">
<h2 class="Ss" id="Background"><a class="permalink" href="#Background">Background</a></h2>
<p class="Pp">This standard is also named &#x201C;IEEE Standard Signaling Method
    for a Bidirectional Parallel Peripheral Interface for Personal
    Computers&#x201D;. 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.</p>
<p class="Pp">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.</p>
<p class="Pp">The IEEE 1284 protocol is fully oriented with all supported
    parallel port modes. The computer acts as master and the peripheral as
    slave.</p>
<p class="Pp">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 &#x201C;as is&#x201D; 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.</p>
<p class="Pp">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.</p>
<p class="Pp">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.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Implementation"><a class="permalink" href="#Implementation">Implementation</a></h2>
<p class="Pp">IEEE 1284 Standard support has been implemented at the top of the
    <code class="Nm">ppbus</code> 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.</p>
<p class="Pp">IEEE 1284 interacts with the <code class="Nm">ppbus</code> system
    as little as possible. That means you still have to request the
    <code class="Nm">ppbus</code> when you want to access it, and of course,
    release it when finished.</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="ARCHITECTURE"><a class="permalink" href="#ARCHITECTURE">ARCHITECTURE</a></h1>
<section class="Ss">
<h2 class="Ss" id="Chip_set,_ppbus_and_device_layers"><a class="permalink" href="#Chip_set,_ppbus_and_device_layers">Chip
  set, ppbus and device layers</a></h2>
<p class="Pp">First, there is the
    <a class="permalink" href="#chip"><i class="Em" id="chip">chip set</i></a>
    layer, the lowest of the <code class="Nm">ppbus</code> system. It provides
    chip set abstraction through a set of low level functions that maps the
    logical model to the underlying hardware.</p>
<p class="Pp" id="ppbus">Secondly, there is the
    <a class="permalink" href="#ppbus"><i class="Em">ppbus</i></a> layer that
    provides functions to:</p>
<ol class="Bl-enum Bd-indent">
  <li>share the parallel port bus among the daisy-chain like connected
    devices</li>
  <li>manage devices linked to <code class="Nm">ppbus</code></li>
  <li>propose an arch-independent interface to access the hardware layer.</li>
</ol>
<p class="Pp" id="device">Finally, the
    <a class="permalink" href="#device"><i class="Em">device</i></a> layer
    represents the traditional device drivers such as <a class="Xr">lpt(4)</a>
    which now use an abstraction instead of real hardware.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Parallel_port_mode_management"><a class="permalink" href="#Parallel_port_mode_management">Parallel
  port mode management</a></h2>
<p class="Pp">Operating modes are differentiated at various
    <code class="Nm">ppbus</code> system layers. There is a difference between a
    <a class="permalink" href="#capability"><i class="Em" id="capability">capability</i></a>
    and a
    <a class="permalink" href="#mode"><i class="Em" id="mode">mode</i></a>. A
    chip set may have a combination of capabilities, but at any one time the
    <code class="Nm">ppbus</code> system operates in a single mode.</p>
<p class="Pp" id="virtual">Nibble mode is a
    <a class="permalink" href="#virtual"><i class="Em">virtual</i></a> 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.</p>
<p class="Pp">Each child device of <code class="Nm">ppbus</code> must set its
    operating mode and other parameters whenever it requests and gets access to
    its parent <code class="Nm">ppbus</code>.</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="FEATURES"><a class="permalink" href="#FEATURES">FEATURES</a></h1>
<section class="Ss">
<h2 class="Ss" id="The_boot_process"><a class="permalink" href="#The_boot_process">The
  boot process</a></h2>
<p class="Pp"><code class="Nm">ppbus</code> attachment tries to detect any PnP
    parallel peripheral (according to <span class="RsT">Plug and Play Parallel
    Port Devices draft from (c)1993-4</span> Microsoft Corporation) then probes
    and attaches known device drivers.</p>
<p class="Pp">During probe, device drivers should request the
    <code class="Nm">ppbus</code> and try to determine if the right capabilities
    are present in the system.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Bus_request_and_interrupts"><a class="permalink" href="#Bus_request_and_interrupts">Bus
  request and interrupts</a></h2>
<p class="Pp"><code class="Nm">ppbus</code> reservation via a bus request is
    mandatory not to corrupt I/O of other devices. For example, when the
    <a class="Xr">lpt(4)</a> device is opened, the bus will be
    &#x201C;allocated&#x201D; to the device driver and attempts to reserve the
    bus for another device will fail until the <a class="Xr">lpt(4)</a> driver
    releases the bus.</p>
<p class="Pp">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.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Micro-sequences"><a class="permalink" href="#Micro-sequences">Micro-sequences</a></h2>
<p class="Pp"><i class="Em">Micro-sequences</i> 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
    <code class="Nm">ppbus</code> layer for a sequence of operations and do most
    of the job at the chip set level.</p>
<p class="Pp">A micro-sequence is an array of opcodes and parameters. Each
    opcode codes an operation (opcodes are described in
    <a class="Xr">microseq(9)</a>). Standard I/O operations are implemented at
    ppbus level whereas basic I/O operations and microseq language are coded at
    adapter level for efficiency.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="GPIO_interface"><a class="permalink" href="#GPIO_interface">GPIO
  interface</a></h2>
<p class="Pp">Pins 1 through 17 of the parallel port can be controlled through
    the <a class="Xr">gpio(4)</a> 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 <a class="Xr">gpio(4)</a>
    interface starts at 0 when numbering pins.</p>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
  ALSO</a></h1>
<p class="Pp"><a class="Xr">atppc(4)</a>, <a class="Xr">gpio(4)</a>,
    <a class="Xr">lpt(4)</a>, <a class="Xr">plip(4)</a>,
    <a class="Xr">ppi(4)</a>, <a class="Xr">microseq(9)</a></p>
</section>
<section class="Sh">
<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1>
<p class="Pp">The <code class="Nm">ppbus</code> system first appeared in
    <span class="Ux">FreeBSD 3.0</span>.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1>
<p class="Pp">This manual page is based on the <span class="Ux">FreeBSD</span>
    <code class="Nm">ppbus</code> manual page. The information has been updated
    for the <span class="Ux">NetBSD</span> port by Gary Thorpe.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="BUGS"><a class="permalink" href="#BUGS">BUGS</a></h1>
<p class="Pp">The <code class="Nm">ppbus</code> framework is still experimental
    and not enabled by default yet.</p>
</section>
</div>
<table class="foot">
  <tr>
    <td class="foot-date">August 19, 2009</td>
    <td class="foot-os">NetBSD 10.1</td>
  </tr>
</table>