Description
Describe the bug
Title: rp1_pio_sm_config_xfer_internal() should support external DMA buffer configuration (zero-copy use cases)
Description:
The current implementation of rp1_pio_sm_config_xfer_internal() always allocates internal DMA buffers using dma_alloc_coherent(). However, rp1_pio_sm_xfer_data() supports passing an external dma_addr, allowing the user to manage DMA buffers independently.
This creates an inconsistency:
- The configuration function (
*_config_xfer_internal) does not allow setting up the DMA channel and FIFO transfer without also allocating bounce buffers. - The transfer function (
*_xfer_data) allows external buffers, but the configuration function does not account for this setup.
Further info iam defining a driver for a radio card (called radioberry). To use the pio makes it really nice and iam offload the CPU in my first experiments i saw a reduction from 40% CPU util to 4%.
Curious to the reply?
Johan
This prevents more advanced or zero-copy DMA use cases, where DMA buffers are allocated and managed externally (e.g., shared buffers, user-mapped memory, etc.).
Suggested improvement:
Enhance rp1_pio_sm_config_xfer_internal() to support different DMA buffer allocation modes:
enum rp1_pio_dma_alloc_mode {
RP1_PIO_DMA_ALLOC_INTERNAL, // current behavior
RP1_PIO_DMA_ALLOC_EXTERNAL, // setup DMA channel, but skip buffer allocation
RP1_PIO_DMA_ALLOC_NONE // configure only, without managing any buffers
};This would allow developers to configure DMA with:
- Internal bounce buffers (default),
- Externally managed buffers (used with pre-mapped
dma_addr), - Or just set up the DMA channel and slave config (for full manual control).
Benefits:
- Supports zero-copy DMA patterns.
- Provides flexibility for integrating with other subsystems.
- Maintains backward compatibility.
Steps to reproduce the behaviour
no steps but just looking into the code
Device (s)
Raspberry Pi 5
System
latest.
Logs
No response
Additional context
No response