search for: dma_bufs

On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote: > This change adds a new flavor of dma-bufs that can be used by virtio > drivers to share exported objects. A virtio dma-buf can be queried by > virtio drivers to obtain the UUID which identifies the underlying > exported object. > > Signed-off-by: David Stevens <stevensd at chromium.org> Is this just for

On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote: > This change adds a new flavor of dma-bufs that can be used by virtio > drivers to share exported objects. A virtio dma-buf can be queried by > virtio drivers to obtain the UUID which identifies the underlying > exported object. > > Signed-off-by: David Stevens <stevensd at chromium.org> Is this just for

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

From: Thierry Reding <treding at nvidia.com> Export some more of the helpers in order to allow drivers to more fine- grainedly select which helpers to use. This gives drivers an easy way to reuse a lot of the code in the helpers while at the same time allowing them to provide their own implementation for other functions in struct dma_buf_ops. Signed-off-by: Thierry Reding <treding at

On Tue, Aug 18, 2020 at 04:13:41PM +0900, David Stevens wrote: > This change adds a new flavor of dma-bufs that can be used by virtio > drivers to share exported objects. A virtio dma-buf can be queried by > virtio drivers to obtain the UUID which identifies the underlying > exported object. > > Signed-off-by: David Stevens <stevensd at chromium.org> This makes VIRTIO

Hi David, On Fri, Jun 19, 2020 at 10:57:37AM +0900, David Stevens wrote: > On Thu, Jun 18, 2020 at 9:29 PM Guennadi Liakhovetski > <guennadi.liakhovetski at linux.intel.com> wrote: > > > > Hi Michael, > > > > On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote: > > > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote: >

...buf_get_uuid() function. Just storing the uuid should be doable (assuming this doesn't change during the lifetime of the buffer), so no need for a callback. - for the runtime upcasting the usual approach is to check the ->ops pointer. Which means that would need to be the same for all virtio dma_bufs, which might get a bit awkward. But I'd really prefer we not add allocator specific stuff like this to dma-buf. -Daniel > --- > drivers/dma-buf/dma-buf.c | 12 ++++++++++++ > include/linux/dma-buf.h | 18 ++++++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --gi...

...buf_get_uuid() function. Just storing the uuid should be doable (assuming this doesn't change during the lifetime of the buffer), so no need for a callback. - for the runtime upcasting the usual approach is to check the ->ops pointer. Which means that would need to be the same for all virtio dma_bufs, which might get a bit awkward. But I'd really prefer we not add allocator specific stuff like this to dma-buf. -Daniel > --- > drivers/dma-buf/dma-buf.c | 12 ++++++++++++ > include/linux/dma-buf.h | 18 ++++++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --gi...

This will otherwise cause a lockdep splat if reservations were a real lock type, so warn when nouveau forgets to unpin a buffer, and fix up the ones I've hit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c index cc79c79..acc6b08 100644 ---

This will otherwise cause a lockdep splat, so warn when nouveau forgets to unpin a buffer, and fix up the ones I've hit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 + drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_prime.c |

On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote: > This patch is an early RFC to judge the direction we are following in > our virtualization efforts in Chrome OS. The purpose is to start a > discussion on how to handle buffer sharing between multiple virtio > devices. > > On a side note, we are also working on a virtio video decoder interface > and

On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote: > Hi Daniel, Gerd, > > On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote: > > > This patch is an early RFC to judge the direction we are following in > > > our virtualization efforts in Chrome OS. The

On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote: > On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote: > > > Hi Daniel, Gerd, > > > > > > On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > > >

On Wed, Oct 16, 2019 at 12:19:02PM +0900, Tomasz Figa wrote: > On Wed, Oct 9, 2019 at 12:04 AM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote: > > > On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > > > > > > > On Sat, Oct 05, 2019 at 02:41:54PM

GEM's vmap and vunmap interfaces now wrap memory pointers in struct dma_buf_map. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_client.c | 18 +++++++++++------- drivers/gpu/drm/drm_gem.c | 28 ++++++++++++++-------------- drivers/gpu/drm/drm_internal.h | 5 +++-- drivers/gpu/drm/drm_prime.c | 14 ++++---------- 4 files changed, 32

From: Rob Clark <robdclark at chromium.org> Needed in the following patch for cache operations. Signed-off-by: Rob Clark <robdclark at chromium.org> --- v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 8 ++++---- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 4 ++--

From: Rob Clark <robdclark at chromium.org> Needed in the following patch for cache operations. Signed-off-by: Rob Clark <robdclark at chromium.org> --- v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 8 ++++---- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 4 ++--

From: Rob Clark <robdclark at chromium.org> Needed in the following patch for cache operations. Signed-off-by: Rob Clark <robdclark at chromium.org> --- v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 8 ++++---- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 4 ++--

...en wrote: > Allow user space to provide an explicit sync fence fd when exporting > a dma-buf from gem handle. The fence will be stored as the explicit > fence to the reservation object. > > Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> All existing userspace treats dma_bufs as long-lived objects. Well, all the userspace that expects implicit syncing, afaik Android shovels lots of dma-bufs around all the time (since ion is using them as it's native buffer handles). So adding an exclusive fence once at export time isn't going to be terribly useful. So I think...

Pointer variables of (void*) type do not require type cast. Signed-off-by: Su Hui <suhui at nfschina.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 2 +-