From: Simona Vetter <simona.vetter@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: simona@ffwll.ch, javierm@redhat.com, airlied@gmail.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
hdegoede@redhat.com, airlied@redhat.com, sean@poorly.run,
sumit.semwal@linaro.org, christian.koenig@amd.com,
admin@kodeit.net, gargaditya08@live.com, jani.nikula@intel.com,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 0/5] drm: Provide a dedicated DMA device for PRIME import
Date: Fri, 7 Mar 2025 14:32:18 +0100 [thread overview]
Message-ID: <Z8r1Ymc0RzoHEUpG@phenom.ffwll.local> (raw)
In-Reply-To: <20250307080836.42848-1-tzimmermann@suse.de>
On Fri, Mar 07, 2025 at 09:03:58AM +0100, Thomas Zimmermann wrote:
> Importing dma-bufs via PRIME requires a DMA-capable hardware device.
> This is not the case for USB, where DMA is performed entirely by the
> USB controller instead of the USB devices.
>
> Drivers for USB-based hardware maintain their own workarounds for this
> problem. The original idea to resolve this was to provide different
> PRIME helpers for such devices, but the dma-buf code internally assumes
> DMA functionality as well. So that ideas is not realistic.
So dma-buf without dma is doable, but you have to avoid dma_buf_attach.
And that is a lot of surgery in the current prime helpers, since those
assume that an attachment always exists. But dma-buf itself is entirely
fine with cpu-only access through either userspace mmap or kernel vmap.
I think as an interim step this is still good, since it makes the current
hacks easier to find because at least it's all common now.
-Sima
> Let's instead turn the current workaround into a feature. Patch 1 adds a
> dma_dev field to struct drm_device and makes the PRIME code use it. Patches
> 2 to 5 replace related driver code.
>
> It will also be useful in other code. The exynos and mediatek drivers
> already maintain a dedicated DMA device for non-PRIME code. They could
> likely use dma_dev as well. GEM-DMA helpers currently allocate DMA
> memory with the regular parent device. They should support the dma_dev
> settings as well.
>
> Tested with udl.
>
> v2:
> - maintain reference on dma_dev (Jani)
> - improve docs (Maxime)
> - update appletbdrm
>
> Thomas Zimmermann (5):
> drm/prime: Support dedicated DMA device for dma-buf imports
> drm/appletbdrm: Set struct drm_device.dma_dev
> drm/gm12u320: Set struct drm_device.dma_dev
> drm/gud: Set struct drm_device.dma_dev
> drm/udl: Set struct drm_device.dma_dev
>
> drivers/gpu/drm/drm_drv.c | 21 ++++++++++++++
> drivers/gpu/drm/drm_prime.c | 2 +-
> drivers/gpu/drm/gud/gud_drv.c | 33 ++++++---------------
> drivers/gpu/drm/gud/gud_internal.h | 1 -
> drivers/gpu/drm/tiny/appletbdrm.c | 27 +++++++-----------
> drivers/gpu/drm/tiny/gm12u320.c | 46 +++++++++---------------------
> drivers/gpu/drm/udl/udl_drv.c | 17 -----------
> drivers/gpu/drm/udl/udl_drv.h | 1 -
> drivers/gpu/drm/udl/udl_main.c | 14 ++++-----
> include/drm/drm_device.h | 41 ++++++++++++++++++++++++++
> 10 files changed, 102 insertions(+), 101 deletions(-)
>
> --
> 2.48.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2025-03-07 13:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 8:03 [PATCH v2 0/5] drm: Provide a dedicated DMA device for PRIME import Thomas Zimmermann
2025-03-07 8:03 ` [PATCH v2 1/5] drm/prime: Support dedicated DMA device for dma-buf imports Thomas Zimmermann
2025-03-07 12:45 ` Jani Nikula
2025-03-07 13:03 ` Maxime Ripard
2025-03-07 8:04 ` [PATCH v2 2/5] drm/appletbdrm: Set struct drm_device.dma_dev Thomas Zimmermann
2025-03-07 11:14 ` Aditya Garg
2025-03-07 8:04 ` [PATCH v2 3/5] drm/gm12u320: " Thomas Zimmermann
2025-03-07 8:04 ` [PATCH v2 4/5] drm/gud: " Thomas Zimmermann
2025-03-07 8:04 ` [PATCH v2 5/5] drm/udl: " Thomas Zimmermann
2025-03-07 12:50 ` [PATCH v2 0/5] drm: Provide a dedicated DMA device for PRIME import Jani Nikula
2025-03-07 13:32 ` Simona Vetter [this message]
2025-03-10 9:50 ` Thomas Zimmermann
2025-03-10 10:04 ` Thomas Zimmermann
2025-03-10 13:56 ` Christian König
2025-03-10 14:30 ` Thomas Zimmermann
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=Z8r1Ymc0RzoHEUpG@phenom.ffwll.local \
--to=simona.vetter@ffwll.ch \
--cc=admin@kodeit.net \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gargaditya08@live.com \
--cc=hdegoede@redhat.com \
--cc=jani.nikula@intel.com \
--cc=javierm@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--cc=sumit.semwal@linaro.org \
--cc=tzimmermann@suse.de \
/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.