This manual describes the device driver for the TEMUX/TEMAP/TECT3 devices. Since the
TEMAP and TECT3 devices contain a subset of the features provided by the TEMUX device, the
same driver is used for all. Briefly the differences between the devices is as follows, please refer
to the devices respective data sheets for more information.
Table 1: Device Differences
Device
TEMUX Yes Yes Yes Yes
TEMAP No Yes Yes Yes
TECT3 Yes No Yes No
This manual describes the driver’s functions, data structures, and architecture. It focuses on the
driver’s interfaces to your application, Real-Time Operating System, and to the
TEMUX/TEMAP/TECT3 device. It also describes in general terms how to modify and port the
driver to your software and hardware platform.
28 T1, 21 E1
Framers
VT1.5/VT2/T
U-11/TU-12
Sonet/SDH
Mapping
M13 MUX
with DS3
Framer
Sonet/SDH
DS3 Mapper
Audience
This manual is written for people who need to:
· Evaluate and test the TEMUX/TEMAP/TECT3 devices
· Modify and add to the TEMUX/TEMAP/TECT3 driver’s functions
· Port the TEMUX/TEMAP/TECT3 driver to a particular platform.
References
For more information about the TEMUX/TEMAP/TECT3 driver, see the driver’s release notes.
For more information about the TEMUX/TEMAP/TECT3 device, see the documents listed in the
table below and any related errata documents.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 2
Document ID: PMC-1991611, Issue 2
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, you cannot reproduce any part of this document, in any form, without
the express written consent of PMC-Sierra, Inc.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 11
Document ID: PMC-1991611, Issue 2
1 INTRODUCTION
The following sections of the TEMUX/TEMAP/TECT3 driver manual describe the
TEMUX/TEMAP/TECT3 device driver. The code provided throughout this document is written
in the ANSI C language. This has been done to promote greater driver portability to other
embedded hardware and Real-Time Operating System environments.
This driver can be used for the TEMUX/TEMAP/TECT3 devices. See Table 1 for a brief
description of the differences between these devices. To properly support the TEMAP device, use
the compile switch DEV_IS_TEMAP during compilation. To properly support the TECT3 device,
use the compile switch DEV_IS_TECT3 during compilation.
Section 2 of this document, Software Architecture, defines the software architecture of the
TEMUX/TEMAP/TECT3 device driver by including a discussion of the driver’s external
interfaces and its main components. The Data Structure information in Section 4 describes the
elements of the driver that either configure or control its behavior. Included here are the
constants, variables, and structures that the TEMUX/TEMAP/TECT3 device driver uses to store
initialization, configuration, and status information. Section 5 provides a detailed description of
each function that is a member of the TEMUX/TEMAP/TECT3 driver Application Programming
Interface (API). This section outlines: (1) function calls that hide device-specific details and (2)
application callbacks that notify the user of significant device events.
For your convenience, this manual provides a brief guide to porting the TEMUX/TEMAP/TECT3
device driver to your hardware and RTOS platform (page 87). In addition, an Appendix
(beginning on page 92) and Index (page 101), provide you with useful reference information.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 12
Document ID: PMC-1991611, Issue 2
This section describes the software architecture of the TEMUX/TEMAP/TECT3 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 TEMUX/TEMAP/TECT3 device driver.
Figure 1: Driver Interfaces
Application
Software Architecture
Function CallsApplication Callbacks
Service Callbacks
TEMUX/TEMAP/TECT3
Device Driver
Hardware
Interrupts
TEMUX/TEMAP/TECT3 Devices
Register
Accesses
Service Calls
RTOS
Application Programming Interface
The driver’s API is a collection of high level functions that can be called by application
programmers to configure, control, and monitor the TEMUX/TEMAP/TECT3 device, such as:
· Initializing the device
· Validating device configuration
· Retrieving device status and statistics information.
· Diagnosing the device
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 13
Document ID: PMC-1991611, Issue 2
The driver API functions use the driver library functions as building blocks to provide this system
level functionality to the application programmer. The driver API also consists of callback
functions that notify the application of significant events that take place within the device.
Real-Time RTOS Interface
The driver’s RTOS interface module provides functions that let the driver use RTOS services. The
RTOS interface functions perform the following tasks for the TEMUX/TEMAP/TECT3 driver:
· Allocate and de-allocate memory
· Manage buffers for the ISR and DPR
· Timer management
· Synchronization management
· Task management
You must modify the RTOS interface code to suit your RTOS environment.
Driver Hardware Interface
The TEMUX/TEMAP/TECT3 hardware interface provides functions that read from and write to
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 TEMUX/TEMAP/TECT3 device
driver. This applies to 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 five main modules:
· Module and Device management
· Driver API
· Driver library
· Interrupt processing
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 14
Document ID: PMC-1991611, Issue 2
The Module Data Block (MDB) and Module Status Block (MSB) are the top layer data
structures, created by the TEMUX/TEMAP/TECT3 device driver to keep track of its initialization
and operating parameters, modes and dynamic data. The MDB is allocated via an RTOS call,
when the driver is first initialized and contains the MSB and all the Device Structures.
Device Data Block (DDB)
The Device Data Block (DDB) is contained in the MDB and is allocated when the module is
opened. The DDB contains context and status information for each TEMUX/TEMAP/TECT3
device that the driver manages. It is initialized when a device is added to the module.
The DDB stores context information about the TEMUX/TEMAP/TECT3 device, such as:
· Device state
· Control information
· Initialization vector
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 15
Document ID: PMC-1991611, Issue 2
The driver API consists of functions used to configure and monitor the various subsystems in the
TEMUX/TEMAP/TECT3 device. The API functions are divided into following sections:
Alarms, Status, and Statistics Section
This section is responsible for monitoring alarms, tracking devices status information and
retrieving performance and error statistics for each device registered with (added to) the driver.
Diagnostics Section
This section is responsible for providing access to the diagnostic capabilities of the
TEMUX/TEMAP/TECT3 devices. Functions are provided to various loopback modes and to test
register accesses.
Device Read/Write Section
This section provides read/write access functions to the various sub-blocks of the
TEMUX/TEMAP/TECT3 devices. Functions are provided to write to the T1/E1 framer block,
SONET/SDH Mapper block, and the DS3 Mux/Demux block. Functions are also provided to read
a block of registers and access the indirect registers.
Driver Library
The driver library module is a collection of low-level utility functions that manipulate the device
registers and the contents of the driver’s DDB. The driver library functions serve as building
blocks for higher level functions that constitute the driver API module. Application software does
not normally call the driver library functions.
Interrupt Processing
The TEMUX/TEMAP/TECT3 driver provides an ISR called temuxISR that checks if there are
any valid interrupt conditions present for the device. This function can be used by a
system-specific interrupt-handler function to service interrupts raised by the device. Its main
purpose is to collect information about the current interrupt condition of the device and pass this
information along to the Deferred-Processing Routine for actual processing.
The low-level interrupt-handler function that traps the hardware interrupt and calls
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 on page 69. You can customize these example implementations to suit your specific
needs.
temuxISR is
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 16
Document ID: PMC-1991611, Issue 2
The DPR provided by the driver (temuxDPR) clears and processes interrupt conditions for the
device. Typically, a system specific function, which runs as a separate task within the RTOS,
executes the DPR.
See page 22 for a detailed explanation of the DPR and interrupt-servicing model.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 17
Document ID: PMC-1991611, Issue 2
Figure 3 shows the software state diagrams for the TEMUX/TEMAP/TECT3 module and
device(s) as maintained by the driver
Figure 3: State Diagram
temuxModuleOpen
Software State Description
Idle
temuxModuleStart
MODULE STATES
temuxModuleClose
temuxModuleStop
Ready
Start
temuxModuleClose
temuxAddtemuxDelete
temuxReset
Inactive
Start
Present
temuxReset
temuxInit
temuxActivate
Active
temuxDeActivate
PER-DEVICE STATES
State transitions are made on the successful execution of the corresponding transition routines
shown. State information helps maintain the integrity of the MDB and the DDB(s) by controlling
the set of operations that are allowed in each state.
3.1 Module States
The following is a description of the TEMUX/TEMAP/TECT3 driver module states.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 18
Document ID: PMC-1991611, Issue 2
The TEMUX/TEMAP/TECT3 driver module has not been initialized. The only API function that
will be accepted in this state is
temuxModuleOpen. In this state the driver does not hold any
RTOS resources (memory, timers, etc), has no running tasks, and performs no actions.
Idle: TMX_MOD_IDLE
The TEMUX/TEMAP/TECT3 driver module has been initialized successfully via the API
function
temuxModuleOpen. 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. The only API functions that will be accepted in this state are
temuxModuleStart and temuxModuleClose.
Ready: TMX_MOD_READY
This is the normal operating state for the driver module. This means that the RTOS resources
have been allocated and the driver is ready for devices to be added. In order to get to this state,
the API function
allocating all of the RTOS resources necessary for the proper operation of the module and the
devices). The API functions accepted here for module control are
temuxModuleClose. The driver module remains in this state while devices are in operation.
Devices can be added via
temuxModuleStart is called (this function is responsible for creating and/or
temuxModuleStop and
temuxAdd.
3.2 Device States
Once the driver module has progressed into the READY state, the user can begin to add
individual devices into operation. The driver module remains in the READY state while devices
are in operation. Devices can be added via
temuxModuleClose are always available in this state (and therefore not mentioned below)
and
and if used, will cause each and every device (that is not in the START state) to be deleted, before
that module function is fully executed.
The following is a description of the TEMUX/TEMAP/TECT3 driver device states:
Start: TMX_START
The TEMUX/TEMAP/TECT3 driver device has not been initialized. The only API function that
will be accepted in this state is
performs no actions. There is a separate flow for each device that can be added and they all start
here.
temuxAdd. The module functions temuxModuleStop
temuxAdd. In this state, the device is unknown by the driver and
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 19
Document ID: PMC-1991611, Issue 2
This device state is a quiet state for the device. In order to get to this state, the API needs to be
called by one of two functions:
temuxAdd: Responsible for verifying the presence of the device and for initializing the data
·
structures associated with this device.
·
temuxReset: De-activates the device and restores the device’s data structures to the
initialized condition.
In this state, devices can be initialized via
Active: TMX_ACTIVE
This is the normal operating state for the device(s). State changes can be initiated from the active
state via
temuxDelete, temuxDeActivate and temuxReset.
Inactive: TMX_INACTIVE
This state is entered via the temuxDeActivate or temuxInit function calls. In this state the
device remains configured but all data functions are de-activated including interrupts and status,
alarms, and counter functions.
temuxReset or temuxDelete will de-configure the device.
3.3 Processing Flows
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.
temuxInit or deleted via temuxDelete.
temuxActivate will return the device to the active state, while
Module Management
The following flow diagram illustrates the typical function call sequences that occur when
initializing or shutting down the TEMUX/TEMAP/TECT3 driver module.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 20
Document ID: PMC-1991611, Issue 2
Perfor ms modul e level ini tial ization of the TEMUX driver. Vali dates the
Module Ini tial ization Vector (MIV). All ocates memory for t he MDB and all
it s component s (i .e. al l the memory needed by the dri ver) and then
ini tiali zes the content s of the MDB with t he validat ed MI V.
Perfor ms modul e level startup of the driver. This i nvolves al locati ng RTOS
resources such as semaphores and ti mer s.
Perfor m all device l evel functi ons here (add, ini t, activate,
de-act ivate, reset , del ete)
Perfor ms Modul e level shutdown of t he TEMUX driver. Thi s involves
delet ing all devi ces current ly inst alled and de-allocati ng all t imers and
semaphores as well as removing the ISR handler and DPR task.
Perfor ms modul e level shutdown of the dri ver. Delet es all devices currentl y
regi stered wit h the dr iver and de-all ocates all t he dri ver's memory.
Device Management
The following figure shows the functions and process that the driver uses to add, initialize, reinitialize, or delete devices.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 21
Document ID: PMC-1991611, Issue 2
performs a register readback test,
allocates memory for storing device context
information, and applies a software reset to the device (using
temuxReset).
Initializes the device based on an initialization vector provided by the
application. The initialization vector is validated by the application and
stored by the driver as part of device context information. The device
registers are then configured accordingly.
Prepares the device for normal operation by enabling interrupts and other
global enables. The device is now operational and all other APIs
can be invoked.
Deactivates the device; and resets the device’s context, which enables the
application to once again initialize the device.
De-activates the device and removes it from normal operation. This
involves disabling the device interrupts and other global enables, such as
links.
pplies a software reset to the device to put it in its default startup state.
Removes the device from the list of devices being controlled by the
temuxDelete
END
TEMUX driver. This function clears the device context information
for the device being deleted.
3.4 Interrupt Servicing
The TEMUX/TEMAP/TECT3 driver services device interrupts using an Interrupt-Service
Routine (ISR) that traps interrupts and a deferred interrupt-processing routine (DPR) that actually
processes the interrupt conditions. 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-context 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
TEMUX/TEMAP/TECT3 driver.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 22
Document ID: PMC-1991611, Issue 2
The driver provides system-independent functions, temuxISR and temuxDPR. You must fill in
the corresponding system-specific functions,
sysTemuxISRHandler and sysTemuxDPRTask.
The system-specific functions isolate the system-specific communication mechanism (between
the ISR and DPR) from the system-independent functions,
temuxISR and temuxDPR.
Figure 6 illustrates the interrupt service model used in the TEMUX/TEMAP/TECT3 driver
design.
Figure 6: Interrupt Service Model
sysTemuxISRHandler
temuxISR
Interrupt
Status
sysTemuxDPRTask
temuxDPR
Indication
Callbacks
Application
Note: Instead of using an interrupt service model, you can use a polling service model in the
TEMUX/TEMAP/TECT3 driver to process the device’s event-indication registers.
Calling temuxISR
An interrupt handler function, which is system dependent, must call temuxISR. But first, the
low-level interrupt-handler function must trap the device interrupts. You must implement this
function for your system.
The interrupt handler that you implement (
vector table of the system processor. Then it is called when one or more
TEMUX/TEMAP/TECT3 devices interrupt the processor. The interrupt handler then calls
temuxISR for each device in the active state that requires service.
The
temuxISR function reads from the master interrupt-status registers and the miscellaneous
interrupt-status registers of the TEMUX/TEMAP/TECT3. Then
status information if valid status bits are set. The
turn clears the initial cause of the interrupt. The
message to the DPR task (for each device that requested service) which contains the valid
interrupt status bits and the device’s context handle.
sysTemuxISRHandler) is installed in the interrupt
temuxISR returns with this
temuxISR also clears those status bits, which in
sysTemuxISRHandler function then sends a
Note: Normally you should pass the status information for deferred interrupt processing by
implementing a message queue.
Calling temuxDPR
The sysTemuxDPRTask 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 TEMUX/TEMAP/TECT3 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,
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 23
Document ID: PMC-1991611, Issue 2
Then temuxDPR processes the status information and takes appropriate action based on the
specific interrupt condition detected. The nature of this processing can differ from system to
system. Therefore,
temuxDPR 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 the indication function does not call any API functions that change the driver’s
state, such as
temuxDelete. Also, ensure that the indication function is non-blocking. You can
customize these callbacks to suit your system.
Note: Since the
temuxISR and temuxDPR 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,
sysTemuxDPRTask. When the driver calls sysTemuxISRHandlerInstall for the first time,
the driver installs
sysTemuxDPRTask function is spawned as a task when sysTemuxDPRTaskInstall is called.
sysTemuxISRHandlerInstall function also creates the communication channel between
The
sysTemuxISRHandler and sysTemuxDPRTask. This communication channel is most
sysTemuxISRHandler in the interrupt vector table of the processor. The
commonly a message queue associated with the
Similarly, during removal of interrupts, the driver removes
microprocessor’s interrupt vector table when
As a reference, this manual provides example implementations of the interrupt installation and
removal functions on page 81. You can customize these prototypes to suit your specific needs.
3.5 Polling Servicing
sysTemuxISRHandler and
sysTemuxDPRTask.
sysTemuxISRHandler from the
sysTemuxDPRTaskRemove is called.
Instead of using an interrupt service model, you can use a polling service model in the
TEMUX/TEMAP/TECT3 driver to process the device’s event-indication registers.
Figure 7 illustrates the polling service model used in the TEMUX/TEMAP/TECT3 driver design.
Figure 7: Polling Service Model
Indication
Callbacks
temuxDPR
Application
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 24
Document ID: PMC-1991611, Issue 2
The polling service code includes some system specific code (prefixed by “sysTemux”), which
typically you must implement for your application. The polling service code also includes some
system independent code (prefixed by “
temux”) provided by the driver that does not change from
system to system.
In polling mode,
sysTemuxISRHandler and temuxISR are not used. When temuxPoll is
called, the message normally sent to the DPR is now passed internally.
The nature of this processing can differ from system to system. Therefore, the DPR calls different
indication callbacks for different interrupt conditions. You can customize these callbacks to fit
your application’s specific requirements. See page 75 for a description of these callback
functions.
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 25
Document ID: PMC-1991611, Issue 2
The file temux.h defines the lowest level (compile time) items, generally those that are needed
by any application code in order to interface with the driver. All source and header files include
this file. The compile constants are defined in the file
etc.
Data Structures
temux.h as UINT1, UINT2, UINT4,
The file
tmx_api.h defines the set of (run time) items needed to interface directly with the core
API functions. The following constants are defined in the file
·
TMX_MAX_DEVICES: 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
· <
TEMUX ERROR CODES>: error codes used throughout the driver code, returned by the API
functions and (when
TMX_FAIL is returned to a function’s caller) used in the global error
number field of the MDB or DDB
·
sTMX_MIV: structure passed by the application into the temuxModuleOpen function call.
·
sTMX_DIV: structure passed by the application into the temuxAdd function call.
The remaining files should only be needed for extended interfaces that make use of the internal
structures or functions of the driver.
4.2 Data Structures
The following are the main data structures employed by the TEMUX/TEMAP/TECT3 driver.
tmx_api.h.
4.3 Structures Passed by the Application
These structures are defined for use by the application and are passed by reference to functions
within the driver.
Module Initialization Vector
Passed via the temuxModuleOpen call, this structure contains all the information needed by the
driver to initialize the module. Special or unusual fields are described first:
·
pMDB: can be used by the application to pass the address of a pre-allocated MDB. If pMDB is
NULL, the driver will allocate sufficient memory to hold the MDB and return its address in
pMDB field.
the
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 26
Document ID: PMC-1991611, Issue 2
· 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
TMX_MAX_DEVICES.
Table 3: Module Initialization Vector: sTMX_MIV
Field Name Field Type Field Description
autoStart UINT2
pMDB void *
maxDevs UINT2
indicates to driver to start the module when opened
(pointer to) pre-allocated or (if NULL) returned MDB
number of devices that must be supported for this session
Device Initialization Vector
Passed via the temuxAdd call, this structure contains all the information needed by the driver to
initialize a TEMUX/TEMAP/TECT3 device. Special or unusual fields are described first:
·
pDDB can be used by the application to pass the address of a pre-allocated DDB. If pDDB is
NULL, the driver will allocate sufficient memory to hold the DDB and return its address in
the
pDDB field.
·
baseAddress: must contain the hardware base address of the device.
·
usrCtxt: this field is strictly a user field. The value passed into the function via this element
will be stored in the DDB and passed back to the application during DPR processing. The
user might use it to identify ‘this’ device or point to some data related to this device.
·
autoInit: is a flag that tells the driver to automatically initialize the device being added
(calling
the device left uninitialized, and the application will have to call temuxInit at a later time.
temuxInit internally does this). If the flag is zero, the DDB will be initialized and
profileNum: is used only when autoInit is set and indicates which mode the device should
·
be initialized into. The function of this element is the same as the profileNum argument to the
function temuxInit. A value of zero indicates that during initialization, after the device is
reset, all registers should remain unchanged (in their initial state).
cbackIO, cbackDS3, cbackFramer, cbackMapper: Passes the addresses of
·
application functions used by the DPR to inform the application code of pending events. If
the user sets the element to NULL, then any events that might cause the DPR to ‘call back’ to
the application will be processed during ISR processing but ignored by the DPR.
Table 4: Device Initialization Vector: sTMX_DIV
Field Name Field Type Field Description
pDDB void *
baseAddress UINT1 *
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 27
Document ID: PMC-1991611, Issue 2
(pointer to) pre-allocated or (if NULL) returned DDB
a user-supplied value that is returned in callback
functions
autoInit UINT2
profileNum UINT2
if non-zero, temuxInit is called internally
profile number to be used for initialization. A profile
number of zero indicates that the driver should leave all
the device registers unchanged after reset
modeISR TMX_ISR_MODE
cbackIO void *
cbackDS3 void *
cbackFramer void *
cbackMapper void *
indicates the type of ISR/polling to do
address of the callback function for IO Events
address of the callback function for DS3 Events
address of the callback function for Framer Events
address of the callback function for Mapper Events (not
valid in TECT3)
Device Initialization Profile
The device initialization profile is used to initialize the TEMUX/TEMAP/TECT3 device to a
specific operating mode. It is used by the profile manipulation functions
temuxGetInitProfile, etc.) and temuxInit. Important fields are given below.
Profiles 0-4 are not valid with the TEMAP device. Profiles 1-3, 5, 7 are not valid in the TECT3
device.
Interrupt-Service Routine Mask Vector
Passed via the temuxClearMask, temuxGetMask and the temuxSetMask calls, this structure
contains all the information needed by the driver to enable and disable any of the interrupts in the
TEMUX/TEMAP/TECT3.
Table 7: ISR Mask Vector: sTMX_MASK
Field Name Field Type Sets / Clears Interrupt Condition
sdet0e UINT1
sdet1e UINT1
io struct tmx_mask_io
ds3 struct tmx_mask_ds3
mux[7] struct tmx_mask_mux
framer[28] struct tmx_mask_framer
mapper struct tmx_mask_mapper
SBI collision detect (register 0)
SBI collision detect (register 1)
IO Section interrupts
DS3 Section interrupts
MUX/MX12/DS2 Section interrupts
FRAMER Section interrupts
MAPPER Section interrupts (not valid in
TECT3)
Mask Sub-structures
These structures also appear in sTMX_MASK (above).
Table 8: IO Section Masks: struct tmx_mask_io
Field Name Field Type Field Description
exsbi.ovre UINT1
exsbi.unde UINT1
insbi.ovre UINT1
insbi.unde UINT1
exsbi.pare UINT1
Proprietary and Confidential to PMC-Sierra, Inc., and for its Customers’ Internal Use 30
Document ID: PMC-1991611, Issue 2
SBI bus egress overrun
SBI bus egress underrun
SBI bus ingress overrun
SBI bus ingress underrun
SBI bus parity
Loading...
+ 73 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.