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, 355 insertions, 0 deletions
diff --git a/static/freebsd/man4/ppbus.4 3.html b/static/freebsd/man4/ppbus.4 3.html new file mode 100644 index 00000000..bdc642ad --- /dev/null +++ b/static/freebsd/man4/ppbus.4 3.html @@ -0,0 +1,355 @@ +<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> |