/usr/src/man/man4/sbus.4

'\" te
.\" Copyright (c) 1999, Sun Microsystems, Inc.
.\" All Rights Reserved
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
.TH SBUS 4 "Dec 31, 1996"
.SH NAME
sbus \- configuration files for SBus device drivers
.SH DESCRIPTION
.sp
.LP
The \fBSBus\fR is a geographically addressed peripheral bus present on many
\fBSPARC\fR hardware platforms. \fBSBus\fR devices are \fIself-identifying\fR
\(em that is to say the \fBSBus\fR card itself provides information to the
system so that it can identify the device driver that needs to be used. The
device usually provides additional information to the system in the form of
name-value pairs that can be retrieved using the \fBDDI\fR property interfaces.
See \fBddi_prop_op\fR(9F) for details.
.sp
.LP
The information is usually derived from a small Forth program stored in the
\fBFCode\fR \fBPROM\fR on the card, so driver configuration files should be
completely unnecessary for these devices. However, on some occasions, drivers
for \fBSBus\fR devices may need to use driver configuration files to augment
the information provided by the \fBSBus\fR card. See \fBdriver.conf\fR(4) for
further details.
.sp
.LP
When they are needed, configuration files for \fBSBus\fR device drivers should
identify the parent bus driver implicitly using the \fIclass\fR keyword.  This
removes the dependency on the particular bus driver involved since this may be
named differently on different platforms.
.sp
.LP
All bus drivers of class \fBsbus\fR recognise the following properties:
.sp
.ne 2
.na
\fB\fBreg\fR\fR
.ad
.RS 14n
An arbitrary length array where each element of the array consists of a 3-tuple
of integers.  Each array element describes a logically contiguous mappable
resource on the \fBSBus.\fR
.sp
The first integer of each tuple specifies the slot number the card is plugged
into. The second integer of each 3-tuple specifies the offset in the slot
address space identified by the first element. The third integer of each
3-tuple specifies the size in bytes of the mappable resource.
.sp
The driver can refer to the elements of this array by index, and construct
kernel mappings to these addresses using \fBddi_map_regs\fR(9F). The index into
the array is passed as the \fIrnumber\fR argument of \fBddi_map_regs()\fR.
.sp
You can use the \fBddi_get*\fR and \fBddi_put*\fR family of functions to access
register space from a high-level interrupt context.
.RE

.sp
.ne 2
.na
\fB\fBinterrupts\fR\fR
.ad
.RS 14n
An arbitrary length array where each element of the array consists of a single
integer. Each array element describes a possible \fBSBus\fR interrupt level
that the device might generate.
.sp
The driver can refer to the elements of this array by index, and register
interrupt handlers with the system using \fBddi_add_intr\fR(9F). The index into
the array is passed as the \fIinumber\fR argument of \fBddi_add_intr()\fR.
.RE

.sp
.ne 2
.na
\fB\fBregisters\fR\fR
.ad
.RS 14n
An arbitrary length array where each element of the array consists of a 3-tuple
of integers.  Each array element describes a logically contiguous mappable
resource on the \fBSBus.\fR
.sp
The first integer of each tuple should be set to \fB\(mi1\fR, specifying that
any SBus slot may be matched. The second integer of each 3-tuple specifies the
offset in the slot address space identified by the first element.  The third
integer of each 3-tuple specifies the size in bytes of the mappable resoure.
.sp
The \fBregisters\fR property can only be used to augment an incompletely
specified \fBreg\fR property with information from a driver configuration file.
It may only be specified in a driver configuration file.
.RE

.sp
.LP
All \fBSBus\fR devices must provide \fBreg\fR properties to the system. The
first two integer elements of the \fBreg\fR property are used to construct the
address part of the device name under \fB/devices\fR.
.sp
.LP
Only devices that generate interrupts need to provide \fBinterrupts\fR
properties.
.sp
.LP
Occasionally, it may be necessary to override or augment the configuration
information supplied by the \fBSBus\fR device. This can be achieved by writing
a driver configuration file that describes a prototype device information
(devinfo) node specification, containing the additional properties required.
.sp
.LP
For the system to merge the information, certain conditions must be met. First,
the \fBname\fR property must be the same. Second, either the first two integers
(slot number and offset) of the two \fBreg\fR properties must be the same, or
the second integer (offset) of the \fBreg\fR and \fBregisters\fR properties
must be the same.
.sp
.LP
In the event that the \fBSBus\fR card has no \fBreg\fR property at all, the
self-identifying information cannot be used, so all the details of the card
must be specified in a driver configuration file.
.SH EXAMPLES
.LP
\fBExample 1 \fRA sample configuration file.
.sp
.LP
Here is a configuration file for an \fBSBus\fR card called \fBSUNW,netboard\fR.
The card already has a simple \fBFCode\fR \fBPROM\fR that creates \fBname\fR
and \fBreg\fR properties, and will have a complete set of properties for normal
use once the driver and firmware is complete.

.sp
.LP
In this example, we want to augment the properties given to us by the firmware.
We use the same \fBname\fR property, and use the \fBregisters\fR property to
match the firmware \fBreg\fR property. That way we don't have to worry about
which slot the card is really plugged into.

.sp
.LP
We want to add an \fBinterrupts\fR property while we are developing the
firmware and driver so that we can start to experiment with interrupts. The
device can generate interrupts at \fBSBus\fR level 3. Additionally, we want to
set a \fBdebug-level\fR property to 4.

.sp
.in +2
.nf
#
# Copyright (c) 1992, by Sun Microsystems, Inc.
#ident  "@(#)SUNW,netboard.conf         1.4     92/03/10 SMI"
#
name="SUNW,netboard" class="sbus"
	registers=-1,0x40000,64,-1,0x80000,1024
	interrupts=3 debug-level=4;
.fi
.in -2
.sp

.SH ATTRIBUTES
.sp
.LP
See \fBattributes\fR(5) for descriptions of the following attributes:
.sp

.sp
.TS
box;
c | c
l | l .
ATTRIBUTE TYPE	ATTRIBUTE VALUE
_
Architecture	SPARC
.TE

.SH SEE ALSO
.sp
.LP
\fBdriver.conf\fR(4), \fBattributes\fR(5), \fBddi_add_intr\fR(9F),
\fBddi_map_regs\fR(9F), \fBddi_prop_op\fR(9F)
.sp
.LP
\fIWriting Device Drivers\fR
.SH WARNINGS
.sp
.LP
The wildcarding mechanism of the \fBregisters\fR property matches every
instance of the particular device attached to the system. This may not always
be what is wanted.