drivers/infiniband/hw/hfi1/sdma.h
Source file repositories/reference/linux-study-clean/drivers/infiniband/hw/hfi1/sdma.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/infiniband/hw/hfi1/sdma.h- Extension
.h- Size
- 32021 bytes
- Lines
- 1056
- Domain
- Driver Families
- Bucket
- drivers/infiniband
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.hlinux/list.hasm/byteorder.hlinux/workqueue.hlinux/rculist.hhfi.hverbs.hsdma_txreq.h
Detected Declarations
struct sdma_set_state_actionstruct sdma_statestruct hw_sdma_descstruct sdma_enginestruct iowait_workstruct sdma_map_elemstruct sdma_vl_mapenum sdma_statesenum sdma_eventsfunction sdma_emptyfunction sdma_descq_freecntfunction sdma_descq_inprocessfunction __sdma_runningfunction sdma_runningfunction sdma_txinit_ahgfunction sdma_txinitfunction sdma_mapping_typefunction sdma_mapping_lenfunction sdma_mapping_addrfunction make_tx_sdma_descfunction sdma_txcleanfunction _sdma_close_txfunction _sdma_txadd_daddrfunction sdma_txadd_pagefunction sdma_txadd_daddrfunction sdma_txadd_kvaddrfunction sdma_build_ahg_descriptorfunction sdma_progressfunction sdma_engine_progress_schedule
Annotated Snippet
struct sdma_set_state_action {
unsigned op_enable:1;
unsigned op_intenable:1;
unsigned op_halt:1;
unsigned op_cleanup:1;
unsigned go_s99_running_tofalse:1;
unsigned go_s99_running_totrue:1;
};
struct sdma_state {
struct kref kref;
struct completion comp;
enum sdma_states current_state;
unsigned current_op;
unsigned go_s99_running;
/* debugging/development */
enum sdma_states previous_state;
unsigned previous_op;
enum sdma_events last_event;
};
/**
* DOC: sdma exported routines
*
* These sdma routines fit into three categories:
* - The SDMA API for building and submitting packets
* to the ring
*
* - Initialization and tear down routines to buildup
* and tear down SDMA
*
* - ISR entrances to handle interrupts, state changes
* and errors
*/
/**
* DOC: sdma PSM/verbs API
*
* The sdma API is designed to be used by both PSM
* and verbs to supply packets to the SDMA ring.
*
* The usage of the API is as follows:
*
* Embed a struct iowait in the QP or
* PQ. The iowait should be initialized with a
* call to iowait_init().
*
* The user of the API should create an allocation method
* for their version of the txreq. slabs, pre-allocated lists,
* and dma pools can be used. Once the user's overload of
* the sdma_txreq has been allocated, the sdma_txreq member
* must be initialized with sdma_txinit() or sdma_txinit_ahg().
*
* The txreq must be declared with the sdma_txreq first.
*
* The tx request, once initialized, is manipulated with calls to
* sdma_txadd_daddr(), sdma_txadd_page(), or sdma_txadd_kvaddr()
* for each disjoint memory location. It is the user's responsibility
* to understand the packet boundaries and page boundaries to do the
* appropriate number of sdma_txadd_* calls.. The user
* must be prepared to deal with failures from these routines due to
* either memory allocation or dma_mapping failures.
*
* The mapping specifics for each memory location are recorded
* in the tx. Memory locations added with sdma_txadd_page()
* and sdma_txadd_kvaddr() are automatically mapped when added
* to the tx and nmapped as part of the progress processing in the
* SDMA interrupt handling.
*
* sdma_txadd_daddr() is used to add an dma_addr_t memory to the
* tx. An example of a use case would be a pre-allocated
* set of headers allocated via dma_pool_alloc() or
* dma_alloc_coherent(). For these memory locations, it
* is the responsibility of the user to handle that unmapping.
* (This would usually be at an unload or job termination.)
*
* The routine sdma_send_txreq() is used to submit
* a tx to the ring after the appropriate number of
* sdma_txadd_* have been done.
*
* If it is desired to send a burst of sdma_txreqs, sdma_send_txlist()
* can be used to submit a list of packets.
*
* The user is free to use the link overhead in the struct sdma_txreq as
* long as the tx isn't in flight.
*
* The extreme degenerate case of the number of descriptors
* exceeding the ring size is automatically handled as
* memory locations are added. An overflow of the descriptor
* array that is part of the sdma_txreq is also automatically
Annotation
- Immediate include surface: `linux/types.h`, `linux/list.h`, `asm/byteorder.h`, `linux/workqueue.h`, `linux/rculist.h`, `hfi.h`, `verbs.h`, `sdma_txreq.h`.
- Detected declarations: `struct sdma_set_state_action`, `struct sdma_state`, `struct hw_sdma_desc`, `struct sdma_engine`, `struct iowait_work`, `struct sdma_map_elem`, `struct sdma_vl_map`, `enum sdma_states`, `enum sdma_events`, `function sdma_empty`.
- Atlas domain: Driver Families / drivers/infiniband.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.