docs: Removed Precompiled HTML

1 files changed, 0 insertions, 384 deletions

diff --git a/static/netbsd/man4/ppbus.4 4.html b/static/netbsd/man4/ppbus.4 4.html
deleted file mode 100644
index 310b7517..00000000
--- a/static/netbsd/man4/ppbus.4 4.html
+++ /dev/null
@@ -1,384 +0,0 @@
-<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>