diff options
Diffstat (limited to 'static/netbsd/man4/ppbus.4 4.html')
| -rw-r--r-- | static/netbsd/man4/ppbus.4 4.html | 384 |
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> — <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 “Fast Centronics” or “Parallel Port FIFO - mode”.</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 “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.</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 “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.</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 - “allocated” 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> |