Drop trailing whitespace.

This commit is contained in:
wiz 2004-01-23 15:33:13 +00:00
parent b7b8fd2efe
commit 9fa543d057
6 changed files with 133 additions and 133 deletions

View File

@ -1,9 +1,9 @@
.\" $NetBSD: atppc.4,v 1.1.1.1 2004/01/19 23:22:23 jdolecek Exp $
.\" $NetBSD: atppc.4,v 1.2 2004/01/23 15:33:13 wiz Exp $
.\"
.\" Copyright (C) Gary Thorpe 2003
.\" Copyright (C) Gary Thorpe 2003
.\" All rights reserved.
.\"
.Dd December 24, 2003
.Dd December 24, 2003
.Dt ATPPC 4
.Os
.Sh NAME
@ -14,48 +14,48 @@
.Cd options ATPPC_VERBOSE
.Cd options ATPPC_DEBUG
.Sh DESCRIPTION
.Nm
supports parallel ports and provides the low level support needed
by higher level drivers such as
.Xr ppbus 4 .
This driver attaches where the traditional NetBSD
.Xr lpt 4
driver would ordinarily. It provides the data transport and chip set
manipulation needed by higher driver layers. This driver is designed to be
one of many possible implementations supporting machine independent parallel
device support via
.Xr ppbus 4 .
.Ss IEEE 1284 support
.Nm
is intended to provide to data-link like services to higher level IEEE 1284
device drivers (such as
supports parallel ports and provides the low level support needed
by higher level drivers such as
.Xr ppbus 4 .
This driver attaches where the traditional NetBSD
.Xr lpt 4
driver would ordinarily. It provides the data transport and chip set
manipulation needed by higher driver layers. This driver is designed to be
one of many possible implementations supporting machine independent parallel
device support via
.Xr ppbus 4 .
.Ss IEEE 1284 support
.Nm
is intended to provide to data-link like services to higher level IEEE 1284
device drivers (such as
.Xr ppbus 4 ).
.Nm
does not directly support IEEE 1284 features such as mode negotiation but
rather provides the necessary infrastructure to allow a higher level driver to
does not directly support IEEE 1284 features such as mode negotiation but
rather provides the necessary infrastructure to allow a higher level driver to
provide these services.
.Pp
.Nm
does provide chip set manipulation, device handshakes (where appropriate),
does provide chip set manipulation, device handshakes (where appropriate),
low-level error detection, and data transfer.
.Ss Supported data transfer modes
.Nm
supports the following data transfer modes: Centronics Compatible (Standard),
Nibble, Byte (PS2), Fast Centronics, ECP, and EPP. Standard and Fast Centronics modes are write only, Nibble and Byte modes are read only, and ECP and EPP
Nibble, Byte (PS2), Fast Centronics, ECP, and EPP. Standard and Fast Centronics modes are write only, Nibble and Byte modes are read only, and ECP and EPP
modes are bidirectional.
.Ss Software Interfaces
The driver provides some generic methods that can apply to many AT-like
.Ss Software Interfaces
The driver provides some generic methods that can apply to many AT-like
parallel port devices (such as non-generic chip sets): see
.Xr atppc 9 .
.Xr atppc 9 .
.Nm
implements the parport interface defined in
.Xr ppbus 9 .
implements the parport interface defined in
.Xr ppbus 9 .
.Ss Supported Devices
.Nm
supports only generic chip sets on the ISA bus. The original FreeBSD
.Nm
supports only generic chip sets on the ISA bus. The original FreeBSD
.Xr ppc 4
driver included support for other chip sets, but this driver is still under
development. Generic chip sets configured by other means besides ISA are also
driver included support for other chip sets, but this driver is still under
development. Generic chip sets configured by other means besides ISA are also
not supported, but are being planned.
.\" .Sh FILES
.\" .Sh EXAMPLES
@ -73,20 +73,20 @@ not supported, but are being planned.
.Xr atppc 9 ,
.Xr microseq 9
.Sh HISTORY
The
The
.Nm
driver is based on the
driver is based on the
.Xr ppc 4
driver, which originally appeared in FreeBSD.
driver, which originally appeared in FreeBSD.
.Sh AUTHORS
This manual page is based on the FreeBSD
.Xr ppc 4
manual page. The information has been updated for NetBSD's port by Gary
This manual page is based on the FreeBSD
.Xr ppc 4
manual page. The information has been updated for NetBSD's port by Gary
Thorpe.
.Sh BUGS
.Bl -item
.It
ISA PnP, PnP BIOS, ACPI attachments are missing. Support is being planned.
ISA PnP, PnP BIOS, ACPI attachments are missing. Support is being planned.
.It
Only standard and FAST mode writes are tested. Nibble reads also tested.
.It

View File

@ -41,7 +41,7 @@
.Nm lp
.Nd printer port Internet Protocol driver
.Sh SYNOPSIS
.Cd "lp* at ppbus?"
.Cd "lp* at ppbus?"
.Cd options PLIP_DEBUG
.Sh DESCRIPTION
The
@ -55,10 +55,10 @@ and any standard AT-compatible printer port with working interrupts may be used.
During the boot process, for each
.Nm ppbus
device which is attached and has an interrupt capability, a corresponding
.Nm
.Nm
device is attached. The
.Nm
device is configured using
device is configured using
.Xr ifconfig 8
using the options for a point-to-point network interface:
.Pp
@ -92,7 +92,7 @@ packet header, and is easier to interface to other types of equipment.
.El
.Pp
The interface MTU defaults to 1500, but may be set to any value. Both ends
of the link must be configured with the same MTU. See
of the link must be configured with the same MTU. See
.Xr ifconfig 8
for details on configuring network interfaces.
.Ss Cable Connections
@ -229,13 +229,13 @@ state to avoid spuriously indicating the start of the next packet).
.Xr ifconfig 8
.Sh HISTORY
The
.Nm
driver was implemented for ppbus in FreeBSD and imported into NetBSD. Crynwr
packet drivers implemented PLIP for MS-DOS. Linux also has a PLIP driver. The
protocols are know as LPIP (FreeBSD) and CLPIP (Crynwr/Linux) in the
.Nm
driver was implemented for ppbus in FreeBSD and imported into NetBSD. Crynwr
packet drivers implemented PLIP for MS-DOS. Linux also has a PLIP driver. The
protocols are know as LPIP (FreeBSD) and CLPIP (Crynwr/Linux) in the
documentation and code of this port. LPIP originally appeared in FreeBSD.
.Sh AUTHORS
This manual page is based on the FreeBSD
This manual page is based on the FreeBSD
.Xr lp 4
manual page. The information has been updated for NetBSD's port by Gary Thorpe.
.Sh BUGS
@ -246,23 +246,23 @@ excessive amounts of CPU. This is unavoidable in the case of CLPIP mode
due to the choice of handshake lines; it could theoretically be improved
in the case of LPIP mode.
.Pp
Regardless of the speed difference between hosts, PLIP is CPU-intensive and its
Regardless of the speed difference between hosts, PLIP is CPU-intensive and its
made worse by having to send nibbles (4 bits) at a time.
.Pp
Polling timeouts are controlled by counting loop iterations rather than
timers, and so are dependent on CPU speed. This is somewhat stabilized
by the need to perform (slow) ISA bus cycles to actually read the port.
.Pp
In the FreeBSD implementation, the idle state was not properly being restored
on errors or when finishing transmitting/receiving. This implementation
attempts to fix this problem which would result in an unresponsive interface
that could no longer be used (the port bits get stuck in a state and nothing
In the FreeBSD implementation, the idle state was not properly being restored
on errors or when finishing transmitting/receiving. This implementation
attempts to fix this problem which would result in an unresponsive interface
that could no longer be used (the port bits get stuck in a state and nothing
can progress) by zeroing the data register when necessary.
.Pp
For unknown reasons, the more complex protocol (CLPIP) yields higher data
transfer rates during testing so far. This could possibly be because the other
side can reliably detect when the host is transmitting in this implementation
of CLPIP (this may not necessarily be true in Linux or MS-DOS packet drivers).
CLPIP gets about 70 KB/sec (the best expected is about 75 KB/sec) and LPIP get
about 55 KB/sec. This is despite LPIP being able to send more packets over the
interface (tested with 'ping -f') compared to CLPIP.
For unknown reasons, the more complex protocol (CLPIP) yields higher data
transfer rates during testing so far. This could possibly be because the other
side can reliably detect when the host is transmitting in this implementation
of CLPIP (this may not necessarily be true in Linux or MS-DOS packet drivers).
CLPIP gets about 70 KB/sec (the best expected is about 75 KB/sec) and LPIP get
about 55 KB/sec. This is despite LPIP being able to send more packets over the
interface (tested with 'ping -f') compared to CLPIP.

View File

@ -38,7 +38,7 @@
.Cd "lpbb* at ppbus?"
.Sh DESCRIPTION
The
.Nm
.Nm
driver supports the Philips official I2C parallel bit-banging interface.
.Pp
.Bd -literal
@ -76,8 +76,8 @@ manual page first appeared in
.Fx 3.0 .
.Sh AUTHORS
This
manual page is based on the
manual page is based on the
.Fx
.Xr lpbb 4
manual page and has been updated for NetBSD's port by
manual page and has been updated for NetBSD's port by
.An Gary Thorpe .

View File

@ -38,7 +38,7 @@
.Cd options LPT_DEBUG
.Cd options LPT_VERBOSE
.Sh DESCRIPTION
The
The
.Nm
driver is the port of the lpt driver to the
.Xr ppbus 4
@ -56,10 +56,10 @@ for more information about the parallel port bus system.
The parallel port bus is reserved by lpt when the printer device is opened
and released when the device is closed.
.Pp
Ports can be configured to use DMA, IEEE negotiations, and IEEE compliant
Ports can be configured to use DMA, IEEE negotiations, and IEEE compliant
transfer modes by using the
.Xr lptctl 8
command, with modes depending on the hardware available.
command, with modes depending on the hardware available.
.Pp
.Ss Minor bit
The minor bit selects some device features:
@ -70,37 +70,37 @@ The minor bit selects some device features:
.It 32 Automatic LF on CR.
.El
.Pp
.Xr mknod 8
.Xr mknod 8
can be used to create such devices if necessary (see BUGS).
.Sh FILES
.Bl -tag -width "/dev/lpt0xx" -compact
.It Pa /dev/lpt?
interrupt-driven ports (minor number 0)
.It Pa /dev/lpa?
polled ports (minor number 128)
polled ports (minor number 128)
.El
.Sh SEE ALSO
.Xr atppc 4 ,
.Xr ppbus 4 ,
.Xr atppc 4 ,
.Xr ppbus 4 ,
.Xr lptctl 8 ,
.Xr mknod 8
.Xr mknod 8
.Sh HISTORY
This driver is derived from drivers which appear in FreeBSD and NetBSD. The
FreeBSD driver is used for ppbus usage while the NetBSD driver's behavior is
This driver is derived from drivers which appear in FreeBSD and NetBSD. The
FreeBSD driver is used for ppbus usage while the NetBSD driver's behavior is
emulated as much as possible for compatibility.
.Sh AUTHORS
This manual page was based on the FreeBSD
This manual page was based on the FreeBSD
.Xr lpt 4
manual page. The information has been updated for NetBSD's port by Gary Thorpe.
.Sh BUGS
If a printer is not connected and on-line,
.Pa /dev/lpt?
and
.Pa /dev/lpa?
cannot be used with
If a printer is not connected and on-line,
.Pa /dev/lpt?
and
.Pa /dev/lpa?
cannot be used with
.Xr lptctl 8 .
A lpt device with minor number
A lpt device with minor number
.Em 64
must be used in this case because it skips the initialization sequence.
must be used in this case because it skips the initialization sequence.
.Pp
Testing has been limited by hardware availability.

View File

@ -44,7 +44,7 @@
.Cd "vpo* at ppbus?"
.Sh DESCRIPTION
The
.Nm
.Nm
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 chip sets.
@ -93,35 +93,35 @@ that provide similar services.
Parallel port chip set support is provided by
.Xr atppc 4 .
.Pp
The ppbus system provides functions and macros to request service from the
The ppbus system provides functions and macros to request service from the
ppbus including reads, writes, setting of parameters, and bus requests/releases.
.Pp
.Xr atppc 4
detects chip set and capabilities and sets up interrupt handling. It makes
methods available for use to the
.Xr atppc 4
detects chip set and capabilities and sets up interrupt handling. It makes
methods available for use to the
.Nm
system.
.Sh PARALLEL PORT MODEL
The logical parallel port model chosen for the ppbus system is the AT
parallel port model. Consequently, for the
The logical parallel port model chosen for the ppbus system is the AT
parallel port model. Consequently, for the
.Em atppc
implementation of ppbus, most of the services provided by ppbus 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
implementation of ppbus, most of the services provided by ppbus 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.
.Ss Description
The parallel port may operate in the following modes:
.Bl -bullet -offset indent
.It
Compatible (Centronics -- the standard parallel port mode) mode, output byte
Compatible (Centronics -- the standard parallel port mode) mode, output byte
.It
Nibble mode, input 4-bits
Nibble mode, input 4-bits
.It
Byte (PS/2) mode, input byte
Byte (PS/2) mode, input byte
.It
Extended Capability Port (ECP) mode, bidirectional byte
Extended Capability Port (ECP) mode, bidirectional byte
.It
Enhanced Parallel Port (EPP) mode, bidirectional byte
Enhanced Parallel Port (EPP) mode, bidirectional byte
.El
.Ss Compatible mode
This mode defines the protocol used by most PCs to transfer data to a printer.
@ -135,12 +135,12 @@ This mode is referred to as
"Fast Centronics" or "Parallel Port FIFO mode".
.Ss Nibble mode
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
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.
.Ss Byte mode
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
All transfers are 8-bits long. Channel direction must be negotiated when doing
IEEE 1248 compliant operations.
.Ss Extended Capability Port mode
The ECP protocol was proposed as an advanced mode for communication with
@ -164,7 +164,7 @@ performance parallel port link that would still be compatible with the
standard parallel port.
.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
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.
.Pp
@ -185,16 +185,16 @@ disturbing the current transfer.
.Ss Mixed modes
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.
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.
.Sh IEEE 1284 1994 Standard
.Ss Background
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
It also specifies a format for a peripheral identification string and a method
of returning this string to the host.
.Pp
This standard is architecture independent and only specifies dialog handshake
@ -206,19 +206,19 @@ The IEEE 1284 protocol is fully oriented with all supported parallel port
modes. The computer acts as master and the peripheral as slave.
.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
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.
.Pp
At any time, the slave may want to send data to the host. The host must
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.
.Pp
If the host accepts the transfer, it must firstly negotiate the reverse mode
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.
@ -229,14 +229,14 @@ termination, transfer in any mode without bothering you with low level
characteristics of the standard.
.Pp
IEEE 1284 interacts with the ppbus system as least as possible. That means
you still have to request the ppbus when you want to access it, and of course,
you still have to request the ppbus when you want to access it, and of course,
release it when finished.
.Sh ARCHITECTURE
.Ss Chip set, ppbus and device layers
First, there is the
.Em chip set
.Em chip set
layer, the lowest of the ppbus system.
It provides chip set abstraction through a set of low level functions that maps
It provides chip set abstraction through a set of low level functions that maps
the logical model to the underlying hardware.
.Pp
Secondly, there is the
@ -253,34 +253,34 @@ propose an arch-independent interface to access the hardware layer.
.Pp
Finally, the
.Em device
layer represents the traditional device drivers such as lpt which now use an
layer represents the traditional device drivers such as lpt which now use an
abstraction instead of real hardware.
.Pp
.Ss Parallel port mode management
Operating modes are differentiated at various ppbus system layers. There is a
difference between a
Operating modes are differentiated at various ppbus system layers. There is a
difference between a
.Em capability
and a
.Em mode .
A chip set may have a combination of capabilities, but at any one time the
A chip set may have a combination of capabilities, but at any one time the
.Nm
system operates in a single mode.
.Pp
Nibble mode is a
Nibble mode is a
.Em virtual
mode: the actual chip set would be in standard mode and the driver would change
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.
.Pp
Each child device of
Each child device of
.Nm
must set its operating mode and other parameters whenever it requests and gets
access to it's parent
must set its operating mode and other parameters whenever it requests and gets
access to it's parent
.Nm .
.Sh FEATURES
.Ss The boot process
.Nm
attachment tries to detect any PnP parallel peripheral (according to
.%T "Plug and Play Parallel Port Devices" draft from (c)1993-4 Microsoft
.%T "Plug and Play Parallel Port Devices" draft from (c)1993-4 Microsoft
Corporation) then probes and attaches known device drivers.
.Pp
During probe, device drivers should request the ppbus and try to
@ -288,23 +288,23 @@ determine if the right capabilities are present in the system.
.Ss Bus request and interrupts
.Nm
reservation via a bus request is mandatory not to corrupt I/O of other devices.
For example, when the
.Xr lpt 4
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
.Em lpt
For example, when the
.Xr lpt 4
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
.Em lpt
driver releases the bus.
.Pp
Child devices can also register interrupt handlers to be called when a hardware
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
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.
.Ss Micro-sequences
.Em Micro-sequences
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
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 ppbus layer for a sequence of operations and do most of
the job at the chip set level.
.Pp
@ -336,6 +336,6 @@ The
system first appeared in
.Fx 3.0 .
.Sh AUTHORS
This manual page is based on the FreeBSD
This manual page is based on the FreeBSD
.Xr ppbus 4
manual page. The information has been updated for NetBSD's port by Gary Thorpe.

View File

@ -44,7 +44,7 @@ the security problems inherent with the use of the
.Pa /dev/io
interface.
.Pp
The programming interface is described in
The programming interface is described in
.Xr ppi 9 .
.Sh FILES
.Sh SEE ALSO
@ -54,10 +54,10 @@ The programming interface is described in
.Xr ppi 9
.Sh HISTORY
.Nm
originally appeared in
originally appeared in
.Fx .
.Sh AUTHORS
This manual page is based on the
This manual page is based on the
.Fx
.Xr ppi 4
manual page and was updated for NetBSD's port by