share/man/man4/ppbus.4

   1 .\" Copyright (c) 1998, 1999 Nicolas Souchu
   2 .\" All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\"
  13 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
  14 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  15 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  16 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  17 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  18 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  19 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  20 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  21 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  22 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  23 .\" SUCH DAMAGE.
  24 .\"
  25 .\" $FreeBSD$
  26 .\"
  27 .Dd March 1, 1998
  28 .Dt PPBUS 4
  29 .Os FreeBSD
  30 .Sh NAME
  31 .Nm ppbus
  32 .Nd
  33 Parallel port bus system
  34 .Sh SYNOPSIS
  35 .Cd "controller ppbus0"
  36 .Pp
  37 .Cd "controller vpo0 at ppbus?"
  38 .Pp
  39 .Cd "device nlpt0 at ppbus?"
  40 .Cd "device plip0 at ppbus?"
  41 .Cd "device ppi0 at ppbus?"
  42 .Cd "device pps0 at ppbus?"
  43 .Cd "device lpbb0 at ppbus?"
  44 .Sh DESCRIPTION
  45 The
  46 .Em ppbus
  47 system provides a uniform, modular and architecture-independent
  48 system for the implementation of drivers to control various parallel devices,
  49 and to utilize different parallel port chipsets.
  50 .Sh DEVICE DRIVERS
  51 In order to write new drivers or port existing drivers, the ppbus system
  52 provides the following facilities:
  53 .Bl -bullet -item -offset indent
  54 .It
  55 architecture-independent macros or functions to access parallel ports
  56 .It
  57 mechanism to allow various devices to share the same parallel port
  58 .It
  59 a user interface named
  60 .Xr ppi 4
  61 that allows parallel port access from outside the kernel without conflicting
  62 with kernel-in drivers.
  63 .El
  64 .Ss Developing new drivers
  65 .Pp
  66 The ppbus system has been designed to support the development of standard
  67 and non-standard software:
  68 .Pp
  69 .Bl -column "Driver" -compact
  70 .It Em Driver Ta Em Description
  71 .It Sy vpo Ta "VPI0 parallel to Adaptec AIC-7110 SCSI controller driver."
  72 It uses standard and non-standard parallel port accesses.
  73 .It Sy ppi Ta "Parallel port interface for general I/O"
  74 .It Sy pps Ta "Pulse per second Timing Interface"
  75 .It Sy lpbb Ta "Philips official parallel port I2C bit-banging interface"
  76 .El
  77 .Ss Porting existing drivers
  78 .Pp
  79 Another approach to the ppbus system is to port existing drivers.
  80 Various drivers have already been ported:
  81 .Pp
  82 .Bl -column "Driver" -compact
  83 .It Em Driver Ta Em Description
  84 .It Sy nlpt Ta "lpt printer driver"
  85 .It Sy plip Ta "lp parallel network interface driver"
  86 .El
  87 .Pp
  88 ppbus should let you port any other software even from other operating systems
  89 that provide similar services.
  90 .Sh PARALLEL PORT CHIPSETS
  91 Parallel port chipset support is provided by
  92 .Xr ppc 4 .
  93 .Pp
  94 The ppbus system provides functions and macros to allocate a new
  95 parallel port bus, then initialize it and upper peripheral device drivers.
  96 .Pp
  97 ppc makes chipset detection and initialization and then calls ppbus attach
  98 functions to initialize the ppbus system.
  99 .Sh PARALLEL PORT MODEL
 100 The logical parallel port model chosen for the ppbus system is the PC's
 101 parallel port model. Consequently, for the i386 implementation of ppbus,
 102 most of the services provided by ppc are macros for inb()
 103 and outb() calls. But, for an other architecture, accesses to one of our logical
 104 registers (data, status, control...) may require more than one I/O access.
 105 .Ss Description
 106 The parallel port may operate in the following modes:
 107 .Bl -bullet -item -offset indent
 108 .It
 109 compatible mode, also called Centronics mode
 110 .It
 111 bidirectional 8/4-bits mode, also called NIBBLE mode
 112 .It
 113 byte mode, also called PS/2 mode
 114 .It
 115 Extended Capability Port mode, ECP
 116 .It
 117 Enhanced Parallel Port mode, EPP
 118 .It
 119 mixed ECP+EPP or ECP+PS/2 modes
 120 .El
 121 .Ss Compatible mode
 122 This mode defines the protocol used by most PCs to transfer data to a printer.
 123 In this mode, data is placed on the port's data lines, the printer status is
 124 checked for no errors and that it is not busy, and then a data Strobe is
 125 generated by the software to clock the data to the printer.
 126 .Pp
 127 Many I/O controllers have implemented a mode that uses a FIFO buffer to
 128 transfer data with the Compatibility mode protocol. This mode is referred to as
 129 "Fast Centronics" or "Parallel Port FIFO mode".
 130 .Ss Bidirectional mode
 131 The NIBBLE mode is the most common way to get reverse channel data from a
 132 printer or peripheral. Combined with the standard host to printer mode, it
 133 provides a complete bidirectional channel.
 134 .Pp
 135 In this mode, outputs are 8-bits long. Inputs are accomplished by reading
 136 4 of the 8 bits of the status register.
 137 .Ss Byte mode
 138 In this mode, the data register is used either for outputs and inputs. Then,
 139 any transfer is 8-bits long.
 140 .Ss Extended Capability Port mode
 141 The ECP protocol was proposed as an advanced mode for communication with
 142 printer and scanner type peripherals. Like the EPP protocol, ECP mode provides
 143 for a high performance bidirectional communication path between the host
 144 adapter and the peripheral.
 145 .Pp
 146 ECP protocol features include:
 147 .Bl -item -offset indent
 148 .It
 149 Run_Length_Encoding (RLE) data compression for host adapters
 150 .It
 151 FIFOs for both the forward and reverse channels
 152 .It
 153 DMA as well as programmed I/O for the host register interface.
 154 .El
 155 .Ss Enhanced Parallel Port mode
 156 The EPP protocol was originally developed as a means to provide a high
 157 performance parallel port link that would still be compatible with the
 158 standard parallel port.
 159 .Pp
 160 The EPP mode has two types of cycle: address and data. What makes the
 161 difference at hardware level is the strobe of the byte placed on the data
 162 lines. Data are strobed with nAutofeed, addresses are strobed with
 163 nSelectin signals.
 164 .Pp
 165 A particularity of the ISA implementation of the EPP protocol is that an
 166 EPP cycle fits in an ISA cycle. In this fashion, parallel port peripherals can
 167 operate at close to the same performance levels as an equivalent ISA plug-in
 168 card.
 169 .Pp
 170 At software level, you may implement the protocol you wish, using data and
 171 address cycles as you want. This is for the IEEE1284 compatible part. Then,
 172 peripheral vendors may implement protocol handshake with the following
 173 status lines: PError, nFault and Select. Try to know how these lines toggle
 174 with your peripheral, allowing the peripheral to request more data, stop the
 175 transfer and so on.
 176 .Pp
 177 At any time, the peripheral may interrupt the host with the nAck signal without
 178 disturbing the current transfer.
 179 .Ss Mixed modes
 180 Some manufacturers, like SMC, have implemented chipsets that support mixed
 181 modes. With such chipsets, mode switching is available at any time by
 182 accessing the extended control register.
 183 .Sh IEEE1284-1994 Standard
 184 .Ss Background
 185 This standard is also named "IEEE Standard Signaling Method for a
 186 Bidirectional Parallel Peripheral Interface for Personal Computers". It
 187 defines a signaling method for asynchronous, fully interlocked, bidirectional
 188 parallel communications between hosts and printers or other peripherals. It
 189 also specifies a format for a peripheral identification string and a method of
 190 returning this string to the host outside of the bidirectional data stream.
 191 .Pp
 192 This standard is architecture independent and only specifies dialog handshake
 193 at signal level. One should refer to architecture specific documentation in
 194 order to manipulate machine dependent registers, mapped memory or other
 195 methods to control these signals.
 196 .Pp
 197 The IEEE1284 protocol is fully oriented with all supported parallel port
 198 modes. The computer acts as master and the peripheral as slave.
 199 .Pp
 200 Any transfer is defined as a finite state automate. It allows software to
 201 properly manage the fully interlocked scheme of the signaling method.
 202 The compatible mode is supported "as is" without any negotiation because it
 203 is compatible. Any other mode must be firstly negotiated by the host to check
 204 it is supported by the peripheral, then to enter one of the forward idle
 205 states.
 206 .Pp
 207 At any time, the slave may want to send data to the host. This is only
 208 possible from forward idle states (nibble, byte, ecp...). So, the
 209 host must have previously negotiated to permit the peripheral to
 210 request transfer. Interrupt lines may be dedicated to the requesting signals
 211 to prevent time consuming polling methods.
 212 .Pp
 213 But peripheral requests are only a hint to the master host. If the host
 214 accepts the transfer, it must firstly negotiate the reverse mode and then
 215 starts the transfer. At any time during reverse transfer, the host may
 216 terminate the transfer or the slave may drive wires to signal that no more
 217 data is available.
 218 .Ss Implementation
 219 IEEE1284 Standard support has been implemented at the top of the ppbus system
 220 as a set of procedures that perform high level functions like negotiation,
 221 termination, transfer in any mode without bothering you with low level
 222 characteristics of the standard.
 223 .Pp
 224 IEEE1284 interacts with the ppbus system as least as possible. That means
 225 you still have to request the ppbus when you want to access it, the negotiate
 226 function doesn't do it for you. And of course, release it later.
 227 .Sh ARCHITECTURE
 228 .Ss adapter, ppbus and device layers
 229 First, there is the
 230 .Em adapter
 231 layer, the lowest of the ppbus system. It provides
 232 chipset abstraction throw a set of low level functions that maps the logical
 233 model to the underlying hardware.
 234 .Pp
 235 Secondly, there is the
 236 .Em ppbus
 237 layer that provides functions to:
 238 .Bl -enum -offset indent
 239 .It
 240 share the parallel port bus among the daisy-chain like connected devices
 241 .It
 242 manage devices linked to ppbus
 243 .It
 244 propose an arch-independent interface to access the hardware layer.
 245 .El
 246 .Pp
 247 Finally, the
 248 .Em device
 249 layer gathers the parallel peripheral device drivers.
 250 .Pp
 251 Each layer has its own C structure respectively ppb_adapter, ppb_data and
 252 ppb_device. The ppb_link structure gathers pointers to other structures and
 253 info shared among different layers.
 254 .Pp
 255 See description of these structures in
 256 .Xr ppbconf 9 .
 257 .Ss Parallel modes management
 258 We have to differentiate operating modes at various ppbus system layers.
 259 Actually, ppbus and adapter operating modes on one hands and for each
 260 one, current and available modes are separated.
 261 .Pp
 262 With this level of abstraction a particular chipset may commute from any
 263 native mode the any other mode emulated with extended modes without
 264 disturbing upper layers. For example, most chipsets support NIBBLE mode as
 265 native and emulated with ECP and/or EPP.
 266 .Pp
 267 This architecture should support IEEE1284-1994 modes.
 268 .Sh FEATURES
 269 .Ss The boot process
 270 The boot process starts with the probe phasis of the
 271 .Xr ppc 4
 272 driver during ISA bus (PC architecture) initialization. During attachment of
 273 the ppc driver, a new ppbus structure is allocated, initialized
 274 (linked to the adapter structure) then passed to the function
 275 .Fn ppb_attachdevs "struct ppb_data *ppb" .
 276 .Pp
 277 .Fn ppb_attachdevs ""
 278 tries to detect any PnP parallel peripheral (according to
 279 .%T "Plug and Play Parallel Port Devices"
 280 draft from (c)1993-4 Microsoft Corporation)
 281 then probes and attaches known device drivers.
 282 .Pp
 283 During probe, device drivers are supposed to request the ppbus and try to
 284 set their operating mode. This mode will be saved in the context structure and
 285 returned each time the driver requests the ppbus.
 286 .Ss Bus allocation and interrupts
 287 ppbus allocation is mandatory not to corrupt I/O of other devices. An other
 288 usage of ppbus allocation is to reserve the port and receive incoming
 289 interrupts.
 290 .Pp
 291 Interrupts are connected to the
 292 .Fn ppcintr ""
 293 function which delivers them to ppbus directly with a
 294 .Fn ppb_intr "struct ppb_link *pl"
 295 call. ppbus redirects the
 296 interrupt to the bus owner's handler if defined. Consequently, if a device
 297 wants to be delivered an interrupt, it must own the ppbus.
 298 .Ss Microsequences
 299 .Em Microsequences
 300 is a general purpose mechanism to allow fast low-level
 301 manipulation of the parallel port. Microsequences may be used to do either
 302 standard (in IEEE1284 modes) or non-standard transfers. The philosophy of
 303 microsequences is to avoid the overhead of the ppbus layer and do most of
 304 the job at adapter level.
 305 .Pp
 306 A microsequence is an array of opcodes and parameters. Each opcode codes an
 307 operation (opcodes are described in
 308 .Xr microseq 9 ).
 309 Standard I/O operations are implemented at ppbus level whereas basic I/O
 310 operations and microseq language are coded at adapter level for efficiency.
 311 .Pp
 312 As an example, the
 313 .Xr vpo 4
 314 driver uses microsequences to implement:
 315 .Bl -bullet -offset indent
 316 .It
 317 a modified version of the NIBBLE transfer mode
 318 .It
 319 various I/O sequences to initialize, select and allocate the peripheral
 320 .El
 321 .Sh SEE ALSO
 322 .Xr nlpt 4 ,
 323 .Xr plip 4 ,
 324 .Xr ppc 4 ,
 325 .Xr ppi 4 ,
 326 .Xr vpo 4 ,
 327 .Xr ppbconf 9
 328 .Sh HISTORY
 329 The
 330 .Nm
 331 manual page first appeared in
 332 .Fx 3.0 .
 333 .Sh AUTHORS
 334 This
 335 manual page was written by
 336 .An Nicolas Souchu .