diff options
Diffstat (limited to 'static/freebsd/man4/ppbus.4 3.html')
| -rw-r--r-- | static/freebsd/man4/ppbus.4 3.html | 355 |
1 files changed, 0 insertions, 355 deletions
diff --git a/static/freebsd/man4/ppbus.4 3.html b/static/freebsd/man4/ppbus.4 3.html deleted file mode 100644 index bdc642ad..00000000 --- a/static/freebsd/man4/ppbus.4 3.html +++ /dev/null @@ -1,355 +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> — <span class="Nd">Parallel - Port Bus system</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">device ppbus</code></p> -<p class="Pp"> - <br/> - <code class="Cd">device lpt</code> - <br/> - <code class="Cd">device plip</code> - <br/> - <code class="Cd">device ppi</code> - <br/> - <code class="Cd">device pps</code> - <br/> - <code class="Cd">device lpbb</code></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> -<p class="Pp">The <i class="Em">ppbus</i> 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.</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 ppbus - 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 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 ppbus 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></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> - <tr id="lpbb"> - <td><a class="permalink" href="#lpbb"><b class="Sy">lpbb</b></a></td> - <td>Philips official parallel port I2C bit-banging 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 ppbus 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="plip"> - <td><a class="permalink" href="#plip"><b class="Sy">plip</b></a></td> - <td>lp parallel network interface driver</td> - </tr> -</table> -<p class="Pp">ppbus 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_CHIPSETS"><a class="permalink" href="#PARALLEL_PORT_CHIPSETS">PARALLEL - PORT CHIPSETS</a></h1> -<p class="Pp">Parallel port chipset support is provided by - <a class="Xr">ppc(4)</a>.</p> -<p class="Pp">The ppbus system provides functions and macros to allocate a new - parallel port bus, then initialize it and upper peripheral device - drivers.</p> -<p class="Pp">ppc makes chipset detection and initialization and then calls - ppbus attach functions to initialize the ppbus 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 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 another architecture, accesses to one of our logical - registers (data, status, control...) may require more than one I/O - access.</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 mode, also called Centronics mode</li> - <li>bidirectional 8/4-bits mode, also called NIBBLE mode</li> - <li>byte mode, also called PS/2 mode</li> - <li>Extended Capability Port mode, ECP</li> - <li>Enhanced Parallel Port mode, EPP</li> - <li>mixed ECP+EPP or ECP+PS/2 modes</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 "Fast Centronics" or "Parallel Port FIFO - mode".</p> -</section> -<section class="Ss"> -<h2 class="Ss" id="Bidirectional_mode"><a class="permalink" href="#Bidirectional_mode">Bidirectional - mode</a></h2> -<p class="Pp">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.</p> -<p class="Pp">In this mode, outputs are 8-bits long. 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. Then, any transfer is 8-bits long.</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</li> - <li>FIFOs for both the forward and reverse channels</li> - <li>DMA as well as 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 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.</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 chipsets that - support mixed modes. With such chipsets, mode switching is available at any - time by accessing the extended control register.</p> -</section> -</section> -<section class="Sh"> -<h1 class="Sh" id="IEEE1284-1994_Standard"><a class="permalink" href="#IEEE1284-1994_Standard">IEEE1284-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 "IEEE Standard Signaling Method - for a Bidirectional Parallel Peripheral Interface for Personal - Computers". 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 - outside of the bidirectional data stream.</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 IEEE1284 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 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 forward idle states.</p> -<p class="Pp">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.</p> -<p class="Pp">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.</p> -</section> -<section class="Ss"> -<h2 class="Ss" id="Implementation"><a class="permalink" href="#Implementation">Implementation</a></h2> -<p class="Pp">IEEE1284 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.</p> -<p class="Pp">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 - later.</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="adapter,_ppbus_and_device_layers"><a class="permalink" href="#adapter,_ppbus_and_device_layers">adapter, - ppbus and device layers</a></h2> -<p class="Pp">First, there is the - <a class="permalink" href="#adapter"><i class="Em" id="adapter">adapter</i></a> - 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.</p> -<p class="Pp">Secondly, there is the <i class="Em">ppbus</i> 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 ppbus</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 - gathers the parallel peripheral device drivers.</p> -</section> -<section class="Ss"> -<h2 class="Ss" id="Parallel_modes_management"><a class="permalink" href="#Parallel_modes_management">Parallel - modes management</a></h2> -<p class="Pp">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.</p> -<p class="Pp">With this level of abstraction a particular chipset may commute - from any native mode to any other mode emulated with extended modes without - disturbing upper layers. For example, most chipsets support NIBBLE mode as - native and emulated with ECP and/or EPP.</p> -<p class="Pp">This architecture should support IEEE1284-1994 modes.</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">The boot process starts with the probe stage of the - <a class="Xr">ppc(4)</a> 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.</p> -<p class="Pp">ppbus attachment tries to detect any PnP parallel peripheral - (according to <span class="RsT">Plug and Play Parallel Port Devices</span> - draft from (c)1993-4 Microsoft Corporation) then probes and attaches known - device drivers.</p> -<p class="Pp">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 - structure and returned each time the driver requests the ppbus.</p> -</section> -<section class="Ss"> -<h2 class="Ss" id="Bus_allocation_and_interrupts"><a class="permalink" href="#Bus_allocation_and_interrupts">Bus - allocation and interrupts</a></h2> -<p class="Pp">ppbus allocation is mandatory not to corrupt I/O of other devices. - Another usage of ppbus allocation is to reserve the port and receive - incoming interrupts.</p> -<p class="Pp" id="BUS_SETUP_INTR">High level interrupt handlers are connected to - the ppbus system thanks to the newbus - <a class="permalink" href="#BUS_SETUP_INTR"><code class="Fn">BUS_SETUP_INTR</code></a>() - and - <a class="permalink" href="#BUS_TEARDOWN_INTR"><code class="Fn" id="BUS_TEARDOWN_INTR">BUS_TEARDOWN_INTR</code></a>() - functions. But, in order to attach a handler, drivers must own the bus. - Consequently, a ppbus request is mandatory in order to call the above - functions (see existing drivers for more info). Note that the interrupt - handler is automatically released when the ppbus is released.</p> -</section> -<section class="Ss"> -<h2 class="Ss" id="Microsequences"><a class="permalink" href="#Microsequences">Microsequences</a></h2> -<p class="Pp"><i class="Em">Microsequences</i> is a general purpose mechanism to - allow fast low-level manipulation 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.</p> -<p class="Pp">A microsequence 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> -<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">lpt(4)</a>, <a class="Xr">plip(4)</a>, - <a class="Xr">ppc(4)</a>, <a class="Xr">ppi(4)</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> manual page 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 was written by <span class="An">Nicolas - Souchu</span>.</p> -</section> -</div> -<table class="foot"> - <tr> - <td class="foot-date">March 1, 1998</td> - <td class="foot-os">FreeBSD 15.0</td> - </tr> -</table> |