1. Introduction *

2. Installation of the software *

3. Deinstallation of the software *

4. Configuring the Ikon board and device driver *

5. Byte ordering and byte packing *

6. Rebuilding the device driver from source code *

7. Source Code Structure charts *

8. Installation File Information *

9. LOOP – loop back test and programming example *

10. MASTER/SLAVE/MANUAL - inter-processor link program *

11. ‘Man’ Pages *

12. Miscellaneous Notes *

13. Revision History *
 
 

1. Introduction
 
 

The Interface Consultants Model DIS1019S Ikon SGI DR11W device driver is a program that extends the IRIX operating system to access the PCI bus to configure an Ikon board to interface through the DR11W bus, hence the name DIS (DR11W Ikon SGI).
 
 

The device driver supports the Ikon 10116 full size PCI bus interface board or the Ikon 10118 half size PCI bus interface board under the Silicon graphics SGI IRIX 6.4 or 6.5 operating system environment.
 
 

Several test programs - ‘loop’, 'master', 'manual', and 'slave' are provided (with C source code) that allows complete functional testing of board and driver, and as an inter-processor link, and also provides a source code example of how to program the card to transfer data.
 
 

The device driver supports the operation of multiple Ikon boards on a single machine. The driver will identify the boards as devices /hw/idr0, /hw/idr1, ... The installation script handles multiple boards and also auto identifies IRIX 6.4 and IRIX 6.5
 
 

This device driver is a functional port of the Sparc Solaris device driver provided by Ikon. Refer to the Ikon documentation for detail register and programming information.
 
 
 
 

To contact Ikon:
 
 

Ikon Corporation

2617 Western Ave.

Seattle, WA 98121

206/728-6465

Fax: 206/728-1633

http://www.tahomatech.com/
http://www.tahomatech.com/DeviceDrivers.htm

email: tahoma@tahomatech.com
 
 

To contact Interface Consultants:
 
 

Interface Consultants, Inc.

3375 Westpark Drive #143

Houston, TX 77005-4262

713/529-3706

http://www.ifc2.com

email:neo@ifc2.com
 
 
 
 

Disclaimer: Marks copyright Interface Consultants, Ikon, or Digital.
 
 

2. Installation of the software
 
 

The installation of the DIS1019S can be accomplished easily and quickly with the included CD.
 
 

First, login as 'root', and insert the CD into the CD-ROM drive. Access the CD drive by typing:
 
 

cd /CDROM
 
 

Next, run the vinstall script on the CD by typing:
 
 

ksh ./vinstall
 
 

The device driver is self-configuring. At this point, the device driver should be functional. A test utility (such as the 'loop' utility included) can be run at this time to test the driver. The machine should be rebooted to make sure the device driver is properly loaded and configured.
 
 

3. Deinstallation of the software
 
 

The deinstallation of the DIS1019S is similar in nature to the installation process by virtue of its ease and speed.
 
 

First, login as 'root', and insert the CD into the CD-ROM drive. Access the CD drive by typing:
 
 

cd /CDROM
 
 
 
 

First, insert the CD into the CD-ROM drive. Next, run the vremove script on the CD by typing:
 
 

ksh ./vremove
 
 

The device driver should be removed at this point. The machine should be rebooted to make sure the device driver is properly removed and to ensure nothing else was affected by the deinstall.
 
 

4. Configuring the Ikon board and device driver
 
 

The Ikon 10116/10118 board has no external dip-switches to set, as certain other Ikon boards did. Thus there are no physical configurations with the board the user must adjust.
 
 

When installing the board, make sure the board is properly seated in its 32 bit PCI slot. Refer to the Ikon 10116/10118 user’s manual for more information.
 
 

The device driver uses DMA and interrupts to achieve high performance. The Ikon 10116/10118 board possesses a set of PCI configuration registers that configure all of the bus interface information such as the register base address of the working registers in the PCI I/O and memory space, and interrupt level. All of the above information is configured at power-on by the IRIX operating system.
 
 

SGI IRIX does not support default value configuration like Sun Solaris with an ‘idr.conf’ file and ‘getprop()’ function calls in the device driver. In the DIS1019S device driver, default configuration values are defined in file ‘idrconf.c’, which is compiled into the device driver. To change a configuration default value, edit the ‘idrconf.c’ file and re-compile, and re-install the driver.
 
 

Below is the contents of the ‘idrconf.c’ configuration file for reference:
 
 

/*

#

# idr.conf

#

# Hardware configuration file for IKON PCI DR11

# interface driver.

#

# This file contains driver configuration defaults, and forces the interrupt priority

# to a value that keeps the scheduler happy.

#

# Several driver default paramaters can be set by modifying this file and re-loading the driver.

# This avoids having to re-compile the driver when it is necessary to change defaults.

#

# ALL DEFAULTS APPLY TO ALL BOARD INSTANCES (this may change later)

#

#

# START OF USER-CONFIGURABLE DEFAULTS

#

# The handshake speed of the DR11 interface is set by the speed_def property.

# Permissible values are 0,1,2, or 3. 0 gives the fastest speed.

# See the board manual for details.

#

*/

cp->speed_def=0;

/*

#

# There are three software timeout clocks used by the driver: a dma timer, a wait-for-ready timer,

# and a wait for ATTENTION timer.

# The defaults for these timers are set by dma_time_def, rdy_time_def, and attn_time_def in SECONDS.

#

*/

cp->dma_time_def=30;

cp->rdy_time_def=30;

cp->attn_time_def=30;

/*

#

# The big vs little endian mode of the board is determined by the byte_swap property.

# 0 causes the data sent/received via the DR11 cable to match the byte ordering of the

# CPU, 1 causes the data within each 16-bit word to be byte-swapped.

#

*/

cp->byte_swap_def=1;

/*

#

# The default polarities of the DR11 signals CYCLE REQUEST and BUSY are determined by the

# cycle_pol_def and busy_pol_def properties, respectively. Cycle_plo_def = 0 causes the

# CYCLE REQUEST input to assert on a rising edge; 1 selects falling edge active. Busy_pol_def

# = 0 causes BUSY to be asserted low, 1 selects high assertion.

#

*/

cp->cycle_pol_def=0;

cp->busy_pol_def=0;

/*

#

# At the beginning of a DR11 block, it may be necessary to issue a software cycle pulse to

# begin the block transfer (in link mode, it is required only for the sending end of the link).

# There are separate cycle properties for read and write blocks. write_cycle_def controls

# the write soft cycle, and read_cycle_def controls reads. Setting either to 1 will cause a

# soft cycle pulse to be issued at the start of EACH corresponding DR11 block.

#

*/

cp->write_cycle_def=1;

cp->read_cycle_def=0;

/*

#

# Link mode also requires that the driver issue an ACLO FCN2 pulse (which becomes an ATTENTION

# at the other end of the link) at the start of each DR11 read block. This is selected by

# setting the read_acf2_def property to 1. We will default to 0 for now - to stay consistent with

# the Sbus version of the driver.

#

*/

cp->read_acf2_def=0;

/*

#

# Several properties set the default states of the DR11 function bits, FCN3, FCN2, and FCN1.

# This is done separately for read and write blocks, and when the device is opened

# Each function bit has a separate property for each situation. The names are

# (hopefully) self-explanatory. Permitted values are 0 or 1.

#

*/

cp->open_f3_def=0;

cp->open_f2_def=0;

cp->open_f1_def=0;

/*

#

*/

cp->write_f3_def=1;

cp->write_f2_def=0;

cp->write_f1_def=0;

/*

#

*/

cp->read_f3_def=1;

cp->read_f2_def=0;

cp->read_f1_def=1;

/*

#

# END OF USER-CONFIGURABLE DEFAULTS

#

#

#

# We force the interrupt priority of the

# driver to level 9 to get it below the level of the

# scheduler - the board's eeprom was reporting a class code that

# caused the OBP to set the board's priority to the same level

# as the scheduler, which required using a high-level

# interrupt handler.

#

# That should have been OK, but when two boards were running at the

# same time, LBOLT was getting confused and confusing the software timer.

# It is not clear who was causing the problem.

#

# We can solve the problem by changing our eeprom to give a class code

# of 0x07, which currently gives us a priority of 1, but that seems

# like too low a priority.

#

# For now, we will force a relatively high priority, but below

# the scheduler priority of 10.

#

# DO NOT MODIFY THIS PROPERTY!!!!!

#

interrupt-priorities=9;

*/
 
 
 
 
 
 
 
 
 
 

5. Byte ordering and byte packing
 
 

The DR11W interface is a 16 bit parallel interface. The Ikon board’s PCI interface is a 32 bit parallel interface, and data transfer from the machine to the board is via 32 bit DMA.
 
 

The byte ordering and byte packing differences between machine architectures have always been an issue when transferring data from one machine to another. Computers have varying ‘natural’ operand sizes – 8 bit, 16 bit, 32 bit, 64 bit, and others, but are all modern architectures are basically byte oriented.
 
 

If a 32 bit data type is stored with the most significant byte in the memory at byte address (n), and the least significant byte in the memory at byte address (n+3), the machine is termed ‘big endian’ because the biggest (most significant) byte is ‘first’ in memory (at the lowest address). The Motorola 68xxx family architecture is a famous big endian machine architecture.
 
 

If a 32 bit data type is stored with the least significant byte in the memory at byte address (n), and the most significant byte in the memory at byte address (n+3), the machine is termed ‘little endian’ because the littlest (least significant) byte is ‘first’ in memory (at the lowest address). The Intel X86 architecture is a famous little endian machine architecture.
 
 

There are also hybrid orderings (like the DEC VAX) that do not order the significance of the data in either ascending or descending byte order, but are word (2 byte) oriented.
 
 

Byte packing refers to how multi-byte data types are stored in memory. Many of the new RISC architectures require that non-single-byte data types be aligned to a machine ‘natural’ operation size boundary – either 32 bits or 64 bits. This means that if you have a C structure of multiple short data types (16 bit values), the individual elements may not be stored in memory at adjacent addresses, but be ‘padded’ with unused bytes to achieve natural boundary alignment. If the structure is transferred to another computer through the DR11W interface, the data may need to be adjusted (before sending or after receipt) to compensate for the differences in byte packing and byte odrer.
 
 

Some C compilers have a ‘#pragma align’ or ‘#pragma pack’ that control byte packing if the hardware architecture allows it.
 
 

In general, the data transfer programs interfacing to the idr device driver on each end of an inter-processor link will be required to perform byte re-ordering of the data during read and/or write to ensure that proper interpretation of the data is achieved. The most portable software implementation transfers arrays of bytes, and interprets the data as other elements in software on each end of the link.
 
 

Later versions of the Ikon board have hardware to do 32 bit byte swapping of DMA data over the PCI bus. This is controlled through the ‘byte_swap_def’ parameter of the ‘idrconf.c’ module. See the previous section for information on changing the configuration default values.
 
 

See the Ikon manual for more information on the byte swapping capabilities.
 
 
 
 

/*

#

# The big vs little endian mode of the board is determined by the byte_swap property.

# 0 causes the data sent/received via the DR11 cable to match the byte ordering of the

# CPU, 1 causes the data within each 16-bit word to be byte-swapped.

#

*/

cp->byte_swap_def=1;
 
 

6. Rebuilding the device driver from source code
 
 
 
 
 
 
 
 

The source code for the device driver can be found under the ./src directory on the CD-ROM. Create a working directory on a hard disk, and copy all the source files from the ./src directory on the CD-ROM to the working directory.
 
 

To rebuild the driver and test programs from the source code, execute the korn shell script 'build', e.g.:
 
 

mkdir src

cd ./src

cp –p /CDROM/src/* .

ksh build clean

ksh build all
 
 

The ‘build’ script detects the IRIX operating system level and runs the proper ‘make’ file to compile the driver and test programs from source code. The build script must be run on both IRIX 6.4 and 6.5 machines to update both operating system version of the driver and test programs. The makefile describes the object file’s dependence on the source code files (C source code ‘.c’ and header files ‘.h’). The make program uses the file time stamps to determine if a source code file is newer than an object, and if so, re-compiles the object from source.
 
 

The device driver consists of the following source code modules on the CD-ROM under /src:

Scripts and miscellaneous file:
 
 

build - the korn shell script to build the driver from source

makefile – the IRIX 6.5 make file

makefile.64 – the IRIX 6.4 make file

vinstall - the korn shell script to install the driver

vremove - the korn shell script to remove the driver

idrdd.mas - the IRIX system configuration ‘master’ file

idrdd.sm - the IRIX system configuration ‘system’ file
 
 

Source code files:
 
 

idrdd.c – the device driver C source code.

idrconf.c – the device driver default values configuration file.
 
 

Header files:
 
 

idr_io.h – the ioctl interface definition header file.

idr_reg.h – the Ikon board register definition header file.

idrdd.h – the device driver internal data structure definition header file.

pcicfg.h – the IRIX PCI configuration space access header file.
 
 

The test program source code is also included:
 
 

loop.c – the loop back test program source code.

master.c – the inter-processor link test program master side source code.

slave.c – the inter-processor link test program slave side source code.

manual.c – the inter-processor link test program manual mode source code.
 
 
 
 

The ‘build’ script determines the IRIX operating system version and calls make with the proper makefile with an optional additional parameter (which is known as the makefile ‘target’). Build can be called with the following targets:
 
 

ksh build – performs a default ‘make’, and therefore is equivalent to ‘all’.

ksh build all – rebuilds idrdd.o, loop, manual, master, slave from source.

ksh build install – copies the device driver files to the proper directories.

ksh build load – copies the idrdd.o file and loads the module with ‘ml’.

ksh build unload 5 –unloads the module with ‘ml unld 5’. Note: use ‘ml list’

ksh build clean – removes idrdd.o, loop, manual, master, slave object files.

ksh build loop – rebuilds loop test program from source.

ksh build manual – rebuilds manual test program from source.

ksh build master – rebuilds master test program from source.

ksh build slave– rebuilds slave test program from source.
 
 
 
 
 
 
 
 

7. Source Code Structure charts
 
 

Structure charts depicting the calling tree of the software are include on the CD-ROM under the '/cdoc' subdirectory, and were generated by the commercial documentation program ‘C-DOC’ Version 4.0.4.
 
 

There are six documentation files generated for each of the five C source code components of the device driver. For a given C source code component of the device driver, the documentation files consist of six text files with the same base name as the C source code file (e.g. idrdd), but with different extensions as follows:
 
 

idrdd.toc - table of contents file: source file vs. function index.
 
 

idrdd.cal - calling function cross reference: function level cross reference of all functions.
 
 

idrdd.tre - caller and called tree: a graphic tree depicting the calling hierarchy of the code.
 
 

idrdd.ref - function level cross reference of identifiers: indexes global and local variables by function reference.
 
 

idrdd.lst - listing of source code file with line numbers and action diagrams that detail the program logic.
 
 

idrdd.cpx - program path complexity and quality metrics
 
 
 
 

The five C source code components are:

idrdd.c

loop.c

master.c

manual.c

slave.c
 
 
 
 

These documentation files are on the DIS1019S CD-ROM under the subdirectory ../cdoc and together comprise approximately 1.2 MB of data, and therefore are not included in printed form in this document.

8. Installation File Information
 
 

The following is a list of the files included on the installation CD:
 
 

vinstall

vremove

idrdd.mas

idrdd.o and idrdd64.o

idrdd.sm

idr_io.h
 
 
 
 

A brief explanation of each of the files can be found on the following pages:
 
 
 
 

vinstall installation batch-file/script
 
 

Contents:

#!/bin/ksh

#

# vinstall - DR11W Ikon PCI device driver for SGI IRIX 6.4/6.5

# Copyright (c) 1998, Interface Consultants, Houston, TX

# 3375 Westpark Drive #143

# Houston, TX 77005-4262

# 713/529-3706

# 713/529-3725 Fax

# http://www.ifc2.com

# email: neo@ifc2.com

#

# vinstall Version 1.0 October 1, 1998

#

VER=`uname -r`

CPU=`uname -m`

OSVER="---"
 
 

echo Installing IDR on IRIX version $VER CPUBOARD=$CPU
 
 

CPUBOARD=$CPU

export CPUBOARD
 
 

if [ $VER = "6.3" ]

then

OSVER="IRIX6_3"

fi
 
 

if [ $VER = "6.4" ]

then

OSVER="IRIX6_4"

fi
 
 

if [ $VER = "6.5" ]

then

OSVER="IRIX6_5"

fi

export OSVER
 
 

if [ $VER = "6.5" ]

then

cp -p idrdd.o /var/sysgen/boot

cp -p idrdd.sm /var/sysgen/system

cp -p idrdd.mas /var/sysgen/master.d/idrdd

cp -p idr_io.h /usr/include/sys

ml ld -c idrdd.o -p idr_

autoconfig

fi
 
 

if [ $VER = "6.4" ]

then

cp -p idrdd64.o /var/sysgen/boot/idrdd.o

cp -p idrdd.sm /var/sysgen/system

cp -p idrdd.mas /var/sysgen/master.d/idrdd

cp -p idr_io.h /usr/include/sys

ml ld -c idrdd.o -p idr_

autoconfig

fi
 
 
 
 

Purpose:

Batch file (korn shell script) to install the device driver.
 
 

Description:

This batch file will copy all of the necessary files to the system to run the device driver, and then it will configure the driver to be ready for operation.
 
 
 
 
 
 

vremove de-installation batch file / script
 
 

Contents:

#!/bin/ksh

#

# vremove - DR11W Ikon PCI device driver for SGI IRIX 6.4

# Copyright (c) 1997, Interface Consultants, Houston, TX

# 3375 Westpark Drive #143

# Houston, TX 77005-4262

# 713/529-3706

# 713/529-3725 Fax

# http://www.ifc2.com

# email: neo@ifc2.com

#

# vremove Version 1.0 October 1, 1998

#

rm /var/sysgen/boot/idrdd.o

rm /var/sysgen/system/idrdd.sm

rm /var/sysgen/master.d/idrdd

rm /usr/include/sys/idr_io.h

autoconfig
 
 

Purpose:

Batch file (korn shell script) to remove the driver.
 
 

Description:

This batch file will remove all files pertinent to the device driver. It will also remove the device that was configured by the driver (idr0).
 
 

idrdd.mas device master file
 
 

Contents:

* idrdd.mas - DR11W Ikon PCI device driver for SGI IRIX 6.4/6.5

* Copyright (c) 1998, Interface Consultants, Houston, TX

* 3375 Westpark Drive #143

* Houston, TX 77005-4262

* 713/529-3706

* 713/529-3725 Fax

* http://www.ifc2.com

* email: neo@ifc2.com

*

* idrdd.mas Version 1.0 October 1, 1998

*

* To Install:

* cp idrdd.mas /var/sysgen/master.d/idrdd

*

* IRIX Example driver "idrdd" -- not for production use

*

* Flags used:

* b: block type device

* c: character type device (yes, both)

* d: dynamically loadable kernel module

* n: driver is semaphored

* s: software device driver

* w: driver is prepared to perform any cache write back operation (none)

*

* Field 1: Element characteristics:

* o specify only once

* r required device

* b block device

* c character device

* t initialize cdevsw[].d_ttys

* j filesystem

* s software driver

* f STREAMS driver

* m STREAMS module

* x not a driver; a loadable module

* k kernel module

* u a stubs module that is loaded after all other normal modules

* n driver is fully semaphored for multi-processor operation;

* the n and p directives are ignored on single-processor systems

* p driver is not semaphored and should run on only one processor

* w driver is prepared to perform any cache write back

* operation required on write data passed via the strategy routine

* d dynamically loadable kernel module

* R auto-registrable dynamically loadable kernel module

* N don't allow auto-unload of dynamically loadable kernel module

* D load, then unload a dynamically loadable kernel module

* e ethernet driver
 
 

*

* External major number (SOFT) is an arbitrary choice from

* the range of numbers reserved for customer drivers.

*

* #DEV is passed in to the driver and used to configure its info array.

*

*

* Loadable driver: FLAG = fdN

* Non-loadable: FLAG = c

*

*FLAG PREFIX SOFT #DEV DEPENDENCIES

cdR idr_ - -

* for debug only cdN idr_ - -
 
 

$$$
 
 

Purpose:

This the the ‘master’ file for the idrdd device driver.
 
 

Description:

This file describes the driver to the IRIX operating system. It details the following information:
 
 

c - this is a character device driver

d - this is a dynamically loadable kernel module

R - this is a auto-registrable dynamically loadable kernel module

idr_ - driver prefix is idr_. This is used by the loader to link to the devswitch functions.

- - the major number for this driver is auto configured
 
 
 
 
 
 
 
 

idrdd.o and idrdd64.o device driver object file
 
 

Purpose:

This is the object file image of the device driver that is loaded into the kernel by the ‘ml’ command.

The file idrdd.o is the IRIX 6.5 version and idrdd64.o is the IRIX6.4 version. The ‘vinstall’ script identifies the operating system version and copies the correct device driver object file to the proper directories.
 
 

Description:

Device driver object file.
 
 
 
 

idrdd.sm device driver system file
 
 

Contents:

VECTOR: bustype=PCI module=idrdd
 
 

Purpose:

This file tells the IRIX operating system that the device driver object module idrdd.o supports a PCI device, and it should be called at init time for the PCI bus to determine if it supports the device being probed.
 
 

Description:

When IRIX boots, it loads the device driver module, and calls the ‘prefix_init’ function for all ‘.sm’ files. In this case, it calls the idr_init function. This allows the driver to register the vendor id and device id of the PCI card it supports. When the IRIX probe finds a PCI card, it calls the ‘prefix_attach’ function for the registered vendor id and device id of the PCI card. The idr_attach function initializes the device and driver.
 
 
 
 
 
 
 
 

idr_io.h header file
 
 

Contents:
 
 

See file ‘idr_io.h’ on the CD-ROM or in /usr/include/sys after installation.
 
 
 
 
 
 

Purpose:

Assigns register values to constants used to interface to the device driver.
 
 

Description:

This header file contains all the #defined constants which were used in the device driver routine to substitute for register values. This file is #included in any program that needs to access the device. It defines the IOCTL interface to the driver and the meaning of the return status. This can be incorporated into a program that sends out IOCTL commands to the Ikon board. See ‘loop.c’ for a source code sample.
 
 
 
 

9. LOOP – loop back test and programming example
 
 

The loop program is provided with C source code as an example of how to write a user program that interfaces to the idr device driver, and as a test program. The loop program requires a ‘loop back’ cable be installed on the Ikon J1 and J2 ribbon cables. See the Ikon manual and the loop.c source code for more information on the test program.
 
 

To run the test program, type:
 
 

./loop
 
 

and at the prompt, type:
 
 

idr0
 
 

to test the first Ikon card in loop back mode.
 
 
 
 

10. MASTER/SLAVE/MANUAL - inter-processor link program
 
 

The master, slave, and manual programs are provided with C source code as an example of how to write a user program that interfaces to the idr device driver, and as an inter-processor link test program. The inter-processor link test programs requires that two DR11W interfaces be ‘cross’ cabled with J1 connected to the other interface’s J2 ribbon cable, and J2 connected to the other interface’s J1 ribbon cable. See the Ikon manual and the source code for more information on the test programs.
 
 

The ‘slave’ end of the interface must be started before the ‘master’ or ‘manual’ end.
 
 

To run the slave inter-processor link test program, type:
 
 

./slave
 
 

and at the prompt, type:
 
 

idr0
 
 

to test the first Ikon card in slave mode.
 
 

Then, to run the master inter-processor link test program, type:
 
 

./master
 
 

and at the prompt, type:
 
 

idr1
 
 

to test the second Ikon card in master mode.
 
 

11. ‘Man’ Pages
 
 

This section provides more detail information about key functions and subroutines contained within the device driver. Their source code is in the following file:
 
 

idrdd.c

idr_unload

idr_open

idr_close

idr_read

idr_write

idr_ioctl

idr_init

idr_attach

idr_detach

idr_error

idr_intr

idrTimeOut

idrStrategy

idrAlenlistSize

idrReportTime

idrDiffTime
 
 
 
 
 
 
 
 

NAME

idr_unload - Routine that unloads the driver.
 
 

SYNOPSIS

int idr_unload (void)
 
 

ARGUMENTS

TYPE NAME (I/O)
 
 

DESCRIPTION

unload
 
 

NAME

idr_open - Function that opens the driver.
 
 

SYNOPSIS

int idr_open (dev_t *, int, int, cred_t *)
 
 

ARGUMENTS

TYPE NAME (I/O)

dev_t *devp pointer device structure

int flag

int otyp

cred_t *cred
 
 

DESCRIPTION

open
 
 

NAME

idr_close - Function that closes the driver.
 
 

SYNOPSIS

int idr_close (dev_t, int, int, cred_t *)
 
 

ARGUMENTS

TYPE NAME (I/O)

dev_t *devp pointer device structure

int flag

int otyp

cred_t *cred
 
 

DESCRIPTION

close
 
 

NAME

idr_read - Function that reads in bytes.
 
 

SYNOPSIS

int idr_read (dev_t, uio_t *, cred_t *)
 
 

ARGUMENTS

TYPE NAME (I/O)

dev_t dev pointer to device

uio_t *uiop

cred_t *crp
 
 

DESCRIPTION

read
 
 

NAME

idr_write - Function that writes bytes.
 
 

SYNOPSIS

int idr_write ( dev_t, uio_t *, cred_t *)
 
 

ARGUMENTS

TYPE NAME (I/O)

dev_t dev pointer to device

uio_t *uiop

cred_t *crp
 
 

DESCRIPTION

write
 
 

NAME

idr_ioctl - Function that passes ioctl commands.
 
 

SYNOPSIS

int idr_ioctl (dev_t, int, void *, int, cred_t *, int *)
 
 

ARGUMENTS

TYPE NAME (I/O)

ioctl, io, control
 
 

NAME

idr_init - Routine that initializes the Ikon board for operations.
 
 

SYNOPSIS

int idr_init (void)
 
 

ARGUMENTS

TYPE NAME (I/O)
 
 

DESCRIPTION

init, initialization
 
 

NAME

idr_attach - Function that attaches the card as a device of the system.
 
 

SYNOPSIS

int idr_attach (vertex_hdl_t)
 
 

ARGUMENTS

TYPE NAME (I/O)

vertex_hdl_t vhdl vertex handle
 
 

DESCRIPTION

attach
 
 

NAME

idr_detach - Function that detaches the Ikon board from the system.
 
 

SYNOPSIS

int idr_detach (vertex_hdl_t)
 
 

ARGUMENTS

TYPE NAME (I/O)

vertex_hdl_t vhdl vertex handle
 
 

DESCRIPTION

detach
 
 

NAME

idr_intr - Function that handles interrupt requests.
 
 

SYNOPSIS

void idr_intr ( eframe_t *, intr_arg_t )
 
 

ARGUMENTS

TYPE NAME (I/O)

eframe_t *ef

intr_arg_t arg
 
 

DESCRIPTION

intr, interrupt
 
 

NAME

idrTimeOut - Function that controls the time-out feature of the driver.
 
 

SYNOPSIS

static void idrTimeOut ( card_t *)
 
 

ARGUMENTS

TYPE NAME (I/O)

card_t *cp pointer to card structure
 
 

DESCRIPTION

timeout
 
 

NAME

idrStrategy - Strategy routine of the device driver.
 
 

SYNOPSIS

static int idrStrategy ( buf_t * )
 
 

ARGUMENTS

TYPE NAME (I/O)

buf_t *bp pointer buffer
 
 

DESCRIPTION

strategy
 
 

NAME

idrAlenlistSize - Function that finds number of pairs in an alenlist.
 
 

SYNOPSIS

static int idrAlenlistSize ( alenlist_t )
 
 

ARGUMENTS

TYPE NAME (I/O)

alenlist_t al alenlist variable
 
 

DESCRIPTION

alenlist, size
 
 

NAME

idrReportTime - Routine that reports the beginning, intr, and end of DMA times.
 
 

SYNOPSIS

static void idrReportTime ( caddr_t, card_t *, int )
 
 

ARGUMENTS

TYPE NAME (I/O)

caddr_t title

card_t *cp pointer to card structure

int final
 
 

DESCRIPTION

time, report
 
 

NAME

idrDiffTime - Routine calculates the difference of two time structures
 
 

SYNOPSIS

static void idrDiffTime ( struct timeval *, struct timeval *, struct timeval *)
 
 

ARGUMENTS

TYPE NAME (I/O)

struct timeval * *st start time pointer

struct timeval * *et end time pointer

struct timeval * *dt time difference pointer
 
 

DESCRIPTION

time, differenc
 
 

12. Miscellaneous Notes

None at this time.

13. Revision History
 
 

10/13/98

1.0 - Full release version - IRIX 6.4
 
 

10/15/98

1.1 - Change IRIX dma functions to 'pciio_dmamap_…()' for Origin2000

Fix system hang from mutex lock not being released on pciio_dmatrans_list()

Add support for IRIX 6.5
 
 

10/23/98

1.2 - Minor cleanup - deleted console printf of version on every open() call.

Add microtime() call for timing tests.