Re: [PATCH] dma-buf: Fix ifnullfree.cocci warnings

[Sumit Semwal]

Hello Vasyl,

On 22 November 2017 at 20:52, Vasyl Gomonovych <gomonov...@gmail.com> wrote:
> NULL check before some freeing functions is not needed.
> drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing 
> debugfs_remove_recursive
> Generated by: scripts/coccinelle/free/ifnullfree.cocci

Thank you for your patch; applied to drm-misc-next.
>
> Signed-off-by: Vasyl Gomonovych <gomonov...@gmail.com>
> ---
>  drivers/dma-buf/dma-buf.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 4a038dcf5361..048827b06c03 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1179,8 +1179,7 @@ static int dma_buf_init_debugfs(void)
>
>  static void dma_buf_uninit_debugfs(void)
>  {
> -   if (dma_buf_debugfs_dir)
> -   debugfs_remove_recursive(dma_buf_debugfs_dir);
> +   debugfs_remove_recursive(dma_buf_debugfs_dir);
>  }
>  #else
>  static inline int dma_buf_init_debugfs(void)
> --
> 1.9.1
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs

Re: [PATCH 0/4] dma-buf: Silence dma_fence __rcu sparse warnings

[Sumit Semwal]

Hi Ville,

On 3 November 2017 at 13:18, Christian König <christian.koe...@amd.com> wrote:
> Patch #4 is Reviewed-by: Christian König <christian.koe...@amd.com>.
>
> The rest is Acked-by: Christian König <christian.koe...@amd.com>.
>
> Regards,
> Christian.
>
>
> Am 02.11.2017 um 21:03 schrieb Ville Syrjala:
>>
>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>
>> When building drm+i915 I get around 150 lines of sparse noise from
>> dma_fence __rcu warnings. This series eliminates all of that.
>>
>> The first two patches were already posted by Chris, but there wasn't
>> any real reaction, so I figured I'd repost with a wider Cc list.
>>
>> As for the other two patches, I'm no expert on dma_fence and I didn't
>> spend a lot of time looking at it so I can't be sure I annotated all
>> the accesses correctly. But I figured someone will scream at me if
>> I got it wrong ;)
>>
>> Cc: Dave Airlie <airl...@redhat.com>
>> Cc: Jason Ekstrand <ja...@jlekstrand.net>
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc: linux-media@vger.kernel.org
>> Cc: Alex Deucher <alexander.deuc...@amd.com>
>> Cc: Christian König <christian.koe...@amd.com>
>> Cc: Sumit Semwal <sumit.sem...@linaro.org>
>> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
>>
>> Chris Wilson (2):
>>drm/syncobj: Mark up the fence as an RCU protected pointer
>>dma-buf/fence: Sparse wants __rcu on the object itself
>>
>> Ville Syrjälä (2):
>>drm/syncobj: Use proper methods for accessing rcu protected pointers
>>dma-buf: Use rcu_assign_pointer() to set rcu protected pointers

For patches 2 (with Daniel's minor comment) and 4, please feel free to add my
Acked-by: Sumit Semwal <sumit.sem...@linaro.org.

>>
>>   drivers/dma-buf/reservation.c |  2 +-
>>   drivers/gpu/drm/drm_syncobj.c | 11 +++
>>   include/drm/drm_syncobj.h |  2 +-
>>   include/linux/dma-fence.h |  2 +-
>>   4 files changed, 10 insertions(+), 7 deletions(-)
>>
>

Best,
Sumit.

Re: [PATCH 0/4] DMA-buf: Fine-tuning for four function implementations

[Sumit Semwal]

Hello Markus,

On 8 May 2017 at 14:40, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Mon, 8 May 2017 11:05:05 +0200
>
> A few update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (4):
>   Combine two function calls into one in dma_buf_debug_show()
>   Improve a size determination in dma_buf_attach()
>   Adjust a null pointer check in dma_buf_attach()
>   Use seq_putc() in two functions

All queued up in drm-misc-next now. Thanks!
>
>  drivers/dma-buf/dma-buf.c| 8 +++-
>  drivers/dma-buf/sync_debug.c | 6 +++---
>  2 files changed, 6 insertions(+), 8 deletions(-)
>
> --
> 2.12.2
>

Best regards,
Sumit.

Re: [PATCHv4 00/12] Ion cleanup in preparation for moving out of staging

[Sumit Semwal]

Hi Laura,

Thanks much for this series!

On 18 April 2017 at 23:57, Laura Abbott <labb...@redhat.com> wrote:
> Hi,
>
> This is v4 of the series to cleanup to Ion. Greg took some of the patches
> that weren't CMA related already. There was a minor bisectability problem
> with the CMA APIs so this is a new version to address that. I also
> addressed some minor comments on the patch to collapse header files.

For the series, please feel free to apply my
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>

>
> Thanks,
> Laura
>
> Laura Abbott (12):
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Stop butchering the DMA address
>   staging: android: ion: Break the ABI in the name of forward progress
>   staging: android: ion: Get rid of ion_phys_addr_t
>   staging: android: ion: Collapse internal header files
>   staging: android: ion: Rework heap registration/enumeration
>   staging: android: ion: Drop ion_map_kernel interface
>   staging: android: ion: Remove ion_handle and ion_client
>   staging: android: ion: Set query return value
>   staging/android: Update Ion TODO list
>
>  arch/powerpc/kvm/book3s_hv_builtin.c|   3 +-
>  drivers/base/dma-contiguous.c   |   5 +-
>  drivers/staging/android/TODO|  21 +-
>  drivers/staging/android/ion/Kconfig |  32 +
>  drivers/staging/android/ion/Makefile|  11 +-
>  drivers/staging/android/ion/compat_ion.c| 152 -
>  drivers/staging/android/ion/compat_ion.h|  29 -
>  drivers/staging/android/ion/ion-ioctl.c |  55 +-
>  drivers/staging/android/ion/ion.c   | 812 
> ++--
>  drivers/staging/android/ion/ion.h   | 386 ---
>  drivers/staging/android/ion/ion_carveout_heap.c |  21 +-
>  drivers/staging/android/ion/ion_chunk_heap.c|  16 +-
>  drivers/staging/android/ion/ion_cma_heap.c  | 120 ++--
>  drivers/staging/android/ion/ion_heap.c  |  68 --
>  drivers/staging/android/ion/ion_page_pool.c |   3 +-
>  drivers/staging/android/ion/ion_priv.h  | 453 -
>  drivers/staging/android/ion/ion_system_heap.c   |  39 +-
>  drivers/staging/android/uapi/ion.h  |  36 +-
>  include/linux/cma.h |   6 +-
>  mm/cma.c|  31 +-
>  mm/cma.h|   1 +
>  mm/cma_debug.c  |   2 +-
>  22 files changed, 524 insertions(+), 1778 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/compat_ion.c
>  delete mode 100644 drivers/staging/android/ion/compat_ion.h
>  delete mode 100644 drivers/staging/android/ion/ion_priv.h
>
> --
> 2.7.4
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs

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

[Sumit Semwal]

= vmw_prime_dmabuf_kmap_atomic,
>>> +   .unmap = vmw_prime_dmabuf_kunmap,
>>> +   .unmap_atomic = vmw_prime_dmabuf_kunmap_atomic,
>>> .mmap = vmw_prime_dmabuf_mmap,
>>> .vmap = vmw_prime_dmabuf_vmap,
>>> .vunmap = vmw_prime_dmabuf_vunmap,
>>> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
>>> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
>>> index fb6a177..2db0413 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
>>> @@ -356,8 +356,8 @@ static struct dma_buf_ops vb2_dc_dmabuf_ops = {
>>> .detach = vb2_dc_dmabuf_ops_detach,
>>> .map_dma_buf = vb2_dc_dmabuf_ops_map,
>>> .unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
>>> -   .kmap = vb2_dc_dmabuf_ops_kmap,
>>> -   .kmap_atomic = vb2_dc_dmabuf_ops_kmap,
>>> +   .map = vb2_dc_dmabuf_ops_kmap,
>>> +   .map_atomic = vb2_dc_dmabuf_ops_kmap,
>>> .vmap = vb2_dc_dmabuf_ops_vmap,
>>> .mmap = vb2_dc_dmabuf_ops_mmap,
>>> .release = vb2_dc_dmabuf_ops_release,
>>> diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
>>> b/drivers/media/v4l2-core/videobuf2-dma-sg.c
>>> index ecff8f4..6fd1343 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
>>> @@ -504,8 +504,8 @@ static struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>>> .detach = vb2_dma_sg_dmabuf_ops_detach,
>>> .map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>>> .unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
>>> -   .kmap = vb2_dma_sg_dmabuf_ops_kmap,
>>> -   .kmap_atomic = vb2_dma_sg_dmabuf_ops_kmap,
>>> +   .map = vb2_dma_sg_dmabuf_ops_kmap,
>>> +   .map_atomic = vb2_dma_sg_dmabuf_ops_kmap,
>>> .vmap = vb2_dma_sg_dmabuf_ops_vmap,
>>> .mmap = vb2_dma_sg_dmabuf_ops_mmap,
>>> .release = vb2_dma_sg_dmabuf_ops_release,
>>> diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
>>> b/drivers/media/v4l2-core/videobuf2-vmalloc.c
>>> index 3f77814..27d1db3 100644
>>> --- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
>>> +++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
>>> @@ -342,8 +342,8 @@ static struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>>> .detach = vb2_vmalloc_dmabuf_ops_detach,
>>> .map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>>> .unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
>>> -   .kmap = vb2_vmalloc_dmabuf_ops_kmap,
>>> -   .kmap_atomic = vb2_vmalloc_dmabuf_ops_kmap,
>>> +   .map = vb2_vmalloc_dmabuf_ops_kmap,
>>> +   .map_atomic = vb2_vmalloc_dmabuf_ops_kmap,
>>> .vmap = vb2_vmalloc_dmabuf_ops_vmap,
>>> .mmap = vb2_vmalloc_dmabuf_ops_mmap,
>>> .release = vb2_vmalloc_dmabuf_ops_release,
>>> diff --git a/drivers/staging/android/ion/ion.c
>>> b/drivers/staging/android/ion/ion.c
>>> index f45115f..95a7f16 100644
>>> --- 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 Institute Poland
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs

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

[Sumit Semwal]

Hi Logan,

Thanks for the patch.

On 20 April 2017 at 13:21, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
>> in highmem.h, the former can be aliased if any dma-buf user includes
>> that header.
>>
>> I'm personally trying to include highmem.h inside scatterlist.h and this
>> breaks the dma-buf code proper.
>>
>> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
>>
>> To maintain consistency 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 <log...@deltatee.com>
>> Reviewed-by: Sinclair Yeh <s...@vmware.com>
>
> Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>
>
> Probably simplest if we pull this in through the drm-misc tree for 4.12.
> Can we have an ack for the v4l side for that pls?
>
> Thanks, Daniel
>
>> ---
>>
>> Changes since v1:
>>
>> - Added the missing tegra driver (noticed by kbuild robot)
>> - Rebased off of drm-intel-next to get the i915 selftest that is new
>> - Fixed nits Sinclair pointed out.
>>
>>  drivers/dma-buf/dma-buf.c  | 16 
>>  drivers/gpu/drm/armada/armada_gem.c|  8 
>>  drivers/gpu/drm/drm_prime.c|  8 
>>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>>  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
>>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>>  drivers/gpu/drm/tegra/gem.c|  8 
>>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>>  drivers/staging/android/ion/ion.c  |  8 
>>  include/linux/dma-buf.h| 22 +++---
>>  14 files changed, 61 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index f72aaac..512bdbc 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>> || !exp_info->ops->map_dma_buf
>> || !exp_info->ops->unmap_dma_buf
>> || !exp_info->ops->release
>> -   || !exp_info->ops->kmap_atomic
>> -   || !exp_info->ops->kmap
>> +   || !exp_info->ops->map_atomic
>> +   || !exp_info->ops->map
>> || !exp_info->ops->mmap)) {
>>   return ERR_PTR(-EINVAL);
>>   }
>> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
>> unsigned long page_num)
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
>> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>>
>> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
>> unsigned long page_num,
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - if (dmabuf->ops->kunmap_atomic)
>> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
>> + if (dmabuf->ops->unmap_atomic)
>> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>>
>> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
>> page_num)
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - return dmabuf->ops->kmap(dmabuf, page_num);
>> + return dmabuf->ops->map(dmabuf, page_num);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
>>
>> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned 
>> long page_num,
>>  {
>>   WARN_ON(!dmabuf);
>>
>> - if (dmabuf->ops->kunmap)
>> - dmabuf->ops

Re: [PATCH] dma-buf: align debugfs output

[Sumit Semwal]

Hi Russell,


On 31 March 2017 at 15:33, Russell King  wrote:
> Align the heading with the values output from debugfs.
>
> Signed-off-by: Russell King 

Thanks for your patch; applied to drm-misc-next.

> ---
>  drivers/dma-buf/dma-buf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index ebaf1923ad6b..f72aaacbe023 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1072,7 +1072,8 @@ static int dma_buf_debug_show(struct seq_file *s, void 
> *unused)
> return ret;
>
> seq_puts(s, "\nDma-buf Objects:\n");
> -   seq_puts(s, "size\tflags\tmode\tcount\texp_name\n");
> +   seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\n",
> +  "size", "flags", "mode", "count");
>
> list_for_each_entry(buf_obj, _list.head, list_node) {
> ret = mutex_lock_interruptible(_obj->lock);
> --
> 2.7.4
>

Best,
Sumit.

Re: [RFC PATCH 08/12] cma: Store a name in the cma structure

[Sumit Semwal]

Hi Laura,

Thanks for the patch.

On 3 March 2017 at 03:14, Laura Abbott  wrote:
>
> Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
> useful to have an explicit name attached to each region. Store the name
> in each CMA structure.
>
> Signed-off-by: Laura Abbott 
> ---
>  drivers/base/dma-contiguous.c |  5 +++--
>  include/linux/cma.h   |  4 +++-
>  mm/cma.c  | 11 +--
>  mm/cma.h  |  1 +
>  mm/cma_debug.c|  2 +-
>  5 files changed, 17 insertions(+), 6 deletions(-)
>

> +const char *cma_get_name(const struct cma *cma)
> +{
> +   return cma->name ? cma->name : "(undefined)";
> +}
> +
Would it make sense to perhaps have the idx stored as the name,
instead of 'undefined'? That would make sure that the various cma
names are still unique.

>  static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>  int align_order)
>  {
> @@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
>   */
>  int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
>  unsigned int order_per_bit,
> +const char *name,
>  struct cma **res_cma)
>  {

Best regards,
Sumit.

Re: [PATCH] dma-buf: add support for compat ioctl

[Sumit Semwal]

Hi Marek,

On 23 February 2017 at 00:37, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Tue, Feb 21, 2017 at 4:08 PM, Christian König
> <deathsim...@vodafone.de> wrote:
>> Am 21.02.2017 um 15:55 schrieb Marek Szyprowski:
>>>
>>> Dear All,
>>>
>>> On 2017-02-21 15:37, Marek Szyprowski wrote:
>>>>
>>>> Hi Christian,
>>>>
>>>> On 2017-02-21 14:59, Christian König wrote:
>>>>>
>>>>> Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
>>>>>>
>>>>>> Add compat ioctl support to dma-buf. This lets one to use
>>>>>> DMA_BUF_IOCTL_SYNC
>>>>>> ioctl from 32bit application on 64bit kernel. Data structures for both
>>>>>> 32
>>>>>> and 64bit modes are same, so there is no need for additional
>>>>>> translation
>>>>>> layer.
>>>>>
>>>>>
>>>>> Well I might be wrong, but IIRC compat_ioctl was just optional and if
>>>>> not specified unlocked_ioctl was called instead.
>>>>>
>>>>> If that is true your patch wouldn't have any effect at all.
>>>>
>>>>
>>>> Well, then why I got -ENOTTY in the 32bit test app for this ioctl on
>>>> 64bit ARM64 kernel without this patch?
>>>>
>>>
>>> I've checked in fs/compat_ioctl.c, I see no fallback in
>>> COMPAT_SYSCALL_DEFINE3,
>>> so one has to provide compat_ioctl callback to have ioctl working with
>>> 32bit
>>> apps.
>>
>>
>> Then my memory cheated on me.
>>
>> In this case the patch is Reviewed-by: Christian König
>> <christian.koe...@amd.com>.
>

Thanks much for spotting this!

> Since you have commit rights for drm-misc, care to push this to
> drm-misc-next-fixes pls? Also I think this warrants a cc: stable,
> clearly an obvious screw-up in creating this api on our side :( So
> feel free to smash my ack on the patch.
>
Daniel, Christian,

I saw this just now, so if Christian hasn't already pulled it into
drm-misc-next-fixes, I'll give it a stab.

> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Best,
Sumit.

-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs

Re: [PATCH] dma-buf/sw_sync: mark sync_timeline_create() static

[Sumit Semwal]

Hi Baoyou,

On 20 September 2016 at 16:43, Gustavo Padovan <gust...@padovan.org> wrote:
> 2016-09-18 Baoyou Xie <baoyou@linaro.org>:
>
>> We get 1 warning when building kernel with W=1:
>> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for 
>> 'sync_timeline_create' [-Wmissing-prototypes]
>>
>> In fact, this function is only used in the file in which it is
>> declared and don't need a declaration, but can be made static.
>> So this patch marks it 'static'.
>>
>> Signed-off-by: Baoyou Xie <baoyou@linaro.org>
>> ---
>>  drivers/dma-buf/sw_sync.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Thanks for finding this.

Thanks for the patch; this doesn't apply to mainline yet, since the
de-staging of sw_sync code is queued for 4.9 via Greg-KH's tree.
CC'ing him.

Greg, would it be possible to please take this via your tree?
>
> Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>

> Gustavo
>

Best regards,
Sumi
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf/sync-file: Avoid enable fence signaling if poll(.timeout=0)

[Sumit Semwal]

Hi Chris,

On 29 August 2016 at 23:56, Gustavo Padovan <gust...@padovan.org> wrote:
> Hi Chris,
>
> 2016-08-29 Chris Wilson <ch...@chris-wilson.co.uk>:
>
>> If we being polled with a timeout of zero, a nonblocking busy query,
>> we don't need to install any fence callbacks as we will not be waiting.
>> As we only install the callback once, the overhead comes from the atomic
>> bit test that also causes serialisation between threads.
>>
>> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
>> Cc: Sumit Semwal <sumit.sem...@linaro.org>
>> Cc: Gustavo Padovan <gust...@padovan.org>
>> Cc: linux-media@vger.kernel.org
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linaro-mm-...@lists.linaro.org
>> ---
>>  drivers/dma-buf/sync_file.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> Indeed, we can shortcut this.
>
> Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>
> Gustavo

Thanks; pushed to drm-misc.

Best,
Sumit.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Sumit Semwal]

Hi Jon,

On 23 August 2016 at 18:38, Jonathan Corbet  wrote:
> On Tue, 23 Aug 2016 08:01:35 +0200
> Daniel Vetter  wrote:
>
>> I'm also not too sure about whether dma-buf really should be it's own
>> subdirectory. It's plucked from the device-drivers.tmpl, I think an
>> overall device-drivers/ for all the misc subsystems and support code would
>> be better. Then one toc there, which fans out to either kernel-doc and
>> overview docs.
>
> I'm quite convinced it shouldn't be.
>
> If you get a chance, could you have a look at the "RFC: The beginning of
> a proper driver-api book" series I posted yesterday (yes, I should have
> copied more of you, sorry)?  It shows the direction I would like to go
> with driver API documentation, and, assuming we go that way, I'd like the
> dma-buf documentation to fit into that.
>

Thanks for your comments, and direction. I'll rework the patches on
top of yours then.
I'll have a look at your patches to think about how do we handle API
guides / detailed documentation as well.

> Thanks,
>
> jon

Best,
Sumit.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] Documentation: move dma-buf documentation to rst

[Sumit Semwal]

Branch out dma-buf related documentation into its own rst file to allow
adding it to the sphinx documentation generated.

While at it, move dma-buf-sharing.txt into rst as the dma-buf guide too;
adjust MAINTAINERS accordingly.

v2:
- Removed authorship as suggested by Jani,
- Address review comments from Jonathan Corbet and Markus Heiser.

Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
---
 Documentation/DocBook/device-drivers.tmpl |  41 ---
 Documentation/dma-buf-sharing.txt | 482 
 Documentation/dma-buf/guide.rst   | 507 ++
 Documentation/dma-buf/intro.rst   |  82 +
 MAINTAINERS   |   2 +-
 5 files changed, 590 insertions(+), 524 deletions(-)
 delete mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 Documentation/dma-buf/guide.rst
 create mode 100644 Documentation/dma-buf/intro.rst

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index 9c10030eb2be..a93fbffa9742 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,47 +128,6 @@ X!Edrivers/base/interface.c
 !Edrivers/base/platform.c
 !Edrivers/base/bus.c
  
- 
-   Buffer Sharing and Synchronization
-   
- The dma-buf subsystem provides the framework for sharing buffers
- for hardware (DMA) access across multiple device drivers and
- subsystems, and for synchronizing asynchronous hardware access.
-   
-   
- This is used, for example, by drm "prime" multi-GPU support, but
- is of course not limited to GPU use cases.
-   
-   
- The three main components of this are: (1) dma-buf, representing
- a sg_table and exposed to userspace as a file descriptor to allow
- passing between devices, (2) fence, which provides a mechanism
- to signal when one device as finished access, and (3) reservation,
- which manages the shared or exclusive fence(s) associated with
- the buffer.
-   
-   dma-buf
-!Edrivers/dma-buf/dma-buf.c
-!Iinclude/linux/dma-buf.h
-   
-   reservation
-!Pdrivers/dma-buf/reservation.c Reservation Object Overview
-!Edrivers/dma-buf/reservation.c
-!Iinclude/linux/reservation.h
-   
-   fence
-!Edrivers/dma-buf/fence.c
-!Iinclude/linux/fence.h
-!Edrivers/dma-buf/seqno-fence.c
-!Iinclude/linux/seqno-fence.h
-!Edrivers/dma-buf/fence-array.c
-!Iinclude/linux/fence-array.h
-!Edrivers/dma-buf/reservation.c
-!Iinclude/linux/reservation.h
-!Edrivers/dma-buf/sync_file.c
-!Iinclude/linux/sync_file.h
-   
- 
  Device Drivers DMA Management
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
deleted file mode 100644
index ca44c5820585..
--- a/Documentation/dma-buf-sharing.txt
+++ /dev/null
@@ -1,482 +0,0 @@
-DMA Buffer Sharing API Guide
-
-
-    Sumit Semwal
-
- 
-
-This document serves as a guide to device-driver writers on what is the dma-buf
-buffer sharing API, how to use it for exporting and using shared buffers.
-
-Any device driver which wishes to be a part of DMA buffer sharing, can do so as
-either the 'exporter' of buffers, or the 'user' of buffers.
-
-Say a driver A wants to use buffers created by driver B, then we call B as the
-exporter, and A as buffer-user.
-
-The exporter
-- implements and manages operations[1] for the buffer
-- allows other users to share the buffer by using dma_buf sharing APIs,
-- manages the details of buffer allocation,
-- decides about the actual backing storage where this allocation happens,
-- takes care of any migration of scatterlist - for all (shared) users of this
-   buffer,
-
-The buffer-user
-- is one of (many) sharing users of the buffer.
-- doesn't need to worry about how the buffer is allocated, or where.
-- needs a mechanism to get access to the scatterlist that makes up this buffer
-   in memory, mapped into its own address space, so it can access the same area
-   of memory.
-
-dma-buf operations for device dma only
---
-
-The dma_buf buffer sharing API usage contains the following steps:
-
-1. Exporter announces that it wishes to export a buffer
-2. Userspace gets the file descriptor associated with the exported buffer, and
-   passes it around to potential buffer-users based on use case
-3. Each buffer-user 'connects' itself to the buffer
-4. When needed, buffer-user requests access to the buffer from exporter
-5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
-6. when buffer-user is done using this buffer completely, it 'disconnects'
-   itself from the buffer.
-
-
-1. Exporter's announcement of buffer export

[PATCH v2 0/2] doc: dma-buf: sphinx conversion

[Sumit Semwal]

Convert dma-buf documentation over to sphinx.

While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.

There is no content change yet; only format conversion and creation of
some hyperlinks.

v2: Address review comments from Jonathan Corbet and Markus Heiser.

Sumit Semwal (2):
  Documentation: move dma-buf documentation to rst
  Documentation/sphinx: link dma-buf rsts

 Documentation/DocBook/device-drivers.tmpl |  41 ---
 Documentation/dma-buf-sharing.txt | 482 
 Documentation/dma-buf/guide.rst   | 507 ++
 Documentation/dma-buf/intro.rst   |  82 +
 Documentation/index.rst   |   2 +
 MAINTAINERS   |   2 +-
 6 files changed, 592 insertions(+), 524 deletions(-)
 delete mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 Documentation/dma-buf/guide.rst
 create mode 100644 Documentation/dma-buf/intro.rst

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Sumit Semwal]

Include dma-buf sphinx documentation into top level index.

Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
---
 Documentation/index.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index e0fc72963e87..8d05070122c2 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -14,6 +14,8 @@ Contents:
:maxdepth: 2
 
kernel-documentation
+   dma-buf/intro
+   dma-buf/guide
media/media_uapi
media/media_kapi
media/dvb-drivers/index
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf: fix kernel-doc warning and typos

[Sumit Semwal]

Hi Randy,

On 17 August 2016 at 05:01, Randy Dunlap <rdun...@infradead.org> wrote:
> From: Randy Dunlap <rdun...@infradead.org>
>
> Fix dma-buf kernel-doc warning and 2 minor typos in
> fence_array_create().
>
Thanks for your patch, I will queue it up!
> Fixes this warning:
> ..//drivers/dma-buf/fence-array.c:124: warning: No description found for 
> parameter 'signal_on_any'
>
> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> Cc: Sumit Semwal <sumit.sem...@linaro.org>
> Cc: linux-media@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
>  drivers/dma-buf/fence-array.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- lnx-48-rc2.orig/drivers/dma-buf/fence-array.c
> +++ lnx-48-rc2/drivers/dma-buf/fence-array.c
> @@ -106,14 +106,14 @@ const struct fence_ops fence_array_ops =
>   * @fences:[in]array containing the fences
>   * @context:   [in]fence context to use
>   * @seqno: [in]sequence number to use
> - * @signal_on_any  [in]signal on any fence in the array
> + * @signal_on_any: [in]signal on any fence in the array
>   *
>   * Allocate a fence_array object and initialize the base fence with 
> fence_init().
>   * In case of error it returns NULL.
>   *
> - * The caller should allocte the fences array with num_fences size
> + * The caller should allocate the fences array with num_fences size
>   * and fill it with the fences it wants to add to the object. Ownership of 
> this
> - * array is take and fence_put() is used on each fence on release.
> + * array is taken and fence_put() is used on each fence on release.
>   *
>   * If @signal_on_any is true the fence array signals if any fence in the 
> array
>   * signals, otherwise it signals when all fences in the array signal.

Best,
Sumit.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

[Sumit Semwal]

Hi Jon!

On 11 August 2016 at 20:06, Jonathan Corbet <cor...@lwn.net> wrote:
> On Thu, 11 Aug 2016 16:17:56 +0530
> Sumit Semwal <sumit.sem...@linaro.org> wrote:
>
>> Convert dma-buf documentation over to sphinx; also cleanup to
>> address sphinx warnings.
>>
>> While at that, convert dma-buf-sharing.txt as well, and make it the
>> dma-buf API guide.
>
> Thanks for working to improve the documentation!  I do have a few overall
> comments...
>
Thank you for your review, and comments; my responses are inline.

>  - The two comment fixes are a separate thing that should go straight to
>the dma-buf maintainer, who is ...  ... evidently somebody
>familiar to you :)  I assume you'll merge those two directly?
>
Yes, of course :) - I will merge them directly, and will remove them
from v2 of this series.

>  - It looks like you create a new RST document but leave the old one in
>place.  Having two copies of the document around can only lead to
>confusion, so I think the old one should go.
>
Agreed on this as well; will correct it.

>  - I really wonder if we want to start carving pieces out of
>device-drivers.tmpl in this way.  I guess I would rather see the
>conversion of that book and the better integration of the other docs
>*into* it.  One of the goals of this whole thing is to unify our
>documentation, not to reinforce the silos.
>
I should've mentioned it in the cover letter - my intention of taking
the dma-buf pieces out was to focus on these first while moving to
sphinx.

My proposal would be, if all the device driver section owners could
take the relevant pieces, convert them to sphinx (ironing out warnings
etc in the process), then we can again 'bind' them together into the
device drivers book in rst format.
This breaks the documentation conversion task into manageable pieces
that can be handled independently, and gives everyone flexibility to
work on their schedules.

This should also help in a good technical re-look at the content by
subsystem developers, and make any documentation updates as required.
The beauty of sphinx should allow us this, I think? Just my 2 cents.

> Does that make sense?
>
I do hope that my proposal above finds some merit with everyone.

> Thanks,
>
> jon

BR,
Sumit.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/4] Documentation: move dma-buf documentation to rst

[Sumit Semwal]

Hi Markus,

On 11 August 2016 at 17:28, Markus Heiser <markus.hei...@darmarit.de> wrote:
> Hi Sumit,
>
> I haven't compiled your patch yet, just my 2cent about the
> reStructuredText (reST) ASCII markup ...
>
Thanks very much for your detailed review comments - highly appreciated!

> Here are some handy links about reST and the Sphinx markup constructs,
> we have not yet added to the documentation (sorry):
>
> * reST primer:http://www.sphinx-doc.org/en/stable/rest.html
> * reST quickref:  http://docutils.sourceforge.net/docs/user/rst/quickref.html
> * Sphinx markup constructs: 
> http://www.sphinx-doc.org/en/stable/markup/index.html
> * Sphinx domains: http://www.sphinx-doc.org/en/stable/domains.html
> * Sphinx cross references:  
> http://www.sphinx-doc.org/en/stable/markup/inline.html#cross-referencing-arbitrary-locations
>
> Am 11.08.2016 um 12:47 schrieb Sumit Semwal <sumit.sem...@linaro.org>:
>
>> Branch out dma-buf related documentation into its own rst file to allow
>> adding it to the sphinx documentation generated.
>>
>> While at it, move dma-buf-sharing.txt into rst as the dma-buf guide too.
>>
>> Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
> ...
>> +dma-buf operations for device dma only
>> +==
>> +
>> +The dma_buf buffer sharing API usage contains the following steps:
>> +
>> +1. Exporter announces that it wishes to export a buffer
>> +2. Userspace gets the file descriptor associated with the exported buffer, 
>> and
>> +   passes it around to potential buffer-users based on use case
>> +3. Each buffer-user 'connects' itself to the buffer
>> +4. When needed, buffer-user requests access to the buffer from exporter
>> +5. When finished with its use, the buffer-user notifies end-of-DMA to 
>> exporter
>> +6. when buffer-user is done using this buffer completely, it 'disconnects'
>> +   itself from the buffer.
>> +
>> +
>> +1. Exporter's announcement of buffer export
>> +---
>
> I can't recommend numbering the (sub-) sections explicit, even if you here
> wanted to numerate the steps. Most often section numbers are controlled by
> the subordinate toctree directive and this might not fit to the step
> numbers.
>
> * 
> http://www.sphinx-doc.org/en/stable/markup/toctree.html?highlight=toc#the-toc-tree
>
>> +
>> +   The buffer exporter announces its wish to export a buffer. In this, it
>> +   connects its own private buffer data, provides implementation for 
>> operations
>> +   that can be performed on the exported :c:type:`dma_buf`, and flags for 
>> the file
>> +   associated with this buffer. All these fields are filled in struct
>> +   :c:type:`dma_buf_export_info`, defined via the 
>> DEFINE_DMA_BUF_EXPORT_INFO macro.
>> +
>
> In restructuredText whitespace are markups.
>
> Do not indent if you don't want to create a (indented) block. I recommend to 
> drop
> the two spaces in front of the paragraphs.
>
> IMHO you have to decide if you like to use sectioning (drop the to spaces)
> or stay with the two spaces and use an enumeration list. If you wan't to stay
> with the enumeration write:
>
> |1. Exporter's announcement of buffer export
> |
> |   The buffer exporter announces its wish to export a buffer. In this, it
> |   connects its own private buffer ..
> |   ...
>
>
Understood; will correct.

>> +   Interface:
>> +  :c:type:`DEFINE_DMA_BUF_EXPORT_INFO(exp_info) 
>> `
>
> If haven't tested your patch, but I guess this will result in a Warning.
>
> the markup ":c:type" is a reference to a typedef description
>
> * http://www.sphinx-doc.org/en/stable/domains.html#role-c:type
>
> If the description is given, you can use the short form
>
> :c:type:`DEFINE_DMA_BUF_EXPORT_INFO`
>
> but I think, this is a function, not a typedef.
>
I did test it before sending out the RFC, and didn't get any warnings.
This, btw, is a macro, so I guess that's why no warning.

While on this topic, in my experimentation, if I just use the short
form, the resultant text doesn't include the "(exp_info)" part as
shown above.

>> +
>> +  :c:func:`struct dma_buf *dma_buf_export(struct dma_buf_export_info 
>> *exp_info)`
>
> short form to refer
>
>  :c:func:`dma_buf_export()`
>
When I last tried the short form, it only gave me a link to the full
definition, and I wanted to have the arguments also shown here, so
that the explanation below was easier. Though I think I tried without
the (), so will try again and let you know.

>> +
>> +   If this succeed

Re: [RFC 3/4] Documentation: move dma-buf documentation to rst

[Sumit Semwal]

Hello Jani,

On 11 August 2016 at 17:17, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Thu, 11 Aug 2016, Sumit Semwal <sumit.sem...@linaro.org> wrote:
>> diff --git a/Documentation/dma-buf/guide.rst 
>> b/Documentation/dma-buf/guide.rst
>> new file mode 100644
>> index ..fd3534fdccb3
>> --- /dev/null
>> +++ b/Documentation/dma-buf/guide.rst
>> @@ -0,0 +1,503 @@
>> +
>> +.. _dma-buf-guide:
>> +
>> +====
>> +DMA Buffer Sharing API Guide
>> +
>> +
>> +Sumit Semwal - sumit.sem...@linaro.org, sum...@kernel.org
>
> Please use the format
>
> :author: Sumit Semwal <sumit.sem...@linaro.org>
>
Thanks very much for reviewing!
> ---
>
> While on this subject, please excuse me for hijacking the thread a bit.
>
> Personally, I believe it would be better to leave out authorship notes
> from documentation and source files in collaborative projects. Of
> course, it is only fair that people who deserve credit get the
> credit. Listing the authors in the file is often the natural thing to
> do, and superficially seems fair.
>
> However, when do you add more names to the list? When has someone
> contributed enough to warrant that? Is it fair that the original authors
> keep getting the credit for the contributions of others? After a while,
> perhaps there is next to nothing left of the original contributions, but
> the bar is really high for removing anyone from the authors. Listing the
> authors gives the impression this is *their* file, while everyone should
> feel welcome to contribute, and everyone who contributes should feel
> ownership.
>
> IMHO we would be better off using just the git history for the credits.
>
:) - I totally agree with your stand; this patch was an (almost)
direct conversion from the earlier format, hence this patch.

But yes, I will remove it in the next iteration.
>
> BR,
> Jani.
>
>
BR,
Sumit.

> PS. I am no saint here, I've got a couple of authors lines myself. I
> promise not to add more. I certainly won't chastise anyone for adding
> theirs.
>
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

[Sumit Semwal]

Convert dma-buf documentation over to sphinx; also cleanup to
address sphinx warnings.

While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.

There is no content change yet; only format conversion and creation of
some hyperlinks.

Sumit Semwal (4):
  dma-buf/fence: kerneldoc: remove unused struct members
  dma-buf/fence: kerneldoc: remove spurious section header
  Documentation: move dma-buf documentation to rst
  Documentation/sphinx: link dma-buf rsts

 Documentation/DocBook/device-drivers.tmpl |  37 ---
 Documentation/dma-buf/guide.rst   | 503 ++
 Documentation/dma-buf/intro.rst   |  76 +
 Documentation/index.rst   |   2 +
 MAINTAINERS   |   2 +-
 include/linux/fence.h |   4 +-
 6 files changed, 583 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/dma-buf/guide.rst
 create mode 100644 Documentation/dma-buf/intro.rst

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 4/4] Documentation/sphinx: link dma-buf rsts

[Sumit Semwal]

Include dma-buf sphinx documentation into top level index.

Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
---
 Documentation/index.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 43c722f15292..2fe8e82d7d8c 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -14,6 +14,8 @@ Contents:
:maxdepth: 2
 
kernel-documentation
+   dma-buf/intro
+   dma-buf/guide
media/media_uapi
media/media_kapi
media/dvb-drivers/index
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 2/4] dma-buf/fence: kerneldoc: remove spurious section header

[Sumit Semwal]

Commit e941759c74a44d6ac2eed21bb0a38b21fe4559e2 ("fence: dma-buf
cross-device synchronization (v18)") had a spurious kerneldoc section
header that caused Sphinx to complain. Fix it.

Fixes: e941759c74a4 ("fence: dma-buf cross-device synchronization (v18)")

Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
---
 include/linux/fence.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fence.h b/include/linux/fence.h
index 5aa95eb886f7..5de89dab0013 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -60,7 +60,7 @@ struct fence_cb;
  * implementer of the fence for its own purposes. Can be used in different
  * ways by different fence implementers, so do not rely on this.
  *
- * *) Since atomic bitops are used, this is not guaranteed to be the case.
+ * Since atomic bitops are used, this is not guaranteed to be the case.
  * Particularly, if the bit was set, but fence_signal was called right
  * before this bit was set, it would have been able to set the
  * FENCE_FLAG_SIGNALED_BIT, before enable_signaling was called.
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 1/4] dma-buf/fence: kerneldoc: remove unused struct members

[Sumit Semwal]

Commit 0431b9065f28ecf6c320fefebe0241620049984f ("staging/android: bring
struct sync_pt back") removed child_list and active_list from struct fence,
but left it in kernel doc. Delete them.

Fixes: 0431b9065f28 ("staging/android: bring struct sync_pt back")

Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
---
 include/linux/fence.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/fence.h b/include/linux/fence.h
index 1de1b3f6fb76..5aa95eb886f7 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -49,8 +49,6 @@ struct fence_cb;
  * @timestamp: Timestamp when the fence was signaled.
  * @status: Optional, only valid if < 0, must be set before calling
  * fence_signal, indicates that the fence has completed with an error.
- * @child_list: list of children fences
- * @active_list: list of active fences
  *
  * the flags member must be manipulated and read using the appropriate
  * atomic ops (bit_*), so taking the spinlock will not be needed most
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 3/4] Documentation: move dma-buf documentation to rst

[Sumit Semwal]

Branch out dma-buf related documentation into its own rst file to allow
adding it to the sphinx documentation generated.

While at it, move dma-buf-sharing.txt into rst as the dma-buf guide too.

Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
---
 Documentation/DocBook/device-drivers.tmpl |  37 ---
 Documentation/dma-buf/guide.rst   | 503 ++
 Documentation/dma-buf/intro.rst   |  76 +
 MAINTAINERS   |   2 +-
 4 files changed, 580 insertions(+), 38 deletions(-)
 create mode 100644 Documentation/dma-buf/guide.rst
 create mode 100644 Documentation/dma-buf/intro.rst

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index 99cdc05bbb7a..a93fbffa9742 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,43 +128,6 @@ X!Edrivers/base/interface.c
 !Edrivers/base/platform.c
 !Edrivers/base/bus.c
  
- 
-   Buffer Sharing and Synchronization
-   
- The dma-buf subsystem provides the framework for sharing buffers
- for hardware (DMA) access across multiple device drivers and
- subsystems, and for synchronizing asynchronous hardware access.
-   
-   
- This is used, for example, by drm "prime" multi-GPU support, but
- is of course not limited to GPU use cases.
-   
-   
- The three main components of this are: (1) dma-buf, representing
- a sg_table and exposed to userspace as a file descriptor to allow
- passing between devices, (2) fence, which provides a mechanism
- to signal when one device as finished access, and (3) reservation,
- which manages the shared or exclusive fence(s) associated with
- the buffer.
-   
-   dma-buf
-!Edrivers/dma-buf/dma-buf.c
-!Iinclude/linux/dma-buf.h
-   
-   reservation
-!Pdrivers/dma-buf/reservation.c Reservation Object Overview
-!Edrivers/dma-buf/reservation.c
-!Iinclude/linux/reservation.h
-   
-   fence
-!Edrivers/dma-buf/fence.c
-!Iinclude/linux/fence.h
-!Edrivers/dma-buf/seqno-fence.c
-!Iinclude/linux/seqno-fence.h
-!Edrivers/dma-buf/sync_file.c
-!Iinclude/linux/sync_file.h
-   
- 
  Device Drivers DMA Management
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
diff --git a/Documentation/dma-buf/guide.rst b/Documentation/dma-buf/guide.rst
new file mode 100644
index ..fd3534fdccb3
--- /dev/null
+++ b/Documentation/dma-buf/guide.rst
@@ -0,0 +1,503 @@
+
+.. _dma-buf-guide:
+
+
+DMA Buffer Sharing API Guide
+====
+
+Sumit Semwal - sumit.sem...@linaro.org, sum...@kernel.org
+
+This document serves as a guide to device-driver writers on what is the dma-buf
+buffer sharing API, how to use it for exporting and using shared buffers.
+
+Any device driver which wishes to be a part of DMA buffer sharing, can do so as
+either the 'exporter' of buffers, or the 'user' of buffers.
+
+Say a driver A wants to use buffers created by driver B, then we call B as the
+exporter, and A as buffer-user.
+
+The exporter
+
+* implements and manages operations for the buffer via
+  :c:type:`struct dma_buf_ops `
+* allows other users to share the buffer by using dma_buf sharing APIs,
+* manages the details of buffer allocation,
+* decides about the actual backing storage where this allocation happens,
+* takes care of any migration of scatterlist - for all (shared) users of this
+  buffer,
+
+The buffer-user
+
+* is one of (many) sharing users of the buffer.
+* doesn't need to worry about how the buffer is allocated, or where.
+* needs a mechanism to get access to the scatterlist that makes up this buffer
+  in memory, mapped into its own address space, so it can access the same area
+  of memory.
+
+dma-buf operations for device dma only
+==
+
+The dma_buf buffer sharing API usage contains the following steps:
+
+1. Exporter announces that it wishes to export a buffer
+2. Userspace gets the file descriptor associated with the exported buffer, and
+   passes it around to potential buffer-users based on use case
+3. Each buffer-user 'connects' itself to the buffer
+4. When needed, buffer-user requests access to the buffer from exporter
+5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
+6. when buffer-user is done using this buffer completely, it 'disconnects'
+   itself from the buffer.
+
+
+1. Exporter's announcement of buffer export
+---
+
+   The buffer exporter announces its wish to export a buffer. In this, it
+   connects its own private buffer data, provides implementation for operations
+   that can be performed on the exported :c:type:`dma_buf`, and flags for the 
file
+   associated with this buffer. All these fields are filled in struct
+   :c:type:`dma_buf_export_in

[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

[Sumit Semwal]

Convert dma-buf documentation over to sphinx; also cleanup to
address sphinx warnings.

While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.

There is no content change yet; only format conversion and creation of
some hyperlinks.

Sumit Semwal (4):
  dma-buf/fence: kerneldoc: remove unused struct members
  dma-buf/fence: kerneldoc: remove spurious section header
  Documentation: move dma-buf documentation to rst
  Documentation/sphinx: link dma-buf rsts

 Documentation/DocBook/device-drivers.tmpl |  37 ---
 Documentation/dma-buf/guide.rst   | 503 ++
 Documentation/dma-buf/intro.rst   |  76 +
 Documentation/index.rst   |   2 +
 MAINTAINERS   |   2 +-
 include/linux/fence.h |   4 +-
 6 files changed, 583 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/dma-buf/guide.rst
 create mode 100644 Documentation/dma-buf/intro.rst

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

Hi Chris,

On 18 July 2016 at 17:40, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Mon, Jul 18, 2016 at 12:16:22PM +0100, Chris Wilson wrote:
>> If we fail to create the anon file, we need to remember to release the
>> module reference on the owner.
>>
Thanks for the patch.

>> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
>> Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
>> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
>> Cc: Sumit Semwal <sumit.sem...@linaro.org>
>> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
>> Cc: linux-media@vger.kernel.org
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linaro-mm-...@lists.linaro.org
>> ---
>>  drivers/dma-buf/dma-buf.c | 15 +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 20ce0687b111..ddaee60ae52a 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -334,6 +334,7 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   struct reservation_object *resv = exp_info->resv;
>>   struct file *file;
>>   size_t alloc_size = sizeof(struct dma_buf);
>> + int ret;
>
> Not sure this really helps readability, but meh. Will apply to drm-misc,
> with a cc: stable.
Daniel, fwiw, please feel free to add
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>

> -Daniel

BR,
~Sumit.
>
>>
>>   if (!exp_info->resv)
>>   alloc_size += sizeof(struct reservation_object);
>> @@ -357,8 +358,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>
>>   dmabuf = kzalloc(alloc_size, GFP_KERNEL);
>>   if (!dmabuf) {
>> - module_put(exp_info->owner);
>> - return ERR_PTR(-ENOMEM);
>> + ret = -ENOMEM;
>> + goto err_module;
>>   }
>>
>>   dmabuf->priv = exp_info->priv;
>> @@ -379,8 +380,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf,
>>   exp_info->flags);
>>   if (IS_ERR(file)) {
>> - kfree(dmabuf);
>> - return ERR_CAST(file);
>> + ret = PTR_ERR(file);
>> + goto err_dmabuf;
>>   }
>>
>>   file->f_mode |= FMODE_LSEEK;
>> @@ -394,6 +395,12 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   mutex_unlock(_list.lock);
>>
>>   return dmabuf;
>> +
>> +err_dmabuf:
>> + kfree(dmabuf);
>> +err_module:
>> + module_put(exp_info->owner);
>> + return ERR_PTR(ret);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_export);
>>
>> --
>> 2.8.1
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] dma-buf: debugfs fixes

[Sumit Semwal]

Hi Mathias,

On 19 June 2016 at 18:01, Mathias Krause <mini...@googlemail.com> wrote:
> This small series is the v2 of the patch posted initially here:
>
>   http://www.spinics.net/lists/linux-media/msg101347.html
>
> It not only fixes the type mix-up and addresses Daniel's remark (patch 1),
> it also smoothes out the error handling in dma_buf_init_debugfs() (patch 2)
> and removes the then unneeded function dma_buf_debugfs_create_file() (patch
> 3).
>
> Please apply!
>
Thanks for your patchset; applied via drm-misc!

> Mathias Krause (3):
>   dma-buf: propagate errors from dma_buf_describe() on debugfs read
>   dma-buf: remove dma_buf directory on bufinfo file creation errors
>   dma-buf: remove dma_buf_debugfs_create_file()
>
>  drivers/dma-buf/dma-buf.c |   44 ++--
>  include/linux/dma-buf.h   |2 --
>  2 files changed, 14 insertions(+), 32 deletions(-)
>
> --
> 1.7.10.4
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: reserved_mem: restore old behavior when no region is defined

[Sumit Semwal]

On 8 June 2016 at 18:35, Rob Herring <r...@kernel.org> wrote:
> On Wed, Jun 8, 2016 at 1:51 AM, Marek Szyprowski
> <m.szyprow...@samsung.com> wrote:
>> Change return value back to -ENODEV when no region is defined for given
>> device. This restores old behavior of this function, as some drivers rely
>> on such error code.
>>
>> Reported-by: Liviu Dudau <liviu.du...@arm.com>
>> Fixes: 59ce4039727ef40 ("of: reserved_mem: add support for using more than
>>one region for given device")
>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
>> ---
>>  drivers/of/of_reserved_mem.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
Looks reasonable; FWIW
Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>
> Acked-by: Rob Herring <r...@kernel.org>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: minor dma-buf updates for 4.7

[Sumit Semwal]

Hi Linus,

A tiny pull request with mostly cosmetic changes in dma-buf for 4.7;
may I request you to please pull?


The following changes since commit 852f42a69b93dc71507adedeed876d57b8c2c2fa:

  Merge branch 'uuid' (lib/uuid fixes from Andy) (2016-05-30 15:27:07 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-4.7

for you to fetch changes up to b02da6f8236148009c22167cd7013d5ce04a2d37:

  dma-buf: use vma_pages() (2016-05-31 22:17:05 +0530)


Minor dma-buf updates for 4.7:
- use of vma_pages instead of explicit computation.
- DocBook and headerdoc updates for dma-buf.


Luis de Bethencourt (1):
  fence: add missing descriptions for fence

Muhammad Falak R Wani (1):
  dma-buf: use vma_pages()

Rob Clark (3):
  dma-buf: headerdoc fixes
  reservation: add headerdoc comments
  doc: update/fixup dma-buf related DocBook

 Documentation/DocBook/device-drivers.tmpl | 36 ++--
 drivers/dma-buf/dma-buf.c |  7 +--
 drivers/dma-buf/reservation.c | 72 +--
 include/linux/dma-buf.h   | 13 --
 include/linux/fence.h |  2 +
 include/linux/reservation.h   | 53 +++
 6 files changed, 169 insertions(+), 14 deletions(-)

Thanks and best regards,
Sumit.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] fence: add missing descriptions for fence

[Sumit Semwal]

Hi Luis,


On 12 April 2016 at 04:03, Luis de Bethencourt  wrote:
> On 11/04/16 21:09, Gustavo Padovan wrote:
>> Hi Luis,
>>
>> 2016-04-11 Luis de Bethencourt :
>>
>>> The members child_list and active_list were added to the fence struct
>>> without descriptions for the Documentation. Adding these.
>>>
Thanks for the patch; will get it queued for for-next.

>>> Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
>>> Signed-off-by: Luis de Bethencourt 
>>> Reviewed-by: Javier Martinez Canillas 
>>> ---
>>> Hi,
>>>
>>> Just resending this patch since it hasn't had any reviews in since
>>> March 21st.
>>>
>>> Thanks,
>>> Luis
>>>
>>>  include/linux/fence.h | 2 ++
>>>  1 file changed, 2 insertions(+)
>>
>> Reviewed-by: Gustavo Padovan 
>>
>>   Gustavo
>>
>
> Thank you Gustavo.
>
> Nice seeing you around here :)
>
> Luis

BR,
Sumit.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

On 21 March 2016 at 13:00, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tiago Vignatti <tiago.vigna...@intel.com>
> Cc: Stéphane Marchesin <marc...@chromium.org>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Cc: Sumit Semwal <sumit.sem...@linaro.org>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> CC: linux-media@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-...@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>

> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..5c4e3e586ec8 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EGAIN or -EINTR, in which case it must be restarted.
>
> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot on coherent access, even when there are
> +systems where it just works without calling these ioctls.
>
>  2. Supporting existing mmap interfaces in importers
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:[in]buffer to complete cpu access for.
>   * @direction: [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>enum dma_data_direction direction)
> --
> 2.8.0.rc3
>

Best regards,
Sumit.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

On 19 March 2016 at 15:39, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Fri, Mar 18, 2016 at 08:02:39PM +, Chris Wilson wrote:
>> Drivers, especially i915.ko, can fail during the initial migration of a
>> dma-buf for CPU access. However, the error code from the driver was not
>> being propagated back to ioctl and so userspace was blissfully ignorant
>> of the failure. Rendering corruption ensues.
>>
>> Whilst fixing the ioctl to return the error code from
>> dma_buf_start_cpu_access(), also do the same for
>> dma_buf_end_cpu_access().  For most drivers, dma_buf_end_cpu_access()
>> cannot fail. i915.ko however, as most drivers would, wants to avoid being
>> uninterruptible (as would be required to guarrantee no failure when
>> flushing the buffer to the device). As userspace already has to handle
>> errors from the SYNC_IOCTL, take advantage of this to be able to restart
>> the syscall across signals.
>>
>> This fixes a coherency issue for i915.ko as well as reducing the
>> uninterruptible hold upon its BKL, the struct_mutex.
>>
>> Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
>> Author: Daniel Vetter <daniel.vet...@ffwll.ch>
>> 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
>> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
>> Cc: Tiago Vignatti <tiago.vigna...@intel.com>
>> Cc: Stéphane Marchesin <marc...@chromium.org>
>> Cc: David Herrmann <dh.herrm...@gmail.com>
>> Cc: Sumit Semwal <sumit.sem...@linaro.org>
>> Cc: Daniel Vetter <daniel.vet...@intel.com>
>> CC: linux-media@vger.kernel.org
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: de...@driverdev.osuosl.org
>
> Applied to drm-misc, I'll send a pull to Dave the next few days if no one
> screams.
> -Daniel
Thanks for pulling it via drm-misc, Daniel.
Chris, I feel since this is an API change, it also needs an update to
the Documentation file.
With that, and a minor nit below, please feel free to add
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>

>
>> ---
>>  drivers/dma-buf/dma-buf.c | 17 +++--
>>  drivers/gpu/drm/i915/i915_gem_dmabuf.c| 15 +--
>>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  5 +++--
>>  drivers/gpu/drm/udl/udl_fb.c  |  4 ++--
>>  drivers/staging/android/ion/ion.c |  6 --
>>  include/linux/dma-buf.h   |  6 +++---
>>  6 files changed, 28 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 9810d1df0691..774a60f4309a 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file,
>>   struct dma_buf *dmabuf;
>>   struct dma_buf_sync sync;
>>   enum dma_data_direction direction;
>> + int ret;
>>
>>   dmabuf = file->private_data;
>>
>> @@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file,
>>   }
>>
>>   if (sync.flags & DMA_BUF_SYNC_END)
>> - dma_buf_end_cpu_access(dmabuf, direction);
>> + ret = dma_buf_end_cpu_access(dmabuf, direction);
>>   else
>> - dma_buf_begin_cpu_access(dmabuf, direction);
>> + ret = dma_buf_begin_cpu_access(dmabuf, direction);
>>
>> - return 0;
>> + return ret;
>>   default:
>>   return -ENOTTY;
>>   }
>> @@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>>   *
>>   * This call must always succeed.
>>   */
Perhaps update the above comment to reflect the change as well?

>> -void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>> - enum dma_data_direction direction)
>> +int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>> +enum dma_data_direction direction)
>>  {
>> + int ret = 0;
>> +
>>   WARN_ON(!dmabuf);
>>
>>   if (dmabuf->ops->end_cpu_access)
>> - dmabuf->ops->end_cpu_access(dmabuf, direction);
>> + ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
>> +
>> + return ret;
>>  }
<< snip>>

Best regards,
Sumit.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: dma-buf changes for 4.2

[Sumit Semwal]

Hi Linus,

Very small pull request on dma-buf for 4.2 merge window. May I request
you to please pull?


The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22:

  Linux 4.1-rc2 (2015-05-03 19:22:23 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-4.2

for you to fetch changes up to 5136629dc5a19701746abd7c8ad98ce0b84dda1d:

  dma-buf: Minor coding style fixes (2015-05-21 11:29:59 +0530)


Minor changes for 4.2
- add ref-counting for kernel modules as exporters
- minor code style fixes


Jagan Teki (1):
  dma-buf: Minor coding style fixes

Sumit Semwal (1):
  dma-buf: add ref counting for module as exporter

 drivers/dma-buf/dma-buf.c | 19 ---
 drivers/dma-buf/reservation.c |  9 ++---
 drivers/dma-buf/seqno-fence.c |  8 +++-
 include/linux/dma-buf.h   | 10 --
 4 files changed, 37 insertions(+), 9 deletions(-)

Thanks and best regards,
Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

On 3 June 2015 at 15:07, Hans Verkuil hverk...@xs4all.nl wrote:
 On 06/03/15 10:41, Russell King - ARM Linux wrote:
 On Wed, Jun 03, 2015 at 08:39:55AM +0200, Hans Verkuil wrote:
 Hi Sumit,

 On 05/05/2015 04:41 PM, Sumit Semwal wrote:
 Hi Russell, everyone,

 First up, sincere apologies for being awol for sometime; had some
 personal / medical things to take care of, and then I thought I'd wait
 for the merge window to get over before beginning to discuss this
 again.

 On 11 February 2015 at 21:53, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
 On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote:
 Hello,

 On 2015-02-11 12:12, Russell King - ARM Linux wrote:
 Which is a damn good reason to NAK it - by that admission, it's a 
 half-baked
 idea.

 If all we want to know is whether the importer can accept only 
 contiguous
 memory or not, make a flag to do that, and allow the exporter to test 
 this
 flag.  Don't over-engineer this to make it _seem_ like it can do 
 something
 that it actually totally fails with.

 As I've already pointed out, there's a major problem if you have already
 had a less restrictive attachment which has an active mapping, and a new
 more restrictive attachment comes along later.

 It seems from Rob's descriptions that we also need another flag in the
 importer to indicate whether it wants to have a valid struct page in the
 scatter list, or whether it (correctly) uses the DMA accessors on the
 scatter list - so that exporters can reject importers which are buggy.

 Okay, but flag-based approach also have limitations.

 Yes, the flag-based approach doesn't let you describe in detail what
 the importer can accept - which, given the issues that I've raised
 is a *good* thing.  We won't be misleading anyone into thinking that
 we can do something that's really half-baked, and which we have no
 present requirement for.

 This is precisely what Linus talks about when he says don't over-
 engineer - if we over-engineer this, we end up with something that
 sort-of works, and that's a bad thing.

 The Keep It Simple approach here makes total sense - what are our
 current requirements - to be able to say that an importer can only accept:
   - contiguous memory rather than a scatterlist
   - scatterlists with struct page pointers

 Does solving that need us to compare all the constraints of each and
 every importer, possibly ending up with constraints which can't be
 satisfied?  No.  Does the flag approach satisfy the requirements?  Yes.


 So, for basic constraint-sharing, we'll just go with the flag based
 approach, with a flag (best place for it is still dev-dma_params I
 suppose) for denoting contiguous or scatterlist. Is that agreed, then?
 Also, with this idea, of course, there won't be any helpers for trying
 to calculate constraints; it would be totally the exporter's
 responsibility to handle it via the attach() dma_buf_op if it wishes
 to.

 What's wrong with the proposed max_segment_count? Many media devices do
 have a limited max_segment_count and that should be taken into account.

 So what happens if you have a dma_buf exporter, and several dma_buf
 importers.  One dma_buf importer attaches to the exporter, and asks
 for the buffer, and starts making use of the buffer.  This export has
 many scatterlist segments.

 Another dma_buf importer attaches to the same buffer, and now asks for
 the buffer, but the number of scatterlist segments exceeds it
 requirement.

So, in the midst of all the various directions this discussion has
taken, I seem to have missed to reiterate the base premise for this
suggestion [1] - that we can use this information to help implement a
deferred allocation logic - so that all the importers can attach
first, and the exporter can do the actual allocation on the first
map() call.
This is also inline with the prescribed usage of dma_buf_attach() /
dma_buf_map_attachment() sequence - ideally speaking, all
participating 'importers' of dma_buf should only attach first, and
then map() at a 'later' time, which is usually right before using the
buffer actually.
Note: at present, both DRI and V4L subsystems don't do that; while
proposing this RFC I had deliberately kept that separate, as it is a
related but orthogonal problem to solve. I guess I should address that
in parallel.

 You can't reallocate the buffer because it's in-use by another importer.
 There is no way to revoke the buffer from the other importer.  So there
 is no way to satisfy this importer's requirements.

You're right; but in a deferred allocation mechanism, this
constraint-sharing can atleast help decide on the most restrictive
allocation at the time of first map() ,and if later, an importer with
more relaxed constraints attaches, it can still use the same buffer.
A more restrictive importer would still be not allowed, but in that
case the exporter can disallow that importer from attaching, and a
feedback to userspace is possible.

 What I'm showing is that the idea

Re: [RFC] Export alignment requirements for buffers

[Sumit Semwal]

Hi Laurent,

Thanks for looping me into this email chain, and apologies about not
responding earlier; it just got lost in the barrage of things.

On 1 June 2015 at 21:20, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Hans,

 On Monday 01 June 2015 11:44:51 Hans Verkuil wrote:
 One of the things that is really irritating is the fact that drivers that
 use contig-dma sometimes want to support USERPTR, allowing applications to
 pass pointers to the driver that point to physically contiguous memory that
 was somehow obtained, and that userspace has no way of knowing whether the
 driver has this requirement or not.

 A related issue is that, depending on the DMA engine, the user pointer might
 have some alignment requirements (page aligned, or at minimum 16 bytes
 aligned) that userspace has no way of knowing.

 The same alignment issue is present also for dma-buf.

 Doesn't the first issue also apply to DMABUF ?

 As you already know, I'm not a big fan of USERPTR when used for sharing
 buffers between devices. DMABUF is a much better choice there. USERPTR can
 still be helpful for other use cases though. One of them that comes to my mind
 is to capturing directly buffers allocated by a software codec (or another
 similar userspace library) that doesn't support externally allocated memory
 (although the core issue there would be the library design).

 Anyway, the problem of conveying memory constraints is identical in the DMABUF
 case, so a solution is needed.

Yes, +1 on that.

The problem posed here is similar in the sense of requirement of
conveying memory constraints, but the key is probably the reverse
direction - the userspace here *needs* to share constraints of
_buffers_ obtained from elsewhere.


 I propose to take one reserved field from struct v4l2_create_buffers and
 from struct v4l2_requestbuffers and change it to this:

   __u32 flags;

 #define V4L2_REQBUFS_FL_ALIGNMENT_MSK 0x3f
 #define V4L2_REQBUFS_FL_PHYS_CONTIG   (1  31)

 Where the alignment is a power of 2 (and if 0 the alignment is unknown). The
 max is 2^63, which should be enough for the foreseeable future :-)

 If the physically contiguous flag is set, then the buffer must be physically
 contiguous.

 These flags can be set for every vb2 dma implementation:

 dma-contig: the PHYS_CONTIG flag is always set and the alignment is (unless
 overridden by the driver) page aligned.

 dma-sg: the PHYS_CONTIG flag is 0 and the alignment will depend on the
 driver DMA implementation. Note: malloc will align the buffer to 8 bytes on
 a 32 bit OS and 16 bytes on a 64 bit OS.

 vmalloc: PHYS_CONFIG is 0 and the alignment should be 3 (2^3 == 8) for 32
 bit and 4 (2^4=16) for 64 bit OS. This matches malloc() which will align
 the buffer to 8 bytes on a 32 bit OS and 16 bytes on a 64 bit OS.

 The flags field can be extended with things like OPAQUE if the buffers
 cannot be mmapped (since they are in protected memory).

 Comments? Alternative solutions?

 The question of conveying memory constraints has been raised several times in
 the past, without any solutions being merged. The work has been revived
 recently, see 
 http://lists.freedesktop.org/archives/dri-devel/2015-February/076862.html for 
 instance.

 Even if the API proposed here is specific to V4L2, and even if the patch set I
 linked to addresses a different problem, I believe it would be wise to widen
 the audience to make sure the solutions we come up with are at least aligned
 between subsystems. I've thus CC'ed Sumit to this e-mail as a start.


So I've been (trying to) work out some way of conveying memory
constraints between devices, and our idea was to get that added to
struct device-dma_parameters; that ways, the userspace doesn't have
to necessarily know of the constraints, and some negotiation can
happen in the kernel itself. It doesn't at the moment concern with
taking care of sharing those back to userspace, but I think that's an
orthogonal thing to handle.

Absolutely, it'd be great if we can come up with some aligned way of
conveying these constraints.
 --
 Regards,

 Laurent Pinchart




-- 
Thanks and regards,

Sumit Semwal
Kernel SubTeam Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf: Minor coding style fixes

[Sumit Semwal]

Hi Jagan,

On 21 May 2015 at 01:09, Jagan Teki jt...@openedev.com wrote:
 - WARNING: Missing a blank line after declarations
 - WARNING: line over 80 characters
 - WARNING: please, no space before tabs

 Signed-off-by: Jagan Teki jt...@openedev.com
 Cc: Sumit Semwal sumit.sem...@linaro.org

Thanks for the patch; I've queued it up in for-next.

Best regards,
~Sumit.

snip
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

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 is in use.

The original patch [1] was submitted by Tomasz Stanislawski, but this
is a simpler way to do it.

v3: call module_put() as late as possible, per gregkh's comment.
v2: move owner to struct dma_buf, and use DEFINE_DMA_BUF_EXPORT_INFO
macro to simplify the change.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org

[1]: https://lkml.org/lkml/2012/8/8/163
---
 drivers/dma-buf/dma-buf.c | 10 +-
 include/linux/dma-buf.h   | 10 --
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c5a9138a6a8d..63a9914e42b8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -29,6 +29,7 @@
 #include linux/anon_inodes.h
 #include linux/export.h
 #include linux/debugfs.h
+#include linux/module.h
 #include linux/seq_file.h
 #include linux/poll.h
 #include linux/reservation.h
@@ -72,6 +73,7 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
if (dmabuf-resv == (struct reservation_object *)dmabuf[1])
reservation_object_fini(dmabuf-resv);
 
+   module_put(dmabuf-owner);
kfree(dmabuf);
return 0;
 }
@@ -302,14 +304,20 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
 
+   if (!try_module_get(exp_info-owner))
+   return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
-   if (dmabuf == NULL)
+   if (!dmabuf) {
+   module_put(exp_info-owner);
return ERR_PTR(-ENOMEM);
+   }
 
dmabuf-priv = exp_info-priv;
dmabuf-ops = exp_info-ops;
dmabuf-size = exp_info-size;
dmabuf-exp_name = exp_info-exp_name;
+   dmabuf-owner = exp_info-owner;
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 2f0b431b73e0..f98bd7068d55 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -115,6 +115,8 @@ struct dma_buf_ops {
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
  * @exp_name: name of the exporter; useful for debugging.
+ * @owner: pointer to exporter module; used for refcounting when exporter is a
+ * kernel module.
  * @list_node: node for dma_buf accounting and debugging.
  * @priv: exporter specific private data for this buffer object.
  * @resv: reservation object linked to this dma-buf
@@ -129,6 +131,7 @@ struct dma_buf {
unsigned vmapping_counter;
void *vmap_ptr;
const char *exp_name;
+   struct module *owner;
struct list_head list_node;
void *priv;
struct reservation_object *resv;
@@ -164,7 +167,8 @@ struct dma_buf_attachment {
 
 /**
  * struct dma_buf_export_info - holds information needed to export a dma_buf
- * @exp_name:  name of the exporting module - useful for debugging.
+ * @exp_name:  name of the exporter - useful for debugging.
+ * @owner: pointer to exporter module - used for refcounting kernel module
  * @ops:   Attach allocator-defined dma buf ops to the new buffer
  * @size:  Size of the buffer
  * @flags: mode flags for the file
@@ -176,6 +180,7 @@ struct dma_buf_attachment {
  */
 struct dma_buf_export_info {
const char *exp_name;
+   struct module *owner;
const struct dma_buf_ops *ops;
size_t size;
int flags;
@@ -187,7 +192,8 @@ struct dma_buf_export_info {
  * helper macro for exporters; zeros and fills in most common values
  */
 #define DEFINE_DMA_BUF_EXPORT_INFO(a)  \
-   struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
+   struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME, \
+.owner = THIS_MODULE }
 
 /**
  * get_dma_buf - convenience wrapper for get_file.
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

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 is in use.

The original patch [1] was submitted by Tomasz, but he's since shifted
jobs and a ping didn't elicit any response.

  [tomasz: Original author]
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Acked-by: Daniel Vetter dan...@ffwll.ch
  [sumits: updated  rebased as per review comments]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org

[1]: https://lkml.org/lkml/2012/8/8/163
---
 drivers/dma-buf/dma-buf.c  | 9 -
 drivers/gpu/drm/armada/armada_gem.c| 1 +
 drivers/gpu/drm/drm_prime.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 1 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 +
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  | 1 +
 drivers/gpu/drm/tegra/gem.c| 1 +
 drivers/gpu/drm/udl/udl_dmabuf.c   | 1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  | 1 +
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 1 +
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 1 +
 drivers/media/v4l2-core/videobuf2-vmalloc.c| 1 +
 drivers/staging/android/ion/ion.c  | 1 +
 include/linux/dma-buf.h| 2 ++
 14 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c5a9138a6a8d..9583eac0238f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -29,6 +29,7 @@
 #include linux/anon_inodes.h
 #include linux/export.h
 #include linux/debugfs.h
+#include linux/module.h
 #include linux/seq_file.h
 #include linux/poll.h
 #include linux/reservation.h
@@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
BUG_ON(dmabuf-cb_shared.active || dmabuf-cb_excl.active);
 
dmabuf-ops-release(dmabuf);
+   module_put(dmabuf-ops-owner);
 
mutex_lock(db_list.lock);
list_del(dmabuf-list_node);
@@ -302,9 +304,14 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
 
+   if (!try_module_get(exp_info-ops-owner))
+   return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
-   if (dmabuf == NULL)
+   if (!dmabuf) {
+   module_put(exp_info-ops-owner);
return ERR_PTR(-ENOMEM);
+   }
 
dmabuf-priv = exp_info-priv;
dmabuf-ops = exp_info-ops;
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 580e10acaa3a..d2c5fc1269b7 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -524,6 +524,7 @@ armada_gem_dmabuf_mmap(struct dma_buf *buf, struct 
vm_area_struct *vma)
 }
 
 static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
+   .owner = THIS_MODULE,
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7fec191b45f7..ed4a6e35dd91 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -289,6 +289,7 @@ static int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf,
 }
 
 static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  {
+   .owner = THIS_MODULE,
.attach = drm_gem_map_attach,
.detach = drm_gem_map_detach,
.map_dma_buf = drm_gem_map_dma_buf,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index cd485c091b30..35fa029353e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -169,6 +169,7 @@ static int exynos_gem_dmabuf_mmap(struct dma_buf *dma_buf,
 }
 
 static struct dma_buf_ops exynos_dmabuf_ops = {
+   .owner  = THIS_MODULE,
.attach = exynos_gem_attach_dma_buf,
.detach = exynos_gem_detach_dma_buf,
.map_dma_buf= exynos_gem_map_dma_buf,
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 7998da27c500..b9355d8d4862 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -213,6 +213,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf 
*dma_buf, size_t start, size
 }
 
 static const struct dma_buf_ops i915_dmabuf_ops =  {
+   .owner = THIS_MODULE,
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 344fd789170d..977ece9be62c 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm

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

[Sumit Semwal]

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 is in use.

The original patch [1] was submitted by Tomasz Stanislawski, but this
is a simpler way to do it.

v2: move owner to struct dma_buf, and use DEFINE_DMA_BUF_EXPORT_INFO
macro to simplify the change.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org

[1]: https://lkml.org/lkml/2012/8/8/163
---
 drivers/dma-buf/dma-buf.c | 10 +-
 include/linux/dma-buf.h   | 10 --
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c5a9138a6a8d..0eff4bf56ef6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -29,6 +29,7 @@
 #include linux/anon_inodes.h
 #include linux/export.h
 #include linux/debugfs.h
+#include linux/module.h
 #include linux/seq_file.h
 #include linux/poll.h
 #include linux/reservation.h
@@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
BUG_ON(dmabuf-cb_shared.active || dmabuf-cb_excl.active);
 
dmabuf-ops-release(dmabuf);
+   module_put(dmabuf-owner);
 
mutex_lock(db_list.lock);
list_del(dmabuf-list_node);
@@ -302,14 +304,20 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
 
+   if (!try_module_get(exp_info-owner))
+   return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
-   if (dmabuf == NULL)
+   if (!dmabuf) {
+   module_put(exp_info-owner);
return ERR_PTR(-ENOMEM);
+   }
 
dmabuf-priv = exp_info-priv;
dmabuf-ops = exp_info-ops;
dmabuf-size = exp_info-size;
dmabuf-exp_name = exp_info-exp_name;
+   dmabuf-owner = exp_info-owner;
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 2f0b431b73e0..f98bd7068d55 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -115,6 +115,8 @@ struct dma_buf_ops {
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
  * @exp_name: name of the exporter; useful for debugging.
+ * @owner: pointer to exporter module; used for refcounting when exporter is a
+ * kernel module.
  * @list_node: node for dma_buf accounting and debugging.
  * @priv: exporter specific private data for this buffer object.
  * @resv: reservation object linked to this dma-buf
@@ -129,6 +131,7 @@ struct dma_buf {
unsigned vmapping_counter;
void *vmap_ptr;
const char *exp_name;
+   struct module *owner;
struct list_head list_node;
void *priv;
struct reservation_object *resv;
@@ -164,7 +167,8 @@ struct dma_buf_attachment {
 
 /**
  * struct dma_buf_export_info - holds information needed to export a dma_buf
- * @exp_name:  name of the exporting module - useful for debugging.
+ * @exp_name:  name of the exporter - useful for debugging.
+ * @owner: pointer to exporter module - used for refcounting kernel module
  * @ops:   Attach allocator-defined dma buf ops to the new buffer
  * @size:  Size of the buffer
  * @flags: mode flags for the file
@@ -176,6 +180,7 @@ struct dma_buf_attachment {
  */
 struct dma_buf_export_info {
const char *exp_name;
+   struct module *owner;
const struct dma_buf_ops *ops;
size_t size;
int flags;
@@ -187,7 +192,8 @@ struct dma_buf_export_info {
  * helper macro for exporters; zeros and fills in most common values
  */
 #define DEFINE_DMA_BUF_EXPORT_INFO(a)  \
-   struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
+   struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME, \
+.owner = THIS_MODULE }
 
 /**
  * get_dma_buf - convenience wrapper for get_file.
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

On 7 May 2015 at 13:40, Greg KH gre...@linuxfoundation.org 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 is in use.

 The original patch [1] was submitted by Tomasz, but he's since shifted
 jobs and a ping didn't elicit any response.

   [tomasz: Original author]
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Acked-by: Daniel Vetter dan...@ffwll.ch
   [sumits: updated  rebased as per review comments]
 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org

 [1]: https://lkml.org/lkml/2012/8/8/163
 ---
  drivers/dma-buf/dma-buf.c  | 9 -
  drivers/gpu/drm/armada/armada_gem.c| 1 +
  drivers/gpu/drm/drm_prime.c| 1 +
  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 1 +
  drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 +
  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  | 1 +
  drivers/gpu/drm/tegra/gem.c| 1 +
  drivers/gpu/drm/udl/udl_dmabuf.c   | 1 +
  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  | 1 +
  drivers/media/v4l2-core/videobuf2-dma-contig.c | 1 +
  drivers/media/v4l2-core/videobuf2-dma-sg.c | 1 +
  drivers/media/v4l2-core/videobuf2-vmalloc.c| 1 +
  drivers/staging/android/ion/ion.c  | 1 +
  include/linux/dma-buf.h| 2 ++
  14 files changed, 22 insertions(+), 1 deletion(-)

 diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
 index c5a9138a6a8d..9583eac0238f 100644
 --- a/drivers/dma-buf/dma-buf.c
 +++ b/drivers/dma-buf/dma-buf.c
 @@ -29,6 +29,7 @@
  #include linux/anon_inodes.h
  #include linux/export.h
  #include linux/debugfs.h
 +#include linux/module.h
  #include linux/seq_file.h
  #include linux/poll.h
  #include linux/reservation.h
 @@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct 
 file *file)
   BUG_ON(dmabuf-cb_shared.active || dmabuf-cb_excl.active);

   dmabuf-ops-release(dmabuf);
 + module_put(dmabuf-ops-owner);

   mutex_lock(db_list.lock);
   list_del(dmabuf-list_node);
 @@ -302,9 +304,14 @@ struct dma_buf *dma_buf_export(const struct 
 dma_buf_export_info *exp_info)
   return ERR_PTR(-EINVAL);
   }

 + if (!try_module_get(exp_info-ops-owner))
 + return ERR_PTR(-ENOENT);
 +
   dmabuf = kzalloc(alloc_size, GFP_KERNEL);
 - if (dmabuf == NULL)
 + if (!dmabuf) {
 + module_put(exp_info-ops-owner);
   return ERR_PTR(-ENOMEM);
 + }

   dmabuf-priv = exp_info-priv;
   dmabuf-ops = exp_info-ops;
 diff --git a/drivers/gpu/drm/armada/armada_gem.c 
 b/drivers/gpu/drm/armada/armada_gem.c
 index 580e10acaa3a..d2c5fc1269b7 100644
 --- a/drivers/gpu/drm/armada/armada_gem.c
 +++ b/drivers/gpu/drm/armada/armada_gem.c
 @@ -524,6 +524,7 @@ armada_gem_dmabuf_mmap(struct dma_buf *buf, struct 
 vm_area_struct *vma)
  }

  static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
 + .owner = THIS_MODULE,
   .map_dma_buf= armada_gem_prime_map_dma_buf,
   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
   .release= drm_gem_dmabuf_release,

 The easier way to do this is change the registration function to add
 the module owner automatically, which keeps you from having to modify
 all of the individual drivers.  Look at how pci and usb do this for
 their driver registration functions.  That should result in a much
 smaller patch, that always works properly for everyone (there's no way
 for driver to get it wrong.)

Thanks Greg; but of course, you're right! We already have a
DEFINE_DMA_BUF_EXPORT_INFO macro, so this is far easier incorporated
into that.

I will spin up the (much simpler) patch and repost!

 thanks,

 greg k-h


Best regards,
Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Hi Russell, everyone,

First up, sincere apologies for being awol for sometime; had some
personal / medical things to take care of, and then I thought I'd wait
for the merge window to get over before beginning to discuss this
again.

On 11 February 2015 at 21:53, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote:
 Hello,

 On 2015-02-11 12:12, Russell King - ARM Linux wrote:
 Which is a damn good reason to NAK it - by that admission, it's a half-baked
 idea.
 
 If all we want to know is whether the importer can accept only contiguous
 memory or not, make a flag to do that, and allow the exporter to test this
 flag.  Don't over-engineer this to make it _seem_ like it can do something
 that it actually totally fails with.
 
 As I've already pointed out, there's a major problem if you have already
 had a less restrictive attachment which has an active mapping, and a new
 more restrictive attachment comes along later.
 
 It seems from Rob's descriptions that we also need another flag in the
 importer to indicate whether it wants to have a valid struct page in the
 scatter list, or whether it (correctly) uses the DMA accessors on the
 scatter list - so that exporters can reject importers which are buggy.

 Okay, but flag-based approach also have limitations.

 Yes, the flag-based approach doesn't let you describe in detail what
 the importer can accept - which, given the issues that I've raised
 is a *good* thing.  We won't be misleading anyone into thinking that
 we can do something that's really half-baked, and which we have no
 present requirement for.

 This is precisely what Linus talks about when he says don't over-
 engineer - if we over-engineer this, we end up with something that
 sort-of works, and that's a bad thing.

 The Keep It Simple approach here makes total sense - what are our
 current requirements - to be able to say that an importer can only accept:
   - contiguous memory rather than a scatterlist
   - scatterlists with struct page pointers

 Does solving that need us to compare all the constraints of each and
 every importer, possibly ending up with constraints which can't be
 satisfied?  No.  Does the flag approach satisfy the requirements?  Yes.


So, for basic constraint-sharing, we'll just go with the flag based
approach, with a flag (best place for it is still dev-dma_params I
suppose) for denoting contiguous or scatterlist. Is that agreed, then?
Also, with this idea, of course, there won't be any helpers for trying
to calculate constraints; it would be totally the exporter's
responsibility to handle it via the attach() dma_buf_op if it wishes
to.

 Frankly, if we want to make it really portable and sharable between devices,
 then IMO we should get rid of struct scatterlist and replace it with simple
 array of pfns in dma_buf. This way at least the problem of missing struct
 page will be solved and the buffer representation will be also a bit more
 compact.

 ... and move the mapping and unmapping of the PFNs to the importer,
 which IMHO is where it should already be (so the importer can decide
 when it should map the buffer itself independently of getting the
 details of the buffer.)

 Such solution however also requires extending dma-mapping API to handle
 mapping and unmapping of such pfn arrays. The advantage of this approach
 is the fact that it will be completely new API, so it can be designed
 well from the beginning.

 As far as I'm aware, there was no big discussion of the dma_buf API -
 it's something that just appeared one day (I don't remember seeing it
 discussed.)  So, that may well be a good thing if it means we can get
 these kinds of details better hammered out.

 However, I don't share your view of completely new API - that would
 be far too disruptive.  I think we can modify the existing API, to
 achieve our goals.

 I don't think changing the dma-mapping API just for this case is really
 on though - if we're passed a list of PFNs, they either must be all
 associated with a struct page - iow, pfn_valid(pfn) returns true for
 all of them or none of them.  If none of them, then we need to be able
 to convert those PFNs to a dma_addr_t for the target device (yes, that
 may need the dma-mapping API augmenting.)

 However, if they are associated with a struct page, then we should use
 the established APIs and use a scatterlist, otherwise we're looking
 at rewriting all IOMMUs and all DMA mapping implementations to handle
 what would become a special case for dma_buf.

 I'd rather... Keep It Simple.

+1 for Keep it simple, and the idea overall. Though I suspect more
dma-buf users (dri / v4l friends?) should comment if this doesn't help
solve things on some platforms / subsystems that they care about.

 So, maybe, as a first step, let's augment dma_buf with a pair of
 functions which get the raw unmapped scatterlist:

 struct sg_table *dma_buf_get_scatterlist(struct dma_buf_attachment *attach)
 {
   

[GIT PULL]: dma-buf updates for 4.1-rc1

[Sumit Semwal]

Hi Linus,

May I request you to pull a few dma-buf changes for 4.1-rc1? minor
cleanup only; this could've gone in for the 4.0 merge window, but for
a copy-paste stupidity from me.

It has been in the for-next since then, and no issues reported.

Thanks and best regards,
Sumit.


The following changes since commit 646da63172f660ba84f195c1165360a9b73583ee:

  Merge tag 'remoteproc-4.1-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc
(2015-04-20 15:40:10 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-4.1

for you to fetch changes up to 72449cb47b0104c32ff8fb9380ade9113375d8d1:

  staging: android: ion: fix wrong init of dma_buf_export_info
(2015-04-21 14:47:16 +0530)


- cleanup of dma_buf_export()
- correction of copy-paste stupidity while doing the cleanup


Sumit Semwal (2):
  dma-buf: cleanup dma_buf_export() to make it easily extensible
  staging: android: ion: fix wrong init of dma_buf_export_info

 Documentation/dma-buf-sharing.txt  | 23 +++--
 drivers/dma-buf/dma-buf.c  | 47 --
 drivers/gpu/drm/armada/armada_gem.c| 10 --
 drivers/gpu/drm/drm_prime.c| 12 ---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  9 +++--
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  9 -
 drivers/gpu/drm/tegra/gem.c| 10 --
 drivers/gpu/drm/ttm/ttm_object.c   |  9 +++--
 drivers/gpu/drm/udl/udl_dmabuf.c   |  9 -
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  8 -
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 -
 drivers/media/v4l2-core/videobuf2-vmalloc.c|  8 -
 drivers/staging/android/ion/ion.c  |  9 +++--
 include/linux/dma-buf.h| 34 +++
 15 files changed, 152 insertions(+), 63 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: dma-buf fixes for 4.0

[Sumit Semwal]

Hi Linus,

May I please request you to pull a couple of fixes in dma-buf for 4.0-rc3?


The following changes since commit b942c653ae265abbd31032f3b4f5f857e5c7c723:

  Merge tag 'trace-sh-3.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
(2015-01-22 06:26:07 +1200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-4.0-rc3

for you to fetch changes up to 4eb2440ed60fb5793f7aa6da89b3d517cc59de43:

  reservation: Remove shadowing local variable 'ret' (2015-01-22 16:29:31 +0530)


dma-buf pull request for 4.0-rc3
- minor timeout  other fixes on reservation/fence


Jammy Zhou (2):
  reservation: wait only with non-zero timeout specified (v3)
  dma-buf/fence: don't wait when specified timeout is zero

Michel Dänzer (1):
  reservation: Remove shadowing local variable 'ret'

 drivers/dma-buf/fence.c   | 3 +++
 drivers/dma-buf/reservation.c | 5 +++--
 2 files changed, 6 insertions(+), 2 deletions(-)

Thanks, and Best regards,
Sumit.

PS: I am not submitting the cleanup that I submitted in my earlier
pull request that you had to reject due to my stupid copy-paste error;
that one patch and it's fix is in for-next, but it's not, strictly
speaking, a fix to qualify for -rc3, hence I'll wait for the next
merge-window to submit it.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL]: few dma-buf updates for 3.20-rc1

[Sumit Semwal]

Hi Linus,

On 22 February 2015 at 01:42, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Fri, Feb 20, 2015 at 8:27 AM, Sumit Semwal sumit.sem...@linaro.org wrote:

 Could you please pull a few dma-buf changes for 3.20-rc1? Nothing
 fancy, minor cleanups.

 No.

 I pulled, and immediately unpulled again.

 This is complete shit, and the compiler even tells you so:

 drivers/staging/android/ion/ion.c: In function ‘ion_share_dma_buf’:
 drivers/staging/android/ion/ion.c:1112:24: warning: ‘buffer’ is
 used uninitialized in this function [-Wuninitialized]
  exp_info.size = buffer-size;
 ^

 Introduced by dma-buf: cleanup dma_buf_export() to make it easily 
 extensible.

 I'm not taking cleanups like this.  And I certainly don't appreciate
 being sent completely bogus shit pull requests at the end of the merge
 cycle.

I apologize sincerely; I shouldn't have missed it before sending you
the pull request. (stupid copy-paste across files is certainly no
excuse for this).

This got caught in for-next too, but right after I sent the pull-request :(.

I also shouldn't have sent it so late in the merge cycle - this could
certainly wait till -rc2, which would've helped me correct it before
the request to you. Serves me right to try and meet the merge-cycle
deadline in a jet-lagged state!

I will definitely take extra precautions next time onward, so you
don't see negligence like this in my requests to you.

Apologies again!

Linus

Best regards,
Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: few dma-buf updates for 3.20-rc1

[Sumit Semwal]

Hi Linus,

Could you please pull a few dma-buf changes for 3.20-rc1? Nothing
fancy, minor cleanups.

The following changes since commit b942c653ae265abbd31032f3b4f5f857e5c7c723:

  Merge tag 'trace-sh-3.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
(2015-01-22 06:26:07 +1200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-3.20

for you to fetch changes up to 817bd7253291fc69d83d4340a7e186f3e6933169:

  dma-buf: cleanup dma_buf_export() to make it easily extensible
(2015-02-18 20:16:20 +0530)


dma-buf pull request for 3.20
- minor timeout  other cleanups on reservation/fence
- cleanup of dma_buf_export()


Jammy Zhou (2):
  reservation: wait only with non-zero timeout specified (v3)
  dma-buf/fence: don't wait when specified timeout is zero

Michel Dänzer (1):
  reservation: Remove shadowing local variable 'ret'

Sumit Semwal (1):
  dma-buf: cleanup dma_buf_export() to make it easily extensible

 Documentation/dma-buf-sharing.txt  | 23 +++--
 drivers/dma-buf/dma-buf.c  | 47 --
 drivers/dma-buf/fence.c|  3 ++
 drivers/dma-buf/reservation.c  |  5 +--
 drivers/gpu/drm/armada/armada_gem.c| 10 --
 drivers/gpu/drm/drm_prime.c| 12 ---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  9 +++--
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  9 -
 drivers/gpu/drm/tegra/gem.c| 10 --
 drivers/gpu/drm/ttm/ttm_object.c   |  9 +++--
 drivers/gpu/drm/udl/udl_dmabuf.c   |  9 -
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  8 -
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 -
 drivers/media/v4l2-core/videobuf2-vmalloc.c|  8 -
 drivers/staging/android/ion/ion.c  |  9 +++--
 include/linux/dma-buf.h| 34 +++
 17 files changed, 158 insertions(+), 65 deletions(-)


Thanks, and best regards,
Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Hi Russell,

On 30 January 2015 at 00:56, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
 Quite possibly for some of these edge some of cases, some of the
 dma-buf exporters are going to need to get more clever (ie. hand off
 different scatterlists to different clients).  Although I think by far
 the two common cases will be I can support anything via an iommu/mmu
 and I need phys contig.

 But that isn't an issue w/ dma-buf itself, so much as it is an issue
 w/ drivers.  I guess there would be more interest in fixing up drivers
 when actual hw comes along that needs it..

 However, validating the attachments is the business of dma-buf.  This
 is actual infrastructure, which should ensure some kind of sanity such
 as the issues I've raised.

 The whole we can push it onto our users is really on - what that
 results in is the users ignoring most of the requirements and just doing
 their own thing, which ultimately ends up with the whole thing turning
 into a disgusting mess - one which becomes very difficult to fix later.

 Now, if we're going to do the more clever thing you mention above,
 that rather negates the point of this two-part patch set, which is to
 provide the union of the DMA capabilities of all users.  A union in
 that case is no longer sane as we'd be tailoring the SG lists to each
 user.

 If we aren't going to do the more clever thing, then yes, we need this
 code to calculate that union, but we _also_ need it to do sanity checking
 right from the start, and refuse conditions which ultimately break the
 ability to make use of that union - in other words, when the union of
 the DMA capabilities means that the dmabuf can't be represented.

 Unless we do that, we'll just end up with random drivers interpreting
 what they want from the DMA capabilities, and we'll have some drivers
 exporting (eg) scatterlists which satisfy the maximum byte size of an
 element, but ignoring the maximum number of entries or vice versa, and
 that'll most probably hide the case of too small a union.

I agree, and I'll add the check for
max_segment_size * max_segment_count  dmabuf-size
and resend; will that be alright with you?

 It really doesn't make sense to do both either: that route is even more
 madness, because we'll end up with two classes of drivers - those which
 use the union approach, and those which don't.

 The KISS principle applies here.

 --
 FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
 according to speedtest.net.


Best regards,
~Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

On 29 January 2015 at 21:17, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
 So, short answer is, it is left to the exporter to decide. The dma-buf
 framework should not even attempt to decide or enforce any of the
 above.

 At each dma_buf_attach(), there's a callback to the exporter, where
 the exporter can decide, if it intends to handle these kind of cases,
 on the best way forward.

 The exporter might, for example, decide to migrate backing storage,

 That's a decision which the exporter can not take.  Think about it...

 If subsystem Y has mapped the buffer, it could be accessing the buffer's
 backing storage at the same time that subsystem Z tries to attach to the
 buffer.

Well, first up, of course the 'migration of backing storage' is an
orthogonal problem to what this patchset attempts to do - in this, I
am only try to make the relevant information available to the
exporter.

With that out of the way, some thoughts on what you mentioned:

So, IF the exporter needs to support migration of backing storage,
even when subsystem Y has mapped the buffer, the exporter knows this
(because of the map_dma_buf() dma_buf_op) - and the attach() also is
notified to / handled by the exporter. With this information, it could
either:
a) not let the subsystem Z attach (the 'simpler' approach), or
b) hold enough state-information about the Z's attach request
internally, then migrate the pages on the unmap_attachment() callback
from the subsystem Y?

(The exact details for this will need to be thought-of by exporters
actually trying to do migration of pages, or delayed allocation, or
such, though)

 Once the buffer has been exported to another user, the exporter has
 effectively lost control over mediating accesses to that buffer.

 All that it can do with the way the dma-buf API is today is to allocate
 a _different_ scatter list pointing at the same backing storage which
 satisfies the segment size and number of segments, etc.

 There's also another issue which you haven't addressed.  What if several
 attachments result in lowering max_segment_size and max_segment_count
 such that:

 max_segment_size * max_segment_count  dmabuf-size

 but individually, the attachments allow dmabuf-size to be represented
 as a scatterlist?

 If an exporter were to take notice of the max_segment_size and
 max_segment_count, the resulting buffer is basically unrepresentable
 as a scatterlist.

Thanks for pointing that out; I guess we'd have to disallow the
attachment which would make that happen. I can add this as another
check in calc_constraints().


  Please consider the possible sequences of use (such as the scenario
  above) when creating or augmenting an API.
 

 I tried to think of the scenarios I could think of, but If you still
 feel this approach doesn't help with your concerns, I'll graciously
 accept advice to improve it.

 See the new one above :)

Another thanks for making me rack my puny brain on these scenarios! :)
[though I strongly suspect I might not have done enough!]
 --
 FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
 according to speedtest.net.

BR,
~Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Hi Russell!

On 29 January 2015 at 20:09, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
 +/*
 + * recalc_constraints - recalculates constraints for all attached devices;
 + *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
 + *  helper.
 + *  Returns recalculated constraints in recalc_cons, or error in the 
 unlikely
 + *  case when constraints of attached devices might have changed.
 + */

Thanks for your valuable review comments!

 Please see kerneldoc documentation for the proper format of these comments.
These are static functions, and as such kerneldoc doesn't enforce
kernel-doc style comments, so in the dma-buf files, we've not followed
them for static functions.
That said, it is certainly a valuable advice, and I could create a
separate patch-set for updating the documentation for the static
functions as well.

 +static int recalc_constraints(struct dma_buf *dmabuf,
 +   struct device_dma_parameters *recalc_cons)
 +{
 + struct device_dma_parameters calc_cons;
 + struct dma_buf_attachment *attach;
 + int ret = 0;
 +
 + init_constraints(calc_cons);
 +
 + list_for_each_entry(attach, dmabuf-attachments, node) {
 + ret = calc_constraints(attach-dev, calc_cons);
 + if (ret)
 + return ret;
 + }
 + *recalc_cons = calc_cons;
 + return 0;
 +}
 +
  /**
   * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
   * with this buffer, so it can be exported.
 @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
 struct dma_buf_ops *ops,
   dmabuf-ops = ops;
   dmabuf-size = size;
   dmabuf-exp_name = exp_name;
 +
 + init_constraints(dmabuf-constraints);
 +
   init_waitqueue_head(dmabuf-poll);
   dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
   dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
 @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,
 struct device *dev)
  {
   struct dma_buf_attachment *attach;
 - int ret;
 + int ret = 0;

   if (WARN_ON(!dmabuf || !dev))
   return ERR_PTR(-EINVAL);
 @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,

   mutex_lock(dmabuf-lock);

 + if (calc_constraints(dev, dmabuf-constraints))
 + goto err_constraints;
 +
   if (dmabuf-ops-attach) {
   ret = dmabuf-ops-attach(dmabuf, dev, attach);
   if (ret)
 @@ -448,6 +514,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
 *dmabuf,

  err_attach:
   kfree(attach);
 +err_constraints:
   mutex_unlock(dmabuf-lock);
   return ERR_PTR(ret);
  }
 @@ -470,6 +537,8 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
 dma_buf_attachment *attach)
   if (dmabuf-ops-detach)
   dmabuf-ops-detach(dmabuf, attach);

 + recalc_constraints(dmabuf, dmabuf-constraints);
 +

 To me, this whole thing seems horribly racy.

 What happens if subsystem X creates a dmabuf, which is passed to
 userspace. It's then passed to subsystem Y, which starts making use
 of it, calling dma_buf_map_attachment() on it.

 The same buffer is also passed (via unix domain sockets) to another
 program, which then passes it independently into subsystem Z, and
 subsystem Z has more restrictive DMA constraints.

 What happens at this point?

 Subsystems such as DRM cache the scatter table, and return it for
 subsequent attach calls, so DRM drivers using the default
 drm_gem_map_dma_buf() implementation would not see the restrictions
 placed upon the dmabuf.  Moreover, the returned scatterlist would not
 be modified for those restrictions either.

 What would other subsystems do?

 This needs more thought before it's merged.

 For example, in the above situation, should we deny the ability to
 create a new attachment when a dmabuf has already been mapped by an
 existing attachment?  Should we deny it only when the new attachment
 has more restrictive DMA constraints?

So, short answer is, it is left to the exporter to decide. The dma-buf
framework should not even attempt to decide or enforce any of the
above.

At each dma_buf_attach(), there's a callback to the exporter, where
the exporter can decide, if it intends to handle these kind of cases,
on the best way forward.

The exporter might, for example, decide to migrate backing storage,
should there be a need to do so, or simply deny when the new
attachment has more restrictive DMA constraints, as you mentioned as a
possibility.

These changes simply allow the exporter, should it wish to, to take
the DMA constraints into consideration while making those decisions.
For the current cases, it should not even matter if the DMA
constraints aren't shared by the devices.

 Please consider the possible sequences of use

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

[Sumit Semwal]

Hi Mauro,

On 28 January 2015 at 18:53, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
 Em Wed, 28 Jan 2015 18:24:03 +0530
 Sumit Semwal sumit.sem...@linaro.org escreveu:

 +/**
 + * helper macro for exporters; zeros and fills in most common values
 + */
 +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
 + struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
 +

 I suspect that this will let the other fields not initialized.

 You likely need to do:

 #define DEFINE_DMA_BUF_EXPORT_INFO(a)   \
 struct dma_buf_export_info a = {\
 .exp_name = KBUILD_MODNAME; \
 .fields = 0;\
 ...
 }
I suspected the same, but Daniel kindly referred to the C99 standard,
which states:
 If there are fewer initializers in a brace-enclosed list than there
are elements or members
of an aggregate, or fewer characters in a string literal used to
initialize an array of known
size than there are elements in the array, the remainder of the
aggregate shall be
initialized implicitly the same as objects that have static storage duration.

So I think we're well covered there?

 Regards,
 Mauro



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

On 28 January 2015 at 16:50, Daniel Thompson daniel.thomp...@linaro.org wrote:
 On 28/01/15 06:00, Sumit Semwal wrote:
snip
 +/**
 + * helper macro for exporters; zeros and fills in most common values
 + */
 +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
 + struct dma_buf_export_info a = {0}; \
 + exp_info.exp_name = KBUILD_MODNAME
 +

 This risks generating C99 warnings unless used with care (and only once
 per function). Shouldn't this be more like:

 #define DEFINE_DMA_BUF_EXPORT_INFO(a) \
 struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }


Ah! My bad; thanks for catching this, Daniel; I'll send out the
updated patch in a minute!
 Daniel.




-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.

Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().

While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
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  | 47 +-
 drivers/gpu/drm/armada/armada_gem.c| 10 --
 drivers/gpu/drm/drm_prime.c| 12 ---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  9 +++--
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  9 -
 drivers/gpu/drm/tegra/gem.c| 10 --
 drivers/gpu/drm/ttm/ttm_object.c   |  9 +++--
 drivers/gpu/drm/udl/udl_dmabuf.c   |  9 -
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  8 -
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 -
 drivers/media/v4l2-core/videobuf2-vmalloc.c|  8 -
 drivers/staging/android/ion/ion.c  |  9 +++--
 include/linux/dma-buf.h| 34 +++
 14 files changed, 142 insertions(+), 50 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..6d3df3dd9310 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
 }
 
 /**
- * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
  * Also connect the allocator specific data and ops to the buffer.
  * Additionally, provide a name string for exporter; useful in debugging.
@@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
  * @exp_name:  [in]name of the exporting module - useful for debugging.
  * @resv:  [in]reservation-object, NULL to allocate default one.
  *
+ * All the above info comes from struct dma_buf_export_info.
+ *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
  * ops, or error in allocating struct dma_buf, will return negative error.
  *
  */
-struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags, const char *exp_name,
-   struct reservation_object *resv)
+struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
 {
struct dma_buf *dmabuf;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
-   if (!resv)
+   if (!exp_info-resv)
alloc_size += sizeof(struct reservation_object);
else
/* prevent dma_buf[1] == dma_buf-resv */
alloc_size += 1;
 
-   if (WARN_ON(!priv || !ops
- || !ops-map_dma_buf
- || !ops-unmap_dma_buf
- || !ops-release
- || !ops-kmap_atomic
- || !ops-kmap
- || !ops-mmap)) {
+   if (WARN_ON(!exp_info-priv
+ || !exp_info-ops
+ || !exp_info-ops-map_dma_buf
+ || !exp_info-ops-unmap_dma_buf
+ || !exp_info-ops-release
+ || !exp_info-ops-kmap_atomic
+ || !exp_info-ops-kmap
+ || !exp_info-ops-mmap)) {
return ERR_PTR(-EINVAL);
}
 
@@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
 
-   dmabuf-priv = priv;
-   dmabuf-ops = ops;
-   dmabuf-size = size;
-   dmabuf-exp_name = exp_name;
+   dmabuf-priv = exp_info-priv;
+   dmabuf-ops = exp_info-ops;
+   dmabuf-size = exp_info-size;
+   dmabuf-exp_name = exp_info-exp_name;
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
 
-   if (!resv) {
-   resv = (struct reservation_object *)dmabuf[1];
-   reservation_object_init(resv);
+   if (!exp_info-resv) {
+   exp_info-resv = (struct reservation_object *)dmabuf[1];
+   reservation_object_init(exp_info-resv);
}
-   dmabuf-resv = resv;
+   dmabuf-resv = exp_info-resv

[RFCv3 1/2] device: add dma_params-max_segment_count

[Sumit Semwal]

From: Rob Clark robdcl...@gmail.com

For devices which have constraints about maximum number of segments in
an sglist.  For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.

The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer.  The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.

Signed-off-by: Rob Clark robdcl...@gmail.com
 [sumits: Minor updates wrt comments]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---

v3: include Robin Murphy's fix[1] for handling '0' as a value for
 max_segment_count
v2: minor updates wrt comments on the first version

[1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/

 include/linux/device.h  |  1 +
 include/linux/dma-mapping.h | 19 +++
 2 files changed, 20 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index fb506738f7b7..a32f9b67315c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
 * sg limitations.
 */
unsigned int max_segment_size;
+   unsigned int max_segment_count;/* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
 };
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb4bfa6..d3351a36d5ec 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct 
device *dev,
return -EIO;
 }
 
+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+   if (dev-dma_parms  dev-dma_parms-max_segment_count)
+   return dev-dma_parms-max_segment_count;
+   return DMA_SEGMENTS_MAX_SEG_COUNT;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+   unsigned int count)
+{
+   if (dev-dma_parms) {
+   dev-dma_parms-max_segment_count = count;
+   return 0;
+   }
+   return -EIO;
+}
+
 static inline unsigned long dma_get_seg_boundary(struct device *dev)
 {
return dev-dma_parms ?
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.

At each attach, the constraints are calculated based on the following:
- max_segment_size, max_segment_count, segment_boundary_mask from
   device_dma_parameters.

In case the attaching device's constraints don't match up, attach() fails.

At detach, the constraints are recalculated based on the remaining
attached devices.

Two helpers are added:
- dma_buf_get_constraints - which gives the current constraints as calculated
  during each attach on the buffer till the time,
- dma_buf_recalc_constraints - which recalculates the constraints for all
  currently attached devices for the 'paranoid' ones amongst us.

The idea of this patch is largely taken from Rob Clark's RFC at
https://lkml.org/lkml/2012/7/19/285, and the comments received on it.

Cc: Rob Clark robdcl...@gmail.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
v3: 
- Thanks to Russell's comment, remove dma_mask and coherent_dma_mask from
  constraints' calculation; has a nice side effect of letting us use
  device_dma_parameters directly to list constraints.
- update the debugfs output to show constraint info as well.
  
v2: split constraints-sharing and allocation helpers

 drivers/dma-buf/dma-buf.c | 126 +-
 include/linux/dma-buf.h   |   7 +++
 2 files changed, 132 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..f363f1440803 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -264,6 +264,66 @@ static inline int is_dma_buf_file(struct file *file)
return file-f_op == dma_buf_fops;
 }
 
+static inline void init_constraints(struct device_dma_parameters *cons)
+{
+   cons-max_segment_count = (unsigned int)-1;
+   cons-max_segment_size = (unsigned int)-1;
+   cons-segment_boundary_mask = (unsigned long)-1;
+}
+
+/*
+ * calc_constraints - calculates if the new attaching device's constraints
+ * match, with the constraints of already attached devices; if yes, returns
+ * the constraints; else return ERR_PTR(-EINVAL)
+ */
+static int calc_constraints(struct device *dev,
+   struct device_dma_parameters *calc_cons)
+{
+   struct device_dma_parameters cons = *calc_cons;
+
+   cons.max_segment_count = min(cons.max_segment_count,
+   dma_get_max_seg_count(dev));
+   cons.max_segment_size = min(cons.max_segment_size,
+   dma_get_max_seg_size(dev));
+   cons.segment_boundary_mask = dma_get_seg_boundary(dev);
+
+   if (!cons.max_segment_count ||
+   !cons.max_segment_size ||
+   !cons.segment_boundary_mask) {
+   pr_err(Dev: %s's constraints don't match\n, dev_name(dev));
+   return -EINVAL;
+   }
+
+   *calc_cons = cons;
+
+   return 0;
+}
+
+/*
+ * recalc_constraints - recalculates constraints for all attached devices;
+ *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
+ *  helper.
+ *  Returns recalculated constraints in recalc_cons, or error in the unlikely
+ *  case when constraints of attached devices might have changed.
+ */
+static int recalc_constraints(struct dma_buf *dmabuf,
+ struct device_dma_parameters *recalc_cons)
+{
+   struct device_dma_parameters calc_cons;
+   struct dma_buf_attachment *attach;
+   int ret = 0;
+
+   init_constraints(calc_cons);
+
+   list_for_each_entry(attach, dmabuf-attachments, node) {
+   ret = calc_constraints(attach-dev, calc_cons);
+   if (ret)
+   return ret;
+   }
+   *recalc_cons = calc_cons;
+   return 0;
+}
+
 /**
  * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
@@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf-ops = ops;
dmabuf-size = size;
dmabuf-exp_name = exp_name;
+
+   init_constraints(dmabuf-constraints);
+
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
@@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
  struct device *dev)
 {
struct dma_buf_attachment *attach;
-   int ret;
+   int ret = 0;
 
if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
@@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
 
mutex_lock(dmabuf-lock);
 
+   if (calc_constraints(dev, dmabuf-constraints))
+   goto err_constraints;
+
if (dmabuf-ops-attach) {
ret = dmabuf-ops-attach(dmabuf, dev, attach

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

[Sumit Semwal]

At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.

Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().

While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
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| 10 --
 drivers/gpu/drm/drm_prime.c| 12 ---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |  9 +++--
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  9 -
 drivers/gpu/drm/tegra/gem.c| 10 --
 drivers/gpu/drm/ttm/ttm_object.c   |  9 +++--
 drivers/gpu/drm/udl/udl_dmabuf.c   |  9 -
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  8 -
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  8 -
 drivers/media/v4l2-core/videobuf2-vmalloc.c|  8 -
 drivers/staging/android/ion/ion.c  |  9 +++--
 include/linux/dma-buf.h| 35 +++
 14 files changed, 143 insertions(+), 50 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..6d3df3dd9310 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
 }
 
 /**
- * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
  * Also connect the allocator specific data and ops to the buffer.
  * Additionally, provide a name string for exporter; useful in debugging.
@@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
  * @exp_name:  [in]name of the exporting module - useful for debugging.
  * @resv:  [in]reservation-object, NULL to allocate default one.
  *
+ * All the above info comes from struct dma_buf_export_info.
+ *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
  * ops, or error in allocating struct dma_buf, will return negative error.
  *
  */
-struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags, const char *exp_name,
-   struct reservation_object *resv)
+struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
 {
struct dma_buf *dmabuf;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
-   if (!resv)
+   if (!exp_info-resv)
alloc_size += sizeof(struct reservation_object);
else
/* prevent dma_buf[1] == dma_buf-resv */
alloc_size += 1;
 
-   if (WARN_ON(!priv || !ops
- || !ops-map_dma_buf
- || !ops-unmap_dma_buf
- || !ops-release
- || !ops-kmap_atomic
- || !ops-kmap
- || !ops-mmap)) {
+   if (WARN_ON(!exp_info-priv
+ || !exp_info-ops
+ || !exp_info-ops-map_dma_buf
+ || !exp_info-ops-unmap_dma_buf
+ || !exp_info-ops-release
+ || !exp_info-ops-kmap_atomic
+ || !exp_info-ops-kmap
+ || !exp_info-ops-mmap)) {
return ERR_PTR(-EINVAL);
}
 
@@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
 
-   dmabuf-priv = priv;
-   dmabuf-ops = ops;
-   dmabuf-size = size;
-   dmabuf-exp_name = exp_name;
+   dmabuf-priv = exp_info-priv;
+   dmabuf-ops = exp_info-ops;
+   dmabuf-size = exp_info-size;
+   dmabuf-exp_name = exp_info-exp_name;
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
 
-   if (!resv) {
-   resv = (struct reservation_object *)dmabuf[1];
-   reservation_object_init(resv);
+   if (!exp_info-resv) {
+   exp_info-resv = (struct reservation_object *)dmabuf[1];
+   reservation_object_init(exp_info-resv);
}
-   dmabuf-resv = resv;
+   dmabuf-resv = exp_info-resv;
 
-   file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
+   file = anon_inode_getfile

Re: [RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Hi Russell!

On 21 January 2015 at 23:01, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Wed, Jan 21, 2015 at 09:46:47AM +0530, Sumit Semwal wrote:
 +static int calc_constraints(struct device *dev,
 + struct dma_buf_constraints *calc_cons)
 +{
 + struct dma_buf_constraints cons = *calc_cons;
 +
 + cons.dma_mask = dma_get_mask(dev);

 I don't think this makes much sense when you consider that the DMA
 infrastructure supports buses with offsets.  The DMA mask is th
 upper limit of the _bus_ specific address, it is not a mask per-se.

 What this means is that = is not the right operation.  Moreover,
 simply comparing masks which could be from devices on unrelated
 buses doesn't make sense either.

 However, that said, I don't have an answer for what you want to
 achieve here.

Thanks for your comments! I suppose in that case, I will leave out the
*dma_masks from this constraints information for now; we can re-visit
it when a specific use case really needs information about the
dma-masks of the attached devices.

I will post an updated patch-set soon.

 --
 FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
 according to speedtest.net.



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] reservation: Remove shadowing local variable 'ret'

[Sumit Semwal]

Hi Michel,

On 22 January 2015 at 12:30, Michel Dänzer mic...@daenzer.net wrote:
 From: Michel Dänzer michel.daen...@amd.com

 It was causing the return value of fence_is_signaled to be ignored, making
 reservation objects signal too early.

Thanks; pushed to my for-next.

 Cc: sta...@vger.kernel.org
 Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com
 Reviewed-by: Alex Deucher alexander.deuc...@amd.com
 Signed-off-by: Michel Dänzer michel.daen...@amd.com
 ---
  drivers/dma-buf/reservation.c | 2 --
  1 file changed, 2 deletions(-)

 diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
 index 3c97c8f..8a37af9 100644
 --- a/drivers/dma-buf/reservation.c
 +++ b/drivers/dma-buf/reservation.c
 @@ -402,8 +402,6 @@ reservation_object_test_signaled_single(struct fence 
 *passed_fence)
 int ret = 1;

 if (!test_bit(FENCE_FLAG_SIGNALED_BIT, lfence-flags)) {
 -   int ret;
 -
 fence = fence_get_rcu(lfence);
 if (!fence)
 return -1;
 --
 2.1.4




-- 
Thanks and best regards,
Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Sumit Semwal]

At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.

Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().

While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 drivers/dma-buf/dma-buf.c  | 47 +-
 drivers/gpu/drm/armada/armada_gem.c| 12 +--
 drivers/gpu/drm/drm_prime.c| 14 +---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 13 +--
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 12 +--
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  | 11 +-
 drivers/gpu/drm/tegra/gem.c| 12 +--
 drivers/gpu/drm/ttm/ttm_object.c   | 11 --
 drivers/gpu/drm/udl/udl_dmabuf.c   | 10 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 10 +-
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 10 +-
 drivers/media/v4l2-core/videobuf2-vmalloc.c| 10 +-
 drivers/staging/android/ion/ion.c  | 11 --
 include/linux/dma-buf.h| 28 +++
 14 files changed, 160 insertions(+), 51 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..6d3df3dd9310 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
 }
 
 /**
- * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
  * Also connect the allocator specific data and ops to the buffer.
  * Additionally, provide a name string for exporter; useful in debugging.
@@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
  * @exp_name:  [in]name of the exporting module - useful for debugging.
  * @resv:  [in]reservation-object, NULL to allocate default one.
  *
+ * All the above info comes from struct dma_buf_export_info.
+ *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
  * ops, or error in allocating struct dma_buf, will return negative error.
  *
  */
-struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags, const char *exp_name,
-   struct reservation_object *resv)
+struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
 {
struct dma_buf *dmabuf;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
-   if (!resv)
+   if (!exp_info-resv)
alloc_size += sizeof(struct reservation_object);
else
/* prevent dma_buf[1] == dma_buf-resv */
alloc_size += 1;
 
-   if (WARN_ON(!priv || !ops
- || !ops-map_dma_buf
- || !ops-unmap_dma_buf
- || !ops-release
- || !ops-kmap_atomic
- || !ops-kmap
- || !ops-mmap)) {
+   if (WARN_ON(!exp_info-priv
+ || !exp_info-ops
+ || !exp_info-ops-map_dma_buf
+ || !exp_info-ops-unmap_dma_buf
+ || !exp_info-ops-release
+ || !exp_info-ops-kmap_atomic
+ || !exp_info-ops-kmap
+ || !exp_info-ops-mmap)) {
return ERR_PTR(-EINVAL);
}
 
@@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
 
-   dmabuf-priv = priv;
-   dmabuf-ops = ops;
-   dmabuf-size = size;
-   dmabuf-exp_name = exp_name;
+   dmabuf-priv = exp_info-priv;
+   dmabuf-ops = exp_info-ops;
+   dmabuf-size = exp_info-size;
+   dmabuf-exp_name = exp_info-exp_name;
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
 
-   if (!resv) {
-   resv = (struct reservation_object *)dmabuf[1];
-   reservation_object_init(resv);
+   if (!exp_info-resv) {
+   exp_info-resv = (struct reservation_object *)dmabuf[1];
+   reservation_object_init(exp_info-resv);
}
-   dmabuf-resv = resv;
+   dmabuf-resv = exp_info-resv;
 
-   file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
+   file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf

Re: [RFCv2 1/2] device: add dma_params-max_segment_count

[Sumit Semwal]

Hi Robin!

On 22 January 2015 at 00:26, Robin Murphy robin.mur...@arm.com wrote:
 Hi Sumit,


 On 21/01/15 04:16, Sumit Semwal wrote:

 From: Rob Clark robdcl...@gmail.com

 For devices which have constraints about maximum number of segments in
 an sglist.  For example, a device which could only deal with contiguous
 buffers would set max_segment_count to 1.

 The initial motivation is for devices sharing buffers via dma-buf,
 to allow the buffer exporter to know the constraints of other
 devices which have attached to the buffer.  The dma_mask and fields
 in 'struct device_dma_parameters' tell the exporter everything else
 that is needed, except whether the importer has constraints about
 maximum number of segments.

 Signed-off-by: Rob Clark robdcl...@gmail.com
   [sumits: Minor updates wrt comments on the first version]
 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
 ---
   include/linux/device.h  |  1 +
   include/linux/dma-mapping.h | 19 +++
   2 files changed, 20 insertions(+)

 diff --git a/include/linux/device.h b/include/linux/device.h
 index fb50673..a32f9b6 100644
 --- a/include/linux/device.h
 +++ b/include/linux/device.h
 @@ -647,6 +647,7 @@ struct device_dma_parameters {
  * sg limitations.
  */
 unsigned int max_segment_size;
 +   unsigned int max_segment_count;/* INT_MAX for unlimited */
 unsigned long segment_boundary_mask;
   };

 diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
 index c3007cb..38e2835 100644
 --- a/include/linux/dma-mapping.h
 +++ b/include/linux/dma-mapping.h
 @@ -154,6 +154,25 @@ static inline unsigned int
 dma_set_max_seg_size(struct device *dev,
 return -EIO;
   }

 +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
 +
 +static inline unsigned int dma_get_max_seg_count(struct device *dev)
 +{
 +   return dev-dma_parms ?
 +   dev-dma_parms-max_segment_count :
 +   DMA_SEGMENTS_MAX_SEG_COUNT;
 +}


 I know this copies the style of the existing code, but unfortunately it also
 copies the subtle brokenness. Plenty of drivers seem to set up a dma_parms
 struct just for max_segment_size, thus chances are you'll come across a
 max_segment_count of 0 sooner or later. How badly is that going to break
 things? I posted a fix recently[1] having hit this problem with
 segment_boundary_mask in IOMMU code.

Thanks very much for reviewing this code; and apologies for missing
your patch that you mentioned here; sure, I will update my patch
accordingly as well.
 +
 +static inline int dma_set_max_seg_count(struct device *dev,
 +   unsigned int count)
 +{
 +   if (dev-dma_parms) {
 +   dev-dma_parms-max_segment_count = count;
 +   return 0;
 +   } else


 This else is just as unnecessary as the other two I've taken out ;)


 Robin.

 [1]:http://article.gmane.org/gmane.linux.kernel.iommu/8175/


 +   return -EIO;
 +}
 +
   static inline unsigned long dma_get_seg_boundary(struct device *dev)
   {
 return dev-dma_parms ?




BR,
Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.

At each attach, the constraints are calculated based on the following:
- dma_mask, coherent_dma_mask from struct device,
- max_segment_size, max_segment_count, segment_boundary_mask from
   device_dma_parameters.

In case the attaching device's constraints don't match up, attach() fails.

At detach, the constraints are recalculated based on the remaining
attached devices.

Two helpers are added:
- dma_buf_get_constraints - which gives the current constraints as calculated
  during each attach on the buffer till the time,
- dma_buf_recalc_constraints - which recalculates the constraints for all
  currently attached devices for the 'paranoid' ones amongst us.

The idea of this patch is largely taken from Rob Clark's RFC at
https://lkml.org/lkml/2012/7/19/285, and the comments received on it.

Cc: Rob Clark robdcl...@gmail.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 drivers/dma-buf/dma-buf.c | 132 +-
 include/linux/dma-buf.h   |  22 
 2 files changed, 153 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c..3781f43 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -264,6 +264,77 @@ static inline int is_dma_buf_file(struct file *file)
return file-f_op == dma_buf_fops;
 }
 
+static inline void init_constraints(struct dma_buf_constraints *cons)
+{
+   cons-coherent_dma_mask = (u64)-1;
+   cons-dma_mask = (u64)-1;
+   cons-dma_parms.max_segment_count = (unsigned int)-1;
+   cons-dma_parms.max_segment_size = (unsigned int)-1;
+   cons-dma_parms.segment_boundary_mask = (unsigned int)-1;
+}
+
+/*
+ * calc_constraints - calculates if the new attaching device's constraints
+ * match, with the constraints of already attached devices; if yes, returns
+ * the constraints; else return ERR_PTR(-EINVAL)
+ */
+static int calc_constraints(struct device *dev,
+   struct dma_buf_constraints *calc_cons)
+{
+   struct dma_buf_constraints cons = *calc_cons;
+
+   cons.dma_mask = dma_get_mask(dev);
+   /* TODO: Check if this is the right way for coherent_mask ? */
+   cons.coherent_dma_mask = dev-coherent_dma_mask;
+
+   cons.dma_parms.max_segment_count =
+   min(cons.dma_parms.max_segment_count,
+   dma_get_max_seg_count(dev));
+   cons.dma_parms.max_segment_size =
+   min(cons.dma_parms.max_segment_size,
+   dma_get_max_seg_size(dev));
+   cons.dma_parms.segment_boundary_mask =
+   dma_get_seg_boundary(dev);
+
+   if (!cons.dma_parms.max_segment_count ||
+   !cons.dma_parms.max_segment_size ||
+   !cons.dma_parms.segment_boundary_mask ||
+   !cons.dma_mask ||
+   !cons.coherent_dma_mask) {
+   pr_err(Dev: %s's constraints don't match\n, dev_name(dev));
+   return -EINVAL;
+   }
+
+   *calc_cons = cons;
+
+   return 0;
+}
+
+/*
+ * recalc_constraints - recalculates constraints for all attached devices;
+ *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
+ *  helper.
+ *  Returns recalculated constraints in recalc_cons, or error in the unlikely
+ *  case when constraints of attached devices might have changed.
+ */
+static int recalc_constraints(struct dma_buf *dmabuf,
+ struct dma_buf_constraints *recalc_cons)
+{
+   struct dma_buf_constraints calc_cons;
+   struct dma_buf_attachment *attach;
+   int ret = 0;
+
+   init_constraints(calc_cons);
+
+   list_for_each_entry(attach, dmabuf-attachments, node) {
+   ret = calc_constraints(attach-dev, calc_cons);
+   if (ret)
+   return ret;
+   }
+   *recalc_cons = calc_cons;
+   return 0;
+}
+
 /**
  * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
@@ -313,6 +384,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf-ops = ops;
dmabuf-size = size;
dmabuf-exp_name = exp_name;
+
+   init_constraints(dmabuf-constraints);
+
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
@@ -422,7 +496,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
  struct device *dev)
 {
struct dma_buf_attachment *attach;
-   int ret;
+   int ret = 0;
 
if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
@@ -436,6 +510,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
 
mutex_lock(dmabuf-lock

[RFCv2 0/2] dma-parms, constraints and helpers for dma-buf

[Sumit Semwal]

Hello Everyone,

Based on review comments received, I've split my earlier patchset on
'dma-buf constraints-enabled allocation' [1] into 2 sets:
- first one is this one, to use dma_parms and related parameters from
   struct device to share constraints, and then to use these constraints in
   dma-buf to help find the least common constraint set that could then be
   used by exporters to decide on allocation.

   This is a partial re-write of what Rob Clark proposed some while ago [2];
   I've tried to take care of review comments on his patchset, but any errors
   and omissions are, ofcourse, mine.

- Second part, one which I'm working on, and will post soon, aims at adding
   allocator-helpers in dma-buf framework which could use this constraint
   information to help choose the right allocator from a list.

While I work on the second part, I thought of sending the RFC for this one,
to get feedback on whether this mechanism seems ok to everyone.

[1] https://lkml.org/lkml/2014/10/10/340
[2] https://lkml.org/lkml/2012/7/19/285

Rob Clark (1):
  device: add dma_params-max_segment_count

Sumit Semwal (1):
  dma-buf: add helpers for sharing attacher constraints with dma-parms

 drivers/dma-buf/dma-buf.c   | 134 +++-
 include/linux/device.h  |   1 +
 include/linux/dma-buf.h |  22 
 include/linux/dma-mapping.h |  19 +++
 4 files changed, 175 insertions(+), 1 deletion(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv2 1/2] device: add dma_params-max_segment_count

[Sumit Semwal]

From: Rob Clark robdcl...@gmail.com

For devices which have constraints about maximum number of segments in
an sglist.  For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.

The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer.  The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.

Signed-off-by: Rob Clark robdcl...@gmail.com
 [sumits: Minor updates wrt comments on the first version]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 include/linux/device.h  |  1 +
 include/linux/dma-mapping.h | 19 +++
 2 files changed, 20 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index fb50673..a32f9b6 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
 * sg limitations.
 */
unsigned int max_segment_size;
+   unsigned int max_segment_count;/* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
 };
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb..38e2835 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct 
device *dev,
return -EIO;
 }
 
+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+   return dev-dma_parms ?
+   dev-dma_parms-max_segment_count :
+   DMA_SEGMENTS_MAX_SEG_COUNT;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+   unsigned int count)
+{
+   if (dev-dma_parms) {
+   dev-dma_parms-max_segment_count = count;
+   return 0;
+   } else
+   return -EIO;
+}
+
 static inline unsigned long dma_get_seg_boundary(struct device *dev)
 {
return dev-dma_parms ?
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/4] dma-buf: Add constraints sharing information

[Sumit Semwal]

Hi Daniel,

Thanks a bunch for your review comments! A few comments, post our
discussion at LPC;

On 12 October 2014 at 00:25, Daniel Vetter dan...@ffwll.ch wrote:
 On Sat, Oct 11, 2014 at 01:37:55AM +0530, Sumit Semwal wrote:
 At present, struct device lacks a mechanism of exposing memory
 access constraints for the device.

 Consequently, there is also no mechanism to share these constraints
 while sharing buffers using dma-buf.

 If we add support for sharing such constraints, we could use that
 to try to collect requirements of different buffer-sharing devices
 to allocate buffers from a pool that satisfies requirements of all
 such devices.

 This is an attempt to add this support; at the moment, only a bitmask
 is added, but if post discussion, we realise we need more information,
 we could always extend the definition of constraint.

 A new dma-buf op is also added, to allow exporters to interpret or decide
 on constraint-masks on their own. A default implementation is provided to
 just AND () all the constraint-masks.

 What constitutes a constraint-mask could be left for interpretation on a
 per-platform basis, while defining some common masks.

 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
 Cc: linux-ker...@vger.kernel.org
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: linux-media@vger.kernel.org
 Cc: dri-de...@lists.freedesktop.org
 Cc: linaro-mm-...@lists.linaro.org

 Just a few high-level comments, I'm between conference travel but
 hopefully I can discuss this a bit at plumbers next week.

 - I agree that for the insane specific cases we need something opaque like
   the access constraints mask you propose here. But for the normal case I
   think the existing dma constraints in dma_params would go a long way,
   and I think we should look at Rob's RFC from aeons ago to solve those:

   https://lkml.org/lkml/2012/7/19/285

   With this we should be able to cover the allocation constraints of 90%
   of all cases hopefully.

 - I'm not sure whether an opaque bitmask is good enough really, I suspect
   that we also need various priorities between different allocators. With
   the option that some allocators are flat-out incompatible.

Your/Rob's idea to figure out the constraints wrt max number of
segments in the sg_list can provide, like you said, maybe 80-90% of
the allocation constraints hopefully. The opaque mask should help for
the remaining 'crazy' cases, so I'll be glad to merge Rob's and my
approach on defining the constraints.

I should think a little bit more about the priority idea that you
propose here (and in another patch), but atm I am unable to see how
that could help solve the finding-out-constraints problem.

 - The big bummer imo with ION is that it fully side-steps, but this
   proposal here also seems to add entirely new allocators. My rough idea

This proposal does borrow this bit from ION, but once we have the
required changes done in the dma api itself, the allocators can just
become shims to the dma api allocators (eg dma_alloc_coherent etc) for
cases where they can be used directly, while leaving provision for any
crazy platform-specific allocators, without the userspace having to
worry about it.

   was that at allocate/attach time we iterate over all attached devices
   like in Rob's patch and compute the most constrained allocation
   requirements. Then we pick the underlying dma api allocator for these
   constraints. That probably means that we need to open up the dma api a
   bit. But I guess for a start we could simply try to allocate from the
   most constrained device. Together with the opaque bits you propose here
   we could even map additional crazy requirements like that an allocation
   must come from a specific memory bank (provided by a special-purpose CMA
   region). That might also mean that requirements are exclusive and no
   allocation is possible.

My idea was a little variation on what you said here - rather than do
compute the most constraint allocation 'after' devices have attached
(and right now, we don't really have a way to know that - but that's
another point), I'd proposed to do the compute on each attach request,
so the requesting drivers can know immediately if the attachment will
not work for the other currently attached devices.

 - I'm not sure we should allow drivers to override the access constraint
   checks really - the dma_buf interfaces already provide this possibility
   through the -attach callback. In there exporters are allowed to reject
   the attachment for any reason whatsover.

This override the access constraint check is again meant only as a
helper, but I could sure drop it.

 - I think we should at least provide a helper implementation to allocate
   dma-buffers for multiple devices using the dma constraints logic we
   implement here. I think we should even go as far as providing a default
   implementation for dma-bufs which uses dma_alloc_coherent and this new
   dma contstraints computation code

Re: [Linaro-mm-sig] [RFC 0/4] dma-buf Constraints-Enabled Allocation helpers

[Sumit Semwal]

Hi Laura,

On 13 October 2014 13:42, Laura Abbott lau...@codeaurora.org wrote:
 On 10/10/2014 1:07 PM, Sumit Semwal wrote:

 Hi,

 Why:
 
   While sharing buffers using dma-buf, currently there's no mechanism to
 let
 devices share their memory access constraints with each other to allow for
 delayed allocation of backing storage.

 This RFC attempts to introduce the idea of memory constraints of a device,
 and how these constraints can be shared and used to help allocate buffers
 that
 can satisfy requirements of all devices attached to a particular dma-buf.

 How:
 
   A constraints_mask is added to dma_parms of the device, and at the time
 of
 each device attachment to a dma-buf, the dma-buf uses this
 constraints_mask
 to calculate the access_mask for the dma-buf.

 Allocators can be defined for each of these constraints_masks, and then
 helper
 functions can be used to allocate the backing storage from the matching
 allocator satisfying the constraints of all devices interested.

 A new miscdevice, /dev/cenalloc [1] is created, which acts as the dma-buf
 exporter to make this transparent to the devices.

 More details in the patch description of cenalloc: Constraint-Enabled
 Allocation helpers for dma-buf.


 At present, the constraint_mask is only a bitmask, but it should be
 possible to
 change it to a struct and adapt the constraint_mask calculation
 accordingly,
 based on discussion.


 Important requirement:
 ==
   Of course, delayed allocation can only work if all participating devices
 will wait for other devices to have 'attached' before mapping the buffer
 for the first time.

 As of now, users of dma-buf(drm prime, v4l2 etc) call the attach() and
 then
 map_attachment() almost immediately after it. This would need to be
 changed if
 they were to benefit from constraints.


 What 'cenalloc' is not:
 ===
 - not 'general' allocator helpers - useful only for constraints-enabled
devices that share buffers with others using dma-buf.
 - not a replacement for existing allocation mechanisms inside various
subsystems; merely a possible alternative.
 - no page-migration - it would be very complementary to the delayed
 allocation
 suggested here.

 TODOs:
 ==
 - demonstration test cases
 - vma helpers for allocators
 - more sample allocators
 - userspace ioctl (It should be a simple one, and we have one ready, but
 wanted
 to agree on the kernel side of things first)



 I'm interested to see the userspace ioctl. The mask based approach of
 Ion does not scale well to a userspace ABI so I'm curious if cenalloc
 does better.
Apologies for the delay in response.
Since with cenalloc, the decision of 'which pool to allocate from' is
not with the userspace, but is calculated based on the devices that
attach, the userspace ABI should be just a simple xxx_create, which
returns an fd that'd be the dma-buf fd. That will allow easy sharing
with other dma-buf importers via standard dma-buf API.

 Thanks,
 Laura

 --
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
 hosted by The Linux Foundation



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf

[Sumit Semwal]

Hi Greg, Daniel!

On 12 October 2014 00:10, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Oct 10, 2014 at 04:09:00PM -0700, Greg Kroah-Hartman wrote:
 On Sat, Oct 11, 2014 at 01:37:56AM +0530, Sumit Semwal wrote:
  Devices sharing buffers using dma-buf could benefit from sharing their
  constraints via struct device, and dma-buf framework would manage the
  common constraints for all attached devices per buffer.
 
  With that information, we could have a 'generic' allocator helper in
  the form of a central dma-buf exporter, which can create dma-bufs, and
  allocate backing storage at the time of first call to
  dma_buf_map_attachment.
 
  This allocation would utilise the constraint-mask by matching it to
  the right allocator from a pool of allocators, and then allocating
  buffer backing storage from this allocator.
 
  The pool of allocators could be platform-dependent, allowing for
  platforms to hide the specifics of these allocators from the devices
  that access the dma-buf buffers.
 
  A sample sequence could be:
  - get handle to cenalloc_device,
  - create a dmabuf using cenalloc_buffer_create;
  - use this dmabuf to attach each device, which has its constraints
 set in the constraints mask (dev-dma_params-access_constraints_mask)
- at each dma_buf_attach() call, dma-buf will check to see if the 
  constraint
  mask for the device requesting attachment is compatible with the 
  constraints
  of devices already attached to the dma-buf; returns an error if it 
  isn't.
  - after all devices have attached, the first call to 
  dma_buf_map_attachment()
will allocate the backing storage for the buffer.
  - follow the dma-buf api for map / unmap etc usage.
  - detach all attachments,
  - call cenalloc_buffer_free to free the buffer if refcount reaches zero;
 
  ** IMPORTANT**
  This mechanism of delayed allocation based on constraint-enablement will 
  work
  *ONLY IF* the first map_attachment() call is made AFTER all attach() calls 
  are
  done.
 
  Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
  Cc: linux-ker...@vger.kernel.org
  Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
  Cc: linux-media@vger.kernel.org
  Cc: dri-de...@lists.freedesktop.org
  Cc: linaro-mm-...@lists.linaro.org
  ---
   MAINTAINERS  |   1 +
   drivers/cenalloc/cenalloc.c  | 597 
  +++
   drivers/cenalloc/cenalloc.h  |  99 +++
   drivers/cenalloc/cenalloc_priv.h | 188 
   4 files changed, 885 insertions(+)
   create mode 100644 drivers/cenalloc/cenalloc.c
   create mode 100644 drivers/cenalloc/cenalloc.h
   create mode 100644 drivers/cenalloc/cenalloc_priv.h
 
  diff --git a/MAINTAINERS b/MAINTAINERS
  index 40d4796..e88ac81 100644
  --- a/MAINTAINERS
  +++ b/MAINTAINERS
  @@ -3039,6 +3039,7 @@ L:linux-media@vger.kernel.org
   L: dri-de...@lists.freedesktop.org
   L: linaro-mm-...@lists.linaro.org
   F: drivers/dma-buf/
  +F: drivers/cenalloc/
   F: include/linux/dma-buf*
   F: include/linux/reservation.h
   F: include/linux/*fence.h
  diff --git a/drivers/cenalloc/cenalloc.c b/drivers/cenalloc/cenalloc.c
  new file mode 100644
  index 000..f278056
  --- /dev/null
  +++ b/drivers/cenalloc/cenalloc.c
  @@ -0,0 +1,597 @@
  +/*
  + * Allocator helper framework for constraints-aware dma-buf backing 
  storage
  + * allocation.
  + * This allows constraint-sharing devices to deferred-allocate buffers 
  shared
  + * via dma-buf.
  + *
  + * Copyright(C) 2014 Linaro Limited. All rights reserved.
  + * Author: Sumit Semwal sumit.sem...@linaro.org
  + *
  + * Structure for management of clients, buffers etc heavily derived from
  + * Android's ION framework.

 Does that mean we can drop ION after this gets merged?

 Yeah, I hope so. Not sure whetether this hope is shared by google android
 people ...
Apologies for the delay in response; was travelling for LPC and so
couldn't respond.

Yes, that is certainly the hope, but this is the first-step RFC which
would need a few more things before ION can be replaced completely.

 /me dreams

 I guess we can collectively dream about this next week at plumbers ;-)
 I'll try to squeeze in some light review of Sumit's patches between
 conference travels ...

 Cheers, Daniel
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linaro-mm-sig] [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf

[Sumit Semwal]

Hi Laura,


On 13 October 2014 14:05, Laura Abbott lau...@codeaurora.org wrote:
 On 10/10/2014 1:07 PM, Sumit Semwal wrote:

 Devices sharing buffers using dma-buf could benefit from sharing their
 constraints via struct device, and dma-buf framework would manage the
 common constraints for all attached devices per buffer.

 With that information, we could have a 'generic' allocator helper in
 the form of a central dma-buf exporter, which can create dma-bufs, and
 allocate backing storage at the time of first call to
 dma_buf_map_attachment.

 This allocation would utilise the constraint-mask by matching it to
 the right allocator from a pool of allocators, and then allocating
 buffer backing storage from this allocator.

 The pool of allocators could be platform-dependent, allowing for
 platforms to hide the specifics of these allocators from the devices
 that access the dma-buf buffers.

 A sample sequence could be:
 - get handle to cenalloc_device,
 - create a dmabuf using cenalloc_buffer_create;
 - use this dmabuf to attach each device, which has its constraints
 set in the constraints mask (dev-dma_params-access_constraints_mask)
- at each dma_buf_attach() call, dma-buf will check to see if the
 constraint
  mask for the device requesting attachment is compatible with the
 constraints
  of devices already attached to the dma-buf; returns an error if it
 isn't.
 - after all devices have attached, the first call to
 dma_buf_map_attachment()
will allocate the backing storage for the buffer.
 - follow the dma-buf api for map / unmap etc usage.
 - detach all attachments,
 - call cenalloc_buffer_free to free the buffer if refcount reaches zero;

 ** IMPORTANT**
 This mechanism of delayed allocation based on constraint-enablement will
 work
 *ONLY IF* the first map_attachment() call is made AFTER all attach() calls
 are
 done.


 My first instinct is 'I wonder which drivers will call map_attachment at
 the wrong time and screw things up'. Are there any plans for
 synchronization and/or debugging output to catch drivers violating this
 requirement?

Well, of course you're right - at the moment, no mechanism to do so.
That will certainly be the next step - we could discuss it sometime
this week at LPC to see what makes better sense.

 [...]

 +int cenalloc_phys(struct dma_buf *dmabuf,
 +phys_addr_t *addr, size_t *len)
 +{
 +   struct cenalloc_buffer *buffer;
 +   int ret;
 +
 +   if (is_cenalloc_buffer(dmabuf))
 +   buffer = (struct cenalloc_buffer *)dmabuf-priv;
 +   else
 +   return -EINVAL;
 +
 +   if (!buffer-allocator-ops-phys) {
 +   pr_err(%s: cenalloc_phys is not implemented by this
 allocator.\n,
 +  __func__);
 +   return -ENODEV;
 +   }
 +   mutex_lock(buffer-lock);
 +   ret = buffer-allocator-ops-phys(buffer-allocator, buffer,
 addr,
 +   len);
 +   mutex_lock(buffer-lock);
 +   return ret;
 +}
 +EXPORT_SYMBOL_GPL(cenalloc_phys);
 +


 The .phys operation makes it difficult to have drivers which can
 handle both contiguous and non contiguous memory (too much special
 casing). Any chance we could drop this API and just have drivers
 treat an sg_table with 1 entry as contiguous memory?
I am not sure I understand how having a .phys makes it more difficult
- and also, for cases where you're sharing buffers between CPU and a
co-processor like DSP, my understanding is that we'd need an
equivalent of a phys address.


 Thanks,
 Laura

 --
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
 hosted by The Linux Foundation



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 4/4] cenalloc: a sample allocator for contiguous page allocation

[Sumit Semwal]

From: Benjamin Gaignard benjamin.gaign...@linaro.org

Signed-off-by: Benjamin Gaignard benjamin.gaign...@linaro.org
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Cc: linux-ker...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/cenalloc/Makefile |   2 +-
 drivers/cenalloc/cenalloc_system_contig.c | 225 ++
 2 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 drivers/cenalloc/cenalloc_system_contig.c

diff --git a/drivers/cenalloc/Makefile b/drivers/cenalloc/Makefile
index d36b531..2f69b61 100644
--- a/drivers/cenalloc/Makefile
+++ b/drivers/cenalloc/Makefile
@@ -1,3 +1,3 @@
 # Makefile for the cenalloc helper
 
-obj-y  += cenalloc.o
+obj-y  += cenalloc.o cenalloc_system_contig.o
diff --git a/drivers/cenalloc/cenalloc_system_contig.c 
b/drivers/cenalloc/cenalloc_system_contig.c
new file mode 100644
index 000..ecf0c03
--- /dev/null
+++ b/drivers/cenalloc/cenalloc_system_contig.c
@@ -0,0 +1,225 @@
+/*
+ * central allocator using kmalloc
+ *
+ * Copyright(C) 2014 Linaro Limited. All rights reserved.
+ * Author: Benjamin Gaignard benjamin.gaign...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include asm/page.h
+#include linux/dma-mapping.h
+#include linux/err.h
+#include linux/highmem.h
+#include linux/mm.h
+#include linux/scatterlist.h
+#include linux/seq_file.h
+#include linux/slab.h
+#include linux/vmalloc.h
+
+#include cenalloc_priv.h
+
+static gfp_t low_order_gfp_flags  = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN);
+
+void cenalloc_pages_sync_for_device(struct device *dev, struct page *page,
+   size_t size, enum dma_data_direction dir)
+{
+   struct scatterlist sg;
+
+   sg_init_table(sg, 1);
+   sg_set_page(sg, page, size, 0);
+   /*
+* This is not correct - sg_dma_address needs a dma_addr_t that is valid
+* for the the targeted device, but this works on the currently targeted
+* hardware.
+*/
+   sg_dma_address(sg) = page_to_phys(page);
+   dma_sync_sg_for_device(dev, sg, 1, dir);
+}
+
+static int cenalloc_system_contig_allocate(struct cenalloc_allocator 
*allocator,
+   struct cenalloc_buffer *buffer, unsigned long len,
+   unsigned long align, unsigned long flags)
+{
+   int order = get_order(len);
+   struct page *page;
+   struct sg_table *table;
+   unsigned long i;
+   int ret;
+
+   if (align  (PAGE_SIZE  order))
+   return -EINVAL;
+
+   page = alloc_pages(low_order_gfp_flags, order);
+   if (!page)
+   return -ENOMEM;
+
+   split_page(page, order);
+
+   len = PAGE_ALIGN(len);
+   for (i = len  PAGE_SHIFT; i  (1  order); i++)
+   __free_page(page + i);
+
+   table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+   if (!table) {
+   ret = -ENOMEM;
+   goto free_pages;
+   }
+
+   ret = sg_alloc_table(table, 1, GFP_KERNEL);
+   if (ret)
+   goto free_table;
+
+   sg_set_page(table-sgl, page, len, 0);
+
+   buffer-sg_table = table;
+
+   cenalloc_pages_sync_for_device(NULL, page, len, DMA_BIDIRECTIONAL);
+
+   return 0;
+
+free_table:
+   kfree(table);
+free_pages:
+   for (i = 0; i  len  PAGE_SHIFT; i++)
+   __free_page(page + i);
+
+   return ret;
+
+}
+
+static void cenalloc_system_contig_free(struct cenalloc_buffer *buffer)
+{
+   struct sg_table *table = buffer-sg_table;
+   struct page *page = sg_page(table-sgl);
+   unsigned long pages = PAGE_ALIGN(buffer-size)  PAGE_SHIFT;
+   unsigned long i;
+
+   for (i = 0; i  pages; i++)
+   __free_page(page + i);
+   sg_free_table(table);
+   kfree(table);
+}
+
+static struct sg_table *cenalloc_system_contig_map_dma
+   (struct cenalloc_allocator *allocator, struct cenalloc_buffer *buffer)
+{
+   return buffer-sg_table;
+}
+
+static void cenalloc_system_contig_unmap_dma
+   (struct cenalloc_allocator *allocator, struct cenalloc_buffer *buffer)
+{
+
+}
+
+static void *cenalloc_system_contig_map_kernel
+   (struct cenalloc_allocator *allocator, struct cenalloc_buffer *buffer)
+{
+   struct

[RFC 1/4] dma-buf: Add constraints sharing information

[Sumit Semwal]

At present, struct device lacks a mechanism of exposing memory
access constraints for the device.

Consequently, there is also no mechanism to share these constraints
while sharing buffers using dma-buf.

If we add support for sharing such constraints, we could use that
to try to collect requirements of different buffer-sharing devices
to allocate buffers from a pool that satisfies requirements of all
such devices.

This is an attempt to add this support; at the moment, only a bitmask
is added, but if post discussion, we realise we need more information,
we could always extend the definition of constraint.

A new dma-buf op is also added, to allow exporters to interpret or decide
on constraint-masks on their own. A default implementation is provided to
just AND () all the constraint-masks.

What constitutes a constraint-mask could be left for interpretation on a
per-platform basis, while defining some common masks.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Cc: linux-ker...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 50 ++-
 include/linux/device.h|  7 ++-
 include/linux/dma-buf.h   | 14 +
 3 files changed, 65 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f3014c4..33bdb6a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -264,6 +264,30 @@ static inline int is_dma_buf_file(struct file *file)
return file-f_op == dma_buf_fops;
 }
 
+/*
+ * def_calc_access_constraints - default implementation of constraint checking
+ */
+static int def_calc_access_constraints(struct dma_buf *dmabuf,
+   struct dma_buf_attachment *attach)
+{
+   unsigned long access_mask;
+
+   access_mask = attach-dev-dma_parms-access_constraints_mask;
+
+   if (!access_mask) {
+   pr_warn(%s dev has no access_constraints_mask; using 
default\n,
+   dev_name(attach-dev));
+access_mask = DMA_BUF_ALL_MEMORY_ACCESS_MASK;
+   }
+
+   dmabuf-access_constraints_mask = access_mask;
+
+   if (!dmabuf-access_constraints_mask)
+   return -EINVAL;
+
+   return 0;
+}
+
 /**
  * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
@@ -313,6 +337,8 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf-ops = ops;
dmabuf-size = size;
dmabuf-exp_name = exp_name;
+   dmabuf-access_constraints_mask = DMA_BUF_ALL_MEMORY_ACCESS_MASK;
+
init_waitqueue_head(dmabuf-poll);
dmabuf-cb_excl.poll = dmabuf-cb_shared.poll = dmabuf-poll;
dmabuf-cb_excl.active = dmabuf-cb_shared.active = 0;
@@ -410,8 +436,10 @@ void dma_buf_put(struct dma_buf *dmabuf)
 EXPORT_SYMBOL_GPL(dma_buf_put);
 
 /**
- * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
- * calls attach() of dma_buf_ops to allow device-specific attach functionality
+ * dma_buf_attach - Add the device to dma_buf's attachments list;
+ * calculates access_constraints and throws error if constraints aren't
+ * satisfied. Optionally, calls attach() of dma_buf_ops to allow
+ * device-specific attach functionality.
  * @dmabuf:[in]buffer to attach device to.
  * @dev:   [in]device to be attached.
  *
@@ -436,11 +464,20 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
 
mutex_lock(dmabuf-lock);
 
+   if (!dmabuf-ops-calc_access_constraints)
+   ret = def_calc_access_constraints(dmabuf, attach);
+   else
+   ret = dmabuf-ops-calc_access_constraints(dmabuf, attach);
+
+   if (ret)
+   goto err_attach;
+
if (dmabuf-ops-attach) {
ret = dmabuf-ops-attach(dmabuf, dev, attach);
if (ret)
goto err_attach;
}
+
list_add(attach-node, dmabuf-attachments);
 
mutex_unlock(dmabuf-lock);
@@ -785,7 +822,7 @@ static int dma_buf_describe(struct seq_file *s)
return ret;
 
seq_puts(s, \nDma-buf Objects:\n);
-   seq_puts(s, size\tflags\tmode\tcount\texp_name\n);
+   seq_puts(s, size\tflags\tmode\tcount\tconstraints\texp_name\n);
 
list_for_each_entry(buf_obj, db_list.head, list_node) {
ret = mutex_lock_interruptible(buf_obj-lock);
@@ -796,10 +833,11 @@ static int dma_buf_describe(struct seq_file *s)
continue;
}
 
-   seq_printf(s, %08zu\t%08x\t%08x\t%08ld\t%s\n,
+   seq_printf(s, %08zu\t%08x\t%08x\t%08ld\t%08lx\t%s\n,
buf_obj-size,
buf_obj-file-f_flags, buf_obj-file-f_mode

[RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf

[Sumit Semwal]

Devices sharing buffers using dma-buf could benefit from sharing their
constraints via struct device, and dma-buf framework would manage the
common constraints for all attached devices per buffer.

With that information, we could have a 'generic' allocator helper in
the form of a central dma-buf exporter, which can create dma-bufs, and
allocate backing storage at the time of first call to
dma_buf_map_attachment.

This allocation would utilise the constraint-mask by matching it to
the right allocator from a pool of allocators, and then allocating
buffer backing storage from this allocator.

The pool of allocators could be platform-dependent, allowing for
platforms to hide the specifics of these allocators from the devices
that access the dma-buf buffers.

A sample sequence could be:
- get handle to cenalloc_device,
- create a dmabuf using cenalloc_buffer_create;
- use this dmabuf to attach each device, which has its constraints
   set in the constraints mask (dev-dma_params-access_constraints_mask)
  - at each dma_buf_attach() call, dma-buf will check to see if the constraint
mask for the device requesting attachment is compatible with the constraints
of devices already attached to the dma-buf; returns an error if it isn't.
- after all devices have attached, the first call to dma_buf_map_attachment()
  will allocate the backing storage for the buffer.
- follow the dma-buf api for map / unmap etc usage.
- detach all attachments,
- call cenalloc_buffer_free to free the buffer if refcount reaches zero;

** IMPORTANT**
This mechanism of delayed allocation based on constraint-enablement will work
*ONLY IF* the first map_attachment() call is made AFTER all attach() calls are
done.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Cc: linux-ker...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 MAINTAINERS  |   1 +
 drivers/cenalloc/cenalloc.c  | 597 +++
 drivers/cenalloc/cenalloc.h  |  99 +++
 drivers/cenalloc/cenalloc_priv.h | 188 
 4 files changed, 885 insertions(+)
 create mode 100644 drivers/cenalloc/cenalloc.c
 create mode 100644 drivers/cenalloc/cenalloc.h
 create mode 100644 drivers/cenalloc/cenalloc_priv.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 40d4796..e88ac81 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3039,6 +3039,7 @@ L:linux-media@vger.kernel.org
 L: dri-de...@lists.freedesktop.org
 L: linaro-mm-...@lists.linaro.org
 F: drivers/dma-buf/
+F: drivers/cenalloc/
 F: include/linux/dma-buf*
 F: include/linux/reservation.h
 F: include/linux/*fence.h
diff --git a/drivers/cenalloc/cenalloc.c b/drivers/cenalloc/cenalloc.c
new file mode 100644
index 000..f278056
--- /dev/null
+++ b/drivers/cenalloc/cenalloc.c
@@ -0,0 +1,597 @@
+/*
+ * Allocator helper framework for constraints-aware dma-buf backing storage
+ * allocation.
+ * This allows constraint-sharing devices to deferred-allocate buffers shared
+ * via dma-buf.
+ *
+ * Copyright(C) 2014 Linaro Limited. All rights reserved.
+ * Author: Sumit Semwal sumit.sem...@linaro.org
+ *
+ * Structure for management of clients, buffers etc heavily derived from
+ * Android's ION framework.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/file.h
+#include linux/fs.h
+#include linux/miscdevice.h
+#include linux/rbtree.h
+#include linux/slab.h
+#include linux/vmalloc.h
+#include linux/debugfs.h
+#include linux/module.h
+
+#include cenalloc.h
+#include cenalloc_priv.h
+
+/*
+ * Constraints-aware allocator framework helper is meant to facilitate
+ * deferred allocation of backing storage for dma-buf buffers.
+ * It works for devices that can share their constraints via dma_params.
+ * These dma_params are then used by dma_buf_attach() to create a mask of
+ * common constraints. The cenalloc constraint helpers then allocate
+ * for the preferred allocator according to the constraint mask.
+ * Allocators and their corresponding constraint masks are pre-populated
+ * for a given system - likely at the time of platform initialization.
+ */
+/**
+ * struct cenalloc_device - the metadata of the cenalloc device node
+ * @dev:   the actual misc device
+ * @buffers:   an rb tree of all

[RFC 0/4] dma-buf Constraints-Enabled Allocation helpers

[Sumit Semwal]

Hi,

Why:

 While sharing buffers using dma-buf, currently there's no mechanism to let
devices share their memory access constraints with each other to allow for
delayed allocation of backing storage.

This RFC attempts to introduce the idea of memory constraints of a device,
and how these constraints can be shared and used to help allocate buffers that
can satisfy requirements of all devices attached to a particular dma-buf.

How:

 A constraints_mask is added to dma_parms of the device, and at the time of
each device attachment to a dma-buf, the dma-buf uses this constraints_mask
to calculate the access_mask for the dma-buf.

Allocators can be defined for each of these constraints_masks, and then helper
functions can be used to allocate the backing storage from the matching
allocator satisfying the constraints of all devices interested.

A new miscdevice, /dev/cenalloc [1] is created, which acts as the dma-buf
exporter to make this transparent to the devices.

More details in the patch description of cenalloc: Constraint-Enabled
Allocation helpers for dma-buf.


At present, the constraint_mask is only a bitmask, but it should be possible to
change it to a struct and adapt the constraint_mask calculation accordingly,
based on discussion.


Important requirement:
==
 Of course, delayed allocation can only work if all participating devices 
will wait for other devices to have 'attached' before mapping the buffer
for the first time.

As of now, users of dma-buf(drm prime, v4l2 etc) call the attach() and then
map_attachment() almost immediately after it. This would need to be changed if
they were to benefit from constraints.


What 'cenalloc' is not:
===
- not 'general' allocator helpers - useful only for constraints-enabled
  devices that share buffers with others using dma-buf.
- not a replacement for existing allocation mechanisms inside various
  subsystems; merely a possible alternative.
- no page-migration - it would be very complementary to the delayed allocation
   suggested here.

TODOs: 
==
- demonstration test cases
- vma helpers for allocators
- more sample allocators
- userspace ioctl (It should be a simple one, and we have one ready, but wanted
   to agree on the kernel side of things first)


May the brickbats begin, please! :)

Best regards,
~Sumit.

[1]: 'C'onstraints 'EN'abled 'ALLOC'ation helpers = cenalloc: it might not be a
very appealing name, so suggestions are very welcome!


Benjamin Gaignard (1):
  cenalloc: a sample allocator for contiguous page allocation

Sumit Semwal (3):
  dma-buf: Add constraints sharing information
  cenalloc: Constraint-Enabled Allocation helpers for dma-buf
  cenalloc: Build files for constraint-enabled allocation helpers

 MAINTAINERS   |   1 +
 drivers/Kconfig   |   2 +
 drivers/Makefile  |   1 +
 drivers/cenalloc/Kconfig  |   8 +
 drivers/cenalloc/Makefile |   3 +
 drivers/cenalloc/cenalloc.c   | 597 ++
 drivers/cenalloc/cenalloc.h   |  99 +
 drivers/cenalloc/cenalloc_priv.h  | 188 ++
 drivers/cenalloc/cenalloc_system_contig.c | 225 +++
 drivers/dma-buf/dma-buf.c |  50 ++-
 include/linux/device.h|   7 +-
 include/linux/dma-buf.h   |  14 +
 12 files changed, 1189 insertions(+), 6 deletions(-)
 create mode 100644 drivers/cenalloc/Kconfig
 create mode 100644 drivers/cenalloc/Makefile
 create mode 100644 drivers/cenalloc/cenalloc.c
 create mode 100644 drivers/cenalloc/cenalloc.h
 create mode 100644 drivers/cenalloc/cenalloc_priv.h
 create mode 100644 drivers/cenalloc/cenalloc_system_contig.c

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 3/4] cenalloc: Build files for constraint-enabled allocation helpers

[Sumit Semwal]

Add the build files for cenalloc, the constraints-enabled allocation
helper framework for dma-buf.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Cc: linux-ker...@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/Kconfig   | 2 ++
 drivers/Makefile  | 1 +
 drivers/cenalloc/Kconfig  | 8 
 drivers/cenalloc/Makefile | 3 +++
 4 files changed, 14 insertions(+)
 create mode 100644 drivers/cenalloc/Kconfig
 create mode 100644 drivers/cenalloc/Makefile

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 1a693d3..f40d2ce 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -182,4 +182,6 @@ source drivers/ras/Kconfig
 
 source drivers/thunderbolt/Kconfig
 
+source drivers/cenalloc/Kconfig
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index ebee555..a04e516 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -161,3 +161,4 @@ obj-$(CONFIG_POWERCAP)  += powercap/
 obj-$(CONFIG_MCB)  += mcb/
 obj-$(CONFIG_RAS)  += ras/
 obj-$(CONFIG_THUNDERBOLT)  += thunderbolt/
+obj-$(CONFIG_CENALLOC)  += cenalloc/
diff --git a/drivers/cenalloc/Kconfig b/drivers/cenalloc/Kconfig
new file mode 100644
index 000..9472d5d
--- /dev/null
+++ b/drivers/cenalloc/Kconfig
@@ -0,0 +1,8 @@
+menuconfig CENALLOC
+   bool cenalloc helper functions
+   default n
+   select ANON_INODES
+   help
+ This option enables the helper allocation framework for drivers using
+ dma-buf buffer-sharing. It uses constraints of participating devices
+ to help find out best suited allocator.
diff --git a/drivers/cenalloc/Makefile b/drivers/cenalloc/Makefile
new file mode 100644
index 000..d36b531
--- /dev/null
+++ b/drivers/cenalloc/Makefile
@@ -0,0 +1,3 @@
+# Makefile for the cenalloc helper
+
+obj-y  += cenalloc.o
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: few dma-buf updates for 3.17-rc3

[Sumit Semwal]

Hi Linus,

The major changes for 3.17 already went via Greg-KH's tree this time
as well; this is a small pull request for dma-buf - all documentation
related.

Could you please pull?


The following changes since commit f1bd473f95e02bc382d4dae94d7f82e2a455e05d:

  Merge branch 'sec-v3.17-rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security
(2014-08-27 17:32:37 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/for-3.17-rc3

for you to fetch changes up to 1f58d9465c568eb47cab939bbc4f30ae51863295:

  dma-buf/fence: Fix one more kerneldoc warning (2014-08-28 11:59:38 +0530)


Small dma-buf pull request for 3.17-rc3


Gioh Kim (1):
  Documentation/dma-buf-sharing.txt: update API descriptions

Thierry Reding (2):
  dma-buf/fence: Fix a kerneldoc warning
  dma-buf/fence: Fix one more kerneldoc warning

 Documentation/dma-buf-sharing.txt | 14 --
 drivers/dma-buf/fence.c   |  2 +-
 include/linux/seqno-fence.h   |  1 +
 3 files changed, 10 insertions(+), 7 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/9] Updated fence patch series

[Sumit Semwal]

On 8 July 2014 20:09, Greg KH gre...@linuxfoundation.org wrote:
 On Tue, Jul 08, 2014 at 03:44:27PM +0200, Daniel Vetter wrote:
 On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote:
  On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote:
   On Wed, Jul 2, 2014 at 7:37 AM, Greg KH gre...@linuxfoundation.org 
   wrote:
Android can expose fences to userspace. It's possible to make the new 
fence
mechanism expose the same fences to userspace by changing 
sync_fence_create
to take a struct fence instead of a struct sync_pt. No other change 
is needed,
because only the fence parts of struct sync_pt are used. But because 
the
userspace fences are a separate problem and I haven't really looked 
at it yet
I feel it should stay in staging, for now.
   
Ok, that's reasonable.
   
At first glance, this all looks sane to me, any objection from anyone
if I merge this through my driver-core tree for 3.17?
  
   Ack from my side fwiw.
 
  Thanks, I'll queue it up later today.

 btw should we add you as a (co)maintainer for driver/core/dma-buf since
 you seem to want to keep a closer tab on what the insane gfx folks are up
 to in there?

 Sure, why not, what's one more maintainership...

 Oh, does that mean you want me to be the one collecting the patches and
 forwarding them on to Linus?  If so, that's fine, I can easily do that
 as well due to my infrastructure being set up for it.

If you're ok, I could continue to do the collecting / forwarding
business - I guess Daniel meant more from the 'not miss patches that
need review'!

Upto you!
 thanks,

 greg k-h
Thanks and best regards,
~Sumit


-- 
Thanks and regards,

Sumit Semwal
Graphics Engineer - Graphics working group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/9] Updated fence patch series

[Sumit Semwal]

Hi Greg,

On 2 July 2014 11:07, Greg KH gre...@linuxfoundation.org wrote:
 On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote:
 So after some more hacking I've moved dma-buf to its own subdirectory,
 drivers/dma-buf and applied the fence patches to its new place. I believe 
 that the
 first patch should be applied regardless, and the rest should be ready now.
 :-)

 Changes to the fence api:
 - release_fence - fence_release etc.
 - __fence_init - fence_init
 - __fence_signal - fence_signal_locked
 - __fence_is_signaled - fence_is_signaled_locked
 - Changing BUG_ON to WARN_ON in fence_later, and return NULL if it triggers.

 Android can expose fences to userspace. It's possible to make the new fence
 mechanism expose the same fences to userspace by changing sync_fence_create
 to take a struct fence instead of a struct sync_pt. No other change is 
 needed,
 because only the fence parts of struct sync_pt are used. But because the
 userspace fences are a separate problem and I haven't really looked at it yet
 I feel it should stay in staging, for now.

 Ok, that's reasonable.

 At first glance, this all looks sane to me, any objection from anyone
 if I merge this through my driver-core tree for 3.17?

Fwiw, Ack from me as well!
 thanks,

 greg k-h
Best regards,
~Sumit.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Sumit Semwal]

 compiler bitfields to flags, change return type of
 enable_signaling to bool. Rework dma_fence_wait. Added
 dma_fence_is_signaled and dma_fence_wait_timeout.
 s/dma// and change exports to non GPL. Added fence_is_signaled and
 fence_enable_sw_signaling calls, add ability to override default
 wait operation.
 v10: remove event_queue, use a custom list, export try_to_wake_up from
 scheduler. Remove fence lock and use a global spinlock instead,
 this should hopefully remove all the locking headaches I was having
 on trying to implement this. enable_signaling is called with this
 lock held.
 v11:
 Use atomic ops for flags, lifting the need for some spin_lock_irqsaves.
 However I kept the guarantee that after fence_signal returns, it is
 guaranteed that enable_signaling has either been called to completion,
 or will not be called any more.

 Add contexts and seqno to base fence implementation. This allows you
 to wait for less fences, by testing for seqno + signaled, and then only
 wait on the later fence.

 Add FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
 An CONFIG_DEBUG_FENCE will be added to turn off the FENCE_TRACE
 spam, and another runtime option can turn it off at runtime.
 v12:
 Add CONFIG_FENCE_TRACE. Add missing documentation for the fence-context
 and fence-seqno members.
 v13:
 Fixup CONFIG_FENCE_TRACE kconfig description.
 Move fence_context_alloc to fence.
 Simplify fence_later.
 Kill priv member to fence_cb.
 v14:
 Remove priv argument from fence_add_callback, oops!
 v15:
 Remove priv from documentation.
 Explicitly include linux/atomic.h.
 v16:
 Add trace events.
 Import changes required by android syncpoints.
 v17:
 Use wake_up_state instead of try_to_wake_up. (Colin Cross)
 Fix up commit description for seqno_fence. (Rob Clark)

 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
 Signed-off-by: Thierry Reding thierry.red...@gmail.com #use 
 smp_mb__before_atomic()
 Reviewed-by: Rob Clark robdcl...@gmail.com
 ---
  Documentation/DocBook/device-drivers.tmpl |2
  drivers/base/Kconfig  |9 +
  drivers/base/Makefile |2
  drivers/base/fence.c  |  416 
 +
  include/linux/fence.h |  333 +++
  include/trace/events/fence.h  |  128 +
  6 files changed, 889 insertions(+), 1 deletion(-)
  create mode 100644 drivers/base/fence.c
  create mode 100644 include/linux/fence.h
  create mode 100644 include/trace/events/fence.h

 Who is going to sign up to maintain this code?  (hint, it's not me...)

 that would be Sumit (dma-buf tree)..

 probably we should move fence/reservation/dma-buf into drivers/dma-buf
 (or something approximately like that)
Yes, that would be me - it might be better to create a new directory
as suggested above (drivers/dma-buf).

 BR,
 -R


 thanks,

 greg k-h
Best regards,
~Sumit.


-- 
Thanks and regards,

Sumit Semwal
Graphics Engineer - Graphics working group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Sumit Semwal]

On 19 June 2014 10:24, Greg KH gre...@linuxfoundation.org wrote:
 On Thu, Jun 19, 2014 at 09:57:35AM +0530, Sumit Semwal wrote:
 Hi Greg,


 
  Who is going to sign up to maintain this code?  (hint, it's not me...)
 
  that would be Sumit (dma-buf tree)..
 
  probably we should move fence/reservation/dma-buf into drivers/dma-buf
  (or something approximately like that)
 Yes, that would be me - it might be better to create a new directory
 as suggested above (drivers/dma-buf).

 That's fine with me, there is going to be more than just one file in
 there, right?  :)

 greg k-h
Certainly atleast 3 :)

~sumit
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

[Sumit Semwal]

Hi Bjorn,

On 21 May 2014 04:50, Bjorn Helgaas bhelg...@google.com wrote:
 On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote:
 Update some descriptions for API arguments and descriptions.

 Signed-off-by: Gioh Kim gioh@lge.com

 I applied this to my dma-api branch for v3.16, thanks!
As always, I would queue this up for my dma-buf pull request, along
with other dma-buf changes.

Thanks and best regards,
~Sumit.

 ---
  Documentation/dma-buf-sharing.txt |   14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

 diff --git a/Documentation/dma-buf-sharing.txt 
 b/Documentation/dma-buf-sharing.txt
 index 505e711..aadd901 100644
 --- a/Documentation/dma-buf-sharing.txt
 +++ b/Documentation/dma-buf-sharing.txt
 @@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the 
 following steps:
size_t size, int flags,
const char *exp_name)

 -   If this succeeds, dma_buf_export allocates a dma_buf structure, and 
 returns a
 -   pointer to the same. It also associates an anonymous file with this 
 buffer,
 -   so it can be exported. On failure to allocate the dma_buf object, it 
 returns
 -   NULL.
 +   If this succeeds, dma_buf_export_named allocates a dma_buf structure, and
 +   returns a pointer to the same. It also associates an anonymous file with 
 this
 +   buffer, so it can be exported. On failure to allocate the dma_buf object,
 +   it returns NULL.

 'exp_name' is the name of exporter - to facilitate information while
 debugging.
 @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the 
 following steps:
 drivers and/or processes.

 Interface:
 -  int dma_buf_fd(struct dma_buf *dmabuf)
 +  int dma_buf_fd(struct dma_buf *dmabuf, int flags)

 This API installs an fd for the anonymous file associated with this 
 buffer;
 returns either 'fd', or error.
 @@ -157,7 +157,9 @@ to request use of buffer for allocation.
 dma_buf-ops- indirection from the users of this interface.

 In struct dma_buf_ops, unmap_dma_buf is defined as
 -  void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
 +  void (*unmap_dma_buf)(struct dma_buf_attachment *,
 +struct sg_table *,
 +enum dma_data_direction);

 unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
 map_dma_buf, this API also must be implemented by the exporter.
 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/



-- 
Thanks and regards,

Sumit Semwal
Graphics Engineer - Graphics working group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: dma-buf updates for 3.14

[Sumit Semwal]

Hi Linus,

Here's another tiny pull request for dma-buf framework updates; just
some debugfs output updates. (There's another patch related to
dma-buf, but it'll get upstreamed via Greg-kh's pull request).

Could you please pull?

The following changes since commit 45f7fdc2ffb9d5af4dab593843e89da70d1259e3:

  Merge branch 'merge' of
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2014-02-11
22:28:47 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-3.14

for you to fetch changes up to c0b00a525c127d0055c1df6283300e17f601a1a1:

  dma-buf: update debugfs output (2014-02-13 10:08:52 +0530)


Small dma-buf pull request for 3.14


Sumit Semwal (1):
  dma-buf: update debugfs output

 drivers/base/dma-buf.c  | 25 -
 include/linux/dma-buf.h |  2 +-
 2 files changed, 13 insertions(+), 14 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dma-buf: update debugfs output

[Sumit Semwal]

Russell King observed 'wierd' looking output from debugfs, and also suggested
better ways of getting device names (use KBUILD_MODNAME, dev_name())

This patch addresses these issues to make the debugfs output correct and better
looking.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 drivers/base/dma-buf.c  | 18 --
 include/linux/dma-buf.h |  2 +-
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index cfe1d8b..bf89fe3 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -621,7 +621,7 @@ static int dma_buf_describe(struct seq_file *s)
return ret;
 
seq_printf(s, \nDma-buf Objects:\n);
-   seq_printf(s, \texp_name\tsize\tflags\tmode\tcount\n);
+   seq_printf(s, size\tflags\tmode\tcount\texp_name\n);
 
list_for_each_entry(buf_obj, db_list.head, list_node) {
ret = mutex_lock_interruptible(buf_obj-lock);
@@ -632,24 +632,22 @@ static int dma_buf_describe(struct seq_file *s)
continue;
}
 
-   seq_printf(s, \t);
-
-   seq_printf(s, \t%s\t%08zu\t%08x\t%08x\t%08ld\n,
-   buf_obj-exp_name, buf_obj-size,
+   seq_printf(s, %08zu\t%08x\t%08x\t%08ld\t%s\n,
+   buf_obj-size,
buf_obj-file-f_flags, buf_obj-file-f_mode,
-   (long)(buf_obj-file-f_count.counter));
+   (long)(buf_obj-file-f_count.counter), 
buf_obj-exp_name);
 
-   seq_printf(s, \t\tAttached Devices:\n);
+   seq_printf(s, \tAttached Devices:\n);
attach_count = 0;
 
list_for_each_entry(attach_obj, buf_obj-attachments, node) {
-   seq_printf(s, \t\t);
+   seq_printf(s, \t);
 
-   seq_printf(s, %s\n, attach_obj-dev-init_name);
+   seq_printf(s, %s\n, dev_name(attach_obj-dev));
attach_count++;
}
 
-   seq_printf(s, \n\t\tTotal %d devices attached\n,
+   seq_printf(s, \nTotal %d devices attached\n,
attach_count);
 
count++;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index dfac5ed..f886985 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -171,7 +171,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
   size_t size, int flags, const char *);
 
 #define dma_buf_export(priv, ops, size, flags) \
-   dma_buf_export_named(priv, ops, size, flags, __FILE__)
+   dma_buf_export_named(priv, ops, size, flags, KBUILD_MODNAME)
 
 int dma_buf_fd(struct dma_buf *dmabuf, int flags);
 struct dma_buf *dma_buf_get(int fd);
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL]: dma-buf updates for 3.12

[Sumit Semwal]

Hi Linus.

Sincere apologies for the html post; this request is now in
plain-text. (it has been convenient using the gmail interface, but I
promise this is the last time you'll see a non-plain-text email from
me.

Apologies again!

Best regards,
~Sumit.

On 11 September 2013 17:07, Sumit Semwal sumit.sem...@linaro.org wrote:
 Hi Linus,

 Here's the 3.12 pull request for dma-buf framework updates. Its yet another
 small one - dma-buf framework now supports size discovery of the buffer via
 llseek.

 Could you please pull?

 Thanks and best regards,
 ~Sumit.


 The following changes since commit 26b0332e30c7f93e780aaa054bd84e3437f84354:

   Merge tag 'dmaengine-3.12' of
 git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine (2013-09-09
 18:07:15 -0700)

 are available in the git repository at:


   git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/for-3.12

 for you to fetch changes up to 19e8697ba45e7bcdb04f2adf6110fbf4882863e5:

   dma-buf: Expose buffer size to userspace (v2) (2013-09-10 11:36:45 +0530)

 
 dma-buf updates for 3.12

 
 Christopher James Halse Rogers (1):
   dma-buf: Expose buffer size to userspace (v2)

 Tuomas Tynkkynen (1):
   dma-buf: Check return value of anon_inode_getfile

  Documentation/dma-buf-sharing.txt | 12 
  drivers/base/dma-buf.c| 32 
  2 files changed, 44 insertions(+)

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: dma-buf updates for 3.10

[Sumit Semwal]

Hi Linus,

The 3.10 pull request for dma-buf framework updates: small one, could
you please pull?

Thanks and best regards,
~Sumit.


The following changes since commit 5f56886521d6ddd3648777fae44d82382dd8c87f:

  Merge branch 'akpm' (incoming from Andrew) (2013-04-30 17:37:43 -0700)

are available in the git repository at:


  git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
tags/tag-for-linus-3.10

for you to fetch changes up to b89e35636bc75b72d15a1af6d49798802aff77d5:

  dma-buf: Add debugfs support (2013-05-01 16:36:22 +0530)


3.10 dma-buf updates
  Added debugfs support to dma-buf.

Sumit Semwal (2):
  dma-buf: replace dma_buf_export() with dma_buf_export_named()
  dma-buf: Add debugfs support

 Documentation/dma-buf-sharing.txt |  13 ++-
 drivers/base/dma-buf.c| 169 +-
 include/linux/dma-buf.h   |  16 +++-
 3 files changed, 189 insertions(+), 9 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] dma-buf: Add support for debugfs

[Sumit Semwal]

Hi All,


On 4 April 2013 11:58, Sumit Semwal sumit.sem...@linaro.org wrote:
 The patch series adds a much-missed support for debugfs to dma-buf framework.

 Based on the feedback received on v1 of this patch series, support is also
 added to allow exporters to provide name-strings that will prove useful
 while debugging.

Since there're no more comments, I'll add this to my for-next, to
queue it up for 3.10.

Best regards,
~Sumit.

 Some more magic can be added for more advanced debugging, but we'll leave that
 for the time being.

 Best regards,
 ~Sumit.

 ---
 changes since v2: (based on review comments from Laurent Pinchart)
  - reordered functions to avoid forward declaration
  - added __exitcall for dma_buf_deinit()

 changes since v1:
  - added patch to replace dma_buf_export() with dma_buf_export_named(), per
 suggestion from Daniel Vetter.
  - fixes on init and warnings as reported and corrected by Dave Airlie.
  - added locking while walking attachment list - reported by Daniel Vetter.

 Sumit Semwal (2):
   dma-buf: replace dma_buf_export() with dma_buf_export_named()
   dma-buf: Add debugfs support

  Documentation/dma-buf-sharing.txt |   13 ++-
  drivers/base/dma-buf.c|  170 
 -
  include/linux/dma-buf.h   |   16 +++-
  3 files changed, 190 insertions(+), 9 deletions(-)

 --
 1.7.10.4




--
Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/2] dma-buf: Add support for debugfs

[Sumit Semwal]

The patch series adds a much-missed support for debugfs to dma-buf framework.

Based on the feedback received on v1 of this patch series, support is also
added to allow exporters to provide name-strings that will prove useful
while debugging.

Some more magic can be added for more advanced debugging, but we'll leave that
for the time being.

Best regards,
~Sumit.

---
changes since v2: (based on review comments from Laurent Pinchart)
 - reordered functions to avoid forward declaration
 - added __exitcall for dma_buf_deinit()

changes since v1:
 - added patch to replace dma_buf_export() with dma_buf_export_named(), per
suggestion from Daniel Vetter.
 - fixes on init and warnings as reported and corrected by Dave Airlie.
 - added locking while walking attachment list - reported by Daniel Vetter.

Sumit Semwal (2):
  dma-buf: replace dma_buf_export() with dma_buf_export_named()
  dma-buf: Add debugfs support

 Documentation/dma-buf-sharing.txt |   13 ++-
 drivers/base/dma-buf.c|  170 -
 include/linux/dma-buf.h   |   16 +++-
 3 files changed, 190 insertions(+), 9 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] dma-buf: replace dma_buf_export() with dma_buf_export_named()

[Sumit Semwal]

For debugging purposes, it is useful to have a name-string added
while exporting buffers. Hence, dma_buf_export() is replaced with
dma_buf_export_named(), which additionally takes 'exp_name' as a
parameter.

For backward compatibility, and for lazy exporters who don't wish to
name themselves, a #define dma_buf_export() is also made available,
which adds a __FILE__ instead of 'exp_name'.

Cc: Daniel Vetter daniel.vet...@ffwll.ch
  [Thanks for the idea!]
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 Documentation/dma-buf-sharing.txt |   13 +++--
 drivers/base/dma-buf.c|   11 +++
 include/linux/dma-buf.h   |   11 +--
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 4966b1b..0b23261 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -52,14 +52,23 @@ The dma_buf buffer sharing API usage contains the following 
steps:
associated with this buffer.
 
Interface:
-  struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
-size_t size, int flags)
+  struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops *ops,
+size_t size, int flags,
+const char *exp_name)
 
If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
 
+   'exp_name' is the name of exporter - to facilitate information while
+   debugging.
+
+   Exporting modules which do not wish to provide any specific name may use the
+   helper define 'dma_buf_export()', with the same arguments as above, but
+   without the last argument; a __FILE__ pre-processor directive will be
+   inserted in place of 'exp_name' instead.
+
 2. Userspace gets a handle to pass around to potential buffer-users
 
Userspace entity requests for a file-descriptor (fd) which is a handle to 
the
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 2a7cb0d..d89102a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,22 +77,24 @@ static inline int is_dma_buf_file(struct file *file)
 }
 
 /**
- * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
  * Also connect the allocator specific data and ops to the buffer.
+ * Additionally, provide a name string for exporter; useful in debugging.
  *
  * @priv:  [in]Attach private data of allocator to this buffer
  * @ops:   [in]Attach allocator-defined dma buf ops to the new buffer.
  * @size:  [in]Size of the buffer
  * @flags: [in]mode flags for the file.
+ * @exp_name:  [in]name of the exporting module - useful for debugging.
  *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
  * ops, or error in allocating struct dma_buf, will return negative error.
  *
  */
-struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags)
+struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
+   size_t size, int flags, const char *exp_name)
 {
struct dma_buf *dmabuf;
struct file *file;
@@ -114,6 +116,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
dmabuf-priv = priv;
dmabuf-ops = ops;
dmabuf-size = size;
+   dmabuf-exp_name = exp_name;
 
file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
 
@@ -124,7 +127,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
 
return dmabuf;
 }
-EXPORT_SYMBOL_GPL(dma_buf_export);
+EXPORT_SYMBOL_GPL(dma_buf_export_named);
 
 
 /**
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 9978b61..6f55c04 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -112,6 +112,7 @@ struct dma_buf_ops {
  * @file: file pointer used for sharing buffers across, and for refcounting.
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
+ * @exp_name: name of the exporter; useful for debugging.
  * @priv: exporter specific private data for this buffer object.
  */
 struct dma_buf {
@@ -123,6 +124,7 @@ struct dma_buf {
struct mutex lock;
unsigned vmapping_counter;
void *vmap_ptr;
+   const char *exp_name;
void *priv;
 };
 
@@ -162,8 +164,13 @@ struct dma_buf_attachment

[PATCH v3 2/2] dma-buf: Add debugfs support

[Sumit Semwal]

Add debugfs support to make it easier to print debug information
about the dma-buf buffers.

Cc: Dave Airlie airl...@redhat.com
 [minor fixes on init and warning fix]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
changes since v2: (based on review comments from Laurent Pinchart)
 - reordered functions to avoid forward declaration
 - added __exitcall for dma_buf_deinit()

changes since v1:
 - fixes on init and warnings as reported and corrected by Dave Airlie.
 - add locking while walking attachment list - reported by Daniel Vetter.
---
 drivers/base/dma-buf.c  |  159 +++
 include/linux/dma-buf.h |5 +-
 2 files changed, 163 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index d89102a..466476f 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,9 +27,18 @@
 #include linux/dma-buf.h
 #include linux/anon_inodes.h
 #include linux/export.h
+#include linux/debugfs.h
+#include linux/seq_file.h
 
 static inline int is_dma_buf_file(struct file *);
 
+struct dma_buf_list {
+   struct list_head head;
+   struct mutex lock;
+};
+
+static struct dma_buf_list db_list;
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
struct dma_buf *dmabuf;
@@ -42,6 +51,11 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
BUG_ON(dmabuf-vmapping_counter);
 
dmabuf-ops-release(dmabuf);
+
+   mutex_lock(db_list.lock);
+   list_del(dmabuf-list_node);
+   mutex_unlock(db_list.lock);
+
kfree(dmabuf);
return 0;
 }
@@ -125,6 +139,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
mutex_init(dmabuf-lock);
INIT_LIST_HEAD(dmabuf-attachments);
 
+   mutex_lock(db_list.lock);
+   list_add(dmabuf-list_node, db_list.head);
+   mutex_unlock(db_list.lock);
+
return dmabuf;
 }
 EXPORT_SYMBOL_GPL(dma_buf_export_named);
@@ -551,3 +569,144 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
mutex_unlock(dmabuf-lock);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+
+#ifdef CONFIG_DEBUG_FS
+static int dma_buf_describe(struct seq_file *s)
+{
+   int ret;
+   struct dma_buf *buf_obj;
+   struct dma_buf_attachment *attach_obj;
+   int count = 0, attach_count;
+   size_t size = 0;
+
+   ret = mutex_lock_interruptible(db_list.lock);
+
+   if (ret)
+   return ret;
+
+   seq_printf(s, \nDma-buf Objects:\n);
+   seq_printf(s, \texp_name\tsize\tflags\tmode\tcount\n);
+
+   list_for_each_entry(buf_obj, db_list.head, list_node) {
+   ret = mutex_lock_interruptible(buf_obj-lock);
+
+   if (ret) {
+   seq_printf(s,
+ \tERROR locking buffer object: skipping\n);
+   goto skip_buffer;
+   }
+
+   seq_printf(s, \t);
+
+   seq_printf(s, \t%s\t%08zu\t%08x\t%08x\t%08d\n,
+   buf_obj-exp_name, buf_obj-size,
+   buf_obj-file-f_flags, buf_obj-file-f_mode,
+   buf_obj-file-f_count.counter);
+
+   seq_printf(s, \t\tAttached Devices:\n);
+   attach_count = 0;
+
+   list_for_each_entry(attach_obj, buf_obj-attachments, node) {
+   seq_printf(s, \t\t);
+
+   seq_printf(s, %s\n, attach_obj-dev-init_name);
+   attach_count++;
+   }
+
+   seq_printf(s, \n\t\tTotal %d devices attached\n,
+   attach_count);
+
+   count++;
+   size += buf_obj-size;
+skip_buffer:
+   mutex_unlock(buf_obj-lock);
+   }
+
+   seq_printf(s, \nTotal %d objects, %zu bytes\n, count, size);
+
+   mutex_unlock(db_list.lock);
+   return 0;
+}
+
+static int dma_buf_show(struct seq_file *s, void *unused)
+{
+   void (*func)(struct seq_file *) = s-private;
+   func(s);
+   return 0;
+}
+
+static int dma_buf_debug_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, dma_buf_show, inode-i_private);
+}
+
+static const struct file_operations dma_buf_debug_fops = {
+   .open   = dma_buf_debug_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
+static struct dentry *dma_buf_debugfs_dir;
+
+static int dma_buf_init_debugfs(void)
+{
+   int err = 0;
+   dma_buf_debugfs_dir = debugfs_create_dir(dma_buf, NULL);
+   if (IS_ERR(dma_buf_debugfs_dir)) {
+   err = PTR_ERR(dma_buf_debugfs_dir);
+   dma_buf_debugfs_dir = NULL;
+   return err;
+   }
+
+   err = dma_buf_debugfs_create_file(bufinfo, dma_buf_describe);
+
+   if (err)
+   pr_debug(dma_buf: debugfs: failed to create node

Re: [PATCH 2/2] dma-buf: Add debugfs support

[Sumit Semwal]

Hi Laurent!

Thanks for the review:

On 27 March 2013 05:38, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Sumit,

 Thanks for the patch.

 On Monday 25 March 2013 16:50:46 Sumit Semwal wrote:
 Add debugfs support to make it easier to print debug information
 about the dma-buf buffers.

 Cc: Dave Airlie airl...@redhat.com
  [minor fixes on init and warning fix]
 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
 ---
 changes since v1:
  - fixes on init and warnings as reported and corrected by Dave Airlie.
  - add locking while walking attachment list - reported by Daniel Vetter.

  drivers/base/dma-buf.c  |  162 
  include/linux/dma-buf.h |5 +-
  2 files changed, 166 insertions(+), 1 deletion(-)

 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index d89102a..7d867ed 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -27,9 +27,18 @@
  #include linux/dma-buf.h
  #include linux/anon_inodes.h
  #include linux/export.h
 +#include linux/debugfs.h
 +#include linux/seq_file.h

  static inline int is_dma_buf_file(struct file *);

 +struct dma_buf_list {
 + struct list_head head;
 + struct mutex lock;
 +};
 +
 +static struct dma_buf_list db_list;
 +
  static int dma_buf_release(struct inode *inode, struct file *file)
  {
   struct dma_buf *dmabuf;
 @@ -42,6 +51,11 @@ static int dma_buf_release(struct inode *inode, struct
 file *file) BUG_ON(dmabuf-vmapping_counter);

   dmabuf-ops-release(dmabuf);
 +
 + mutex_lock(db_list.lock);
 + list_del(dmabuf-list_node);
 + mutex_unlock(db_list.lock);
 +
   kfree(dmabuf);
   return 0;
  }
 @@ -125,6 +139,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const
 struct dma_buf_ops *ops, mutex_init(dmabuf-lock);
   INIT_LIST_HEAD(dmabuf-attachments);

 + mutex_lock(db_list.lock);
 + list_add(dmabuf-list_node, db_list.head);
 + mutex_unlock(db_list.lock);
 +
   return dmabuf;
  }
  EXPORT_SYMBOL_GPL(dma_buf_export_named);
 @@ -551,3 +569,147 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void
 *vaddr) mutex_unlock(dmabuf-lock);
  }
  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
 +
 +static int dma_buf_init_debugfs(void);
 +static void dma_buf_uninit_debugfs(void);
 +
 +static int __init dma_buf_init(void)
 +{
 + mutex_init(db_list.lock);
 + INIT_LIST_HEAD(db_list.head);
 + dma_buf_init_debugfs();
 + return 0;
 +}
 +
 +subsys_initcall(dma_buf_init);
 +
 +static void __exit dma_buf_deinit(void)

 This function is never called.

You're right; it's missing an __exitcall() - I will add it!
 +{
 + dma_buf_uninit_debugfs();
 +}

 If you moved those two functions at the end of the file you could get rid of
 the forward declarations above.

Sure - will do that.
 +
 +#ifdef CONFIG_DEBUG_FS
 +static int dma_buf_describe(struct seq_file *s)
 +{
 + int ret;
 + struct dma_buf *buf_obj;
 + struct dma_buf_attachment *attach_obj;
 + int count = 0, attach_count;
 + size_t size = 0;
 +
 + ret = mutex_lock_interruptible(db_list.lock);
 +
 + if (ret)
 + return ret;
 +
 + seq_printf(s, \nDma-buf Objects:\n);
 + seq_printf(s, \texp_name\tsize\tflags\tmode\tcount\n);
 +
 + list_for_each_entry(buf_obj, db_list.head, list_node) {
 + ret = mutex_lock_interruptible(buf_obj-lock);
 +
 + if (ret) {
 + seq_printf(s,
 +   \tERROR locking buffer object: skipping\n);
 + goto skip_buffer;
 + }
 +
 + seq_printf(s, \t);
 +
 + seq_printf(s, \t%s\t%08zu\t%08x\t%08x\t%08d\n,
 + buf_obj-exp_name, buf_obj-size,
 + buf_obj-file-f_flags, buf_obj-file-f_mode,
 + buf_obj-file-f_count.counter);
 +
 + seq_printf(s, \t\tAttached Devices:\n);
 + attach_count = 0;
 +
 + list_for_each_entry(attach_obj, buf_obj-attachments, node) {
 + seq_printf(s, \t\t);
 +
 + seq_printf(s, %s\n, attach_obj-dev-init_name);
 + attach_count++;
 + }
 +
 + seq_printf(s, \n\t\tTotal %d devices attached\n,
 + attach_count);
 +
 + count++;
 + size += buf_obj-size;
 +skip_buffer:
 + mutex_unlock(buf_obj-lock);
 + }
 +
 + seq_printf(s, \nTotal %d objects, %zu bytes\n, count, size);
 +
 + mutex_unlock(db_list.lock);
 + return 0;
 +}
 +
 +static int dma_buf_show(struct seq_file *s, void *unused)
 +{
 + void (*func)(struct seq_file *) = s-private;
 + func(s);
 + return 0;
 +}
 +
 +static int dma_buf_debug_open(struct inode *inode, struct file *file)
 +{
 + return single_open(file, dma_buf_show, inode-i_private);
 +}
 +
 +static const struct file_operations dma_buf_debug_fops = {
 + .open

[PATCH v2 0/2] dma-buf: Add support for debugfs

[Sumit Semwal]

The patch series adds a much-missed support for debugfs to dma-buf framework.

Based on the feedback received on v1 of this patch series, support is also
added to allow exporters to provide name-strings that will prove useful
while debugging.

Some more magic can be added for more advanced debugging, but we'll leave that
for the time being.

Best regards,
~Sumit.


Sumit Semwal (2):
  dma-buf: replace dma_buf_export() with dma_buf_export_named()
  dma-buf: Add debugfs support

 Documentation/dma-buf-sharing.txt |   13 ++-
 drivers/base/dma-buf.c|  173 -
 include/linux/dma-buf.h   |   16 +++-
 3 files changed, 193 insertions(+), 9 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] dma-buf: replace dma_buf_export() with dma_buf_export_named()

[Sumit Semwal]

For debugging purposes, it is useful to have a name-string added
while exporting buffers. Hence, dma_buf_export() is replaced with
dma_buf_export_named(), which additionally takes 'exp_name' as a
parameter.

For backward compatibility, and for lazy exporters who don't wish to
name themselves, a #define dma_buf_export() is also made available,
which adds a __FILE__ instead of 'exp_name'.

Cc: Daniel Vetter daniel.vet...@ffwll.ch
  [Thanks for the idea!]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 Documentation/dma-buf-sharing.txt |   13 +++--
 drivers/base/dma-buf.c|   11 +++
 include/linux/dma-buf.h   |   11 +--
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 4966b1b..0b23261 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -52,14 +52,23 @@ The dma_buf buffer sharing API usage contains the following 
steps:
associated with this buffer.
 
Interface:
-  struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
-size_t size, int flags)
+  struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops *ops,
+size_t size, int flags,
+const char *exp_name)
 
If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
 
+   'exp_name' is the name of exporter - to facilitate information while
+   debugging.
+
+   Exporting modules which do not wish to provide any specific name may use the
+   helper define 'dma_buf_export()', with the same arguments as above, but
+   without the last argument; a __FILE__ pre-processor directive will be
+   inserted in place of 'exp_name' instead.
+
 2. Userspace gets a handle to pass around to potential buffer-users
 
Userspace entity requests for a file-descriptor (fd) which is a handle to 
the
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 2a7cb0d..d89102a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,22 +77,24 @@ static inline int is_dma_buf_file(struct file *file)
 }
 
 /**
- * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
  * Also connect the allocator specific data and ops to the buffer.
+ * Additionally, provide a name string for exporter; useful in debugging.
  *
  * @priv:  [in]Attach private data of allocator to this buffer
  * @ops:   [in]Attach allocator-defined dma buf ops to the new buffer.
  * @size:  [in]Size of the buffer
  * @flags: [in]mode flags for the file.
+ * @exp_name:  [in]name of the exporting module - useful for debugging.
  *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
  * ops, or error in allocating struct dma_buf, will return negative error.
  *
  */
-struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags)
+struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
+   size_t size, int flags, const char *exp_name)
 {
struct dma_buf *dmabuf;
struct file *file;
@@ -114,6 +116,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
dmabuf-priv = priv;
dmabuf-ops = ops;
dmabuf-size = size;
+   dmabuf-exp_name = exp_name;
 
file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
 
@@ -124,7 +127,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct 
dma_buf_ops *ops,
 
return dmabuf;
 }
-EXPORT_SYMBOL_GPL(dma_buf_export);
+EXPORT_SYMBOL_GPL(dma_buf_export_named);
 
 
 /**
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 9978b61..6f55c04 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -112,6 +112,7 @@ struct dma_buf_ops {
  * @file: file pointer used for sharing buffers across, and for refcounting.
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
+ * @exp_name: name of the exporter; useful for debugging.
  * @priv: exporter specific private data for this buffer object.
  */
 struct dma_buf {
@@ -123,6 +124,7 @@ struct dma_buf {
struct mutex lock;
unsigned vmapping_counter;
void *vmap_ptr;
+   const char *exp_name;
void *priv;
 };
 
@@ -162,8 +164,13 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf

[PATCH 2/2] dma-buf: Add debugfs support

[Sumit Semwal]

Add debugfs support to make it easier to print debug information
about the dma-buf buffers.

Cc: Dave Airlie airl...@redhat.com
 [minor fixes on init and warning fix]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
changes since v1:
 - fixes on init and warnings as reported and corrected by Dave Airlie.
 - add locking while walking attachment list - reported by Daniel Vetter.

 drivers/base/dma-buf.c  |  162 +++
 include/linux/dma-buf.h |5 +-
 2 files changed, 166 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index d89102a..7d867ed 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,9 +27,18 @@
 #include linux/dma-buf.h
 #include linux/anon_inodes.h
 #include linux/export.h
+#include linux/debugfs.h
+#include linux/seq_file.h
 
 static inline int is_dma_buf_file(struct file *);
 
+struct dma_buf_list {
+   struct list_head head;
+   struct mutex lock;
+};
+
+static struct dma_buf_list db_list;
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
struct dma_buf *dmabuf;
@@ -42,6 +51,11 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
BUG_ON(dmabuf-vmapping_counter);
 
dmabuf-ops-release(dmabuf);
+
+   mutex_lock(db_list.lock);
+   list_del(dmabuf-list_node);
+   mutex_unlock(db_list.lock);
+
kfree(dmabuf);
return 0;
 }
@@ -125,6 +139,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
mutex_init(dmabuf-lock);
INIT_LIST_HEAD(dmabuf-attachments);
 
+   mutex_lock(db_list.lock);
+   list_add(dmabuf-list_node, db_list.head);
+   mutex_unlock(db_list.lock);
+
return dmabuf;
 }
 EXPORT_SYMBOL_GPL(dma_buf_export_named);
@@ -551,3 +569,147 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
mutex_unlock(dmabuf-lock);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+
+static int dma_buf_init_debugfs(void);
+static void dma_buf_uninit_debugfs(void);
+
+static int __init dma_buf_init(void)
+{
+   mutex_init(db_list.lock);
+   INIT_LIST_HEAD(db_list.head);
+   dma_buf_init_debugfs();
+   return 0;
+}
+
+subsys_initcall(dma_buf_init);
+
+static void __exit dma_buf_deinit(void)
+{
+   dma_buf_uninit_debugfs();
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int dma_buf_describe(struct seq_file *s)
+{
+   int ret;
+   struct dma_buf *buf_obj;
+   struct dma_buf_attachment *attach_obj;
+   int count = 0, attach_count;
+   size_t size = 0;
+
+   ret = mutex_lock_interruptible(db_list.lock);
+
+   if (ret)
+   return ret;
+
+   seq_printf(s, \nDma-buf Objects:\n);
+   seq_printf(s, \texp_name\tsize\tflags\tmode\tcount\n);
+
+   list_for_each_entry(buf_obj, db_list.head, list_node) {
+   ret = mutex_lock_interruptible(buf_obj-lock);
+
+   if (ret) {
+   seq_printf(s,
+ \tERROR locking buffer object: skipping\n);
+   goto skip_buffer;
+   }
+
+   seq_printf(s, \t);
+
+   seq_printf(s, \t%s\t%08zu\t%08x\t%08x\t%08d\n,
+   buf_obj-exp_name, buf_obj-size,
+   buf_obj-file-f_flags, buf_obj-file-f_mode,
+   buf_obj-file-f_count.counter);
+
+   seq_printf(s, \t\tAttached Devices:\n);
+   attach_count = 0;
+
+   list_for_each_entry(attach_obj, buf_obj-attachments, node) {
+   seq_printf(s, \t\t);
+
+   seq_printf(s, %s\n, attach_obj-dev-init_name);
+   attach_count++;
+   }
+
+   seq_printf(s, \n\t\tTotal %d devices attached\n,
+   attach_count);
+
+   count++;
+   size += buf_obj-size;
+skip_buffer:
+   mutex_unlock(buf_obj-lock);
+   }
+
+   seq_printf(s, \nTotal %d objects, %zu bytes\n, count, size);
+
+   mutex_unlock(db_list.lock);
+   return 0;
+}
+
+static int dma_buf_show(struct seq_file *s, void *unused)
+{
+   void (*func)(struct seq_file *) = s-private;
+   func(s);
+   return 0;
+}
+
+static int dma_buf_debug_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, dma_buf_show, inode-i_private);
+}
+
+static const struct file_operations dma_buf_debug_fops = {
+   .open   = dma_buf_debug_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
+static struct dentry *dma_buf_debugfs_dir;
+
+static int dma_buf_init_debugfs(void)
+{
+   int err = 0;
+   dma_buf_debugfs_dir = debugfs_create_dir(dma_buf, NULL);
+   if (IS_ERR(dma_buf_debugfs_dir)) {
+   err = PTR_ERR(dma_buf_debugfs_dir);
+   dma_buf_debugfs_dir

Re: [PATCH 3/3] dma-buf: restore args on failure of dma_buf_mmap

[Sumit Semwal]

On 19 March 2013 05:19, Mauro Carvalho Chehab mche...@redhat.com wrote:
 Em Thu, 07 Feb 2013 15:54:52 +0530
 Sumit Semwal sumit.sem...@linaro.org escreveu:

 Hi John,

 On Thursday 07 February 2013 05:33 AM, John Sheu wrote:
  From: John Sheu s...@chromium.org
 
  Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
  themselves on failure.  Not restoring the struct's data on failure
  causes a double-decrement of the vm_file's refcount.
 Thanks for your patch; could you please re-send it to the correct,
 relevant lists and me (as the maintainer of dma-buf) rather than just to
 linux-media ml?

 Yes, it doesn't make sense to apply this one via the media tree ;)

 I'm applying patches 1 and 2, as they should go through the media tree.
Sure, this patch is already in mainline as of 3.9-rc1 :)

 Thanks!
 Mauro

 I just chanced to see this patch, otherwise it could easily have slipped
 past me (and other interested parties).

 You could run scripts/get_maintainer.pl on your patch to find out the
 right lists / email IDs to CC.

 Thanks and best regards,
 ~Sumit.
 
  Signed-off-by: John Sheu s...@google.com
  ---
drivers/base/dma-buf.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
  index a3f79c4..01daf9c 100644
  --- a/drivers/base/dma-buf.c
  +++ b/drivers/base/dma-buf.c
  @@ -446,6 +446,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
   unsigned long pgoff)
{
  +   struct file *oldfile;
  +   int ret;
  +
  if (WARN_ON(!dmabuf || !vma))
  return -EINVAL;
 
  @@ -459,14 +462,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct 
  vm_area_struct *vma,
  return -EINVAL;
 
  /* readjust the vma */
  -   if (vma-vm_file)
  -   fput(vma-vm_file);
  -
  +   oldfile = vma-vm_file;
  vma-vm_file = get_file(dmabuf-file);
 
  vma-vm_pgoff = pgoff;
 
  -   return dmabuf-ops-mmap(dmabuf, vma);
  +   ret = dmabuf-ops-mmap(dmabuf, vma);
  +   if (ret) {
  +   /* restore old parameters on failure */
  +   vma-vm_file = oldfile;
  +   fput(dmabuf-file);
  +   } else {
  +   if (oldfile)
  +   fput(oldfile);
  +   }
  +   return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
 
 

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


 --

 Cheers,
 Mauro



--
Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: dma-buf updates for 3.9

[Sumit Semwal]

Hi Linus,

Here's the 3.9 pull request for dma-buf framework updates: could you
please pull?

Thanks and best regards,
~Sumit.


The following changes since commit d895cb1af15c04c522a25c79cc429076987c089b:

  Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2013-02-26
20:16:07 -0800)

are available in the git repository at:


  git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
tags/tag-for-linus-3.9

for you to fetch changes up to 495c10cc1c0c359871d5bef32dd173252fc17995:

  CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap
(2013-02-27 15:14:02 +0530)


3.9: dma-buf updates
Refcounting implemented for vmap in core dma-buf


Daniel Vetter (1):
  dma-buf: implement vmap refcounting in the interface logic

John Sheu (1):
  CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap

 Documentation/dma-buf-sharing.txt |6 +++-
 drivers/base/dma-buf.c|   66 ++---
 include/linux/dma-buf.h   |4 ++-
 3 files changed, 63 insertions(+), 13 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linaro-mm-sig] [PATCH] CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap

[Sumit Semwal]

On 14 February 2013 16:16, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 On Tue, Feb 12, 2013 at 2:50 AM,  s...@google.com wrote:
 From: John Sheu s...@google.com

 Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
 themselves on failure.  Not restoring the struct's data on failure
 causes a double-decrement of the vm_file's refcount.

 Signed-off-by: John Sheu s...@google.com

 Yeah, makes sense that this little helper here cleans up any damage it
 caused when the callback fails.

 Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

Thanks John, Daniel!

I'll pull it in the for-next soon.

Best regards,
~Sumit.

 ---
  drivers/base/dma-buf.c |   21 +++--
  1 files changed, 15 insertions(+), 6 deletions(-)

 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index 09e6878..06c6225 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -536,6 +536,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
  int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
  unsigned long pgoff)
  {
 +   struct file *oldfile;
 +   int ret;
 +
 if (WARN_ON(!dmabuf || !vma))
 return -EINVAL;

 @@ -549,15 +552,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct 
 vm_area_struct *vma,
 return -EINVAL;

 /* readjust the vma */
 -   if (vma-vm_file)
 -   fput(vma-vm_file);
 -
 +   get_file(dmabuf-file);
 +   oldfile = vma-vm_file;
 vma-vm_file = dmabuf-file;
 -   get_file(vma-vm_file);
 -
 vma-vm_pgoff = pgoff;

 -   return dmabuf-ops-mmap(dmabuf, vma);
 +   ret = dmabuf-ops-mmap(dmabuf, vma);
 +   if (ret) {
 +   /* restore old parameters on failure */
 +   vma-vm_file = oldfile;
 +   fput(dmabuf-file);
 +   } else {
 +   if (oldfile)
 +   fput(oldfile);
 +   }
 +   return ret;
  }
  EXPORT_SYMBOL_GPL(dma_buf_mmap);

 --
 1.7.8.6


 ___
 Linaro-mm-sig mailing list
 linaro-mm-...@lists.linaro.org
 http://lists.linaro.org/mailman/listinfo/linaro-mm-sig



 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap

[Sumit Semwal]

+dri-devel ML


 On 12 February 2013 07:20, s...@google.com wrote:

 From: John Sheu s...@google.com

 Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
 themselves on failure.  Not restoring the struct's data on failure
 causes a double-decrement of the vm_file's refcount.

 Signed-off-by: John Sheu s...@google.com

 ---
  drivers/base/dma-buf.c |   21 +++--
  1 files changed, 15 insertions(+), 6 deletions(-)

 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index 09e6878..06c6225 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -536,6 +536,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
  int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
  unsigned long pgoff)
  {
 +   struct file *oldfile;
 +   int ret;
 +
 if (WARN_ON(!dmabuf || !vma))
 return -EINVAL;

 @@ -549,15 +552,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
 vm_area_struct *vma,
 return -EINVAL;

 /* readjust the vma */
 -   if (vma-vm_file)
 -   fput(vma-vm_file);
 -
 +   get_file(dmabuf-file);
 +   oldfile = vma-vm_file;
 vma-vm_file = dmabuf-file;
 -   get_file(vma-vm_file);
 -
 vma-vm_pgoff = pgoff;

 -   return dmabuf-ops-mmap(dmabuf, vma);
 +   ret = dmabuf-ops-mmap(dmabuf, vma);
 +   if (ret) {
 +   /* restore old parameters on failure */
 +   vma-vm_file = oldfile;
 +   fput(dmabuf-file);
 +   } else {
 +   if (oldfile)
 +   fput(oldfile);
 +   }
 +   return ret;
  }
  EXPORT_SYMBOL_GPL(dma_buf_mmap);

 --
 1.7.8.6




 --

 Thanks and regards,

 Sumit Semwal

 Linaro Kernel Engineer - Graphics working group

 Linaro.org │ Open source software for ARM SoCs

 Follow Linaro: Facebook | Twitter | Blog



-- 
Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] dma-buf: restore args on failure of dma_buf_mmap

[Sumit Semwal]

Hi John,

On Thursday 07 February 2013 05:33 AM, John Sheu wrote:

From: John Sheu s...@chromium.org

Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
themselves on failure.  Not restoring the struct's data on failure
causes a double-decrement of the vm_file's refcount.
Thanks for your patch; could you please re-send it to the correct, 
relevant lists and me (as the maintainer of dma-buf) rather than just to 
linux-media ml?


I just chanced to see this patch, otherwise it could easily have slipped 
past me (and other interested parties).


You could run scripts/get_maintainer.pl on your patch to find out the 
right lists / email IDs to CC.


Thanks and best regards,
~Sumit.


Signed-off-by: John Sheu s...@google.com
---
  drivers/base/dma-buf.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..01daf9c 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -446,6 +446,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
  int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
 unsigned long pgoff)
  {
+   struct file *oldfile;
+   int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;

@@ -459,14 +462,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma,
return -EINVAL;

/* readjust the vma */
-   if (vma-vm_file)
-   fput(vma-vm_file);
-
+   oldfile = vma-vm_file;
vma-vm_file = get_file(dmabuf-file);

vma-vm_pgoff = pgoff;

-   return dmabuf-ops-mmap(dmabuf, vma);
+   ret = dmabuf-ops-mmap(dmabuf, vma);
+   if (ret) {
+   /* restore old parameters on failure */
+   vma-vm_file = oldfile;
+   fput(dmabuf-file);
+   } else {
+   if (oldfile)
+   fput(oldfile);
+   }
+   return ret;
  }
  EXPORT_SYMBOL_GPL(dma_buf_mmap);




--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL]: dma-buf updates for 3.8

[Sumit Semwal]

Hi Linus,

A fairly small dma-buf pull request for 3.8 - only 2 patches. Could
you please pull?

Thanks!
~Sumit.

The following changes since commit f01af9f85855e38fbd601e033a8eac204cc4cc1c:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc
(2012-12-19 20:31:02 -0800)

are available in the git repository at:


  git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
tags/tag-for-linus-3.8

for you to fetch changes up to ada65c74059f8c104f1b467c126205471634c435:

  dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER (2012-12-20
12:05:06 +0530)


3.8: dma-buf minor updates


Maarten Lankhorst (1):
  dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

Rob Clark (1):
  dma-buf: might_sleep() in dma_buf_unmap_attachment()

 drivers/base/dma-buf.c  |2 +
 include/linux/dma-buf.h |   99 ---
 2 files changed, 2 insertions(+), 99 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf: Add debugfs support

[Sumit Semwal]

On 14 December 2012 16:04, Daniel Vetter dan...@ffwll.ch wrote:

 Missed one ...

 On Fri, Dec 14, 2012 at 10:36 AM,  sumit.sem...@ti.com wrote:
  +   list_for_each_entry(attach_obj, buf_obj-attachments, 
  node) {
  +   seq_printf(s, \t\t);
  +
  +   seq_printf(s, %s\n, attach_obj-dev-init_name);
  +   attach_count++;
  +   }

 You need to hold dmabuf-lock while walking the attachment list.
 -Daniel


Thanks Daniel!

Will update in next version.

 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch



Best regards,

Sumit Semwal
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

[Sumit Semwal]

On 17 December 2012 14:25, Sumit Semwal sumit.sem...@linaro.org wrote:
Apologies for re-sending, since the gmail ui 'decided' to set some
formatting options by default!
 Hi Maarten,

 On 14 December 2012 17:27, Maarten Lankhorst m.b.lankho...@gmail.com
 wrote:

 Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
  From: Sumit Semwal sumit.sem...@linaro.org
 
  Add debugfs support to make it easier to print debug information
  about the dma-buf buffers.
 
 I like the idea, I don't know if it could be done in a free manner, but
 for bonus points
 could we also have the dma-buf fd be obtainable that way from a debugfs
 entry?

 Doing so would allow me to 'steal' a dma-buf from an existing mapping
 easily, and test against that.

 Also I think the name of the device and process that exported the dma-buf
 would be useful
 to have as well, even if in case of the device that would mean changing
 the api slightly to record it.

 I was thinking of having a directory structure like this:

 /sys/kernel/debug/dma_buf/stats

 and then for each dma-buf:

 /sys/kernel/debug/dma-buf/exporting_file.c/number-fd
 /sys/kernel/debug/dma-buf/exporting_file.c/number-attachments
 /sys/kernel/debug/dma-buf/exporting_file.c/number-info

 Opening the fd file would give you back the original fd, or fail with -EIO
 if refcount was dropped to 0.

 Would something like this be doable? I don't know debugfs that well, but I
 don't see why it wouldn't be,

 Let me think more about it, but I am inclined to add simple support first,
 and then add more features to dma_buf debugfs as it grows.

 I still would want to take Daniel's suggestion on dma_buf_export_named()
 before I push this patch, so I guess I'll try to work a little more and
 prepare it for 3.9?

 I quite like your idea of .../dma-buf/exporting_file.c/...  , which would
 need the above as well :)


 ~Maarten

 Best regards,
 ~Sumit.




--
Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()

[Sumit Semwal]

On Friday 28 September 2012 01:09 PM, Maarten Lankhorst wrote:

Op 28-09-12 09:29, Rob Clark schreef:

From: Rob Clark r...@ti.com

We never really clarified if unmap could be done in atomic context.
But since mapping might require sleeping, this implies mutex in use
to synchronize mapping/unmapping, so unmap could sleep as well.  Add
a might_sleep() to clarify this.

Signed-off-by: Rob Clark r...@ti.com
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/base/dma-buf.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c30f3e1..877eacb 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
struct sg_table *sg_table,
enum dma_data_direction direction)
  {
+   might_sleep();
+
if (WARN_ON(!attach || !attach-dmabuf || !sg_table))
return;


Looks good to me!

Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com

Thanks Rob,

Applied to for-next.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] dma-fence: dma-buf synchronization (v7)

[Sumit Semwal]

Hi Maarten,

On 8 August 2012 00:17, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 Op 07-08-12 19:53, Maarten Lankhorst schreef:
 A dma-fence can be attached to a buffer which is being filled or consumed
 by hw, to allow userspace to pass the buffer without waiting to another
 device.  For example, userspace can call page_flip ioctl to display the
 next frame of graphics after kicking the GPU but while the GPU is still
 rendering.  The display device sharing the buffer with the GPU would
 attach a callback to get notified when the GPU's rendering-complete IRQ
 fires, to update the scan-out address of the display, without having to
 wake up userspace.

Thanks for this patchset; Could you please also fill up
Documentation/dma-buf-sharing.txt, to include the relevant bits?

We've tried to make sure the Documentation corresponding is kept
up-to-date as the framework has grown, and new features are added to
it - and I think features as important as dma-fence and dmabufmgr do
warrant a healthy update.

 I implemented this for intel and debugged it with intel - nouveau
 interaction. Unfortunately the nouveau patches aren't ready at this point,
 but the git repo I'm using is available at:

 http://cgit.freedesktop.org/~mlankhorst/linux/

 It has the patch series and a sample implementation for intel, based on
 drm-intel-next tree.

 I tried to keep it deadlock and race condition free as much as possible,
 but locking gets complicated enough that if I'm unlucky something might
 have slipped through regardless.

 Especially the locking in i915_gem_reset_requests, is screwed up.
 This shows what a real PITA it is to abort callbacks prematurely while
 keeping everything stable. As such, aborting requests should only be done
 in exceptional circumstances, in this case hardware died and things are
 already locked up anyhow..

 ~Maarten


-- 
Thanks and best regards,
Sumit Semwal
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma-buf: add reference counting for exporter module

[Sumit Semwal]

Hi Tomasz,

On 8 August 2012 19:36, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Aug 08, 2012 at 03:53:10PM +0200, Tomasz Stanislawski wrote:
 Hi Laurent,

 On 08/08/2012 03:35 PM, Laurent Pinchart wrote:
  Hi Tomasz,
 
  Thanks for the patch.
Thanks for the patch; may I ask you to split it into 2 patches (1
dma-buf and 1 drm) and submit? That ways, either Dave or I can take
the patches for either pull request.
With that, please feel free to add my Acked-by as well.
 
  On Wednesday 08 August 2012 12:17:41 Tomasz Stanislawski wrote:
  This patch adds reference counting on a module that exports dma-buf and
  implements its operations. This prevents the module from being unloaded
  while DMABUF file is in use.
 
  Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
  ---
   Documentation/dma-buf-sharing.txt  |3 ++-
   drivers/base/dma-buf.c |   10 +-
   drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
   drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
   drivers/gpu/drm/nouveau/nouveau_prime.c|1 +
   drivers/gpu/drm/radeon/radeon_prime.c  |1 +
   drivers/staging/omapdrm/omap_gem_dmabuf.c  |1 +
   include/linux/dma-buf.h|2 ++
   8 files changed, 18 insertions(+), 2 deletions(-)
 
 [snip]

  @@ -96,6 +98,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
  dma_buf_ops *ops, struct file *file;
 
 if (WARN_ON(!priv || !ops
  +|| !ops-owner

 Thank you for spotting this.
 I didn'y know that try_get_module returned true is module was NULL.

 BTW. Is it worth to add .owner = THIS_MODULE, to all dma_buf
 exporters in this patch?

 Yeah, I think that makes sense. Otherwise it might get lost somewhere,
 i.e. you can smash my Ack on this.
 -Daniel
 --
 Daniel Vetter
 Mail: dan...@ffwll.ch
 Mobile: +41 (0)79 365 57 48



-- 
Thanks and regards,
Sumit Semwal.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/3] dma-fence: dma-buf synchronization (v5)

[Sumit Semwal]

Hi Maarten,
On 27 July 2012 19:09, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 A dma-fence can be attached to a buffer which is being filled or consumed
 by hw, to allow userspace to pass the buffer without waiting to another
 device.  For example, userspace can call page_flip ioctl to display the
 next frame of graphics after kicking the GPU but while the GPU is still
 rendering.  The display device sharing the buffer with the GPU would
 attach a callback to get notified when the GPU's rendering-complete IRQ
 fires, to update the scan-out address of the display, without having to
 wake up userspace.
Since Rob is the original author of this (and I the next?), may I
request you to re-submit with his From: bit?

Rob / Daniel: comments on this series will help me line it up in
for-next, and maybe even for 3.7-rc.

Best regards,
~Sumit.
snip
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html