Some systems need to load large FPGA configuration images. The FPGA
subsystem allows loading images from the filesystem, but this requires
the entire image to be loaded into kernel memory first. For drivers
that need a DMA-capable buffer for programming, the data is then
copied again into DMA memory. This creates needless memory pressure
and delays due to the extra copy.

This series adds dma-buf support that allows userspace to allocate a
buffer directly from a DMA heap, write the FPGA image into it, and
pass the file descriptor to the kernel via ioctl — skipping the
intermediate kernel buffer entirely.

Userspace flow:
  1. Allocate buffer from /dev/dma_heap/ (e.g., CMA heap)
  2. mmap the buffer and write the FPGA image into it
  3. ioctl(/dev/fpgaX, FPGA_IOCTL_LOAD_DMA_BUF, &dmabuf_fd)

The dma-buf logic is implemented as a separate layer on top of the
FPGA manager, keeping buffer management separate from the write path.
Individual FPGA drivers opt in by calling fpga_dmabuf_register().
---
This work is based on the approach discussed in [1].

[1] https://lore.kernel.org/all/20231122053035.3758124-1-nava.kishore.manne@amd.com/
---
Aravind Thokala (2):
  fpga: Add dma-buf interface for FPGA programming
  fpga: versal: add dma-buf programming support

 .../userspace-api/ioctl/ioctl-number.rst      |   1 +
 MAINTAINERS                                   |   1 +
 drivers/fpga/Kconfig                          |   9 +
 drivers/fpga/Makefile                         |   2 +
 drivers/fpga/fpga-dmabuf.c                    | 198 ++++++++++++++++++
 drivers/fpga/versal-fpga.c                    |  33 ++-
 include/linux/fpga/fpga-dmabuf.h              |  22 ++
 include/linux/fpga/fpga-mgr.h                 |   1 +
 include/uapi/linux/fpga.h                     |  15 ++
 9 files changed, 281 insertions(+), 1 deletion(-)
 create mode 100644 drivers/fpga/fpga-dmabuf.c
 create mode 100644 include/linux/fpga/fpga-dmabuf.h
 create mode 100644 include/uapi/linux/fpga.h

-- 
2.34.1

On 8/16/26 17:07, Aravind Thokala wrote:
> Some systems need to load large FPGA configuration images. The FPGA
> subsystem allows loading images from the filesystem, but this requires
> the entire image to be loaded into kernel memory first. For drivers
> that need a DMA-capable buffer for programming, the data is then
> copied again into DMA memory. This creates needless memory pressure
> and delays due to the extra copy.
> 
> This series adds dma-buf support that allows userspace to allocate a
> buffer directly from a DMA heap, write the FPGA image into it, and
> pass the file descriptor to the kernel via ioctl — skipping the
> intermediate kernel buffer entirely.

Well when you have a device with limited DMA capabilitiesthen DMA buf heaps doesn't allocate DMA-capable memory for that device either.

So the explanation you give above why this interface might be useful is clearly not correct. The DMA subsystem will still do an additional copy when you try to import the DMA-buf allocated from the heap into this device.

Either you need to define a heap with specific allocation restrictions (e.g. GFP_DMA32) or you allocate the DMA-buf through your fpga device so that dma_alloc_attrs() knows that a certain device needs to access the pages beforehand.

Regards,
Christian.

> 
> Userspace flow:
>   1. Allocate buffer from /dev/dma_heap/ (e.g., CMA heap)
>   2. mmap the buffer and write the FPGA image into it
>   3. ioctl(/dev/fpgaX, FPGA_IOCTL_LOAD_DMA_BUF, &dmabuf_fd)
> 
> The dma-buf logic is implemented as a separate layer on top of the
> FPGA manager, keeping buffer management separate from the write path.
> Individual FPGA drivers opt in by calling fpga_dmabuf_register().
> ---
> This work is based on the approach discussed in [1].
> 
> [1] https://lore.kernel.org/all/20231122053035.3758124-1-nava.kishore.manne@amd.com/
> ---
> Aravind Thokala (2):
>   fpga: Add dma-buf interface for FPGA programming
>   fpga: versal: add dma-buf programming support
> 
>  .../userspace-api/ioctl/ioctl-number.rst      |   1 +
>  MAINTAINERS                                   |   1 +
>  drivers/fpga/Kconfig                          |   9 +
>  drivers/fpga/Makefile                         |   2 +
>  drivers/fpga/fpga-dmabuf.c                    | 198 ++++++++++++++++++
>  drivers/fpga/versal-fpga.c                    |  33 ++-
>  include/linux/fpga/fpga-dmabuf.h              |  22 ++
>  include/linux/fpga/fpga-mgr.h                 |   1 +
>  include/uapi/linux/fpga.h                     |  15 ++
>  9 files changed, 281 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/fpga/fpga-dmabuf.c
>  create mode 100644 include/linux/fpga/fpga-dmabuf.h
>  create mode 100644 include/uapi/linux/fpga.h
> 

Hi Christian,

On 8/24/2026 2:20 PM, Christian König wrote:
> On 8/16/26 17:07, Aravind Thokala wrote:
>> Some systems need to load large FPGA configuration images. The FPGA
>> subsystem allows loading images from the filesystem, but this requires
>> the entire image to be loaded into kernel memory first. For drivers
>> that need a DMA-capable buffer for programming, the data is then
>> copied again into DMA memory. This creates needless memory pressure
>> and delays due to the extra copy.
>>
>> This series adds dma-buf support that allows userspace to allocate a
>> buffer directly from a DMA heap, write the FPGA image into it, and
>> pass the file descriptor to the kernel via ioctl — skipping the
>> intermediate kernel buffer entirely.
> 
> Well when you have a device with limited DMA capabilitiesthen DMA buf heaps doesn't allocate DMA-capable memory for that device either.
> 
> So the explanation you give above why this interface might be useful is clearly not correct. The DMA subsystem will still do an additional copy when you try to import the DMA-buf allocated from the heap into this device.
> 
> Either you need to define a heap with specific allocation restrictions (e.g. GFP_DMA32) or you allocate the DMA-buf through your fpga device so that dma_alloc_attrs() knows that a certain device needs to access the pages beforehand.
> 
> Regards,
> Christian.
> 

Thank you for the review. Agreed, the current approach does not 
guarantee DMA-capable allocations for all devices.

We are looking into the device-owned allocation approach using 
dma_alloc_attrs() and plan to follow up with an updated series.

Kind Regards,
Aravind.


>>
>> Userspace flow:
>>    1. Allocate buffer from /dev/dma_heap/ (e.g., CMA heap)
>>    2. mmap the buffer and write the FPGA image into it
>>    3. ioctl(/dev/fpgaX, FPGA_IOCTL_LOAD_DMA_BUF, &dmabuf_fd)
>>
>> The dma-buf logic is implemented as a separate layer on top of the
>> FPGA manager, keeping buffer management separate from the write path.
>> Individual FPGA drivers opt in by calling fpga_dmabuf_register().
>> ---
>> This work is based on the approach discussed in [1].
>>
>> [1] https://lore.kernel.org/all/20231122053035.3758124-1-nava.kishore.manne@amd.com/
>> ---
>> Aravind Thokala (2):
>>    fpga: Add dma-buf interface for FPGA programming
>>    fpga: versal: add dma-buf programming support
>>
>>   .../userspace-api/ioctl/ioctl-number.rst      |   1 +
>>   MAINTAINERS                                   |   1 +
>>   drivers/fpga/Kconfig                          |   9 +
>>   drivers/fpga/Makefile                         |   2 +
>>   drivers/fpga/fpga-dmabuf.c                    | 198 ++++++++++++++++++
>>   drivers/fpga/versal-fpga.c                    |  33 ++-
>>   include/linux/fpga/fpga-dmabuf.h              |  22 ++
>>   include/linux/fpga/fpga-mgr.h                 |   1 +
>>   include/uapi/linux/fpga.h                     |  15 ++
>>   9 files changed, 281 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/fpga/fpga-dmabuf.c
>>   create mode 100644 include/linux/fpga/fpga-dmabuf.h
>>   create mode 100644 include/uapi/linux/fpga.h
>>
>