ppbus(4)

NAME

ppbus - Parallel Port Bus system

SYNOPSIS

device ppbus
device vpo
device lpt
device plip
device ppi
device pps
device lpbb

DESCRIPTION

The ppbus system provides a uniform, modular and architec

ture-independent
system for the implementation of drivers to control various

parallel
devices, and to utilize different parallel port chipsets.

DEVICE DRIVERS

In order to write new drivers or port existing drivers, the

ppbus system
provides the following facilities:

+o architecture-independent macros or functions to

access parallel

ports

+o mechanism to allow various devices to share the

same parallel

port

+o a user interface named ppi(4) that allows parallel

port access

from outside the kernel without conflicting with

kernel-in
drivers.

Developing new drivers

The ppbus system has been designed to support the develop

ment of standard
and non-standard software:

Driver Description
vpo VPI0 parallel to Adaptec AIC-7110 SCSI controller

driver. It

uses standard and non-standard parallel port ac

cesses.

ppi Parallel port interface for general I/O
pps Pulse per second Timing Interface
lpbb Philips official parallel port I2C bit-banging in

terface

Porting existing drivers

Another approach to the ppbus system is to port existing

drivers. Various drivers have already been ported:

Driver Description
lpt lpt printer driver
plip lp parallel network interface driver

ppbus should let you port any other software even from other

operating
systems that provide similar services.

PARALLEL PORT CHIPSETS

Parallel port chipset support is provided by ppc(4).

The ppbus system provides functions and macros to allocate a

new parallel
port bus, then initialize it and upper peripheral device

drivers.

ppc makes chipset detection and initialization and then

calls ppbus
attach functions to initialize the ppbus system.

PARALLEL PORT MODEL

The logical parallel port model chosen for the ppbus system

is the PC's
parallel port model. Consequently, for the i386 implementa

tion of ppbus,
most of the services provided by ppc are macros for inb()

and outb()
calls. But, for an other architecture, accesses to one of

our logical
registers (data, status, control...) may require more than

one I/O
access.

Description

The parallel port may operate in the following modes:

+o compatible mode, also called Centronics mode

+o bidirectional 8/4-bits mode, also called NIBBLE

mode

+o byte mode, also called PS/2 mode

+o Extended Capability Port mode, ECP

+o Enhanced Parallel Port mode, EPP

+o mixed ECP+EPP or ECP+PS/2 modes

Compatible mode

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.

Many I/O controllers have implemented a mode that uses a FI

FO buffer to
transfer data with the Compatibility mode protocol. This

mode is
referred to as "Fast Centronics" or "Parallel Port FIFO

mode".

Bidirectional mode

The NIBBLE mode is the most common way to get reverse chan

nel data from a
printer or peripheral. Combined with the standard host to

printer mode,
it provides a complete bidirectional channel.

In this mode, outputs are 8-bits long. Inputs are accom

plished by reading 4 of the 8 bits of the status register.

Byte mode

In this mode, the data register is used either for outputs

and inputs.
Then, any transfer is 8-bits long.

Extended Capability Port mode

The ECP protocol was proposed as an advanced mode for commu

nication with
printer and scanner type peripherals. Like the EPP proto

col, ECP mode
provides for a high performance bidirectional communication

path between
the host adapter and the peripheral.

ECP protocol features include:

Run_Length_Encoding (RLE) data compression for host

adapters

FIFOs for both the forward and reverse channels

DMA as well as programmed I/O for the host register

interface.

Enhanced Parallel Port mode

The EPP protocol was originally developed as a means to pro

vide a high
performance parallel port link that would still be compati

ble with the
standard parallel port.

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.

A particularity of the ISA implementation of the EPP proto

col 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.

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 hand

shake 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.

At any time, the peripheral may interrupt the host with the

nAck signal
without disturbing the current transfer.

Mixed modes

Some manufacturers, like SMC, have implemented chipsets that

support
mixed modes. With such chipsets, mode switching is avail

able at any time
by accessing the extended control register.

IEEE1284-1994 Standard

Background

This standard is also named "IEEE Standard Signaling Method

for a Bidirectional Parallel Peripheral Interface for Personal Comput

ers". It
defines a signaling method for asynchronous, fully inter

locked, 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.

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 regis

ters, mapped memory or other methods to control these signals.

The IEEE1284 protocol is fully oriented with all supported

parallel port
modes. The computer acts as master and the peripheral as

slave.

Any transfer is defined as a finite state automaton. It al

lows software
to properly manage the fully interlocked scheme of the sig

naling method.
The compatible mode is supported "as is" without any negoti

ation 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.

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 request

ing signals to
prevent time consuming polling methods.

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 sig

nal that no
more data is available.

Implementation

IEEE1284 Standard support has been implemented at the top of

the ppbus
system as a set of procedures that perform high level func

tions like
negotiation, termination, transfer in any mode without both

ering you with
low level characteristics of the standard.

IEEE1284 interacts with the ppbus system as little as possi

ble. 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.

ARCHITECTURE

adapter, ppbus and device layers

First, there is the adapter layer, the lowest of the ppbus

system. It
provides chipset abstraction throw a set of low level func

tions that maps
the logical model to the underlying hardware.

Secondly, there is the ppbus layer that provides functions

to:

1. share the parallel port bus among the daisy-chain

like con
nected devices

2. manage devices linked to ppbus

3. propose an arch-independent interface to access

the hardware
layer.

Finally, the device layer gathers the parallel peripheral

device drivers.

Parallel modes management
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.

With this level of abstraction a particular chipset may com

mute from any
native mode the 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.

This architecture should support IEEE1284-1994 modes.

FEATURES

The boot process

The boot process starts with the probe stage of the ppc(4)

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.

ppbus attachment tries to detect any PnP parallel peripheral

(according
to Plug and Play Parallel Port Devices draft from (c)1993-4

Microsoft
Corporation) then probes and attaches known device drivers.

During probe, device drivers are supposed to request the pp

bus 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.

Bus allocation and interrupts ppbus allocation is mandatory not to corrupt I/O of other

devices. An
other usage of ppbus allocation is to reserve the port and

receive incoming interrupts.

High level interrupt handlers are connected to the ppbus

system thanks to
the newbus BUS_SETUP_INTR() and BUS_TEARDOWN_INTR() func

tions. But, in
order to attach a handler, drivers must own the bus. Conse

quently, a
ppbus request is mandatory in order to call the above func

tions (see
existing drivers for more info). Note that the interrupt

handler is
automatically released when the ppbus is released.

Microsequences
Microsequences 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 trans

fers. The philosophy of microsequences is to avoid the overhead of the

ppbus layer and
do most of the job at adapter level.

A microsequence is an array of opcodes and parameters. Each

opcode codes
an operation (opcodes are described in microseq(9)). Stan

dard I/O operations are implemented at ppbus level whereas basic I/O oper

ations and
microseq language are coded at adapter level for efficiency.

As an example, the vpo(4) driver uses microsequences to im

plement:

+o a modified version of the NIBBLE transfer mode

+o various I/O sequences to initialize, select and

allocate the
peripheral

SEE ALSO

lpt(4), plip(4), ppc(4), ppi(4), vpo(4)

HISTORY

The ppbus manual page first appeared in FreeBSD 3.0.

AUTHORS

This manual page was written by Nicolas Souchu.

BSD March 1, 1998

BSD