STRUCT DMA_SLAVE_CONFIG(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct dma_slave_config(9) πŸ’–

okay bestie, welcome to the Kernel API Manual! this is the entry for struct dma_slave_config(9), and it is literally the runtime config for a DMA slave channel. no cap, it’s giving β€œlet’s set up this channel at runtime” energy πŸ¦‹

πŸŽ€ NAME πŸŽ€

struct dma_slave_config β€” dma slave channel runtime config. that’s the name, that’s the vibe, and we are obsessed with how specific it is πŸ’…

✨ SYNOPSIS ✨

struct dma_slave_config {
    enum dma_transfer_direction direction;
    phys_addr_t src_addr;
    phys_addr_t dst_addr;
    enum dma_slave_buswidth src_addr_width;
    enum dma_slave_buswidth dst_addr_width;
    u32 src_maxburst;
    u32 dst_maxburst;
    u32 src_port_window_size;
    u32 dst_port_window_size;
    bool device_fc;
    void *peripheral_config;
    size_t peripheral_size;
};

πŸ¦‹ Members πŸ¦‹

  • direction β€” whether the data shall go in or out on this slave channel, right now. DMA_MEM_TO_DEV and DMA_DEV_TO_MEM are legal values. DEPRECATED, drivers should use the direction argument to the device_prep_slave_sg and device_prep_dma_cyclic functions or the dir field in the dma_interleaved_template structure. not me putting deprecated fields on blast but πŸ‘€
  • src_addr β€” this is the physical address where DMA slave data should be read (RX), if the source is memory this argument is ignored. RX girlies rise πŸ’–
  • dst_addr β€” this is the physical address where DMA slave data should be written (TX), if the destination is memory this argument is ignored. TX transmission moment ✨
  • src_addr_width β€” this is the width in bytes of the source (RX) register where DMA data shall be read. If the source is memory this may be ignored depending on architecture. Legal values: 1, 2, 3, 4, 8, 16, 32, 64, 128. bytes bestie, bytes πŸ“
  • dst_addr_width β€” same as src_addr_width but for destination target (TX) mutatis mutandis. same energy, different direction πŸŽ€
  • src_maxburst β€” the maximum number of words (note: words, as in units of the src_addr_width member, not bytes) that can be sent in one burst to the device. Typically something like half the FIFO depth on I/O peripherals so you don’t overflow it. This may or may not be applicable on memory sources. do not overflow the FIFO, that’s the whole assignment 🫢
  • dst_maxburst β€” same as src_maxburst but for destination target mutatis mutandis. destination burst, same rules πŸ’œ
  • src_port_window_size β€” The length of the register area in words the data need to be accessed on the device side. It is only used for devices which is using an area instead of a single register to receive the data. Typically the DMA loops in this area in order to transfer the data. register area loop-de-loop 🌈
  • dst_port_window_size β€” same as src_port_window_size but for the destination port. destination port window, slay 🌸
  • device_fc β€” Flow Controller Settings. Only valid for slave channels. Fill with 'true' if peripheral should be flow controller. Direction will be selected at Runtime. flow controller era πŸ‘‘
  • peripheral_config β€” peripheral configuration for programming peripheral for dmaengine transfer. peripheral programming bestie πŸ’…
  • peripheral_size β€” peripheral configuration buffer size. buffer size check πŸŽ€

🌸 Description 🌸

This struct is passed in as configuration data to a DMA engine in order to set up a certain channel for DMA transport at runtime. The DMA device/engine has to provide support for an additional callback in the dma_device structure, device_config and this struct will then be passed in as an argument to the function. that’s the whole runtime setup moment ✨

The rationale for adding configuration information to this struct is as follows: if it is likely that more than one DMA slave controllers in the world will support the configuration option, then make it generic. If not: if it is fixed so that it be sent in static from the platform data, then prefer to do that. generic if multiple controllers might support it; static platform data if it’s fixed β€” iykyk πŸ¦‹

πŸ”₯ SEE ALSO πŸ”₯

Kernel file ./include/linux/dmaengine.h β€” and literally the whole extended universe, bestie: dma_cookie_t(9), enum dma_status(9), enum dma_transaction_type(9), enum dma_transfer_direction(9), struct data_chunk(9), struct dma_interleaved_template(9), struct dma_vec(9), enum dma_ctrl_flags(9), enum sum_check_bits(9), enum sum_check_flags(9), enum dma_desc_metadata_mode(9), struct dma_chan_percpu(9), struct dma_router(9), struct dma_chan(9), struct dma_chan_dev(9), enum dma_slave_buswidth(9), enum dma_residue_granularity(9), struct dma_slave_caps(9), dma_filter_fn(9), struct dma_async_tx_descriptor(9), struct dma_tx_state(9), enum dmaengine_alignment(9), struct dma_slave_map(9), struct dma_filter(9), struct dma_device(9), dmaengine_prep_peripheral_dma_vec(9), dmaengine_prep_config_sg_safe(9), dmaengine_prep_config_single_safe(9), dmaengine_prep_dma_memset(9), dmaengine_terminate_all(9), dmaengine_terminate_async(9), dmaengine_synchronize(9), dmaengine_terminate_sync(9), dma_async_issue_pending(9), dma_async_is_tx_complete(9), dma_async_is_complete(9).


mwah πŸ’‹ this page is brought to you by the Kernel API Manual, source/version ./include/linux, dated October 2026 β€” go set up that channel at runtime, bestie! 🫢✨

πŸ“¦ where this page comes from