Proprietary and Confidential to PMC-Sierra, Inc.
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
ABOUT THIS MA NUA L A ND S/UNI-4X622
This manual describes the S/UNI-4x622 (PM5358) device driver. It describes the driver’s
functions, data structures, and architecture. This manual focuses on the driver’s interfaces and
their relationship to your application, real-time operating system, and to the device. It also
describes in general terms how to modify and port the driver to your software and hardware
platform.
Audience
This manual was written for people who need to:
• Evaluate and test the S/UNI-4x622 devices
• Modify and add to the S/UNI-4x622 driver’s functions
• Port the S/UNI-4x622 driver to a particular platform.
References
For more information about the S/UNI-4x622 driver, see the driver’s release notes. For more
information about the S/UNI-4x622 device, see the documents listed in Table 1 and any related
errata documents.
Table 1: Related Documents
Document NumberDocument Name
PMC-1991044Saturn User Network Interface (4x622) Telecom Standard Product
Data Sheet
Note: Ensure that you use the document that PMC-Sierra issued for your version of the device
and driver.
Revision History
Issue No.Issue DateDetails of Change
Issue 1April, 2001Document created
Proprietary and Confidential to PMC-Sierra, Inc.2
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Legal Issues
None of the information contained in this document constitutes an express or implied warranty by
PMC-Sierra, Inc. as to the sufficiency, fitness or suitability for a particular purpose of any such
information or the fitness, or suitability for a particular purpose, merchantability, performance,
compatibility with other parts or systems, of any of the products of PMC-Sierra, Inc., or any
portion thereof, referred to in this document. PMC-Sierra, Inc. expressly disclaims all
representations and warranties of any kind regarding the contents or use of the information,
including, but not limited to, express and implied warranties of accuracy, completeness,
merchantability, fitness for a particular use, or non-infringement.
In no event will PMC-Sierra, Inc. be liable for any direct, indirect, special, incidental or
consequential damages, including, but not limited to, lost profits, lost business or lost data
resulting from any use of or reliance upon the information, whether or not PMC-Sierra, Inc. has
been advised of the possibility of such damage.
The information is proprietary and confidential to PMC-Sierra, Inc., and for its customers’
internal use. In any event, no part of this document may be reproduced in any form without the
express written consent of PMC-Sierra, Inc.
Proprietary and Confidential to PMC-Sierra, Inc.12
Document ID: PMC-2010419, Issue 1
1 INTRODUCTION
The following sections of the S/UNI-4x622 Device Driver Design Specification describe the
S/UNI-4x622 device driver. The code provided throughout this document is written in ANSI-C.
This has been done to promote greater driver portability to other embedded hardware (Section 5)
and Real-Time Operating System (RTOS) environments (Section 6).
Section 2 of this document, Software Architecture, defines the software architecture of the
S/UNI-4x622 device driver by including a discussion of the driver’s external interfaces and its
main components. The Data Structure information in Section 3 describes the elements of the
driver that either configure or control its behavior. Included here are the constants, variables, and
structures that the S/UNI-4x622 device driver uses to store initialization, configuration, and status
information. Section 4 provides a detailed description of each function that is a member of the
S/UNI-4x622 driver Application Programming Interface (API). This section outlines function
calls that hide device-specific details and application callbacks that notify the user of significant
device events.
PM5358 S/UNI-4x622 Driver Manual
Introduction
Proprietary and Confidential to PMC-Sierra, Inc.13
Document ID: PMC-2010419, Issue 1
2 SOFTWARE ARCHITECTURE
This section describes the software architecture of the S/UNI-4x622 device driver. This includes a
discussion of the driver’s external interfaces and its main components.
2.1 Driver External Interfaces
Figure 1 illustrates the external interfaces defined for the S/UNI-4x622 device driver.
Figure 1: Driver External Interfaces
Application
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Function CallsApplication Callbacks
Service Callbacks
S/UNI-4x622 Device Driver
Service Calls
Hardware
Interrupts
S/UNI-4x622 Devices
Register
Accesses
RTOS
Application Programming Interface
The driver Application Programming Interface (API) is a list of high-level functions that can be
invoked by application programmers to configure, control and monitor S/UNI-4x622 devices.
The API functions perform operations that are more meaningful from a system’s perspective. The
API includes functions such as:
Proprietary and Confidential to PMC-Sierra, Inc.14
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
• Initialize the device(s)
• Perform diagnostic tests
• Validate configuration information
• Retrieve status and counts information
The driver API functions use the services of the other driver components to provide this systemlevel functionality to the application programmer.
The driver API also consists of callback routines that are used to notify the application of
significant events that take place within the device(s) and module.
Real-Time OS Interface
The driver’s RTOS interface provides functions that let the driver use RTOS services. The driver
requires the memory, interrupt, and preemption services from the RTOS. The RTOS interface
functions perform the following tasks for the driver:
• Allocate and de-allocate memory
• Manage buffers for the ISR and the DPR
• Enable and disable preemption
The RTOS interface also includes service callbacks. These are functions installed by the driver
using RTOS service calls such as installing interrupts. These service callbacks are invoked when
an interrupt occurs.
Note: You must modify RTOS interface code to suit your RTOS.
Hardware Interface
The hardware interface provides functions that read from and write to the device registers. The
hardware interface also provides a template for an ISR that the driver calls when the device raises
a hardware interrupt. You must modify this function based on the interrupt configuration of your
system.
2.2 Main Components
Figure 2 illustrates the top level architectural components of the S/UNI-4x622 device driver. This
applies in both polled and interrupt driven operation. In polled operation the ISR is called
periodically. In interrupt operation the interrupt directly triggers the ISR.
The driver includes eight main components:
• Module and device(s) data-blocks
• Interrupt-service routine
• Deferred-processing routine
Proprietary and Confidential to PMC-Sierra, Inc.15
Document ID: PMC-2010419, Issue 1
• Alarm, status and counts
• Section Overhead
• Line Overhead
• Path Overhead
• Payload Processor
• Interface Configuration
• APS Configuration
Figure 2: Driver Architecture
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Application
Function
Calls
Application
Callbacks
Deferred
Processing
Routine
Interrupt
Context
Interrupt
Service
Routine
Hardware
Interrupts
Driver API
Alarm, Status &
Statistics
Diagnostics
Module
Data Block
Device Data Blocks
.......
Hardware Interface
S/UNI-4x622 Devices
APS Configuration
Section Overhead
Line Overhead
Path Overhead
Payload Processor
Interface Configuration
Register
Accesses
Service
Callbacks
RTOS
RTOS Interface
Service
Calls
Module Data-Block and Device(s) Data-Blocks
The Module Data-Block (MDB) is the top layer data structure, created by the S/UNI-4x622 driver
to store context information about the driver module, such as:
•Module state
Proprietary and Confidential to PMC-Sierra, Inc.16
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
• Maximum number of devices
• The DDB(s)
The Device Data-Block (DDB) is contained in the MDB, and initialized by the driver module for
each S/UNI-4x622 device that is registered. There is one DDB per device and there is a limit on
the number of DDBs, and that limit is set by the USER when the module is initialized. The DDB
is used to store context information about one device, such as:
• Device state
• Control information
• Initialization parameters
• Callback function pointers
Interrupt-Service Routine
The S/UNI-4x622 driver provides an ISR called suni4x622ISR that checks if there is any valid
interrupt condition present for the device. This function can be used by a system-specific
interrupt-handler function to service interrupts raised by the device.
The low-level interrupt-handler function that traps the hardware interrupt and calls
suni4x622ISR is system and RTOS dependent. Therefore, it is outside the scope of the driver.
Example implementations of an interrupt handler and functions that install and remove it are
provided as a reference in section 5.2. You can customize these example implementations to suit
your specific needs.
See section 2.5 for a detailed explanation of the ISR and interrupt-servicing model.
Deferred-Processing Routine
The S/UNI-4x622 driver provides a DPR called suni4x622DPR that processes any interrupt
condition gathered by the ISR for that device. Typically, a system specific function, which runs as
a separate task within the RTOS, will call
suni4x622DPR.
Example implementations of a DPR task and functions that install and remove it are provided as a
reference in section 5.2. You can customize these example implementations to suit your specific
needs.
See section 2.5 for a detailed explanation of the DPR and interrupt-servicing model.
Alarms, Status and Counts
The alarm, status and counts section is responsible for monitoring alarms, tracking devices status
information and retrieving counts for each device registered with (added to) the driver.
Proprietary and Confidential to PMC-Sierra, Inc.17
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Section Overhead
The Section Overhead section provides functions to control and monitor the section overhead
processing. Read / Write access is given to the section trace message (J0). This message is
compared with a configurable reference and mismatches are reported. Section BIP-8 (B1) errors
are accumulated in a counter that can be read. Section overhead alarms are detected and reported.
For diagnostic purposes, errors can be introduced in the section overhead bytes.
Line Overhead
The Line Overhead section provides functions to configure and monitor the line overhead on both
the receive and transmit sides. Read / Write access is given to the APS bytes (K1 and K2) and
most other overhead bytes. Line BIP-8 (B2) errors are accumulated in a counter that can be read.
Line overhead alarms are detected and reported. For diagnostic purposes, errors can be introduced
in the line overhead bytes. Additional functions are provided to automatically insert line RDI and
line AIS.
Path Overhead
The Path Overhead section provides functions to configure and monitor the path overhead on
both the receive and transmit sides. Read / Write access is given to the path trace message (J1)
and the path signal label (C2). Both are compared with a configurable reference and mismatches
are reported. Path BIP-8 (B3) errors and REI are accumulated in a counter that can be read. Path
overhead alarms are detected and reported. For diagnostic purposes, errors can be introduced in
the path overhead bytes. Additional functions are provided to automatically insert path AIS, and
force generation of individual outgoing justification events.
Payload Processor
The Payload Processor section provides functions to configuring the payload for ATM or POS
processing. Function is provided to configure ATM/POS processing.
Interface Configuration
The Interface Configuration section provides functions to configure the FIFO, line and system
side interface for ATM or POS mode. Functions are provided for FIFO management to separate
the line side timing from the higher layer ATM/POS link layer timing. The Line interface is
responsible for receive/transmit line clock configuration. The System interface is responsible for
configuring the system to UTOPIA Level 3 or POS-PHY Level 3 interface for either ATM or POS
application.
APS Configuration
The APS Configuration section provides function to configure the operating mode for the device
to either a protect or working mate in a APS failover condition.
Proprietary and Confidential to PMC-Sierra, Inc.18
Document ID: PMC-2010419, Issue 1
2.3 Software States
Figure 3 shows the software state diagram for the S/UNI-4x622 driver. State transitions occur on
the successful execution of the corresponding transition functions shown. State information helps
maintain the integrity of the MDB and DDB(s) by controlling the set of operations allowed in
each state.
Figure 3: Driver Software States
suni4x622ModuleOpen
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Idle
suni4x622ModuleStart
MODULE STATES
suni4x622ModuleClose
suni4x622ModuleStop
Ready
suni4x622Reset
Start
suni4x622ModuleClose
Start
suni4x622Addsuni4x622Delete
Present
suni4x622Init
suni4x622Activate
Inactive
suni4x622Reset
Active
suni4x622DeActivate
PER-DEVICE STATES
Proprietary and Confidential to PMC-Sierra, Inc.19
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Module States
The following is a description of the S/UNI-4x622 module states. See section 4.1 for a detailed
description of the API functions that are used to change the module state.
Start
The driver module has not been initialized. In this state the driver does not hold any RTOS
resources (memory, timers, etc); has no running tasks, and performs no actions.
Idle
The driver module has been initialized successfully. The Module Initialization Vector (MIV) has
been validated, the Module Data Block (MDB) has been allocated and loaded with current data,
the per-device data structures have been allocated, and the RTOS has responded without error to
all the requests sent to it by the driver.
Ready
This is the normal operating state for the driver module. This means that all RTOS resources have
been allocated and the driver is ready for devices to be added. The driver module remains in this
state while devices are in operation.
Device States
The following is a description of the S/UNI-4x622 per-device states. The state that is mentioned
here is the software state as maintained by the driver, and not as maintained inside the device
itself. See section 4.3 for a detailed description of the API functions that are used to change the
per-device state.
Start
The device has not been initialized. In this state the device is unknown by the driver and performs
no actions. There is a separate flow for each device that can be added, and they all start here.
Present
The device has been successfully added. A Device Data Block (DDB) has been associated to the
device and updated with the user context, and a device handle has been given to the USER. In this
state the device performs no actions.
Inactive
In this state the device is configured but all data functions are de-activated including interrupts
and alarms, as well as status and counts functions.
Active
This is the normal operating state for the device. In this state, interrupt servicing or polling is
enabled.
Proprietary and Confidential to PMC-Sierra, Inc.20
Document ID: PMC-2010419, Issue 1
2.4 Processing Flows
This section describes the main processing flows of the S/UNI-4x622 driver components.
The flow diagrams presented here illustrate the sequence of operations that take place for
different driver functions. The diagrams also serve as a guide to the application programmer by
illustrating the sequence in which the application must invoke the driver API.
Module Management
The following diagram illustrates the typical function call sequences that occur when initializing
or shutting down the S/UNI-4x622 driver module.
Figure 4: Module Management Flow Diagram
START
suni4x622ModuleOpen
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Performs module level initializat ion of the driver. Validates the Module
Initialization Vector (MIV). Allocates memory for the MDB and all its
components (i.e. all the memory needed by the driver) and then initializes
the contents of the MDB with the validated MIV.
suni4x622ModuleStart
suni4x622AddInitProfile
suni4x622DeleteInitProfile
suni4x622ModuleStop
suni4x622ModuleClose
END
Performs module level startup of the dri ver. This involves allocating RTOS
resources such as semaphores and timers and installing the ISR handler
and DPR task.
Register an initialization profile. This allows the user to store pre-defined
parameter vectors that are validated ahead of time. When the deviceinitialization function is in voked only a profile number need t o be passed.
This method simplifies and expedites the above operations.
Perform all device level functions here (add, init, acti vate, de-activate,
reset, delete,...)
De-register an initialization profile previously registered with the driver.
Performs Module level shutdown of the driver. This involves deleting all
devices currently installed and de-allocating all timers and s emaphores as
well as removing the IS R handler and DPR task.
Performs module level shutdown of the driver. De-allocates all the driver's
memory.
Device Management
The following figure shows the typica l func tion ca ll sequ ence s that the dr iv er uses to add,
initialize, re-initialize, and delete the S/UNI-4x622 device.
Proprietary and Confidential to PMC-Sierra, Inc.21
Document ID: PMC-2010419, Issue 1
Figure 5: Device Management Flow Diagram
START
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
suni4x622Add
suni4x622Init
suni4x622Activate
suni4x622Reset
suni4x622DeActivate
suni4x622Reset
Detects the new device in hardware, assigns a DDB to the new device
andstores the user's context for the device. Returns a device handle to
the user
Applies a reset to the device and initializes the device registers
and associated RA Ms based on the DIV passed by the user. The
user may only pass a profile number, which corresponds to a
previously saved & validated set of configurations (by using
suni4x622AddInitProfile
Prepares the device f or normal operation by enabling interrupts and
other global enables. ISR routines are installed when the module is
started using
operational and all other API can be invoked.
In order to re-initi alize the device, reset the device using
suni4x622Reset
again.
De-activates the device and removes it from normal operation.
This involves disabling the device interrupts. ISR routines for this
device are removed
when the module is closed.
Applies a software reset to the device to put it in its def ault startup
state.
sysSuni4x622ISRHandlerInstall
and go through the initialization sequence
usingsysSuni4x622ISRHandlerRemove
)
. The device is now
suni4x622Delete
END
Removes the device from the list of devices being controlled by the
S/UNI-4x622 driver. This function de-allocates the device context
information for the device being deleted.
2.5 Interrupt Servicing
The S/UNI-4x622 driver services device interrupts using an Interrupt-Service Routine (ISR) that
traps interrupts, and a Deferred-Processing Routine (DPR) that actually processes the interrupt
conditions and clears them. This lets the ISR execute quickly and exit. Most of the
time-consuming processing of the interrupt conditions is deferred to the DPR by queuing the
necessary interrupt- c ont ext information to the DPR task. The DPR function runs in the context of
a separate task within the RTOS.
Note: Since the DPR task processes potentially serious interrupt conditions, you should set the
DPR task’s priority higher than the application task interacting with the S/UNI-4x622 driver.
Proprietary and Confidential to PMC-Sierra, Inc.22
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
The driver provides system-independent functions, suni4x622ISR and suni4x622DPR. You
must fill in the corresponding system-specific functions,
sysSuni4x622DPRTask. The system-specific funct ions iso la te the sy stem-specific
sysSuni4x622ISRHandler and
communication mechanism (between the ISR and DPR) from the system-independent functions,
suni4x622ISR and suni4x622DPR.
Figure 6 illustrates the interrupt service model used in the S/UNI-4x622 driver design.
Figure 6: Interrupt Service Mode
sysSuni4x622ISRHandler
suni4x622ISR
Interrupt
Context
Information
sysSuni4x622DPRTask
suni4x622DPR
Indication
Callbacks
Application
Note: Instead of using an interrupt service model, you can use a polling service model in the
S/UNI-4x622 driver to process the device’s event-indication registers (see page 26).
Calling suni4x622ISR
An interrupt handler function, which is system dependent, must call suni4x622ISR. But first,
the low-level interrupt-handler function must trap the device interrupts. You must implement this
function to fit your own system. As a reference, an example implementation of the interrupt
handler (sysSuni4x622ISRHandler) appears on page 110. You can customize this example
implementation to suit your needs.
The interrupt handler that you implement (
interrupt vector table of the system processor. It is called when one or more S/UNI-4x622 devices
interrupt the processor. The interrupt handler then calls
active state that has interrupt processing enabled.
sysSuni4x622ISRHandler) is installed in the
suni4x622ISR for each device in the
The
suni4x622ISR function reads from the master interrupt-status registers and the
miscellaneous interrupt-status registers of the S/UNI-4x622. If at least one valid interrupt
condition is found then
information as well as the current device handle. The
disables all the device’s interrupts detected. The
suni4x622ISR fills an Interrupt-Service Vector (ISV) with this status
suni4x622ISR function also clears and
sysSuni4x622ISRHandler function is then
responsible to send this ISV buffer to the DPR task.
Note: Normally you should save the status information for deferred processing by implementing a
message queue. The interrupt hand le r sends the sta tus information to the queue by the
sysSuni4x622ISRHandler.
Proprietary and Confidential to PMC-Sierra, Inc.23
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
Calling suni4x622DPR
The sysSuni4x622DPRTask function is a system specific function that runs as a separate task
within the RTOS. You should set the DPR task’s priority higher than the application task(s)
interacting with the S/UNI-4x622 driver. In the message-queue implementation model, this task
has an associated message queue. The task waits for messages from the ISR on this message
queue. When a message arrives,
the received ISV.
suni4x622DPR processes the status information and takes appropriate action based on the
Then
specific interrupt condition detected. The nature of this processing can differ from system to
system. Therefore,
suni4x622DPR calls different indication callbacks for different interrupt
conditions.
Typically, you should implement these callback functions as simple message posting functions
that post messages to an application task. However, you can implement the indication callback to
perform processing within the DPR task context and return without sending any messages. In this
case, ensure that this callback function does not call any API functions that would change the
driver’s state, such as
suni4x622Delete. Also, ensure that the callback function is
non-blocking because the DPR task executes while S/UNI-4x622 interrupts are disabled. You can
customize these callbacks to suit your system. See page 103 for example implementations of the
callback functions.
sysSuni4x622DPRTask calls the DPR (suni4x622DPR) with
Note: Since the
suni4x622ISR and suni4x622DPR routines themselves do not specify a
communication mechanism, you have full flexibility in choosing a communication mechanism
between the two. A convenient way to implement this communication mechanism is to use a
message queue, which is a service that most RTOSs provide.
You must implement the two system specific functions,
sysSuni4x622DPRTask. When the driver calls sysSuni4x622ISRHandlerInstall, the
application installs
and the
sysSuni4x622ISRHandlerInstall function also creates the communication chann el betwe en
sysSuni4x622ISRHandler and sysSuni4x622DPRTask. This communication channe l is
sysSuni4x622DPRTask function is spawned as a task by the application. The
sysSuni4x622ISRHandler in the interrupt vector table of the processor,
most commonly a message queue associated with the
Similarly, during removal of interrupts, the driver removes
sysSuni4x622ISRHandler and
sysSuni4x622DPRTask.
sysSuni4x622ISRHandler from
the microprocessor’s interrupt vector table and deletes the task associated with
sysSuni4x622DPRTask.
As a reference, this manual provides example implementations of the interrupt installation and
removal functions on pages 109 and 111. You can customize these prototypes to suit your specific
needs.
Calling suni4x622Poll
Instead of using an interrupt service model, you can use a polling service model in the S/UNI4x622 driver to process the device’s event-indication registers.
Figure 7 illustrates the polling service model used in the S/UNI-4x622 driver design.
Proprietary and Confidential to PMC-Sierra, Inc.24
Document ID: PMC-2010419, Issue 1
Figure 7: Polling Service Model
PM5358 S/UNI-4x622 Driver Manual
Software Architecture
suni4x622Poll
Interrupt Context
Information
suni4x622DPRsuni4x622ISR
In polling mode, the application is responsible for calling
service any pending error or alarm conditions. When
Indication
Callbacks
Application
suni4x622Poll often enough to
suni4x622Poll is called, the
suni4x622ISR function is called internally.
The
suni4x622ISR function reads from the master interrupt-status registers and the
miscellaneous interrupt-status registers of the S/UNI-4x622. If at least one valid interrupt
condition is found then
suni4x622ISR fills an Interrupt-Service Vector (ISV) with this status
information as well as the current device handle. In polling mode, this ISV buffer is passed to the
DPR task by calling
suni4x622DPR internally.
Proprietary and Confidential to PMC-Sierra, Inc.25
Document ID: PMC-2010419, Issue 1
3 DATA STRUCTURES
This section describes the elements of the driver that configure or control its behavior, and should
therefore be of interest to the application programmer. Included here are the constants, variables
and structures that the S/UNI-4x622 device driver uses to store initialization, configuration and
counts information. The channel number starts from 0. The structure contains arrays of four
elements, where index 0 corresponds to the first channel and index 3 corresponds to the fourth
channel. For more information on our naming convention, the reader is referred to Appendix A
(page 121).
3.1 Constants
The following Constants are used throughout the driver code:
<S/UNI-4x622 ERROR CODES>: error codes used throughout the driver code, returned by
•
the API functions and used in the global error number field of the MDB and DDB. For a
complete list of error codes, see Appendix B (page 125).
PM5358 S/UNI-4x622 Driver Manual
Data Structures
•
SUNI4x622_MAX_DEVS: defines the maximum number of devices that can be supported by
this driver. This constant must not be changed without a thorough analysis of the
consequences to the driver code
•
SUNI4x622_MOD_START, SUNI4x622_MOD_IDLE, SUNI4x622_MOD_READY: the three
SUNI4x622_INACTIVE: the four possible device states (stored in stateDevice)
stateModule)
3.2 Structures Passed by the Application
These structures are defined for use by the application and are passed as argument to functions
within the driver. These structures are the Module Initialization Vector (MIV), the Device
Initialization Vector (DIV) and the ISR mask.
Module Initialization Vector: MIV
Passed via the suni4x622ModuleOpen call, this structure contains all the in formation needed
by the driver to initialize and connect to the RTOS.
•
maxDevs is used to inform the driver how many devices will be operating concurrently
during this session. The number is used to calculate the amount of memory that will be
allocated to the driver. The maximum value that can be passed is
(see section 3.1).
SUNI4x622_MAX_DEVS
Proprietary and Confidential to PMC-Sierra, Inc.26
Document ID: PMC-2010419, Issue 1
(pointer to) errModule (see descript ion in the MDB)
Maximum number of devices supported during this session
Maximum number of initialization profiles
Device Initialization Vector: DIV
Passed via the suni4x622Init call, this structure contains all the information needed by the
driver to initialize a S/UNI-4x622 device. This structure is also passed via the
suni4x622SetInitProfile call when used as an initialization profile.
•
valid indicates that this initialization profile has been properly initialized and may be used
by the USER. This field should be ignored when the DIV is passed directly.
•
pollISR is a flag that indicates the type of interrupt servicing the driver is to use. The
choices are ‘polling’ (
(
SUNI4x622_ISR_MODE). When configured in polling the interrupt capability of the device
is NOT used, and the USER is responsible for calling
actual processing of the event information is the same for both modes.
will be used by the DPR to inform the application code of pending events. If these fields are
set as NULL, then any events that might cause the DPR to ‘call back’ the application will be
processed during ISR processing but ignored by the DPR.
SUNI4x622_POLL_MODE), and ‘interrupt driven’
suni4x622Poll periodically. The
and cbackAPS are used to pass the address of application functions that
Proprietary and Confidential to PMC-Sierra, Inc.27
Document ID: PMC-2010419, Issue 1
PM5358 S/UNI-4x622 Driver Manual
Field NameField TypeField Description
Data Structures
cbackPYLDsSUNI4x622_CBACK
cbackFIFOsSUNI4x622_CBACK
cbackIntfLinesSUNI4x622_CBACK
cbackIntfSyssSUNI4x622_CBACK
cbackAPSsSUNI4x622_CBACK
cfgGlobalsSUNI4x622_CFG_GLOBAL
cfgChan[4]sSUNI4x622_CFG_CHAN
ISR Enable/Disable Mask
Address for the callback function for
PYLD events
Address for the callback function for FIFO
events
Address for the callback function for Line
Interface events
Address for the callback function for
System Interface events
Address for the callback function for APS
events
Global configuration block
Channel configuration block (4 channels
per device)
Passed via the suni4x622SetMask, suni4x622GetMask and suni4x622ClrMask calls, this
structure contains all the information needed by the driver to enable and disable any of the
interrupts in the S/UNI-4x622.