Note: Descriptions are shown in the official language in which they were submitted.
218400~
..'~ ~
Serial Driver Interface for Modular
I/0 Software Architecture
Field of Invention
The preeent invention relatea in general to data
5 processing and computer systems and in particular to
methods and c~ aLus for implementing an operating
system and hardware ind~ ~d~llL software interface for
serial data input/output (I/0).
Descri~tion of the Prior ~rt
A8 microprocessors and storage device3 grow in speed
and capacity, many computer u8ers realize that current
storage and networking capabilities and standards are
failing to keep pace and are becoming critical
performance bottlenecks.
For example, video and broadcast providers would
like to avoid the so-called "~no~kPrn~t" wherein stored
images on tape must be transferred by hand from one site
to another. There is a demand, therefore, for a purely
digital studio. EIowever, for the digital studio to
become a reality, disk storage aystems must be capable of
capturing data at full frame rates without data
compression and, similarly, data distribution systems
must be able to transfer video data between systems at
comparable speeds.
Another industry requiring data transfer and storage
beyond current capabilities is the digital pre-press
industry. Digital pre-press systems are typically called
218~00~ ~
-- 2 --
upon to move enormous image data files between editing
stations, Raster Image Processing systems (RIPs), and in
many cases, digital press controllers. The size of these
image data files is often on the order of hundreds of
5 megabytes per image. It ig not llnrl , therefore, that
at present data transfer rates the transfer of these
images can take minutes apiece.
I~urthermore, it is noteworthy that the speed of
server sy3tems is al~o affected by current storage
10 subsystem input/output (I/O).
Accordingly, better storage and ct~nn~ct;vity
solutions are needed in order to address the problems set
f orth above .
One emerglng solution to the above problem is the
15 new Serial Storage Architecture (SSA) and connectivity
technology. A full explanation and specification of the
SSA is set out in SSA-Industry Association Reference
Documents:
1. SSA-IA/95PH Serial Storage Architecture -
1995 Physical, October 12, 1995 (Rev. 3)
2. SSA-IA/95SP Serial Storage Architecture -
1995 SCSI -2 Protocol, October 11, 1995 (Rev. 3)
3. Serial Storage Architecture Physical Layer 1
(SSA-PHl) x3Tl~ l/1145D, March 29, 1996 (Rev. 9a)
4. Serial Storage Architecture Transport Layer 1
(SSA-TLl) x3T10.1/0989D, February 28, 1996 (Rev. 10)
5. Serial Storage Architecture SCSI-2 Protocol
2184000
. ~ , ,
-- 3
(SSA-S2P) X3T10.1/1121D, February 28, 1996 (Rev. 7)
These above documents are all incorporated herein by
reference. Generally, compared to aging technologies
such as the Small ~ r System Interface (SCSI), SSA
5 offers six times the performance, eight times the device
connectivity, fault t~ rAn~, autoconfiguration,
simplified cabling and connections, lower cost, and
dramatically increased efficiency. SSA technology is
therefore becoming a preferred architecture choice to
10 realize the desired data transfer and storage speed
requirements .
Similarly, serial fibre channel technology is
presently being implemented to achieve improved data
transfer and storage speeds. A full .-~lAnAt;r~n of the
15 fibre channel technology is set out in the following
documents:
1. Fibre Channel Arbitrated Loop (FC-AL), March
26, 1996 (Rev. 5.1)
2. Fibre Channel Physical and Signaling Interface
(FC-PH) x3.230-1994
3. Fibre Channel Single Byte Command Code Sets
(SBCCS) Mapping Protocol (FC-SB~, May 26, 1995 (Rev. 3.4)
4. Fibre Channel Private Loop Direct Attach (FC-
PLDA), January 22, 1996 (Rev. 1 . 0)
5. SCSI-3 Fibre Channel Protocol for SCSI (FCP),
May 30, 1995 (Rev. 12)
These documents are also incorporated herein by
.
218~00~
-~.` ~ '
-- 4
ref erence ~
However, in order to replace current I/O technology,
e~g~ SCSI, on a host/peripheral computer sy~tem with, for
example, SSA or fibre channel, not only do the physical
5 I/O adapter cards need to be replaced with serial adapter
cards supportive of SSA or fibre channel, but also both
software device drivers and adapter drivers need to be
replaced with drivers in accordance with the SSA or fibre
channel standard. The time and expense of redeveloping
10 these driver~, however, can become prohibitive.
Therefore, a need exists for a method and apparatus
whereby serial architecture-- ~t;hle adapter drivers
can be developed inexpensively and quickly and which can
operate with existing device drivers.
SUr~lP~Y OF TEIE INVENTION
It is an obj ective of the present invention to
provide a serial driver interface which is operable with
existing device drivers and is portable across multiple
operating systems.
It is a further object of the pre~ent invention to
simplify development of new serial I/O adapter drivers.
Other obj ects of the present invention will be
apparent from the l~ ln~ of the specification and
claims .
The preferred embodiment of the present invention i~
a computer operating system and hardware-independent
218~0
.,
-- 5
process for impl: - ;n~ input/output (I/0) between
protocol-in~ ~ t;h1e device drivers and targets. The
invention comprises the following steps.
An I/0 request is received according to a f irst
5 protocol from a device driver and is translated into a
second I/0 request according to a second protocol. A
data structure, pointed to by a first pointer, is
assembled and ;n~ the second I/0 request, a unique
token value, and a second pointer to an operating system-
0 dependent completion function. The first pointer is thensent to an adapter which is forced to send the second I/0
request to the target . Upon receiving a response f rom
the target, the process associates the response with the
previously assembled data structure by way of the unique
15 token value. Finally, the operating sy6tem-~l~r-~n-l~nt
completion function is called to process the response in
accordance with the operating systems needs.
Thus, the present invention allows, for example, the
interface of parallel SCSI device drivers and SSA or
20 fibre channel ~ ;hle devices or nodes. Furthermore,
the invention can also pass original SSA, ~
directly to SSA compatible devices by simply eliminating
the translating step, or original fibre channel ,~ n~
directly to fibre channel compatible devices.
25 Brief Description of the Drawinq8
The advantages and features of the present invention
218~00Q
r . - 6 -
will become more clearly apparent from the following
description of an illustrative embodiment of the
invention, given as a non-restrictive example only and
represented in the ~c~, ying drawings, in which:
FIG. 1 shows a typical parallel I/0 software
architecture and associated peripheral connectivity
according to the prior art.
FIG. 2 shows a serial I/0 software architecture and
associated ppr;~hpral connectivity according to the prior
art.
FIG. 3 depicts a serial I/0 software and hardware
architecture according to the present invention.
FIGs. 4a-c set forth the preferred data structure3
in accordance with the present invention.
FIGS. 5-8 set forth software routine prototypes in
accordance with the present invention.
FIG. 9 shows defined registers for an interface
controller in accordance with the present invention.
FIGs 10-24 and 26-31 show flow diagrams for
2 0 impl t; n~ the adapter driver use of serial driver
interface software routines.
FIG. 25 shows a data structure comprising
information representative of each adapter and device
connected to the adapter
FIGs. 32-39 show flow diagrams for implementing the
adapter driver-to-adapter interface.
2~4n~0
-- 7
Detailed Descri~tion of the Preferred Ernbodiment
FIG . 1 shows a typical parallel input/output ( I/0)
sof tware architecture according to the prior art . The
operating system/application 100 communicates with any of
nodes 104 via device driver 101, adapter driver 102, and
adapter 103. Communication between the operating
system/application 100 and adapter 103 iB accomplished
via common bus 105. Nodes 104 can be storage devices
~uch as hard drives or tape drives or other similar
devices, or alternatively, nodes 104 can be other host
computer systems. The device driver 101, adapter driver
102, and adapter 103 work in conjunction to effect
communication according to a standard parallel protocol
such a~ the Small Computer System Interface (SCSI), SCSI-
2, or any other standard parallel protocol known in the
art .
FIG. 2 show6 a typical 6erial I/0 software
architecture according to the prior art. Referring to
Fig. 2, the operating system/application 100 communicates
with any of 6erial I/0 compatible nodes 115 via device
driver 111, adapter driver 112, and adapter 116.
Communication between the operating system/application
110 and the adapter 116 is accomplished via common bus
105. The architecture depicted in FIG. 2 is particularly
6uited to effect communication between the operating
sy6tem/application 100 and nodes 115 u6ing the Serial
Storage Architecture (SSA). However, one 6killed in the
2ls~0a~
. ~ ~
-- 8
art will recognize that to take advantage of SSA for
example, device driver 111 and adapter driver 112 must be
redeveloped in accordance with SSA protocol standards.
This can lead to great expense and delay in impl~ j ns
5 3erial I/O.
The present invention, however, facilitate3 and
reduces the cost of implementing serial I/O by keeping
existing device driver 111, developed in accordance with,
for instance, the SCSI-2 protocol, unmodified.
A preferred embodiment of the present invention is
illustrated in FIG. 3. As ~hown in FIG. 3, the serial
driver interface (SDI) 113 is incorporated within the
adapter driver 110. Generally, the SDI 113 comprises a
~et of routines and data ~tructures that provide a high-
15 level interface between the adapter driver 110 and
adapter 114. A~ will be further explained herein, the
SDI 113 and adapter 114 provide all the necessary
translation services, SSA protocol services, and
transport and physical ~upport required to transform, for
20 example, SCSI-2 command/response exchanges into SSA-
, -t;hle command/regponse exchanges. One skilled in
the art will recognize that any discussion in this
specification referring to SSA alone is also equally
applicable to fibre channel technology.
2~ The SDI 113 provides routines for initializing
itself, communicating with adapter 114, and interrupt
handling. Several provided routines have an interface
2184000
but not an impl~ -ntat;on~ These routines are "operating
system-~ ronll~nt" as will be explained hereinafter.
More specif ically, as shown in FIG . 3, the SDI 113
includes initialization routinea 150, mailbox routines
200, packet routines 300, and operating system-dependent
routines 400 to effect the afc,L~ ned functions. In
the pref erred embodiment, the adapter 114 includes
firmware and sufficient memory capacity for a mailbox 201
comprising random access memory ~RAM), device
command/response gueues (CRQs) 301 and an asynchronous
event command/response gueue (Async CRQ) 302.
Initialization routines 150 are used to initialize
the SDI 113. Mailbox routine~ 200 are used for obtaining
information about the adapter 114 and the serial I/O-
compatible nodes 115 ~tt~c~ to the adapter 114. Packet
routines 300 are used for sending, for example, SCSI-2
SSA message structures (SMSs) to a node 115 through the
adapter 114. Finally, the operating system-dependent
routines 400 are used to implement the SDI 113 in
different operating systems. Preferred data ~3tructure~3
to be used with the SDI 113 and the various routines
mentioned above will next be discussed in detail.
SDI Data Structures
With reference to FIGs. 4a-c, the following data
structures are defined for use with the SDI 113. One
~killed i~ the art will recognize the hierarchical
218~000
-- 1 o
organization of the various structures as defined using
the ANSI C ~ ng language. In operation of the
present invention, the defined data atructurea are
located in host DMA memory, accessible to both the
5 computer operating 3ystem and adapter 114. A diacussion
of the .~ of each data structure is set forth
hereinaf ter .
The data structure sdi_xt_packet is created by the
SDI 113 and sent to a device CRQ, or Async CRQ.
10 sdi_xt_packet is one of the following types:
sdi_xt_ssa_packet or sdi_xt_async_packet, both of which
are discussed hereinafter. Complete_c~llhark is a
pointer to a function called by adapter driver 110 when
the packet has been completed. The adapter driver 110
15 must set the c~llh;l~k function in each packet.
link_space is used for inserting and removing the packet
from; n~rn:~l queues . phys_addr is the physical address
of the packet. driver_space is a 16 byte space allocated
for use by the adapter driver 110. For example, this is
20 used by a Netware driver to link the packet to a
corresponding Host Adapter Control Block (HAC~) .
The data structure sdi_xt_ssa_packet ~ ~nt~;n~ the
request and response information necessary to issue an
SSA packet to a target, that is a CRQ. The request
25 section contains the SSA SCSI-2 SMS and data pointers
that the adapter 114 requires in order to process the
request. The response section contains completion statu8
218~00Q
-- 11 --
inf ormation .
The data structure sdi_xt_ssa_request contains the
command bytes (SMS) and data pointers that the adapter
114 requires in order to process the SMS to the node 115.
cr~num is the CRQ associated with the destination node
llS . E~ach node' 8 CRQ is found by calling
sdi_get_next_device discussed later in this
specification. token is a 32-bit field that is used to
obtain addrf~ h; l; ty to the packet during response
0 processing. When the adapter 114 completes a request, it
will return the token to the SDI 113. The SDI 113 casts
token to a pointer to an sdi_xt_packet . The token f ield
should be set to the appropriate value, typically the
virtual address of the sdi_xt_packet. timeout i8 the
lS timeout value in milliseconds for the packet.
dma_address is the physical address of the data to be
transferred. For requests that do not involve data
transfer, this field should be 3et to zero. dma_size is
the size in bytes of the d~ta transfer to be transferred.
For requests that do not involve data transfer, this
field should be set to zero. dma_type is the type of the
data transfer. For example, constants representative of
normal or scatter/gather types can be used. sms is the
sdi_xt_scsi2_sms discussed hereinafter.
The data structure sdi_xt_ssa_response ~ont~;n~ the
response information associated with a
sdi_xt_ssa_request. token i~ a copy of the token in the
.~ 218~0~
-- 12 --
associated sdi xt_ssa_request The L~ ;n;ng elements in
sdi_xt_ssa_response are protocol-dependent. Using SCSI-2
as an example, reason is the completion reason. state
holds the status bits indicating the command progress at
5 completion. If the command results in the device
returning a SCSI-2 status SSA message, then scsi_status
is set to the status f ield f rom that message . residual
is set to the number of bytea not transferred if the
command completes successfully, but with less data
lO transf erred than was requested .
The data structure sdi_xt_async_packet c~nt~;n~ the
request and response information necessary to queue an
asynchronous packet to the adapter 114. Queue Async
packets are returned to the SDI 113 when asynchronous
15 events occur. Like the non-Async packet described above,
sdi xt_async_packet comprises a request section and a
response section.
The data structure sdi_xt_async_request ~ nt:~;n.c the
CRQ number and a token. cra num should be set to a
20 constant representative of the async CRQ ID. token
r~nt~; n~ a value ag explained above with regard to
sdi_ssa_xt_request .
The data structure gdi_xt_agync_regponge rr~nt~; n~
asynchronous event information returned from the adapter
25 114. token ~ nt;i;n~ a value as described above with
regard to sdi_ssa_xt_response. reason r~nti~;nFI the type
of async packet Constants representative of the
.~ - 2184~0~
-- 1 3
following events can be defined: the adapter 114 has
detected a new node 115 on the SSA web, the adapter 114
has detected that a node 115 was removed from the SSA
web, an adapter 114 log event has occurred; the data in
log_num is valid, or an adapter 114 or node 115 error
event ha3 occurred; or the data in error_num is valid.
new_target rr)ntAinq information about a new target that
was added to the web. del_target c~t~;nq infr~rr~ti~n
about a target that was deleted f rom the web . log_num
-~nt~inq a log message reprPqPnt~tive of, for example, a
web reconfiguration. err_num ~-..nt~;nq an error meq~age
representative of, for example, total reset, absolute
reset, or i ntPrn~l error of a node 115 .
The data structure sdi_xt_sg_element is an entry in
15 a scatter/gather list that is sent to the adapter 114.
The scatter/gather capability of adapter 114 can be found
by calling sdi_get_scatter_gather_info described
hereinaf ter . sg_buf_size is the length of the
scatter/gather re~uest in bytes and sg_buf_phys_addr is
20 the phyaical address of the request buffer. T h e
data structure sdi_xt_hba_info is used to return
information about a host bus adapter (HsA~, or adapter
114. The structure comprises firmware and hardware
revision numbers and a unique ID assigned to the adapter
114.
The data structure sdi_xt_scsi2_sms is the last
structure in sdi_xt_ssa_request. Each element of this
218400
. ~ ' . .
- 14 --
particular structure is disclosed by the SSA
do t~;on cited earlier, incorporated herein by
ref erence .
Tn; tialization Routines
Init;~l;7~t;~n routines 150 are provided to
initialize the SDI 113 and the adapter 114, query adapter
114 attributes, and reset the adapter 114. FIG. 5 shows
ANSI C source code prototypes for each of the
initialization routines 150 operable with the SDI 113.
10 One skilled in the art will recognize the role of each of
the following routines as it is further explained herein.
Further, the use or sequence of uae of the initialization
routines 150 will be discussed hereinafter by way of flow
charts .
The routine sdi_get_hba_object_size returns the size
in bytes of an adapter data object. The size returned is
used to allocate a block of memory that will be used by
the SDI 113 to internally manage the adapter 114. The
adapter~ 8 pointer is a parameter to most of the SDI 113
20 routines. As can be seen from the prototype in FIG. 5,
the routine has no parameters.
The routine sdi_initialize detects the presence of
an adapter 114 at a specified host bus adapter (HBA). If
an adapter 114 is found, the SDI 113 initializes a data
25 structure pointed to by a pointer. The parameter
hba_number is the index of an HBA and adptr i~ a pointer
21840Q~
- 15 -
to an sA obj ect . The parameter caller_context i8 a
pointer to a driver-defined object and is stored in the
SDI 113 for each BA. The pointer is paased to the
operating system dependent routines 400 discussed
hereinaf ter . The pointer should be set to a driver-
defined object or to null if no object is required. The
routine sdi_initialize will return a value of O if an BA
was detected and successfully ini~ I. Otherwise,
the return value is a constant indicative of one of the
0 following errors: device not found, bad vendor ID,
unknown, or bad register.
The routine sdi_enable_hba is provided for certain
device driver architectures, e . g . Netware, that require
that adapter resources be registered before they can be
used. In the case of Netware, the memory mapped run-time
registers on the adapter 114 must be registered before
they can be used. In the prototype of FIG. 5, ~a~ t~r
adptr is a pointer to an BA obj ect . The routine
sdi_enable_hba will return a value of O if the adapter
114 was enabled. Ii the adapter 114 was not enabled, a
non- zero constant will be returned .
The routine sdi_reset_hba resets the specif ied
adapter llg. The parameter adptr is a ptr to an E~BA
obj ect . This routine provides no return value .
The routine sdi_hba_count returns the number of
adapters detected in the system. The routine has no
parameters .
218400Q
i-
-- 1 6
The routine sdi_hba_ir~ returns the interruptrequest line (IRQ) associated with an adapter 114. The
~al t~r adptr ig a pointer to an EIBA object.
The routine sdi_hba_rt_virtual_addr returns the
5 logical, or virtual, address of the adapter 114 memory
mapped registers. This routine is provided for those
operating systems that require registering the memory
mapped registera, e . g . Netware . The required parameter
is adptr, a pointer to an EIsA object.
The routine sdi_hba_rt_physical_addr returns the
physical address of the adapter 114 memory mapped
registers. This routine is provided for those operating
systems that require registering the memory mapped
registers, e . g . Netware . The required parameter is
adptr, a pointer to an BA object.
The routine sdi_hba_rt_size returns the size in
bytes of the adapter memory mapped registers. This
routine is provided for those operating systems that
require registering the memory mapped registers, e . g .
Netware. The required parameter is adptr, a pointer to
an HBA obj ect .
The routine sdi_hba pci_bus_number returns the PCI
bus number associated with the adapter. The required
parameter is adptr, a pointer to an HsA object.
The routine sdi_hba_pci_device_number returns the
PCI device number associated with the adapter 114. The
required parameter is adptr, a pointer to an BA object.
218400~ ~
. .
-- 17 --
The routine sdi_hba_pci_device_number returns the
PCI device number associated with the adapter.
Packet Rollt; n~
Packet routines 300 are used to allocate, send,
5 free, and complete sdi_xt_packet structures discussed
above. FIG. 6 shows ANSI C source code prototypes for
each of the packet routines 300 operable with the SDI
113. With reference to FIG. 3, packet routines 300 send
packets 304 or async packets 306 to the adapter 114.
10 Upon completion of the packet, respective responaes 305,
307 are sent from the adapter 114 to the SDI 113. One
skilled in the art will recognize the role of each of the
routines set forth in Fig. 6 as it is further explained
herein. Further, the use or sequence of use of the
15 packet routines 300 will be discussed hereinafter by way
of f low charts .
The routine sdi_send~acket sends a specified packet
to a specified adapter 114. Parameter adptr is a pointer
to an ~8A o~ject and parameter pkt is a pointer to an
20 sdi_xt_packet structure to be sent to the device at the
CRQ set in the crq num field of the packet request. This
routine provides no return value.
The routine sdi_stock packet_pool stocks a pool of
free packets. The packets are carved from memory
25 beginning at address vaddr. The size of the memory
allocation depends on the number of the packets that are
21840~
. .
-- 18 --
to be created. This routine may be called more than once
to increase the size of the pool. With reference to the
prototype in FI~:. 6, the parameter adptr is a pointer to
an HBA obj ect, vaddr is a pointer to a virtual base
5 address of ~77~t~-1 space, paddr is a pointer to
physical base address of allocated space, and size is the
size of allocated space in bytes. The routine
sdi_stock_packet_pool returns the number of packets
actually ~tocked in the pool.
The routine sdi_get_packet_from_pool gets a packet
pointer from the pool of created packets. Parameter
adptr is a pointer to an HBA object. The routine returns
the value 0 if no packets are available, or the value 1
if a packet was retrieved successfully.
The routine sdi_get_physical_base_addr sets mapping
registers in the HBA to reference hogt memory b~;nn;n~
at base_addr. This function is used if the physical
address range of the system does not begin at OxO0000000.
Parameter adptr is a pointer to an HBA object and
20 parameter base_addr is the base address in host memory.
There is no return value associated with this routine.
The routine sdi_stock_sglist_pool stocks a pool of
free scatter/gather lists. The lists are carved from
memory beginning at vaddr. The size oi the memory
25 allocation depends on the number of lists that are to be
created. Thi~ routine may be called more that once to
increase the size of the pool. The parameter adptr i~ a
- .. 2i840~
. ,
-- 19 --
pointer to an H~3A object, nelem is the number of
scatter/gather elements in each scatter/gather list,
vaddr is a pointer to a virtual base address of allocated
space, and size ia the size of allocated space in bytes.
5 The routine returns the number of scatter/gather liats
actually stocked in the pool.
The routine sdi_get_sglist_from_pool gets a
scatter/gather list f rom the list pool . The parameter
adptr is a pointer to an H;3A object and psgl is a pointer
10 to a pointer to a scatter/gather list. The routine
returns a value of 0 if no scatter/gather list is
available, or a value 1 if a scatter/gather list i5
available and pointed to by psgl.
The routine sdi_return sglist_to_pool returns a
15 scatter/gather list to the list pool. Parameter adptr is
a pointer to an H~3A obj ect and psgl is a pointer to a
scatter/gather list to be returned to the pool. There is
no return value associated with this routine.
The routine sdi_interrupt is the SDI 113 time entry
20 point. The interrupt service routine (ISR) of adapter
driver 110 must call this routine for each adapter 114
supported by the driver 110. For those interrupts that
indicate the completion of a packet a callback function
as~ociated with the packet is called. The routine
25 sdi_interrupt executes in interrupt context. Parameter
adptr is a pointer to an H~3A obj ect . The routine returns
a value of o if the SDI 113 succe~sfully proces~ed the
^ ~ 2184000
-- 20 --
interrupt, or a value of 1 if the adapter 114 did not
have a pending interrupt, 80 that the SDI 113 could not
process one.
The routine packet_complete~ l lh~.~k is an operating
5 system dependent routine. The SDI 113 will call this
routine for each packet that completes. The routine
executes in interrupt context. Paramater pkt is a
pointer to the sdi_xt_packet that the SDI 113 has
completed. The routine provides no return value. For
10 example, a command l~~l l hZlr~k routine checks for the
scsi_status upon packet completion.
The routine sdi_return_packet_to_pool is used to
return a packet to the adapter' 8 114 pool of packets set
up by sdi_stock_packet_pool.
Mailbox Routine~
Mailbox routines 200 are used to obtain information
about the adapter 114 and, for example, the SSA-
~, t;hle nodes 115 attached to the adapter 114. FIG.
20 7 shows ANSI C source code prototypes for each of the
mailbox routines 200 operable with the SDI 113. With
reference to FIG. 3, mailbox routines 200 send mailbox
202 expecting immediate re3ponses 203. That i8,
the mailbox routines 200 will wait for the message
25 response 203 before returning. One skilled in the art
will recognize the role of each the following mailbox
routines 200 as each is further explained herein.
-. 2104000
-- 2 1
Further, the use or sequence of use of the mailbox
routines 200 will be discussed hereinafter by way of flow
chart 8 .
The return values of each of the mailbox routines
5 200, except for one exception described below, are
constants representative of the status of the routine,
namely, success, timeout, or ;n~rnill error.
The routine sdi_get_hba_info is used to gather
information about each adapter including firmware and
10 hardware revisions, and the unique ID (UID) of the
adapter. Parameter adptr is a pointer to an BA object
and rev is a pointer to a driver-declared variable of
type sdi_xt_hba_info. IJpon return, the detected firmware
and hardware revisions, and the UID of the adapter 114 is
15 stored in a data structure as shown in FIG. 9.
The routine sdi_get_next_device is used to gather
information about devices that support a particular upper
level protocol, e.g. SSA. Parameter adptr is a pointer
to an HBA object, ulp is a constant representative of the
20 upper level protocol, e.g. SSA or TCP. Parameter crq num
is a pointer to a driver-declared variable for the CRQ
number of the target. To obtain the first target, this
parameter should be set to a particular constant. On
return, the cr~num will contain the CRQ number of the
25 first target. To obtain information of subsequent
targets, the previously returned crq num is used. If
there are no more targets, another constant is returned.
2184000 `
. . .
-- 22 --
Parameter uid_hi and uid_low are, respectively, pointers
to driver-declared variables for the high and low 32 bits
of the target unique ID (UID).
The routine sdi_open_crg is used to instruct the
adapter 114 to logically open the specified
command/response queue (CRQ) with the specif ied upper
level protocol. Each CRQ, with the exception of the
Async CRQ, mu~t be opened before it can be used. The
parameter adptr is a pointer to an HBA object, ulp is the
upper level protocol and crq num is the CRQ number of the
device or node 115.
The routine sdi_close_crq is used to instruct the
adapter 114 to logically close the specified CRQ.
Parameter adptr i8 a pointer to an HBA object and crq_num
is the CRQ of the device or node 115.
The routine sdi_get_scatter_gather_info is used to
determine the adapter' 8 114 scatter/gather capability.
Paramater adptr is a pointer to an HBA object, capability
is the capability of the adapter 114 to handle
scatter/gather lists, max_entries is the maximum number
of entries in the list, and max_xfer is the maximum data
transfer per entry. If either of the latter two
parameters are unlimited, it should be set to a va~Lue of
--1. ~
The routine sdi_get_ssa_web_info obtains SSA wèb map
information from the adapter 114. The web information
will be transferred by the adapter into an assigned
. ~: 2ls~00a
-- 23 --
buffer. Parameters include adptr, a pointer to an BA
object, web_buff_p, a physical address of buffer,
web_buff_v, a virtual address of buffer, and buff_size/
the size of the buffer in bytes. Web information i8
5 tranaferred by the adapter 114 into the buffer whose
physical address i8 web_buff_p. The amount of
information is limited to buffer_8ize.
o~eratinq Sv~tem Der)~n(1~t Rout; ne~
Operating system dependent routines 400 enable the
10 SDI 113 to be portable across multiple operating systems.
FI~. 8 shows ANSI C source code prototypes for each of
the operating syf~tem routines operable with the SDI 113.
One skilled in the art will recognize the role of each of
the following routines as it i9 further ~ ;nr~d herein.
15 Further, the use of the operating system dependent
routines 400 will be discussed hereinafter by way of flow
charts
The routine sdi_pci_f ind_device is used to f ind the
next PCI device. The parameter driver_context is a
20 pointer to a driver-defined object associated with a
particular H!3A. The parameter is set by initialization
routine 150 sdi_initialize. Parameter bus is the
returned bus number, device is the returned PCI device
number, function is the returned PCI function number,
25 vendor_id is the PCI vendor ID, device_id is the PCI
device ID, index i8 the number o~ matched adapters to
. 218~000
, . .
-- 24 --
skip before beginning the search, and driver-context i8
a pointer to the driver defined object associated with an
HBA. The routine sdi_pci_find_device returns a constant
indicative of success or error including, no device
5 found, bad vendor ID, or unknown.
The routine sdi_pci_read_config_register is used to
read the adapter 114 configuration registers to determine
its configuration information. The routine is also used
to determine the adapter' s 114 IRQ and the address of the
lO adapter' 8 114 memory mapped registers . contents i5 the
returned contents of the register, reg_num is the
register number to read, bus is the PCI bus number,
device is the PCI device number, function is the PCI
function number, and driver context is a pointer to the
15 driver defined object associated with an H3A. A8 noted
above, driver-context is set by initialization routine
150 sdi_initialize . The routine
sdi_pci_read_conf ig_register returns a constant
indicative of success or error including, bad register or
2 0 unknown .
The routine sdi_map_physical_to_virtual is used to
map a physical address memory area to a virtual address.
The SDI 113 uses this routine to map the address of the
memory mapped registers from physical to virtual.
25 Parameter paddr is the physical address to map, size is
the size of the memory area, and driver_context is a
pointer to the driver-defined object a~ociated With the
- . 218400~
. ~ .
-- 2 5
X3A. There ib no return value a3sociated with this
routine .
The routine sdi_delay_task delays a current
operating system task. It is used during SDI 113 mailbox
5 routines 200. Parameter ticks is the number of ticks to
delay, which is dependent upon the granularity of the
timer. Parameter driver_context is the same as described
above. The routine has no return value.
The routine sdi_ticks~er_second return the
10 granularity of the operating system' 8 timer and is used
by the SDI 113 during mailbox routines 200. The
parameter driver_context is the same as is PYpl :~; nPd
above. The routine returns the number of ticks per
second which can then be used by the routine
15 sdi_delay_task.
Ada~ter Flln~tionalitY
In order for the SDI to operate, many of the
sof tware routines described above must be able to
communicate with the adapter 114. In the preferred
20 ~mh~ t of the pre8ent invention communication is made
operable via defined registers for adapter 114 as shown
in Fig. 9 A PCI 9060 interface controller is an example
of an interface controller suitable for this purpose. It
should be noted, however, that any adapter having similar
25 flln~ ni~l capability of the 9060 controller can also be
u8ed. Moreover, the regieter8 deecribed could be
~. 218400~
-- 26 --
implemented via software on the host computer system.
All communication between the adapter driver 110
comprising the SDI 113 is initiated by the adapter driver
110. There are two types of messages: mail messages and
packeta. Mail messages, shown in Fig. 3 as 202, 203, are
~;~tP messages and are placed in registers 5-8 in
Fig. 9. Packets, shown in Fig. 3 as 304-307, are used to
transfer SSA ~ -~q~P~ ) via registers 1, 2, to
the adapter 114 and to receive responses in registers 3,
4 from the adapter 114. These message transfers can be
accomplished across any standard bus architectures
including GIO, PCI, Sbus or VME. Specifically, ~
are sent to the adapter 114 by copying the physical
address of the packet to register 1 or 2. Responses are
received from the adapter 114 in registers 3 or 4.
Register 9 of Fig. 9 is used to indicate to the adapter
114 that a command or mail message has been written to
one of the registers, and register 10 is used to indicate
to the SDI that a response has been written to one of the
registers. ~:n the present embodiment, the registers thus
described are offset 0x40 from the address of the memory
mapped registers.
Operation gf the SDI
The operation of the adapter driver 110 comprising
the SDI 113 in combination with the adapter 114 will now
be exPlained
. 2184000
.
-- 27 --
Fig. 10 shows the highest level of operation of the
SDI 113 and adapter 114. At step 2070, the adapter
driver 110 is initialized. At atep 2071, request and
response queues are initialized on adapter 114 to support
the sending and receiving of packets. Final
initialization routines for adapter 114 are implemented
at step 2072 including ini~ ; 7; n~ a serial controller
clock, on-board clock, and PCI interface control. Then
an infinite loop is entered compri3ing steps 2073 and
2074 in which the response_wait_queue is checked and
other functions ;n~ ;n~ for example, serial controller,
timer and clock, and I.ED control are implemented. Step
2074 is also the point at which interr~al process queues
of the adapter are handled.
Initi~ tio~
The SDI 113 and adapter 114 are first initialized
using the SDI routines described earlier. With reference
to FIG. 11, sdi_get_hba_object_size is first called in
step 1010 after which sdi_initialize is called in step
1011. From within the routine sdi_initialize, operating
system dependent (OSD) routines sdi_pci_find_device and
sdi pci_read config_register are called as shown in Fig.
12. That is, each host bus adapter (H3A), that is an
adapter supporting the functions of adapter 114, will be
found via steps 1020, 1021 and 1023. If no more devices
are found, control is passed back to sdi_initialize at
218~00~
~ . .
-- 28 --
step 1022. Again with reference to Fig. 11,
sdi_initialize is called via step 1012 until all H3Aa in
the system have been found. At this point,
sdi_enable_hba is called in step 1015 for each H;3A. One
5 of the functions of sdi_enable _hba is to call, OSD
function sdi_map_physical_to_virtual as shown in step
1025 of Fig. 13. After this OSD function is called the
control is returned in step 1026 to sdi_enable_hba. If
there are no more BAs to enable, the process is
terminated in step 1014 of Fig. 11.
After each H~3A has been enabled, any one, or
combination, of functions A-J can next be called. Each
of these routines is illustrated, respectively, in FIGs.
14-23. Which routines are called depend on the operating
15 system in which the adapter driver 110 is located. For
example, sdi_hba_rt_virtual_address need only be called
for the Netware operating system, but not for the Windows
NT operating system.
Fig. 14 depicts the calling of sdi_hba_ir~ in step
3000. The procedure returns at step 3001.
Fig. 15 depicts the calling of
sdi_hba_rt_virtual_addr in step 3010 and returning in
step 3 011.
Fig. 16 shows sdi_hba_rt physical_addr being called
in step 3020 and then returning in step 3021.
Fig. 17 illustrates in step 3030 the calling of
routine sdi_hba_rt_size and return in 8tep 3031.
218~0~
-- 29 --
Fig. 18 shows sdi_hba_pci_bus_number being called in
step 3040 and then returning in step 3041
Fig. 19 shows in step 3050 a call to
sdi_hba_pci_device and then return in step 3051.
Fig. 20 depicts a call to sdi_get physical_base_addr
in step 3060 and a return in step 3061.
Fig. 21 shows sdi_get_hba_info being called in step
3070 and a return in step 3071.
Fig. 22 shows a call to sdi_get_sg_info in step
3080. If at step 3081 the return value of
sdi_get_sg_info indicates that the adapter 114 has
scatter/gather capability then the device driver is
informed that the adapter driver 110 can support
scatter/gather. If the adapter 114 cannot support
15 scatter/gather, then the device driver is informed
likewise in step 3083. The procedure returns at step
3084 .
Fig. 23 Yhows at step 3090 a call to
sdi_get_web_info. The information returned is processed
20 in step 3091. That is, the returned values can be stored
in a data structure representative of the ~erial network
or web. The procedure returns in step 3~)92.
Identifvinq Devices
Once the adapter driver 110 ha~ found and
25 initialized each E~BA or adapter 114, each SSA device
connected to each HBA must be identified and a data
q~
r~ ~ 218~o~
- 30 --
structure repreaentative of the device must be
init;~ ed. This process is ~rl~;n.o~ with reference to
Pigs. 24 and 25. In step 1090, sdi_get_next_device is
called to identify the first device on a web or network.
5 This routine returns information about those SSA devices
that support a prede~ ~;nPd upper level protocol. If a
device is found in step 1091, the routine will return a
unique command/request queue (CRQ) number for the upper
level protocol- ~ hle device found. If no more
10 devices are found in step 1091 then the procedure is
exited .
For each device found a device structure iæ
initialized in step 1093 and at step 1094 sdi_open_crq is
called to logically open the device.
The result of finding all HBAs and devices connected
to each HBA is a data 3tructure such as that shown in
Fig. 25. Each element 50 represents an HBA, or adapter
114, pointed to by pointer 51. Each HBA 51 is further
associated with device structures 52 representing each
20 identified device connected to that particular adapter or
HBA .
Sendinq a Packet
A command from a device driver through the SDI will
next be explained with reference to Fig. 26. Before any
25 packets can be sent at all, a pool of packets must be
pre-positioned by calling sdi_stock_packet pool in ~tep
2 1 8 4 0 0
-- 3 1
1030. Upon receipt of an I/O request from the device
driver in step 1031, sdi_get_packet_from_pool is called
in step 1032. If no packeta are available at step 1033,
the process returns at step 1034. If a packet is
5 available, the device driver I/O request, which may be in
accordance with a SCSI protocol for example, is
tr~nRlat~d into its SSA equivalent in step 1035. Mapping
of the SCSI-2 protocol to SSA is implemented in
acco, dc.llce with the SSA do~ ~; nn noted in
10Description of the Prior Art section of this
specification. Mapping a SCSI-2 protocol to fibre
channel is likewire set out in the f ibre channel
documentation .
Once tr~nRlz~;nn has been completed, the ssa_request
15 structure is completed in step 1036 and then
sdi_send_packet i8 called in step 1037. The sending of
a packet is now complete and the procesR returns in step
1038 .
If the adapter 114 has scatter/gather capability, as
20 determined by an earlier call to
sdi_get_scatter_gather_info, then sending a packet is
slightly different than as ]ust explained. With
reference to Fig. 27, sdi_stock_sglist_pool is first
called in step 1040 after which sdi_stock_packet_pool is
25 called in step 1041. As in the earlier case, upon
receiving an I/O requeRt from the device driver in step
1042, sdi_get_packet_from_pool is called in step 1043 and
.~ 218~000 `
-- 3 2
if none ia available in step 1044, the process returns.
If, however, a packet is available the proce~g cnnt;n~
to step 1046 in which sdi get_sglist_from_pool is called.
If no scatter/gather list is available in step 1047, the
5 packet previously retrieved i8 returned to the packet
pool in step 1048 and the process returns.
Assuming a scatter/gather list is available in step
1047, the I/O request is translated to its SSA equivalent
in step 1050, the ssa_request structure is completed in
0 step 1051, the scatter/gather list ia linked ~o the
packet in step 1052 and then sdi_send_packet is called in
1053 Finally, the process returns at step 1054 after
step 1053.
It was noted earlier that the adapter 114 includes
15 an asynchronous event command/response queue (Async CRQ
302 in FIG. 3), and that there are special async data
structures as shown in FIG. 4b. The hAn~ll; n~ of A3ync
events represents a dramatic difference between hi~nt11 ;n3
of parallel SCSI and SSA. SSA is a network of device
20 attachments, and the at~ tF~ may be dynamic with
devices being removed and added while the network is in
operation. The Async CRQ responds to these events (e . g .,
device removed, device attached, local port dis~nn~ct~od~
local port connected) and passes the information to the
25 adapter driver 110 which maintains a list of available
nodes 115.
The Async Packet is a command whose function is to
~18~000
. ~
- 3 3
wait for the next Asynchronous event and report it. The
command may remain pending ;n-lPf;n;t~ly. In the
preferred embodiment, some number of Async Packets are
posted to the Async CRQ to allow a series of event
5 notifications to pass from the adapter 114 to the adapter
driver 110. The Command/Response ---^hAn; Pm is uaed in
this way to allow the Async Packet support to make uae of
the same interf ace as the other non-Async CRQ methods .
In other words, the adapter driver 110 may send one
10 or more Async packets to the adapter 114 using
sdi_sent_packet. The CRQ number for the Async packets
should be set to a constant reserved for the Async CRQ.
When an asynchronous event occurs, the adapter 114
returns the Async packet to the adapter driver 110. The
5 packet's ~;~llh2i~k routine will then initiate the
r iate procegging for the type of Agync event .
EIandlinq ComT~leted Packets
Fig. 28 illustrates the process for completing
packets. When a response is written to one of the
20 response registers 3 or ~ of Fig. 9 and the local to PCI
doorbell register 10 is set, as will be further explained
below, the SDI is interrupted to process the response
packet. In step 1060, the packet status is determined
from the scsi_status field of the ssa_response. If the
25 status is not O~, i.e. non-zero, in step 1061, an error
code is set in step 1062. If the status is zero both the
;~. 218~00~
-- 34 -
packet and scatter/gather list are returned in steps 1063
and 1064 and then the status code is returned to the
device driver in step 1065.
Other F~ tiorl~
Fig. 29 depicts a process for closing CRQs and
resetting HBAs if n~re~s~ry or if desired. For instance,
some operating systems, e.g. ~etware, can dynamically
unload drivers. The present invention supports such a
capability through the procedure shown in Fig. 29.
Beginning at step 1070, a counter is set to zero and then
at step 1071 it is determined whether the CRQ number
equivalent to that counter number is open. If the CRQ is
open, the CRQ will then be closed at step 1072 by calling
sdi_close_crg. The procedure proceeds to step 1073. If
the CRQ is not open at step 1071, then the procedure
advances directly to step 1073. At step 1073 it is
determined whether the counter exceeds a predetermined
maximum number o~ devices. If not, the counter is
incremented at step 1074 and the process loops back to
step 1071. If the counter is greater than or e~[ual to
the maximum number of devices at step 1073, then
sdi_reset_hba is called at step 1075, thus resetting the
HBA. If there are more HBAs at step 1076, the process
loops back to step 1070, otherwise, the process returns
at step 1077.
`~ 218~0~0
- 35 -
As was noted earlier, mail messages are; ~ ltP
messages and the SDI expects responses f rom the adapter
114 before P~P~'Ut;n~ any other routines. Accordingly,
the SDI 113 also includes OSD routines that will delay
5 other proces~ing until mail messages have completed.
Fig . 3 0 illustrates the use of these routines which are
called from within each mailbox routine 200. At step
1080, sdi_ticks per_second is called. A multiple of the
return value of that routine is then passed to
10 sdi_delay_task at step 1081 in order to effectuate the
delay. Step 1082 then returns control back to the
mailbox routine 200 that was previously called.
Fig. 31 illustrates a typical interrupt handler
operable with the SDI 113. Using the return value of
15 sdi_hba_count from step 1100, sdi_interrupt is called in
step 1103 after step 1101 for each adapter 114 in the
system. If there are no more HBAs, the process returns
in step 1102. A8 noted in the earlier description of the
sdi_interrupt routine, the routine
20 packet_complete_c;-llh~l-k is called from within
~di_interrupt .
Flow of ~ n~/Regpongeg setween the SDI and AdaPter
The adapter driver 110 passes a packet to the
adapter 114 by calling sdi_send packet. A8 explained
25 earlier, the packet field complete_~ ~l lh~--k points to an
OSD function to be called when the packet completes,
- ' 2~8gO~d
-- 36 --
while other packet f ielda describe the particular
command .
With reference to Fig. 32, at step 2000,
sdi_send_packet places the packet on a request_Q, a
5 linked list of all packets pending tr~nr~ n to the
adapter 114. The routine sdi_send packet also calls
sdi_start_request_queue at 2005 which is shown in more
detail in Fig. 33. After step 2005, the procedure
returns. If routine sdi_start_request_queue is unable to
10 service the queue due to no available command slots, Fig.
g elements 1, 2, the routine will be called again from
the sdi_interrupt function when a constant indicative of
sdi_interrupt_slot_free is set in the status register 10
in Fig. 9.
The routine sdi_start_request_queue attempt~ to
service the first packet of the request queue by writing
the packet pointer to a free command slot register 1, 2.
A command slot register 1, 2 is free when its contents is
zero. According to the flow chart of Fig. 33, if there
20 is no entry on the request queue the routine
start_request_queue returns per step 2010. On the other
hand, if there is an entry on the request queue at step
2010, a counter is reset at step 2011. If the counter is
zero at step 2013 then the routine goes to step 2014
25 where it is de~rrn; n~ whether command slot 0, register
1 in Fig. 9, is not in use. If command slot 0 is not in
use the packet is removed from the request queue in 8tep
.,
218~0~Q
-- 37 --
2015 and the packet pointer (pkt) is written to command
slot 0 in step 2016. Then, at step 2017, a constant
sdi_interrupt_packet_command i3 set in the
pci_to_local_doorbell register 9 of Fig. 9 and then the
5 routine restarts.
If at step 2014 command slot 0 is in use, the
counter is in.~ d at step 2018 and the routine flows
back to step 2013. Thus if the counter is not 0 at step
2013, the counter is tested as to whether it is equal to
10 1. If no, the routine returns. If the counter is equal
to 1, then the routine tests if command slot 1, register
2 in Fig. g, is not in use in step 2021. If command slot
is not in use, then the packet is removed f rom the
request queue in step 2022 and the packet pointer (pkt)
is written to command slot 1 in step 2023. Thereafter,
the constant sdi_interrupt_packet_command is set in the
pci_to_local_doorbell register 9 of ~ig. 9 and then the
routine restarts as explained earlier. If at step 2021
command slot 1 was in use, the counter is incremented at
20 step 2018 as shown.
If a command slot register 1, 2 has been written by
the sdi_start_request_queue routine, the interrupt to the
adapter 114 is set by writing an
sdi_interrupt_packet_command bit to the
25 pci_to local_doorbell register 9 as explained above. ~n
response to the interrupt, the adapter 114 enters a
doorbell_interrupt routine as shown in 3~ig. 34. This
~; 218~
-- 38 --
routine, at step 2030, reads the Interrupt and Control
Status register 11 of Fig. 9 and determine3 if the
sdi_interrupt packet_eommand bit has been set. If it has
not been set the routiner at step 2034, writes the
5 constant sdi_interrupt_packet_command bit clear in the
pci_to_1ocal_doorbell register 9, thus elearing the
interrupt, and then returns. If, on the other hand, the
sdi_interrupt_packet_eommand bit is set at step 2031,
then the doorbell_interrupt routine calls the
10 cheek_emd_list routine, shown in detail in Fig. 35.
Generally the check_cmd_list funetion gets the
pointer to the packet from the valid command list entry
and passes it to adapter 114 firmware for processing
according to well known processes. The command list
15 entry is cleared thus making it available for new
packets. Then, the adapter 114 signals availability of
a command slot register 1, 2 to the adapter driver 110 by
writing the sdi_interrupt_slot_free bit in the
local_to_pci_doorbell register 10 of Fig 9.
In particular, with reference to Fig. 35, a counter
cmds_taken is reset to zero in step 2040. Thereafter, at
step 2041, if command slot 0 is not zero the packet
pointer is read from command slot 0 in step 2042, command
slot 0 is reset in step 2043, the counter cmds_taken is
incremented in step 2044, and finally, the read packet
pointer is placed on an internal process queue of the
adapter 114. If command slot 0 has a zero value at step
~: 21840~0
-- 39 -
2041, then command slot 1 is tested for a zero value in
step 2050. If command slot 1 is nonzero, the packet
pointer is read from command slot 1 in step 2051, command
alot 1 is reset in step 2052, the counter cmds_taken is
5 incremented in step 2044, and finally, as with the
command read from command slot 0, the read packet pointer
from command slot 1 is placed on an ;n~rn~l proce8s
queue of the adapter 114.
If both command slots registers 1, 2 of Fig. 9 have
10 zero values, step 2055 determines whether the counter
cmds_taken is not zero. If cmds_taken is in fact not
zero, then a constant sdi_interrupt slot_free is set in
the local_to pci_~ h~l 1 in step 2056 and the function
returns . If cmds_taken is zero the function; ~ l y
15 returns.
Upon command completion, that is the adapter 114
properly processed the command, the adapter 114 calls the
resp_send routine shown in Fig. 36. The resp_send
routine in step 2060 places the pointer to the packet in
20 the resp_wait_queue. The resp_wait_queue is a linked
list of packets pending for transmission to the adapter
driver 110. In step 2061, resp_send calls the function
check_resp_wait_queue and then returns. The routine
check_resp_wait_queue attempts to service the
25 resp_wait_s~ueue's first entry by writing the packet
pointer to a free response slot 3, 4 of Fig. 9. A slot
i3 free if it~ contents i~ zero. If, however,
-
218~00~ ;
-- 40 --
check_resp_wait_queue is unable to immediately service
the queue due to nonzero response slot registers 3, 4,
the routine will eventually be called again from the
adapter driver 110 main loop, shown in Fig. 10.
Fig. 37 shows the check_resp_wait_~ueue function in
detail. In step 2080, the flag resp_sent is reset to
zero. Thereafter, at step 2081 it is detprm;n~d whether
there is an entry on the resp_wait_queue. If not, it is
det~rm;n.ocl at step 2082 whether counter resp_sent is not
0. If the counter is zero the function returns.
Otherwise, in step 2083, an sdi_interrupt_packet_response
bit is set in the local_to_pci_doorbell register 10.
If there is an entry on the resp_wait_queue at step
2081, step 2085 determines whether response slot 0, i.e.
register 3, is zero. If 80, the packet is taken from the
resp_wait_queue in step 2086 and the token is written to
response slot 0 in step 2087. In step 2088 flag
resp_sent is set to 1 and the function goes back to step
2081. If response slot 0 is not zero in step 2085, then
response slot 1, i.e. register ~, is tested for its
value. If zero, then the packet is taken from the
resp_wait_queue in step 2091 and the token is written to
response slot 1 in step 2092. If neither response slot
has a zero value, then the function is routed back to
step 2082 as shown in Fig. 38.
A8 explained earlier the token is used as a means
for the adapter driver 110 to map a response back to the
21~DDO
-- 4 1
original command. The token is set to the logical (or
virtual ) address of the packet . Upon reading the token
from the response slot register 3, 4, the adapter driver
110 looks up pkt based on the token value and the
5 completed packet status can then be processed as
explained earlier with reference to FIG. 28.
As described above, if a response slot register 3,
4 has been written, the adapter driver 110 is signaled by
setting the sdi_interrupt_packet_response bit in the
10 local_to_pci_doorbell register 10. With the
local_to pci_doorbell set, the adapter driver' 8 110
sdi_interrupt function is entered. This function is
illustrated in Fig. 38.
In step 2100 of Fig. 38, the cause is read from the
15 local_to_pci_doorbell register 10 and then i8 written
back to local_to_pci doorbell register 10 to clear the
interrupt cause. If the interrupt cause ANDED with a
conatant representative of sdi_interrupt_slot_free is yes
in step 2102 then sdi_start_request_queue is called in
20 step 2110. Otherwise, if the interrupt cause ANDED with
a c o n 8 t a n t r e p r e 8 e n t a t i v e o f
sdi_interrupt_packet_response is yes in step 2103,
sdi_process_response_list is called in step 2111. The
cause is again evaluated in step 2104. If the cause is
25 zero the function returns. Otherwise, the function loops
back to step 2100.
The routine sdi_process_response list, depicted in
218~00~ i
-- 42 --
Fig. 39, is used to check for entries in the response
slot registers 3, 4. According to the figure, on start-
up a counter i8 set to zero in step 2120 . The counter' 8
value is thereafter checked in step 2121. If the counter
5 is zero, then response 810t 0 is checked for a nonzero
value in step 2123. If response slot 0 is not nonzero
then the counter is inc;, ~-d in step 2135 and the
routine proceeds back to step 2121. If response slot 0
is nonzero then the packet is read therefrom in step
2123, the response slot 0 is reset to zero to make it
available, the complete_c~l1h~-k function for the packet
is called in step 2125, and then the counter is
in~:L ~ t e~l .
If at atep 2121, the counter is not equal to zero,
and the counter e~uals 1 at step 2130, response slot 1 is
checked for a nonzero value in step 2131. If response
slot 1 has a nonzero value, the packet i3 read from
response 810t 1, response slot 1 is then reset to zero in
step 2133 to make it available, the complete_callback
20 function is called in step 2134 and the counter is
incremented. I~ response slot 1 has a 0 value at step
2131 then the counter is simply incremented. However, if
at step 2130, the counter is not equal to 1, then the
function returns. In other words, there are no responses
25 to be read.
The SDI 113 routines and data structures described
herein enable economical development of adapter drivers
218400~
-- 43 --
to permit protocol ;n~ ~-t;hle device drivers and
targets to pass I/0 request~ and responses to and from
one another. Moreover, the routines described herein are
designed to operate independent of operating system
5 environment.
While the present invention has been described with
reference to particular routines and data ~tructures,
those ~killed in the art will recognize that some of the
routines may be c inp~l and others may be broken down
10 further and the data structures may be arranged
differently. Furthermore, as noted previously, the SD
invention is operable in a plurality of operating systems
including MIPS, Intel I960, Pentium, Power PC and SPARC
based systems. Accordingly, not all disclosed routines
15 are necessary for any particular implementation. Further
still, tho~e skilled in the art will appreciate that
additional error trapping and h;3~1 in~ routines, for
example, may be included in any completed program code.
