/*
* CDDL HEADER START
*
* The contents of this file are subject to the terms of the
* Common Development and Distribution License (the "License").
* You may not use this file except in compliance with the License.
*
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
* See the License for the specific language governing permissions
* and limitations under the License.
*
* When distributing Covered Code, include this CDDL HEADER in each
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
* If applicable, add the following below this CDDL HEADER, with the
* fields enclosed by brackets "[]" replaced with your own identifying
* information: Portions Copyright [yyyy] [name of copyright owner]
*
* CDDL HEADER END
*/
/*
* Copyright 2009 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*/
#ifndef _SYS_IB_ADAPTERS_TAVOR_HW_H
#define _SYS_IB_ADAPTERS_TAVOR_HW_H
/*
* Contains all the structure definitions and #defines for all Tavor
* hardware resources and registers (as defined by the Tavor register
* specification). Wherever possible, the names in the Tavor spec
* have been preserved in the structure and field names below.
*/
#ifdef __cplusplus
extern "C" {
#endif
/*
* Offsets into the CMD BAR (BAR 0) for many of the more interesting hardware
* registers. These registers include the HCR (more below), the Event Cause
* Register (ECR) and its related clear register, the Interrupt Clear register
* (CLR_INT), and the software reset register (SW_RESET).
*/
/*
* Ownership flags used to define hardware or software ownership for
* various Tavor resources
*/
/*
* Determines whether or not virtual-to-physical address translation is
* required. Several of the Tavor hardware structures can be optionally
* accessed by Tavor without going through the TPT address translation
* tables.
*/
/*
* HCA Command Register (HCR)
* The HCR command interface provides privileged access to the HCA in
* order to query, configure and modify HCA execution. It is the
* primary mechanism through which mailboxes may be posted to Tavor
* firmware. To use this interface software fills the HCR with pointers
* to input and output mailboxes. Some commands support immediate
* parameters, however, and for these commands the HCR will contain the
* input or output parameters. Command execution completion can be
* detected either by the software polling the HCR or by waiting for a
* command completion event.
*/
struct tavor_hw_hcr_s {
};
/*
* Tavor "QUERY_DEV_LIM" command
* The QUERY_DEV_LIM command returns the device limits and capabilities
* supported by the Tavor device. This command should be run before
* running the INIT_HCA command (below) in order to determine the maximum
* capabilities of the device and which optional features are supported.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_querydevlim_s {
};
#else
struct tavor_hw_querydevlim_s {
};
#endif
/*
* Tavor "QUERY_FW" command
* The QUERY_FW command retrieves the firmware revision and the Command
* Interface revision. The command also returns the HCA attached local
* memory area (DDR) which is used by the firmware. Below we also
* include some defines which are used to enforce a minimum firmware
* version check (see tavor_fw_version_check() for more details).
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_queryfw_s {
};
#else
struct tavor_hw_queryfw_s {
};
#endif
/*
* Tavor "QUERY_DDR" command
* The QUERY_DDR command retrieves information regarding the HCA attached
* local memory area (DDR). This information includes: the DIMM PCI BAR,
* the total address space provided by the HCA attached local memory, and
* some DIMM-specific information. Note: Some of the HCA attached local
* memory is reserved for use by firmware. This extent of this reserved
* area can be obtained through the QUERY_FW command (above).
*
* Below we first define the tavor_hw_queryddr_dimm_t or "Logical DIMM
* Information" structure. Four of these are present in the QUERY_DDR
* command.
*/
#ifdef _LITTLE_ENDIAN
typedef struct tavor_hw_queryddr_dimm_s {
#else
typedef struct tavor_hw_queryddr_dimm_s {
#endif
#ifdef _LITTLE_ENDIAN
struct tavor_hw_queryddr_s {
};
#else
struct tavor_hw_queryddr_s {
};
#endif
/*
* Tavor "QUERY_ADAPTER" command
* The QUERY_ADAPTER command retrieves adapter specific parameters. The
* command also retrieves the PCI(X) interrupt pin routing for each of
* the INTx# pins supported by the device. This information is used by
* the driver during interrupt processing in order to clear the appropriate
* interrupt bit.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_queryadapter_s {
};
#else
struct tavor_hw_queryadapter_s {
};
#endif
/*
* Tavor "INIT_HCA" and "QUERY_HCA" commands
* The INIT_HCA command configures all HCA resources in HCA attached local
* memory and some system relevant information. The same mailbox output
* format is used by the QUERY_HCA command. All parameters, which are
* specifically the output of the QUERY_HCA command are marked as
* "QUERY_HCA only". These parameters are not configurable through the
* INIT_HCA command, but can be retrieved as read-only through the
* QUERY_HCA command.
*
* Below we first define several structures which help make up the whole
* tavor_udav_mem_param_t for "Memory Access Parameters for UDAV Table",
* tavor_multicast_param_t for "Multicast Support Parameters",
* tavor_tpt_param_t for "Translation and Protection Table Parameters",
* and tavor_uar_param_t for Tavor "UAR Parameters".
*/
#ifdef _LITTLE_ENDIAN
typedef struct tavor_hw_qp_ee_cq_eq_rdb_s {
#else
typedef struct tavor_hw_qp_ee_cq_eq_rdb_s {
#endif
#ifdef _LITTLE_ENDIAN
typedef struct tavor_udav_mem_param_s {
#else
typedef struct tavor_udav_mem_param_s {
#endif
#ifdef _LITTLE_ENDIAN
typedef struct tavor_multicast_param_s {
#else
typedef struct tavor_multicast_param_s {
#endif
#ifdef _LITTLE_ENDIAN
typedef struct tavor_tpt_param_s {
#else
typedef struct tavor_tpt_param_s {
#endif
#ifdef _LITTLE_ENDIAN
typedef struct tavor_uar_param_s {
#else
typedef struct tavor_uar_param_s {
#endif
#ifdef _LITTLE_ENDIAN
struct tavor_hw_initqueryhca_s {
};
#else
struct tavor_hw_initqueryhca_s {
};
#endif
/*
* Tavor "INIT_IB" command
* The INIT_IB command enables the physical layer of a given IB port.
* It provides control over the IB port attributes. The capabilities
* requested here should not exceed the device limits, as retrieved by
* the QUERY_DEV_LIM command (above). To query information about the IB
* port or node, the driver may submit GetPortInfo or GetNodeInfo MADs
* through the Tavor MAD_IFC command.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_initib_s {
};
#else
struct tavor_hw_initib_s {
};
#endif
/*
* Tavor Memory Protection Table (MPT) entries
* The Memory Protection Table (MPT) contains the information associated
* with all the regions and windows. The MPT table resides in a physically-
* contiguous area in HCA attached local memory, and the memory key (R_Key
* or L_Key) is used to calculate the physical address for accessing the
* entries in the table.
*
* The following structure is used in the SW2HW_MPT, QUERY_MPT, and
* HW2SW_MPT commands.
* The SW2HW_MPT command transfers ownership of an MPT entry from software
* to hardware. The command takes the MPT entry from the input mailbox and
* stores it in the MPT in the hardware. The command will fail if the
* requested MPT entry is already owned by the hardware or if the MPT index
* given in the command is inconsistent with the MPT entry memory key.
* The QUERY_MPT command retrieves a snapshot of an MPT entry. The command
* takes the current state of an MPT entry from the hardware and stores it
* in the output mailbox. The command will fail if the requested MPT entry
* is already owned by software.
* Finally, the HW2SW_MPT command transfers ownership of an MPT entry from
* the hardware to the software. The command takes the MPT entry from the
* hardware, invalidates it, and stores it in the output mailbox. The
* command will fail if the requested entry is already owned by software.
* The command will also fail if the MPT entry in question is a Memory
* Region which has Memory Windows currently bound to it.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_mpt_s {
};
#else
struct tavor_hw_mpt_s {
};
#endif
/*
* Tavor Memory Translation Table (MTT) entries
* After accessing the MPT table (above) and validating the access rights
* where it translates the virtual address to a physical address. This
* translation is performed using the Memory Translation Table entries
* (MTT). Note: The MTT in hardware is organized into segments and each
* segment contains multiple address translation pages (MTT entries).
* Each memory region (MPT above) points to the first segment in the MTT
* that corresponds to that region.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_mtt_s {
};
#else
struct tavor_hw_mtt_s {
};
#endif
/*
* Tavor Event Queue Context Table (EQC) entries
* Tavor supports 64 Event Queues, and the status of Event Queues is stored
* in the Event Queue Context (EQC) table. The EQC table is a physically-
* contiguous memory structure in the HCA attached local memory. Each EQC
* table entry contains Event Queue status and information required by
* the hardware in order to access the event queue.
*
* The following structure is used in the SW2HW_EQ, QUERY_EQ, and HW2SW_EQ
* commands.
* The SW2HW_EQ command transfers ownership of an EQ context from software
* to hardware. The command takes the EQC entry from the input mailbox and
* stores it in the EQC in the hardware. The command will fail if the
* requested EQC entry is already owned by the hardware.
* The QUERY_EQ command retrieves a snapshot of an EQC entry. The command
* stores the snapshot in the output mailbox. The EQC state and its values
* are not affected by the QUERY_EQ command.
* Finally, the HW2SW_EQ command transfers ownership of an EQC entry from
* the hardware to the software. The command takes the EQC entry from the
* hardware and stores it in the output mailbox. The EQC entry will be
* invalidated as a result of the command. It is the responsibility of the
* software to unmap all the events, which might have been previously
* mapped to the EQ, prior to issuing the HW2SW_EQ command.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_eqc_s {
};
#else
struct tavor_hw_eqc_s {
};
#endif
/*
* Tavor Event Queue Entries (EQE)
* Each EQE contains enough information for the software to identify the
* source of the event. The following structures are used to define each
* of the various kinds of events that the Tavor hardware will generate.
* Note: The tavor_hw_eqe_t below is the generic "Event Queue Entry". All
* other EQEs differ only in the contents of their "event_data" field.
*
* Below we first define several structures which define the contents of
* the "event_data" fields:
* tavor_hw_eqe_cq_t for "Completion Queue Events"
* tavor_hw_eqe_cqerr_t for "Completion Queue Error Events"
* tavor_hw_eqe_portstate_t for "Port State Change Events"
* tavor_hw_eqe_cmdcmpl_t for "Command Interface Completion Events"
* tavor_hw_eqe_qp_evt_t for "Queue Pair Events" such as Path Migration
* Succeeded, Path Migration Failed, Communication Established, Send
* Queue Drained, Local WQ Catastrophic Error, Invalid Request Local
* WQ Error, and Local Access Violation WQ Error.
* tavor_hw_eqe_operr_t for "Operational and Catastrophic Error Events"
* such as EQ Overflow, Misbehaved UAR page, Internal Parity Error,
* Uplink bus error, and DDR data error.
* tavor_hw_eqe_pgflt_t for "Not-present Page Fault on WQE or Data
* Buffer Access". (Note: Currently, this event is unsupported).
*
* Note also: The following structures are not #define'd with both
* little-endian and big-endian definitions. This is because their
* individual fields are not directly accessed except through the macros
* defined below.
*/
typedef struct tavor_hw_eqe_cq_s {
typedef struct tavor_hw_eqe_cqerr_s {
typedef struct tavor_hw_eqe_portstate_s {
typedef struct tavor_hw_eqe_cmdcmpl_s {
typedef struct tavor_hw_eqe_qp_evt_s {
typedef struct tavor_hw_eqe_operr_s {
typedef struct tavor_hw_eqe_pgflt_s {
typedef struct tavor_hw_eqe_ecc_s {
struct tavor_hw_eqe_s {
union {
} event_data;
};
/*
* The following macros are used for extracting (and in some cases filling in)
* information from EQEs
*/
#define TAVOR_EQE_EVTSUBTYPE_SHIFT 0
#define TAVOR_EQE_CQNUM_SHIFT 0
#define TAVOR_EQE_QPNUM_SHIFT 0
#define TAVOR_EQE_CMDTOKEN_SHIFT 0
#define TAVOR_EQE_CMDSTATUS_SHIFT 0
#define TAVOR_EQE_OPERRTYPE_SHIFT 0
((TAVOR_HW_OWNER << TAVOR_EQE_OWNER_SHIFT) & \
/*
* Tavor Completion Queue Context Table (CQC) entries
* The CQC table is a physically-contiguous memory area residing in HCA
* attached local memory. Each CQC table entry contains information
* required by the hardware to access the completion queue to post
* completions (CQE).
*
* The following structure is used in the SW2HW_CQ, QUERY_CQ, RESIZE_CQ,
* and HW2SW_CQ commands.
* The SW2HW_CQ command transfers ownership of an CQ context from software
* to hardware. The command takes the CQC entry from the input mailbox and
* stores it in the CQC in the hardware. The command will fail if the
* requested CQC entry is already owned by the hardware.
* The QUERY_CQ command retrieves a snapshot of a CQC entry. The command
* stores the snapshot in the output mailbox. The CQC state and its values
* are not affected by the QUERY_CQ command.
* Finally, the HW2SW_CQ command transfers ownership of a CQC entry from
* the hardware to the software. The command takes the CQC entry from the
* hardware and stores it in the output mailbox. The CQC entry will be
* invalidated as a result of the command.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_cqc_s {
};
#else
struct tavor_hw_cqc_s {
};
#endif
/*
* Tavor Completion Queue Entries (CQE)
* Each CQE contains enough information for the software to associate the
* completion with the Work Queue Element (WQE) to which it corresponds.
*
* Note: The following structure is not #define'd with both little-endian
* and big-endian definitions. This is because each CQE's individual
* fields are not directly accessed except through the macros defined below.
*/
struct tavor_hw_cqe_s {
};
/*
* The following macros are used for extracting (and in some cases filling in)
* information from CQEs
*/
#define TAVOR_CQE_QPNUM_SHIFT 0
#define TAVOR_CQE_DQPN_SHIFT 0
#define TAVOR_CQE_DLID_SHIFT 0
(arg)))
(arg)))
#ifdef _LITTLE_ENDIAN
{ \
if ((cq)->cq_is_umap) { \
} else { \
} \
}
#else
{ \
if ((cq)->cq_is_umap) { \
} else { \
} \
}
#endif
/*
* Tavor Shared Receive Queue (SRQ) Context Entry Format
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_srqc_s {
};
#else
struct tavor_hw_srqc_s {
};
#endif
/*
* Tavor MOD_STAT_CFG input mailbox structure
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_mod_stat_cfg_s {
};
#else
struct tavor_hw_mod_stat_cfg_s {
};
#endif
/*
* Tavor UD Address Vector (UDAV)
* Tavor UDAV are used in conjunction with Unreliable Datagram (UD) send
* WQEs. Each UD send message specifies an address vector that denotes its
* link and (optional) network layer destination address. The IBA verbs
* interface enables the separation of the address administration from the
* send WQE posting. The verbs consumer must use special verbs to create
* and modify address handles (which represent hardware address vectors).
* When posting send WQEs to UD QP, the verbs consumer must supply a
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_udav_s {
};
#else
struct tavor_hw_udav_s {
};
#endif
/*
* Tavor Queue Pair Context Table (QPC) entries
* The QPC table is a physically-contiguous memory area residing in HCA
* attached local memory. Each QPC entry is accessed for reads and writes
* by the HCA while executing work requests on the associated QP.
*
* The following structure is used in the RST2INIT_QP, INIT2INIT_QP,
* INIT2RTR_QP, RTR2RTS_QP, RTS2RTS_QP, SQERR2RTS_QP, TOERR_QP, RTS2SQD_QP,
* SQD2RTS_QP, TORST_QP, and QUERY_QP commands.
* With the exception of the QUERY_QP command, each of these commands reads
* from some portion of the QPC in the input mailbox and modified the QPC
* stored in the hardware. The QUERY_QP command retrieves a snapshot of a
* QPC entry. The command stores the snapshot in the output mailbox. The
* QPC state and its values are not affected by the QUERY_QP command.
*
* Below we first define the tavor_hw_addr_path_t or "Tavor Address Path"
* structure. This structure is used to provide address path information
* (both primary and secondary) for each QP context. Note: Since this
* structure is _very_ similar to the tavor_hw_udav_t structure above,
* we are able to leverage the similarity with filling in and reading from
* the two types of structures. See tavor_get_addr_path() and
* tavor_set_addr_path() in tavor_misc.c for more details.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_addr_path_s {
};
#else
struct tavor_hw_addr_path_s {
};
#endif
#ifdef _LITTLE_ENDIAN
struct tavor_hw_qpc_s {
};
#else
struct tavor_hw_qpc_s {
};
#endif
/*
* Tavor Multicast Group Member (MCG)
* Tavor MCG are organized in a physically-contiguous memory table (the
* Multicast Group Table) in the HCA attached local memory. This table is
* actually comprised of two consecutive tables: the Multicast Group Hash
* Table (MGHT) and the Additional Multicast Group Members Table (AMGM).
* Each such entry contains an MGID and a list of QPs that are attached to
* the multicast group. Each such entry may also include an index to an
* Additional Multicast Group Member Table (AMGM) entry. The AMGMs are
* used to form a linked list of MCG entries that all map to the same hash
* value. The MCG entry size is configured through the INIT_HCA command.
* Note: An MCG actually consists of a single tavor_hw_mcg_t and some
* number of tavor_hw_mcg_qp_list_t (such that the combined structure is a
* power-of-2).
*
* The following structures are used in the READ_MGM and WRITE_MGM commands.
* The READ_MGM command reads an MCG entry from the multicast table and
* returns it in the output mailbox. Note: This operation does not affect
* the MCG entry state or values.
* The WRITE_MGM command retrieves an MCG entry from the input mailbox and
* stores it in the multicast group table at the index specified in the
* command. Once the command has finished execution, the multicast group
* table is updated. The old entry contents are lost.
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_mcg_s {
};
#else
struct tavor_hw_mcg_s {
};
#endif
/* Multicast Group Member - QP List entries */
#ifdef _LITTLE_ENDIAN
struct tavor_hw_mcg_qp_list_s {
uint32_t q :1;
};
#else
struct tavor_hw_mcg_qp_list_s {
uint32_t q :1;
};
#endif
/*
* Structure for getting the peformance counters from the HCA
*/
#ifdef _LITTLE_ENDIAN
struct tavor_hw_sm_perfcntr_s {
};
#else /* BIG ENDIAN */
struct tavor_hw_sm_perfcntr_s {
};
#endif
/*
* Tavor User Access Region (UAR)
* Tavor doorbells are each rung by writing to the doorbell registers that
* form a User Access Region (UAR). A doorbell is a write-only hardware
* register which enables passing information from software to hardware
* with minimum software latency. A write operation from the host software
* to these doorbell registers passes information about the HCA resources
* and initiates processing of the doorbell data. There are 6 types of
* doorbells in Tavor.
*
* "Send Doorbell" for synchronizing the attachment of a WQE (or a chain
* of WQEs) to the send queue.
* "RD Send Doorbell" (Same as above, except for RD QPs) is not supported.
* "Receive Doorbell" for synchronizing the attachment of a WQE (or a chain
* of WQEs) to the receive queue.
* "CQ Doorbell" for updating the CQ consumer index and requesting
* completion notifications.
* "EQ Doorbell" for updating the EQ consumer index, arming interrupt
* triggering, and disarming CQ notification requests.
* "InfiniBlast" (which would have enabled access to the "InfiniBlast
* buffer") is not supported.
*
* Note: The tavor_hw_uar_t below is the container for all of the various
* doorbell types. Below we first define several structures which make up
* the contents of those doorbell types.
*
* Note also: The following structures are not #define'd with both little-
* endian and big-endian definitions. This is because each doorbell type
* is not directly accessed except through a single ddi_put64() operation
* (see tavor_qp_send_doorbell, tavor_qp_recv_doorbell, tavor_cq_doorbell,
* or tavor_eq_doorbell)
*/
typedef struct tavor_hw_uar_send_s {
typedef struct tavor_hw_uar_recv_s {
/* Max descriptors per Tavor doorbell */
typedef struct tavor_hw_uar_cq_s {
/* Default value for use in NOTIFY_CQ doorbell */
typedef struct tavor_hw_uar_eq_s {
struct tavor_hw_uar_s {
};
/*
* Tavor Send Work Queue Element (WQE)
* A Tavor Send WQE is built of the following segments, each of which is a
* multiple of 16 bytes. Note: Each individual WQE may contain only a
* subset of these segments described below (according to the operation type
* and transport type of the QP).
*
* This segment contains the address of the next WQE to be executed and the
* information required in order to allocate the resources to execute the
* next WQE. The "Ctrl" part of this segment contains the control
* information required to execute the WQE, including the opcode and other
* control information.
* The "Datagram" segment contains address information required in order to
* form a UD message.
* The "Bind" segment contains the parameters required for a Bind Memory
* Window operation.
* The "Remote Address" segment is present only in RDMA or Atomic WQEs and
* specifies remote virtual addresses and RKey, respectively. Length of
* RDMA-write/RDMA-read) or set to eight (for Atomic).
* The "Atomic" segment is present only in Atomic WQEs and specifies
*
* Note: The following structures are not #define'd with both little-endian
* and big-endian definitions. This is because their individual fields are
* not directly accessed except through macros defined below.
*/
struct tavor_hw_snd_wqe_nextctrl_s {
uint32_t c :1;
uint32_t e :1;
uint32_t s :1;
uint32_t i :1;
};
struct tavor_hw_snd_wqe_ud_s {
};
struct tavor_hw_snd_wqe_bind_s {
};
struct tavor_hw_snd_wqe_remaddr_s {
};
struct tavor_hw_snd_wqe_atomic_s {
};
/*
* Tavor "MLX transport" Work Queue Element (WQE)
* The format of the MLX WQE is similar to that of the Send WQE (above)
* with the following exceptions. MLX WQEs are used for sending MADs on
* (defined below) consists of scatter-gather list entries. The contents
* of these SGLs (also defined below) will be put on the wire exactly as
* they appear in the buffers. In addition, the VCRC and the ICRC of each
* sent packet can be modified by changing values in the following header
* or in the payload of the packet itself.
*/
struct tavor_hw_mlx_wqe_nextctrl_s {
uint32_t c :1;
uint32_t e :1;
};
/*
* Tavor Receive Work Queue Element (WQE)
* Like the Send WQE, the Receive WQE is built of 16-byte segments. The
* some number of scatter list entries for the incoming message.
*
* The format of the scatter-gather list entries is also shown below. For
* Receive WQEs the "inline_data" field must be cleared (i.e. data segments
* cannot contain inline data).
*/
struct tavor_hw_rcv_wqe_nextctrl_s {
uint32_t c :1;
uint32_t e :1;
};
/*
* as a workaround to a Tavor hardware erratum related to having
* the first 32-bits in the WQE set to zero.
*/
struct tavor_hw_wqe_sgl_s {
};
/*
* The following defines are used when building descriptors for special QP
* work requests (i.e. MLX transport WQEs). Note: Because Tavor MLX transport
* requires the driver to build actual IB packet headers, we use these defines
* for the most common fields in those headers.
*/
/*
* The following macros are used for building each of the individual
* segments that can make up a Tavor WQE. Note: We try not to use the
* structures (with their associated bitfields) here, instead opting to
* build and put 64-bit or 32-bit chunks to the WQEs as appropriate,
* primarily because using the bitfields appears to force more read-modify-
* write operations.
*
* TAVOR_WQE_BUILD_UD - Builds Unreliable Datagram Segment
*
* TAVOR_WQE_BUILD_REMADDR - Builds Remote Address Segment using
* RDMA info from the work request
* TAVOR_WQE_BUILD_RC_ATOMIC_REMADDR - Builds Remote Address Segment
* for RC Atomic work requests
* TAVOR_WQE_BUILD_ATOMIC - Builds Atomic Segment using atomic
* info from the work request
* TAVOR_WQE_BUILD_BIND - Builds the Bind Memory Window
* Segment using bind info from the
* work request
* TAVOR_WQE_BUILD_DATA_SEG - Builds the individual Data Segments
* for Send, Receive, and MLX WQEs
* TAVOR_WQE_BUILD_INLINE - Builds an "inline" Data Segment
* (primarily for MLX transport)
* TAVOR_WQE_BUILD_INLINE_ICRC - Also builds an "inline" Data Segment
* (but used primarily in the ICRC
* portion of MLX transport WQEs)
* TAVOR_WQE_LINKNEXT - Links the current WQE to the
* previous one
* TAVOR_WQE_LINKFIRST - Links the first WQE on the current
* chain to the previous WQE
* TAVOR_WQE_BUILD_MLX_LRH - Builds the inline LRH header for
* MLX transport MADs
* TAVOR_WQE_BUILD_MLX_GRH - Builds the inline GRH header for
* MLX transport MADs
* TAVOR_WQE_BUILD_MLX_BTH - Builds the inline BTH header for
* MLX transport MADs
* TAVOR_WQE_BUILD_MLX_DETH - Builds the inline DETH header for
* MLX transport MADs
*/
{ \
\
TAVOR_WQE_SENDHDR_UD_DQPN_MASK) << 32) | \
}
{ \
\
(wr_rdma)->rdma_raddr); \
}
{ \
\
}
{ \
\
}
{ \
\
TAVOR_WQE_SENDHDR_BIND_ATOM : 0; \
TAVOR_WQE_SENDHDR_BIND_WR : 0; \
TAVOR_WQE_SENDHDR_BIND_RD : 0; \
}
{ \
\
}
{ \
\
}
{ \
\
}
{ \
\
}
{ \
(ctrl)); \
(next)); \
}
{ \
(ctrl)); \
(next)); \
}
{ \
(next)); \
}
{ \
\
\
} else { \
} \
} else { \
} \
\
lrh_tmp |= IB_LID_PERMISSIVE; \
} else { \
} \
}
/*
* Note: The GRH payload length, calculated below, is the overall packet
* length (in bytes) minus LRH header and GRH headers.
*
* Also note: Filling in the GIDs in the way we do below is helpful because
*/
{ \
\
\
\
sizeof (ib_grh_t))) << 16; \
\
}
{ \
\
\
} \
bth_tmp |= TAVOR_MLX_DEF_PKEY; \
} else { \
} \
}
{ \
\
\
} else { \
} \
}
/*
* Undocumented:
* The following registers (and the macros to access them) are not defined
* in the Tavor PRM. But we have high confidence that these offsets are
* unlikely to change in the lifetime of the Tavor hardware.
*/
((port) * TAVOR_HW_GUIDTABLE_PORT_SIZE) + \
((sgid_ix) * TAVOR_HW_GUIDTABLE_GID_SIZE))); \
((port) * TAVOR_HW_GUIDTABLE_PORT_SIZE) + \
((sgid_ix) * TAVOR_HW_GUIDTABLE_GID_SIZE) + \
((port) * TAVOR_HW_PKEYTABLE_PORT_SIZE) + \
/*
* Flash interface:
* Below we have PCI config space space offsets for flash interface
* access, offsets within Tavor CR space for accessing flash-specific
* information or settings, masks used for flash settings, and
* timeout values for flash operations.
*/
/* Intel Command Set */
#ifdef __cplusplus
}
#endif
#endif /* _SYS_IB_ADAPTERS_TAVOR_HW_H */