Re: [Intel-gfx] [PATCH v5 00/21] Move all drivers to a common dma-buf locking convention

| 17 +- > drivers/infiniband/core/umem_dmabuf.c | 7 +- > .../common/videobuf2/videobuf2-dma-contig.c | 22 +- > .../media/common/videobuf2/videobuf2-dma-sg.c | 19 +- > .../common/videobuf2/videobuf2-vmalloc.c | 17 +- > .../platform/nvidia/tegra-vde/dmabuf-c

Re: [Intel-gfx] [PATCH v5 15/21] dma-buf: Move dma_buf_vmap() to dynamic locking specification

return; > > + dma_resv_assert_held(dmabuf->resv); > + > BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr)); > BUG_ON(dmabuf->vmapping_counter == 0); > BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map)); > -- > 2.37.3 > -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs

Re: [Intel-gfx] [PATCH v2] dma-buf-map: Rename to iosys-map

t drm-misc-next and provide a > >follow up to cleanup the MAINTAINERS file a bit more. Thank you for the patch; apologies for not being able to respond earlier (was out due to covid, just getting back slowly). With Christian's suggestions, looks good to me as well - feel free to add an A

Re: [Intel-gfx] [PATCH 4/7] dma-buf: Document DMA_BUF_IOCTL_SYNC

Signed-off-by: Jason Ekstrand > > Cc: Daniel Vetter > > Cc: Christian König > > Cc: Sumit Semwal > > We're still missing the doc for the SET_NAME ioctl, but maybe Sumit can be > motivated to fix that? > Yes, certainly, I'll cook up a patc

Re: [Intel-gfx] [PATCH 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory

Hi Thomas, On Fri, 18 Sep 2020 at 11:36, Sumit Semwal wrote: > > Hello Thomas, > > On Mon, 14 Sep 2020 at 16:55, Thomas Zimmermann wrote: > > > > Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings > > of dma-buf memory in kernel address spa

Re: [Intel-gfx] [PATCH 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory

-map for storing struct dma_buf.vaddr_ptr > dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces > dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces FWIW, for the series, please feel free to add my Acked-by: Sumit Semwal > > Documentation/driver-api/dma-buf.rst

Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"

Hi Christian, On Fri, 26 Jun 2020, 18:10 Daniel Vetter, wrote: > On Fri, Jun 26, 2020 at 9:03 AM Christian König > wrote: > > > > Am 26.06.20 um 06:43 schrieb Sumit Semwal: > > > On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote: > > >> Ignoring everyt

Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"

On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote: > > Ignoring everything else ... > > On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula > wrote: > > As a side note, there seem to be extra checks in place for acks when > > applying non-i915 patches to drm-intel; there are no such checks for > > drm-m

Re: [Intel-gfx] [PATCH 00/15] Retire dma_buf_k(un)map

g shared. > > So since it was never used, and this idea's time is clearly over, let's > remove it all. As always, thanks for helping keep this code sane :) Fwiw, for the series, please feel free to add my Acked-by: Sumit Semwal > > Only real change I had to do (aside fro

Re: [Intel-gfx] [PATCH] dma-buf: rename reservation_object to dma_resv

ks for doing this! Acked-by: Sumit Semwal > > Letting the compiler do the real work (for the bits I spot checked it > was the expected mechanical translation), and overwhelmingly agreeing with > the motivation, > Reviewed-by: Chris Wilson > -Chris > Best, Sumit. _

Re: [Intel-gfx] [PATCHv2] drm/prime: Forward declare struct device

struct device' declared inside > parameter list will not be visible outside of this definition or > declaration > struct device *attach_dev); > ^~ > > Forward declare it. > > Signed-off-by: Laura Abbott Thanks for the

Re: [Intel-gfx] [PULL] drm-misc-next-fixes

On 21 April 2017 at 03:20, Daniel Vetter wrote: >> - Rename dma_buf_ops->kmap_* to avoid naming collision (Logan) > > This one touches v4l and ion and is acked by the corresponding > maintainers (but Sumit forgot to record that when applying the patch, > and Sean didn't highlight it in the summar

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

--- a/drivers/staging/android/ion/ion.c >>> +++ b/drivers/staging/android/ion/ion.c >>> @@ -1020,10 +1020,10 @@ static const struct dma_buf_ops dma_buf_ops = { >>> .release = ion_dma_buf_release, >>> .begin_cpu_access = ion_dma_buf_begin_cpu_access, >>> .end_cpu_access = ion_dma_buf_end_cpu_access, >>> - .kmap_atomic = ion_dma_buf_kmap, >>> - .kunmap_atomic = ion_dma_buf_kunmap, >>> - .kmap = ion_dma_buf_kmap, >>> - .kunmap = ion_dma_buf_kunmap, >>> + .map_atomic = ion_dma_buf_kmap, >>> + .unmap_atomic = ion_dma_buf_kunmap, >>> + .map = ion_dma_buf_kmap, >>> + .unmap = ion_dma_buf_kunmap, >>> }; >>> >>> struct dma_buf *ion_share_dma_buf(struct ion_client *client, >>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h >>> index bfb3704..79f27d6 100644 >>> --- a/include/linux/dma-buf.h >>> +++ b/include/linux/dma-buf.h >>> @@ -39,13 +39,13 @@ struct dma_buf_attachment; >>> >>> /** >>>* struct dma_buf_ops - operations possible on struct dma_buf >>> - * @kmap_atomic: maps a page from the buffer into kernel address >>> - * space, users may not block until the subsequent unmap >>> call. >>> - * This callback must not sleep. >>> - * @kunmap_atomic: [optional] unmaps a atomically mapped page from the >>> buffer. >>> - *This Callback must not sleep. >>> - * @kmap: maps a page from the buffer into kernel address space. >>> - * @kunmap: [optional] unmaps a page from the buffer. >>> + * @map_atomic: maps a page from the buffer into kernel address >>> + * space, users may not block until the subsequent unmap >>> call. >>> + * This callback must not sleep. >>> + * @unmap_atomic: [optional] unmaps a atomically mapped page from the >>> buffer. >>> + * This Callback must not sleep. >>> + * @map: maps a page from the buffer into kernel address space. >>> + * @unmap: [optional] unmaps a page from the buffer. >>>* @vmap: [optional] creates a virtual mapping for the buffer into >>> kernel >>>* address space. Same restrictions as for vmap and friends apply. >>>* @vunmap: [optional] unmaps a vmap from the buffer >>> @@ -206,10 +206,10 @@ struct dma_buf_ops { >>> * to be restarted. >>> */ >>> int (*end_cpu_access)(struct dma_buf *, enum dma_data_direction); >>> - void *(*kmap_atomic)(struct dma_buf *, unsigned long); >>> - void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *); >>> - void *(*kmap)(struct dma_buf *, unsigned long); >>> - void (*kunmap)(struct dma_buf *, unsigned long, void *); >>> + void *(*map_atomic)(struct dma_buf *, unsigned long); >>> + void (*unmap_atomic)(struct dma_buf *, unsigned long, void *); >>> + void *(*map)(struct dma_buf *, unsigned long); >>> + void (*unmap)(struct dma_buf *, unsigned long, void *); >>> >>> /** >>> * @mmap: > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > -- Thanks and regards, Sumit Semwal Linaro Mobile Group - Kernel Team Lead Linaro.org │ Open source software for ARM SoCs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

istency I've renamed all four of kmap* and kunmap* to be >> map* and unmap*. (Even though only kmap_atomic presently conflicts.) >> >> [1] https://www.spinics.net/lists/target-devel/msg15070.html >> >> Signed-off-by: Logan Gunthorpe >> Reviewed-by: Sinclair Y

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

Hi Daniel, On 11 April 2017 at 13:03, Sumit Semwal wrote: > On 11 April 2017 at 12:38, Daniel Stone wrote: >> Hi, >> >> On 11 April 2017 at 07:48, Daniel Vetter wrote: >>> Note: As Daniel Stone mentioned in the announcement fd.o admins >>> started chat

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

'll take a while to get there. For now this is good enough I >> think. > > All true. > > Reviewed-by: Daniel Stone > Thanks for this, Daniel! Reviewed-by: Sumit Semwal Best, Sumit. > Cheers, > Daniel ___ Intel-gfx mailing

Re: [Intel-gfx] [PATCH] dma/fence: Export enable-signaling tracepoint for emission by drivers

ng and would like to emit this tracepoint for completeness. >> >> Signed-off-by: Chris Wilson >> Cc: Sumit Semwal >> Cc: Daniel Vetter >> --- >> drivers/dma-buf/dma-fence.c | 1 + >> 1 file changed, 1 insertion(+)

Re: [Intel-gfx] [PATCH 3/3] dma-fence: Introduce drm_fence_set_error() helper

Hi Chris, On 4 January 2017 at 19:42, Chris Wilson wrote: > The dma_fence.error field (formerly known as dma_fence.status) is an > optional field that may be set by drivers before calling > dma_fence_signal(). The field can be used to indicate that the fence was > completed in err rather than wit

Re: [Intel-gfx] [PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()

pretty. On the series: > > Reviewed-by: Daniel Vetter > FWIW, please feel free, for this series, to apply my Reviewed-by: Sumit Semwal > I'll defer to Gustavo for another pass over it and merging it to drm-misc. > -Daniel > Best, Sumit. >> --- >> drivers/dma-bu

Re: [Intel-gfx] [PATCH 0/5] sphinxification for dma-buf docs

Thanks Jonathan! On 12 December 2016 at 01:14, Jonathan Corbet wrote: > On Sun, 11 Dec 2016 18:35:42 +0100 > Daniel Vetter wrote: > >> > Here's a thought, though: how about if we slip in a little version of >> > dma-buf.rst now with a "coming soon, don't miss it!!" message? Then the >> > rest o

Re: [Intel-gfx] [PATCH 0/5] sphinxification for dma-buf docs

plicit vs. explicit fencing >> and how it's all supposed to work. >> Thanks for the patch series; I had something in the works too, but you beat me to it! :) Looks good to me, so please feel free to add my Acked-by: Sumit Semwal to the series. >> But just cleanup in the dma

Re: [Intel-gfx] [PATCH 02/11] drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu before wait

Hi Lucas, On 23 September 2016 at 18:25, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:25AM +0100, Chris Wilson wrote: >> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a >> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not >> need to handle such c

Re: [Intel-gfx] [PATCH 05/11] drm/vmwgfx: Remove call to reservation_object_test_signaled_rcu before wait

Hi Thomas, Sinclair, On 23 September 2016 at 18:26, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:28AM +0100, Chris Wilson wrote: >> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a >> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not >> need to ha

Re: [Intel-gfx] [PATCH 04/11] drm/nouveau: Remove call to reservation_object_test_signaled_rcu before wait

Hi Ben, On 23 September 2016 at 18:25, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:27AM +0100, Chris Wilson wrote: >> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a >> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not >> need to handle such con

Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

Hi Alex, On 23 September 2016 at 18:24, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:24AM +0100, Chris Wilson wrote: >> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a >> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not >> need to handle such co

Re: [Intel-gfx] [PATCH] dma-buf: Release module reference on creation failure

Signed-off-by: Chris Wilson >> Reviewed-by: Joonas Lahtinen >> Cc: Joonas Lahtinen >> Cc: Sumit Semwal >> Cc: Daniel Vetter >> Cc: linux-me...@vger.kernel.org >> Cc: dri-de...@lists.freedesktop.org >> Cc: linaro-mm-...@lists.linaro.org >> --- >> drive

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

On 21 March 2016 at 13:00, Daniel Vetter wrote: > Just a bit of wording polish plus mentioning that it can fail and must > be restarted. > > Requested by Sumit. > > Cc: Chris Wilson > Cc: Tiago Vignatti > Cc: Stéphane Marchesin > Cc: David Herrmann > Cc: Sum

Re: [Intel-gfx] [PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()

851e >> Author: Daniel Vetter >> Date: Thu Feb 11 20:04:51 2016 -0200 >> >> dma-buf: Add ioctls to allow userspace to flush >> >> Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible >> Testcase: igt/prime_mmap_coherency/ioctl-errors >> S

Re: [Intel-gfx] [PATCH 2/4] dma-buf: Add ioctls to allow userspace to flush

(3 << 0) > +#define DMA_BUF_SYNC_START (0 << 2) > +#define DMA_BUF_SYNC_END (1 << 2) > +#define DMA_BUF_SYNC_VALID_FLAGS_MASK \ > + (DMA_BUF_SYNC_RW | DMA_BUF_SYNC_END) > + > +#define DMA_BUF_BASE 'b' > +#define DMA_BUF_IOCTL_SYNC _IOWR(DMA_BUF_BASE, 0, struct dma_buf_sync) > + > +#endif > -- > 2.1.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thanks and regards, Sumit Semwal. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dma-buf: add ref counting for module as exporter

On 7 May 2015 at 13:40, Greg KH wrote: > On Thu, May 07, 2015 at 01:00:52PM +0530, Sumit Semwal wrote: >> Add reference counting on a kernel module that exports dma-buf and >> implements its operations. This prevents the module from being unloaded >> while DMABUF file

[Intel-gfx] [PATCH] dma-buf: add ref counting for module as exporter

[tomasz: Original author] Signed-off-by: Tomasz Stanislawski Acked-by: Daniel Vetter [sumits: updated & rebased as per review comments] Signed-off-by: Sumit Semwal [1]: https://lkml.org/lkml/2012/8/8/163 --- drivers/dma-buf/dma-buf.c | 9 - drivers/

Re: [Intel-gfx] [PATCH v3] dma-buf: cleanup dma_buf_export() to make it easily extensible

Hi Mauro, On 28 January 2015 at 18:53, Mauro Carvalho Chehab wrote: > Em Wed, 28 Jan 2015 18:24:03 +0530 > Sumit Semwal escreveu: > >> +/** >> + * helper macro for exporters; zeros and fills in most common values >> + */ >> +#define DEFINE_DMA_BUF_EXPORT

[Intel-gfx] [PATCH v3] dma-buf: cleanup dma_buf_export() to make it easily extensible

() with dma_buf_export(), and change all callers accordingly. Signed-off-by: Sumit Semwal --- v3: Daniel Thompson caught the C99 warning issue w/ using {0}; using {.exp_name = xxx} instead. v2: add macro to zero out local struct, and fill KBUILD_MODNAME by default drivers/dma-buf/dma-buf.c

Re: [Intel-gfx] [PATCH v2] dma-buf: cleanup dma_buf_export() to make it easily extensible

On 28 January 2015 at 16:50, Daniel Thompson wrote: > On 28/01/15 06:00, Sumit Semwal wrote: >> +/** >> + * helper macro for exporters; zeros and fills in most common values >> + */ >> +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\ >> +

[Intel-gfx] [PATCH v2] dma-buf: cleanup dma_buf_export() to make it easily extensible

() with dma_buf_export(), and change all callers accordingly. Signed-off-by: Sumit Semwal --- v2: add macro to zero out local struct, and fill KBUILD_MODNAME by default drivers/dma-buf/dma-buf.c | 47 +- drivers/gpu/drm/armada/armada_gem.c

[Intel-gfx] [RFC] dma-buf: cleanup dma_buf_export() to make it easily extensible

() with dma_buf_export(), and change all callers accordingly. Signed-off-by: Sumit Semwal --- drivers/dma-buf/dma-buf.c | 47 +- drivers/gpu/drm/armada/armada_gem.c| 12 +-- drivers/gpu/drm/drm_prime.c| 14

Re: [Intel-gfx] linux-next: manual merge of the dma-buf tree with the drm-intel tree

On 20 May 2014 12:25, Stephen Rothwell wrote: > Hi Sumit, > > Today's linux-next merge of the dma-buf tree got a conflict in > drivers/gpu/drm/i915/i915_gem_dmabuf.c between commit 5cc9ed4b9a7a > ("drm/i915: Introduce mapping of user pages into video memory (userptr) > ioctl") from the drm-intel t