search for: dmabuf

...> 2 files changed, 30 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..fa5210ba6aaa 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) > +{ > + if (WARN_ON(!dmabuf) || !uuid) > + return -EINVAL; > + > + if (!dmabuf->ops->get_uuid) > + re...

...> 2 files changed, 30 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..fa5210ba6aaa 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,18 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) > +{ > + if (WARN_ON(!dmabuf) || !uuid) > + return -EINVAL; > + > + if (!dmabuf->ops->get_uuid) > + re...

...x/dma-buf.h> +#include <linux/reservation.h> #include <drm/drmP.h> #include "drm_internal.h" +#include "../../staging/android/sync.h" /* * DMA-BUF/GEM Object references and lifetime overview: @@ -329,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { * drm_gem_prime_export - helper library implemention of the export callback * @dev: drm_device to export from * @obj: GEM object to export - * @flags: flags like DRM_CLOEXEC + * @flags: flags like DRM_CLOEXEC or DRM_SYNC_FD * * This is the implementation of the gem_prime_export f...

.../reservation.h> > #include <drm/drmP.h> > #include "drm_internal.h" > +#include "../../staging/android/sync.h" > > /* > * DMA-BUF/GEM Object references and lifetime overview: > @@ -329,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { > * drm_gem_prime_export - helper library implemention of the export callback > * @dev: drm_device to export from > * @obj: GEM object to export > - * @flags: flags like DRM_CLOEXEC > + * @flags: flags like DRM_CLOEXEC or DRM_SYNC_FD > * > * This is the imple...

...ee ioctl). If NOUVEAU_AS_ALLOC_FLAGS_FIXED_OFFSET is set, offset specifies the requested virtual address. Otherwise, an arbitrary address will be allocated. In addition to this, a way to map/unmap buffers is needed. Ordinarily, one would just use DRM_IOCTL_PRIME_FD_TO_HANDLE to import and map a dmabuf into gem. However, this ioctl will try to grab the virtual address range for this buffer, which will fail in the CUDA case since the virtual address range has been reserved ahead of time. So we perhaps introduce a set of ioctls to map/unmap buffers on top of an already existing virtual address al...

...> index 1693aa7c14b5..9a87639e7008 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -386,10 +386,6 @@ static struct dma_buf *export_and_register_object(struct drm_device *dev, > > if (obj->funcs && obj->funcs->export) > dmabuf = obj->funcs->export(obj, flags); > - else if (dev->driver->gem_prime_export) > - dmabuf = dev->driver->gem_prime_export(obj, flags); > - else > - dmabuf = drm_gem_prime_export(obj, flags); > if (IS_ERR(dmabuf)) { > /* normally the created dma-buf takes ow...

From: Thierry Reding <treding at nvidia.com> struct device is forward-declared twice. Remove the second instance. Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk> Signed-off-by: Thierry Reding <treding at nvidia.com> --- include/drm/drm_prime.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h index

Hi, > Having the support for vmapping dmabuf's is required to share > dmabufs to drivers that want CPU access. This is the case of > a vivid to virtio-gpu pipeline, where the virtio-gpu driver > exports dmabufs to the video4linux vivid driver. > > The first patch adds virtio_gpu_object_kunmap() and calls > it from the T...

...me.c b/drivers/gpu/drm/drm_prime.c index 1693aa7c14b5..9a87639e7008 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -386,10 +386,6 @@ static struct dma_buf *export_and_register_object(struct drm_device *dev, if (obj->funcs && obj->funcs->export) dmabuf = obj->funcs->export(obj, flags); - else if (dev->driver->gem_prime_export) - dmabuf = dev->driver->gem_prime_export(obj, flags); - else - dmabuf = drm_gem_prime_export(obj, flags); if (IS_ERR(dmabuf)) { /* normally the created dma-buf takes ownership of the ref, * but...

...a/drivers/gpu/drm/nouveau/nouveau_prime.c +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c @@ -62,14 +62,15 @@ struct drm_gem_object *nouveau_gem_prime_import_sg_table(struct drm_device *dev, struct nouveau_drm *drm = nouveau_drm(dev); struct nouveau_bo *nvbo; struct dma_resv *robj = attach->dmabuf->resv; - size_t size = attach->dmabuf->size; + u64 size = attach->dmabuf->size; u32 flags = 0; + int align = 0; int ret; flags = TTM_PL_FLAG_TT; dma_resv_lock(robj, NULL); - nvbo = nouveau_bo_alloc(&drm->client, size, flags, 0, 0); + nvbo = nouveau_bo_alloc(&dr...

...me.c b/drivers/gpu/drm/drm_prime.c index 8a6a3c99b7d8..1cffb004d3c8 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -386,10 +386,6 @@ static struct dma_buf *export_and_register_object(struct drm_device *dev, if (obj->funcs && obj->funcs->export) dmabuf = obj->funcs->export(obj, flags); - else if (dev->driver->gem_prime_export) - dmabuf = dev->driver->gem_prime_export(obj, flags); - else - dmabuf = drm_gem_prime_export(obj, flags); if (IS_ERR(dmabuf)) { /* normally the created dma-buf takes ownership of the ref, * but...

Hello. All features are about usability and simple user experience. 1. Its about local display / dmabuf feature. Currently user needs to use virt-viewer tool. But virt-manager already incorporates graphical console. It would be nice if it could support accelerated gvt-g local display. Preferably with minimum performance overhead. Also virt-manager should allow to use mdev videocard alone, without req...

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are fixes for a couple of issues that I've been running into when testing on various Tegra boards. The first two patches fix up issues in the fix that I had sent out earlier to fix the regression introduced in drm-misc-next. The first one is critical because it avoids a BUG_ON as reported by Ilia, while the second is less

Hi, This is a proof of concept of GPU forwarding for Linux guest on Linux host. I'd like to get comments and suggestions from community before I put more time on it. To summarize what it is: 1. It's a solution to bring GPU acceleration for Linux vm guest on Linux host. It could works with different GPU although the current proof of concept only works with Intel GPU. 2. The basic idea

...gt; 2 files changed, 36 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..a04632284ec2 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,20 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +#ifdef CONFIG_VIRTIO > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) Hmm, I think I would drop the #ifdef cheers, Gerd

...hat report because of the other noisy >> reports. >> >> [1] >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114671v2/shard-snb5/igt at prime_vgem@sync at rcs0.html >> >> The test does the following: >> >> 1. creates vgem >> 2. export it do dmabuf >> 3. mmaps dmabuf >> >> There is an obvious deadlock there. The DRM code assumes that mmap() is >> unlocked, while for dma-buf it's locked. I'll see how to fix it for v14. >> > Christian, there is a deadlock problem in drm_gem_shmem_mmap() once we > move...

...stencil w/o depth on EG radeon: force 2D tiling for MSAA surfaces radeon: tweak TILE_SPLIT for MSAA surfaces tests/modetest: fix distcheck configure: bump version for 2.4.38 release Paulo Zanoni (1): intel: add more Haswell PCI IDs Rob Clark (5): omap: clarify dmabuf file descriptor ownership omap: add API to import bo's from dmabuf fd's omap: add refcnting and handle tracking intel: fix build error modetest: fix uninitialized fourcc git tag: libdrm-2.4.38 http://dri.freedesktop.org/www/libdrm/libdrm-2.4.38.tar.bz2 MD5: 8018e0...

...gpu_drv.h" > @@ -30,6 +33,84 @@ > * device that might share buffers with virtgpu > */ > > +static struct sg_table * > +virtgpu_gem_map_dma_buf(struct dma_buf_attachment *attach, > + enum dma_data_direction dir) > +{ > + struct drm_gem_object *obj = attach->dmabuf->priv; > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); > + struct sg_table *sgt; > + int ret; > + > + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > + if (!sgt) > + return ERR_PTR(-ENOMEM); > + > + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > + if (ret) {...

...as only the > host can know the requirements for memory allocation of the video > decode accelerator hardware. So you probably have some virtio-video-decoder. You allocate a gpu buffer, export it as dma-buf, import it into the decoder, then let the video decoder render to it. Right? Using dmabufs makes sense for sure. But we need an separate field in struct dma_buf for an (optional) host dmabuf identifier, we can't just hijack the dma address. cheers, Gerd

...gpu > > > */ > > > > > > +static struct sg_table * > > > +virtgpu_gem_map_dma_buf(struct dma_buf_attachment *attach, > > > + enum dma_data_direction dir) > > > +{ > > > + struct drm_gem_object *obj = attach->dmabuf->priv; > > > + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); > > > + struct sg_table *sgt; > > > + int ret; > > > + > > > + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > > > + if (!sgt) > > > +...