drivers/dma/nbpfaxi.c
Source file repositories/reference/linux-study-clean/drivers/dma/nbpfaxi.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/dma/nbpfaxi.c- Extension
.c- Size
- 41529 bytes
- Lines
- 1536
- Domain
- Driver Families
- Bucket
- drivers/dma
- 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.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/bitmap.hlinux/bitops.hlinux/clk.hlinux/dma-mapping.hlinux/dmaengine.hlinux/err.hlinux/interrupt.hlinux/io.hlinux/log2.hlinux/module.hlinux/of.hlinux/of_dma.hlinux/platform_device.hlinux/slab.hdt-bindings/dma/nbpfaxi.hdmaengine.h
Detected Declarations
struct nbpf_configstruct nbpf_link_regstruct nbpf_devicestruct nbpf_channelstruct nbpf_descstruct nbpf_link_descstruct nbpf_descstruct nbpf_desc_pagestruct nbpf_channelstruct nbpf_deviceenum nbpf_modelfunction nbpf_chan_readfunction nbpf_chan_writefunction nbpf_readfunction nbpf_writefunction nbpf_chan_haltfunction nbpf_status_getfunction nbpf_status_ackfunction nbpf_error_getfunction nbpf_error_clearfunction nbpf_startfunction nbpf_chan_preparefunction nbpf_chan_prepare_defaultfunction nbpf_chan_configurefunction nbpf_xfer_dsfunction nbpf_xfer_sizefunction nbpf_prep_onefunction nbpf_bytes_leftfunction nbpf_configurefunction nbpf_issue_pendingfunction nbpf_tx_statusfunction list_for_each_entryfunction nbpf_tx_submitfunction nbpf_desc_page_allocfunction nbpf_desc_putfunction nbpf_scan_ackedfunction list_for_each_entry_safefunction nbpf_chan_idlefunction list_for_each_entry_safefunction nbpf_pausefunction nbpf_terminate_allfunction nbpf_configfunction nbpf_alloc_chan_resourcesfunction nbpf_free_chan_resourcesfunction list_for_each_entry_safefunction nbpf_chan_taskletfunction list_for_each_entry_safefunction nbpf_chan_irq
Annotated Snippet
struct nbpf_config {
int num_channels;
int buffer_size;
};
/*
* We've got 3 types of objects, used to describe DMA transfers:
* 1. high-level descriptor, containing a struct dma_async_tx_descriptor object
* in it, used to communicate with the user
* 2. hardware DMA link descriptors, that we pass to DMAC for DMA transfer
* queuing, these must be DMAable, using either the streaming DMA API or
* allocated from coherent memory - one per SG segment
* 3. one per SG segment descriptors, used to manage HW link descriptors from
* (2). They do not have to be DMAable. They can either be (a) allocated
* together with link descriptors as mixed (DMA / CPU) objects, or (b)
* separately. Even if allocated separately it would be best to link them
* to link descriptors once during channel resource allocation and always
* use them as a single object.
* Therefore for both cases (a) and (b) at run-time objects (2) and (3) shall be
* treated as a single SG segment descriptor.
*/
struct nbpf_link_reg {
u32 header;
u32 src_addr;
u32 dst_addr;
u32 transaction_size;
u32 config;
u32 interval;
u32 extension;
u32 next;
} __packed;
struct nbpf_device;
struct nbpf_channel;
struct nbpf_desc;
struct nbpf_link_desc {
struct nbpf_link_reg *hwdesc;
dma_addr_t hwdesc_dma_addr;
struct nbpf_desc *desc;
struct list_head node;
};
/**
* struct nbpf_desc - DMA transfer descriptor
* @async_tx: dmaengine object
* @user_wait: waiting for a user ack
* @length: total transfer length
* @chan: associated DMAC channel
* @sg: list of hardware descriptors, represented by struct nbpf_link_desc
* @node: member in channel descriptor lists
*/
struct nbpf_desc {
struct dma_async_tx_descriptor async_tx;
bool user_wait;
size_t length;
struct nbpf_channel *chan;
struct list_head sg;
struct list_head node;
};
/* Take a wild guess: allocate 4 segments per descriptor */
#define NBPF_SEGMENTS_PER_DESC 4
#define NBPF_DESCS_PER_PAGE ((PAGE_SIZE - sizeof(struct list_head)) / \
(sizeof(struct nbpf_desc) + \
NBPF_SEGMENTS_PER_DESC * \
(sizeof(struct nbpf_link_desc) + sizeof(struct nbpf_link_reg))))
#define NBPF_SEGMENTS_PER_PAGE (NBPF_SEGMENTS_PER_DESC * NBPF_DESCS_PER_PAGE)
struct nbpf_desc_page {
struct list_head node;
struct nbpf_desc desc[NBPF_DESCS_PER_PAGE];
struct nbpf_link_desc ldesc[NBPF_SEGMENTS_PER_PAGE];
struct nbpf_link_reg hwdesc[NBPF_SEGMENTS_PER_PAGE];
};
/**
* struct nbpf_channel - one DMAC channel
* @dma_chan: standard dmaengine channel object
* @tasklet: channel specific tasklet used for callbacks
* @base: register address base
* @nbpf: DMAC
* @name: IRQ name
* @irq: IRQ number
* @slave_src_addr: source address for slave DMA
* @slave_src_width: source slave data size in bytes
* @slave_src_burst: maximum source slave burst size in bytes
* @slave_dst_addr: destination address for slave DMA
* @slave_dst_width: destination slave data size in bytes
Annotation
- Immediate include surface: `linux/bitmap.h`, `linux/bitops.h`, `linux/clk.h`, `linux/dma-mapping.h`, `linux/dmaengine.h`, `linux/err.h`, `linux/interrupt.h`, `linux/io.h`.
- Detected declarations: `struct nbpf_config`, `struct nbpf_link_reg`, `struct nbpf_device`, `struct nbpf_channel`, `struct nbpf_desc`, `struct nbpf_link_desc`, `struct nbpf_desc`, `struct nbpf_desc_page`, `struct nbpf_channel`, `struct nbpf_device`.
- Atlas domain: Driver Families / drivers/dma.
- 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.