All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Aravind Thokala <aravind.thokala@amd.com>,
	mdf@kernel.org, yilun.xu@intel.com, trix@redhat.com,
	sumit.semwal@linaro.org
Cc: corbet@lwn.net, skhan@linuxfoundation.org,
	linux-kernel@vger.kernel.org, linux-fpga@vger.kernel.org,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-doc@vger.kernel.org,
	git@amd.com, nava.kishore.manne@amd.com
Subject: Re: [PATCH 0/2] fpga: add dma-buf based FPGA programming interface
Date: Mon, 24 Aug 2026 10:50:10 +0200	[thread overview]
Message-ID: <e747060e-ba01-4d0b-aaa6-d4c619494f09@amd.com> (raw)
In-Reply-To: <20260816150734.2092802-1-aravind.thokala@amd.com>

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
> 


      parent reply	other threads:[~2026-08-24  8:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-16 15:07 [PATCH 0/2] fpga: add dma-buf based FPGA programming interface Aravind Thokala
2026-08-16 15:07 ` [PATCH 1/2] fpga: Add dma-buf interface for FPGA programming Aravind Thokala
2026-08-16 15:19   ` sashiko-bot
2026-08-16 15:07 ` [PATCH 2/2] fpga: versal: add dma-buf programming support Aravind Thokala
2026-08-16 15:18   ` sashiko-bot
2026-08-20  6:57     ` Aravind Thokala
2026-08-24  8:50 ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e747060e-ba01-4d0b-aaa6-d4c619494f09@amd.com \
    --to=christian.koenig@amd.com \
    --cc=aravind.thokala@amd.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=git@amd.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mdf@kernel.org \
    --cc=nava.kishore.manne@amd.com \
    --cc=skhan@linuxfoundation.org \
    --cc=sumit.semwal@linaro.org \
    --cc=trix@redhat.com \
    --cc=yilun.xu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.