Drop trailing whitespace.
This commit is contained in:
parent
b7b8fd2efe
commit
9fa543d057
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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 .
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue