Re: dma-buf: cleanup dma_buf_export() to make it easily extensible

[Sumit Semwal]

Hi Dan,

On 21 February 2015 at 00:56, Dan Carpenter dan.carpen...@oracle.com wrote:
 Hello Sumit Semwal,

 The patch 817bd7253291: dma-buf: cleanup dma_buf_export() to make it
 easily extensible from Jan 23, 2015, leads to the following static
 checker warning:

 drivers/staging/android/ion/ion.c:1112 ion_share_dma_buf()
 error: potentially dereferencing uninitialized 'buffer'.

Thanks for catching this! I am preparing a patch which I will submit asap.
 drivers/staging/android/ion/ion.c
   1103  struct dma_buf *ion_share_dma_buf(struct ion_client *client,
   1104  struct ion_handle 
 *handle)
   1105  {
   1106  struct ion_buffer *buffer;
^^
   1107  struct dma_buf *dmabuf;
   1108  bool valid_handle;
   1109  DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
   1110
     exp_info.ops = dma_buf_ops;
   1112  exp_info.size = buffer-size;
 ^^
   1113  exp_info.flags = O_RDWR;
   1114  exp_info.priv = buffer;
 ^^
 And here also.

   1115

 regards,
 dan carpenter



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: android: ion: fix wrong init of dma_buf_export_info

[Sumit Semwal]

Fixes: 817bd7253291 (dma-buf: cleanup dma_buf_export() to make it
easily extensible)

Stupid copy-paste from me in the above patch leads to the following static
checker warning:

drivers/staging/android/ion/ion.c:1112 ion_share_dma_buf()
error: potentially dereferencing uninitialized 'buffer'.

drivers/staging/android/ion/ion.c
  1103  struct dma_buf *ion_share_dma_buf(struct ion_client *client,
  1104  struct
ion_handle *handle)
  1105  {
  1106  struct ion_buffer *buffer;
   ^^
  1107  struct dma_buf *dmabuf;
  1108  bool valid_handle;
  1109  DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
  1110
    exp_info.ops = dma_buf_ops;
  1112  exp_info.size = buffer-size;
^^
  1113  exp_info.flags = O_RDWR;
  1114  exp_info.priv = buffer;
^^
And here also.

  1115

This patch corrects this stupidity.

Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 drivers/staging/android/ion/ion.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index a4297be8f12f..204860a36c29 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1108,11 +1108,6 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
bool valid_handle;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
 
-   exp_info.ops = dma_buf_ops;
-   exp_info.size = buffer-size;
-   exp_info.flags = O_RDWR;
-   exp_info.priv = buffer;
-
mutex_lock(client-lock);
valid_handle = ion_handle_validate(client, handle);
if (!valid_handle) {
@@ -1124,6 +1119,11 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
*client,
ion_buffer_get(buffer);
mutex_unlock(client-lock);
 
+   exp_info.ops = dma_buf_ops;
+   exp_info.size = buffer-size;
+   exp_info.flags = O_RDWR;
+   exp_info.priv = buffer;
+
dmabuf = dma_buf_export(exp_info);
if (IS_ERR(dmabuf)) {
ion_buffer_put(buffer);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCHv2 1/1] staging/ion: Add support to get ion handle from dma buf

[Sumit Semwal]

Hi Rohit,

On 6 January 2016 at 12:41, Rohit kumar <rohit...@samsung.com> wrote:
> Currently we can only import dma buf fd's to get ion_handle.
> Adding support to import dma buf handles to support kernel
> specific use cases.
>
> An example use case is in linux platforms such as Tizen, in which
> DRM-GEM is used for buffer management for graphics. It has gem_handle
> corresponding to a buffer and uses gem_name for sharing the buffer
> with other processes. However,it also uses dma_buf fd for 3d operations.
> For wayland, there are multiple calls for gem_handle to dma_buf fd
> conversion. So, we store dma_buf associated with buffer. But, there is
> no api for getting ion_handle from dma_buf. This patch exposes api to
> retrieve the ion handle from dma_buf for similar use cases. With this
> patch, we can integrate ION within DRM-GEM for buffer management and
> dma_buf sharing.
>
> Signed-off-by: Rohit kumar <rohit...@samsung.com>
> ---
> v2: Updated commit message with use case explanation, as suggested by
> Laura Abbott<labb...@redhat.com>
>
Thanks for this patch.

In general it looks good to me, but perhaps you should add related ION
tests for this as well? Once you add that and share for review, feel
free to add
Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>

>  drivers/staging/android/ion/ion.c |   21 +++--
>  drivers/staging/android/ion/ion.h |   20 
>  2 files changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index e237e9f..5509716 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -1151,16 +1151,13 @@ int ion_share_dma_buf_fd(struct ion_client *client, 
> struct ion_handle *handle)
>  }
>  EXPORT_SYMBOL(ion_share_dma_buf_fd);
>
> -struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd)
> +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> + struct dma_buf *dmabuf)
>  {
> -   struct dma_buf *dmabuf;
> struct ion_buffer *buffer;
> struct ion_handle *handle;
> int ret;
>
> -   dmabuf = dma_buf_get(fd);
> -   if (IS_ERR(dmabuf))
> -   return ERR_CAST(dmabuf);
> /* if this memory came from ion */
>
> if (dmabuf->ops != _buf_ops) {
> @@ -1199,6 +1196,18 @@ end:
>  }
>  EXPORT_SYMBOL(ion_import_dma_buf);
>
> +struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
> +{
> +   struct dma_buf *dmabuf;
> +
> +   dmabuf = dma_buf_get(fd);
> +   if (IS_ERR(dmabuf))
> +   return ERR_CAST(dmabuf);
> +
> +   return ion_import_dma_buf(client, dmabuf);
> +}
> +EXPORT_SYMBOL(ion_import_dma_buf_fd);
> +
>  static int ion_sync_for_device(struct ion_client *client, int fd)
>  {
> struct dma_buf *dmabuf;
> @@ -1306,7 +1315,7 @@ static long ion_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
> {
> struct ion_handle *handle;
>
> -   handle = ion_import_dma_buf(client, data.fd.fd);
> +   handle = ion_import_dma_buf_fd(client, data.fd.fd);
> if (IS_ERR(handle))
> ret = PTR_ERR(handle);
> else
> diff --git a/drivers/staging/android/ion/ion.h 
> b/drivers/staging/android/ion/ion.h
> index b860c5f..a1331fc 100644
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -192,14 +192,26 @@ struct dma_buf *ion_share_dma_buf(struct ion_client 
> *client,
>  int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle 
> *handle);
>
>  /**
> - * ion_import_dma_buf() - given an dma-buf fd from the ion exporter get 
> handle
> + * ion_import_dma_buf() - get ion_handle from dma-buf
> + * @client:the client
> + * @dmabuf:the dma-buf
> + *
> + * Get the ion_buffer associated with the dma-buf and return the ion_handle.
> + * If no ion_handle exists for this buffer, return newly created ion_handle.
> + * If dma-buf from another exporter is passed, return ERR_PTR(-EINVAL)
> + */
> +struct ion_handle *ion_import_dma_buf(struct ion_client *client,
> + struct dma_buf *dmabuf);
> +
> +/**
> + * ion_import_dma_buf_fd() - given a dma-buf fd from the ion exporter get 
> handle
>   * @client:the client
>   * @fd:the dma-buf fd
>   *
> - * Given an dma-buf fd that was allocated through ion via ion_share_dma_buf,
> - * import that fd and return a handle representing it.  If a dma-buf from
> + * Given an dma-buf fd 

Re: [PATCH 00/18] staging/android: clean up SW_SYNC

[Sumit Semwal]

On 9 June 2016 at 13:53, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Wed, Jun 08, 2016 at 10:45:34PM -0700, Greg Kroah-Hartman wrote:
>> On Wed, Jun 08, 2016 at 04:07:59PM -0300, Gustavo Padovan wrote:
>> > Hi Greg,
>> >
>> > Any comment on this?
>>
>> I am just starting to catch up on patches, please give me some time,
>> staging patches are at the bottom of my priority list, sorry.
>
> fwiw on the patch series:
>
> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Likewise, fwiw for this series,

Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>
> --
> 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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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-me...@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.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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-me...@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.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] dma-buf/sync_file: de-stage sync_file

[Sumit Semwal]

Thanks for the patch, Gustavo!

On 18 March 2016 at 19:49, Gustavo Padovan  wrote:
> From: Gustavo Padovan 
>
> sync_file is useful to connect one or more fences to the file. The file is
> used by userspace to track fences.
>
I think it is worthwhile to add relevant bits to the Documentation as
well - care to add relevant stuff to either Documentation/dma_buf.txt,
or to a file of its own? (I'd prefer the former, but would leave it
upto you.)

> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/Kconfig|   2 +
>  drivers/dma-buf/Kconfig|  11 +
>  drivers/dma-buf/Makefile   |   1 +
>  drivers/dma-buf/sync_file.c| 382 
> +
>  drivers/staging/android/Kconfig|   1 +
>  drivers/staging/android/sync.c | 362 ---
>  drivers/staging/android/sync.h |  92 +
>  drivers/staging/android/sync_debug.c   |   1 +
>  include/linux/sync_file.h  | 106 ++
>  .../uapi/sync.h => include/uapi/linux/sync_file.h  |   0
>  10 files changed, 506 insertions(+), 452 deletions(-)
>  create mode 100644 drivers/dma-buf/Kconfig
>  create mode 100644 drivers/dma-buf/sync_file.c
>  create mode 100644 include/linux/sync_file.h
>  rename drivers/staging/android/uapi/sync.h => include/uapi/linux/sync_file.h 
> (100%)
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index d2ac339..430f761 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -114,6 +114,8 @@ source "drivers/rtc/Kconfig"
>
>  source "drivers/dma/Kconfig"
>
> +source "drivers/dma-buf/Kconfig"
> +
>  source "drivers/dca/Kconfig"
>
>  source "drivers/auxdisplay/Kconfig"
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> new file mode 100644
> index 000..9824bc4
> --- /dev/null
> +++ b/drivers/dma-buf/Kconfig
> @@ -0,0 +1,11 @@
> +menu "DMABUF options"
> +
> +config SYNC_FILE
> +   bool "sync_file support for fences"
> +   default n
> +   select ANON_INODES
> +   select DMA_SHARED_BUFFER
> +   ---help---
> + This option enables the fence framework synchronization to export
> + sync_files to userspace that can represent one or more fences.
> +endmenu
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index 57a675f..4a424ec 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1 +1,2 @@
>  obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
> +obj-$(CONFIG_SYNC_FILE)+= sync_file.o
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> new file mode 100644
> index 000..df786a2
> --- /dev/null
> +++ b/drivers/dma-buf/sync_file.c
> @@ -0,0 +1,382 @@
> +/*
> + * drivers/dma-buf/sync_file.c
> + *
> + * Copyright (C) 2012 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct file_operations sync_file_fops;
> +
> +static struct sync_file *sync_file_alloc(int size, const char *name)
> +{
> +   struct sync_file *sync_file;
> +
> +   sync_file = kzalloc(size, GFP_KERNEL);
> +   if (!sync_file)
> +   return NULL;
> +
> +   sync_file->file = anon_inode_getfile("sync_file", _file_fops,
> +sync_file, 0);
> +   if (IS_ERR(sync_file->file))
> +   goto err;
> +
> +   kref_init(_file->kref);
> +   strlcpy(sync_file->name, name, sizeof(sync_file->name));
> +
> +   init_waitqueue_head(_file->wq);
> +
> +   return sync_file;
> +
> +err:
> +   kfree(sync_file);
> +   return NULL;
> +}
> +
> +static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
> +{
> +   struct sync_file_cb *check;
> +   struct sync_file *sync_file;
> +
> +   check = container_of(cb, struct sync_file_cb, cb);
> +   sync_file = check->sync_file;
> +
> +   if (atomic_dec_and_test(_file->status))
> +   wake_up_all(_file->wq);
> +}
> +
> +/* TODO: implement a create which takes more that one fence */
> +struct sync_file *sync_file_create(const char *name, struct fence *fence)
> +{
> +   struct sync_file *sync_file;
> +
> +   sync_file = sync_file_alloc(offsetof(struct sync_file, 

Re: [PATCH] MAINTAINERS: add entry for the Sync File Framework

[Sumit Semwal]

Hi Gustavo,

On 11 May 2016 at 19:15, Gustavo Padovan <gust...@padovan.org> wrote:
> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>
> Add Gustavo as maintainer for the Sync File Framework. Sumit is
> co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's
> tree as base.
>
> Cc: Sumit Semwal <sumit.sem...@linaro.org>
> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>

With the de-staging patches going through staging,  perhaps we should add an
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>
and request Greg to take it via the same?
> ---
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8c10b4c..0abc9c3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3677,6 +3677,16 @@ F:   include/linux/*fence.h
>  F: Documentation/dma-buf-sharing.txt
>  T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
>
> +SYNC FILE FRAMEWORK
> +M: Gustavo Padovan <gust...@padovan.org>
> +S: Maintained
> +L: linux-me...@vger.kernel.org
> +L: dri-de...@lists.freedesktop.org
> +F: drivers/dma-buf/sync_file.c
> +F: include/linux/sync_file.h
> +F: Documentation/sync_file.txt
> +T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
> +
>  DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
>  M: Vinod Koul <vinod.k...@intel.com>
>  L: dmaeng...@vger.kernel.org
> --
> 2.5.5
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Linaro-mm-sig] [RESEND][PATCH 0/5] Ion cleanup

[Sumit Semwal]

Hi Laura,

On 14 August 2016 at 14:17, Benjamin Gaignard
<benjamin.gaign...@linaro.org> wrote:
> This series of patches look good for me, thanks for the clean up
>
> Reviewed-by: Benjamin Gaignard <benjamin.gaign...@linaro.org>
>
> 2016-08-08 18:52 GMT+02:00 Laura Abbott <labb...@redhat.com>:
>> I never saw any feedback or action on these patches so this is a resend.
>> Probably hit the window when everyone was busy/traveling.
>>
Looks good to me; please feel free to apply my
Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>

>> ---
>>
>> Hi,
>>
>> This is some clean up of old Ion interfaces and APIs. These are interfaces 
>> that
>> mostly existed before dma_buf was well integrated into the kernel along with
>> reservations for board files.
>>
>> If there are objections to deletion I expect it to turn into a discussion 
>> about
>> what other APIs need to be extended.
>>
>> Thanks,
>> Laura
>>
Best,
Sumit.

>> Laura Abbott (5):
>>   staging: android: ion: Get rid of ion_sg_table
>>   staging: android: ion: Drop ion_phys interface
>>   staging: android: ion: Get rid of map_dma/unmap_dma
>>   staging: android: ion: Drop ion_carveout_allocate definitions
>>   staging: android: ion: Get rid of ion_reserve
>>
>>  drivers/staging/android/ion/ion.c   | 103 
>> ++--
>>  drivers/staging/android/ion/ion.h   |  41 --
>>  drivers/staging/android/ion/ion_carveout_heap.c |  33 +---
>>  drivers/staging/android/ion/ion_chunk_heap.c|  17 +---
>>  drivers/staging/android/ion/ion_cma_heap.c  |  34 +---
>>  drivers/staging/android/ion/ion_priv.h  |  30 +--
>>  drivers/staging/android/ion/ion_system_heap.c   |  44 +-
>>  7 files changed, 19 insertions(+), 283 deletions(-)
>>
>> --
>> 2.5.5
>>
>> ___
>> Linaro-mm-sig mailing list
>> linaro-mm-...@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
>
>
> --
> Benjamin Gaignard
>
> Graphic Study Group
>
> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: android: ion: Make ION_OF depend on OF_ADDRESS

[Sumit Semwal]

Hi Laura,

On 14 September 2016 at 21:03, Laura Abbott <labb...@redhat.com> wrote:
> The Ion platform code uses of_platform_device_create which has
> dependencies on OF_ADDRESS. Depending on OF is not sufficient
>
Thanks for the patch; looks good to me.
Please feel free to apply my
Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>

Best,
Sumit.

> Building sparc64:allmodconfig ... failed
> --
> Error log:
> ...
> drivers/built-in.o: In function `ion_parse_dt':
> (.text+0x11aa2c): undefined reference to `of_platform_device_create'
>
> Add a dependency on OF_ADDRESS
>
> Reported-by: Guenter Roeck <li...@roeck-us.net>
> Signed-off-by: Laura Abbott <labb...@redhat.com>
> ---
> Based on next-20160914
> ---
>  drivers/staging/android/ion/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/Kconfig 
> b/drivers/staging/android/ion/Kconfig
> index 8a54ddc..9410554 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -43,7 +43,7 @@ source "drivers/staging/android/ion/hisilicon/Kconfig"
>
>  config ION_OF
> bool "Devicetree support for Ion"
> -   depends on ION && OF
> +   depends on ION && OF_ADDRESS
> help
>   Provides base support for defining Ion heaps in devicetree
>   and setting them up. Also includes functions for platforms
> --
> 2.7.4
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH -next] staging: android: ion: Fix return value check in hi6220_ion_probe()

[Sumit Semwal]

On 16 September 2016 at 07:40, Laura Abbott <labb...@redhat.com> wrote:
> On 09/14/2016 07:20 PM, Wei Yongjun wrote:
>>
>> From: Wei Yongjun <weiyongj...@huawei.com>
>>
>> In case of error, the function ion_device_create() returns ERR_PTR() and
>> never returns NULL. The NULL test in the return value check should be
>> replaced with IS_ERR().
>>
>
> Acked-by: Laura Abbott <labb...@redhat.com>
>
Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>
>
>> Signed-off-by: Wei Yongjun <weiyongj...@huawei.com>
>> ---
>>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> index f392db2..659aa71 100644
>> --- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> +++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> @@ -49,8 +49,8 @@ static int hi6220_ion_probe(struct platform_device
>> *pdev)
>> platform_set_drvdata(pdev, ipdev);
>>
>> ipdev->idev = ion_device_create(NULL);
>> -   if (!ipdev->idev)
>> -   return -ENOMEM;
>> +   if (IS_ERR(ipdev->idev))
>> +   return PTR_ERR(ipdev->idev);
>>
>> ipdev->data = ion_parse_dt(pdev, hisi_heaps);
>> if (IS_ERR(ipdev->data))
>>
>>
>>
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: android ion/hisi: fix dependencies

[Sumit Semwal]

On 16 September 2016 at 07:40, Laura Abbott <labb...@redhat.com> wrote:
> On 09/15/2016 08:57 AM, Arnd Bergmann wrote:
>>
>> The newly added Hi6220 Ion code fails to build when the ION_OF helpers
>> are not present:
>>
>> drivers/staging/android/ion/hisilicon/hi6220_ion.o: In function
>> `hi6220_ion_remove':
>> hi6220_ion.c:(.text.hi6220_ion_remove+0x4c): undefined reference to
>> `ion_destroy_platform_data'
>> drivers/staging/android/ion/hisilicon/hi6220_ion.o: In function
>> `hi6220_ion_probe':
>> hi6220_ion.c:(.text.hi6220_ion_probe+0x5c): undefined reference to
>> `ion_parse_dt'
>> hi6220_ion.c:(.text.hi6220_ion_probe+0xf8): undefined reference to
>> `ion_destroy_platform_data'
>>
>> This selects the symbol when needed.
>>
>
> Acked-by: Laura Abbott <labb...@redhat.com>
>
Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>
>
>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>> Fixes: 2b40182a19bc ("staging: android: ion: Add ion driver for Hi6220 SoC
>> platform")
>> ---
>>  drivers/staging/android/ion/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/staging/android/ion/Kconfig
>> b/drivers/staging/android/ion/Kconfig
>> index 94105544feef..c8fb4134c55d 100644
>> --- a/drivers/staging/android/ion/Kconfig
>> +++ b/drivers/staging/android/ion/Kconfig
>> @@ -36,6 +36,7 @@ config ION_TEGRA
>>  config ION_HISI
>> tristate "Ion for Hisilicon"
>> depends on ARCH_HISI && ION
>> +   select ION_OF
>> help
>>   Choose this option if you wish to use ion on Hisilicon Platform.
>>
>>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH for-4.4 04/19] x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic

[Sumit Semwal]

From: Vitaly Kuznetsov <vkuzn...@redhat.com>

[ Upstream commit 59107e2f48831daedc46973ce4988605ab066de3 ]

There is a feature in Hyper-V ('Debug-VM --InjectNonMaskableInterrupt')
which injects NMI to the guest. We may want to crash the guest and do kdump
on this NMI by enabling unknown_nmi_panic. To make kdump succeed we need to
allow the kdump kernel to re-establish VMBus connection so it will see
VMBus devices (storage, network,..).

To properly unload VMBus making it possible to start over during kdump we
need to do the following:

 - Send an 'unload' message to the hypervisor. This can be done on any CPU
   so we do this the crashing CPU.

 - Receive the 'unload finished' reply message. WS2012R2 delivers this
   message to the CPU which was used to establish VMBus connection during
   module load and this CPU may differ from the CPU sending 'unload'.

Receiving a VMBus message means the following:

 - There is a per-CPU slot in memory for one message. This slot can in
   theory be accessed by any CPU.

 - We get an interrupt on the CPU when a message was placed into the slot.

 - When we read the message we need to clear the slot and signal the fact
   to the hypervisor. In case there are more messages to this CPU pending
   the hypervisor will deliver the next message. The signaling is done by
   writing to an MSR so this can only be done on the appropriate CPU.

To avoid doing cross-CPU work on crash we have vmbus_wait_for_unload()
function which checks message slots for all CPUs in a loop waiting for the
'unload finished' messages. However, there is an issue which arises when
these conditions are met:

 - We're crashing on a CPU which is different from the one which was used
   to initially contact the hypervisor.

 - The CPU which was used for the initial contact is blocked with interrupts
   disabled and there is a message pending in the message slot.

In this case we won't be able to read the 'unload finished' message on the
crashing CPU. This is reproducible when we receive unknown NMIs on all CPUs
simultaneously: the first CPU entering panic() will proceed to crash and
all other CPUs will stop themselves with interrupts disabled.

The suggested solution is to handle unknown NMIs for Hyper-V guests on the
first CPU which gets them only. This will allow us to rely on VMBus
interrupt handler being able to receive the 'unload finish' message in
case it is delivered to a different CPU.

The issue is not reproducible on WS2016 as Debug-VM delivers NMI to the
boot CPU only, WS2012R2 and earlier Hyper-V versions are affected.

Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Acked-by: K. Y. Srinivasan <k...@microsoft.com>
Cc: de...@linuxdriverproject.org
Cc: Haiyang Zhang <haiya...@microsoft.com>
Link: http://lkml.kernel.org/r/20161202100720.28121-1-vkuzn...@redhat.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Signed-off-by: Sumit Semwal <sumit.sem...@linaro.org>
---
 arch/x86/kernel/cpu/mshyperv.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index cfc4a96..83b5f7a 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct ms_hyperv_info ms_hyperv;
 EXPORT_SYMBOL_GPL(ms_hyperv);
@@ -157,6 +158,26 @@ static unsigned char hv_get_nmi_reason(void)
return 0;
 }
 
+#ifdef CONFIG_X86_LOCAL_APIC
+/*
+ * Prior to WS2016 Debug-VM sends NMIs to all CPUs which makes
+ * it dificult to process CHANNELMSG_UNLOAD in case of crash. Handle
+ * unknown NMI on the first CPU which gets it.
+ */
+static int hv_nmi_unknown(unsigned int val, struct pt_regs *regs)
+{
+   static atomic_t nmi_cpu = ATOMIC_INIT(-1);
+
+   if (!unknown_nmi_panic)
+   return NMI_DONE;
+
+   if (atomic_cmpxchg(_cpu, -1, raw_smp_processor_id()) != -1)
+   return NMI_HANDLED;
+
+   return NMI_DONE;
+}
+#endif
+
 static void __init ms_hyperv_init_platform(void)
 {
/*
@@ -182,6 +203,9 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n",
lapic_timer_frequency);
}
+
+   register_nmi_handler(NMI_UNKNOWN, hv_nmi_unknown, NMI_FLAG_FIRST,
+"hv_nmi_unknown");
 #endif
 
if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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: [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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/3] staging: android: ion: Minor clean ups and fixes

[Sumit Semwal]

Hi Archit,

On 17 May 2017 at 13:45, Archit Taneja <arch...@codeaurora.org> wrote:
> The recent ION clean ups introduced some leftover code that can be
> removed, and a bug that comes up if the call to dma_buf_map_attachment()
> from an importer fails. Fix these.
>
> Archit Taneja (3):
>   staging: android: ion: Remove unused members from ion_buffer
>   staging: android: ion: Remove ION_FLAG_CACHED_NEEDS_SYNC
>   staging: android: ion: Avoid calling free_duped_table() twice
>
Thanks for these patches! Please feel free to add my
Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>

>  drivers/staging/android/ion/ion.c  | 14 +++---
>  drivers/staging/android/ion/ion.h  | 14 --
>  drivers/staging/android/uapi/ion.h |  6 --
>  3 files changed, 3 insertions(+), 31 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>

Best,
Sumit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] staging: android: ion: Combine cache and uncache pools

[Sumit Semwal]

Hello Yisheng,

On 7 February 2018 at 09:29, Yisheng Xie <xieyishe...@huawei.com> wrote:
> Now we call dma_map in the dma_buf API callbacks and handle explicit
> caching by the dma_buf sync API, which make cache and uncache pools
> in the same handling flow, which can be combined.
>
Thanks for the patch! Perhaps you should also put the version history
here, to capture the changes from previous versions?

> Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
With that done, please feel free to add
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>

> ---
>  drivers/staging/android/ion/ion.c |  5 --
>  drivers/staging/android/ion/ion.h | 13 +
>  drivers/staging/android/ion/ion_page_pool.c   |  5 +-
>  drivers/staging/android/ion/ion_system_heap.c | 76 
> +--
>  4 files changed, 16 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 461b193..c094be2 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -33,11 +33,6 @@
>  static struct ion_device *internal_dev;
>  static int heap_id;
>
> -bool ion_buffer_cached(struct ion_buffer *buffer)
> -{
> -   return !!(buffer->flags & ION_FLAG_CACHED);
> -}
> -
>  /* this function should only be called while dev->lock is held */
>  static void ion_buffer_add(struct ion_device *dev,
>struct ion_buffer *buffer)
> diff --git a/drivers/staging/android/ion/ion.h 
> b/drivers/staging/android/ion/ion.h
> index 1bc443f..ea08978 100644
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -185,14 +185,6 @@ struct ion_heap {
>  };
>
>  /**
> - * ion_buffer_cached - this ion buffer is cached
> - * @buffer:buffer
> - *
> - * indicates whether this ion buffer is cached
> - */
> -bool ion_buffer_cached(struct ion_buffer *buffer);
> -
> -/**
>   * ion_device_add_heap - adds a heap to the ion device
>   * @heap:  the heap to add
>   */
> @@ -302,7 +294,6 @@ size_t ion_heap_freelist_shrink(struct ion_heap *heap,
>   * @gfp_mask:  gfp_mask to use from alloc
>   * @order: order of pages in the pool
>   * @list:  plist node for list of pools
> - * @cached:it's cached pool or not
>   *
>   * Allows you to keep a pool of pre allocated pages to use from your heap.
>   * Keeping a pool of pages that is ready for dma, ie any cached mapping have
> @@ -312,7 +303,6 @@ size_t ion_heap_freelist_shrink(struct ion_heap *heap,
>  struct ion_page_pool {
> int high_count;
> int low_count;
> -   bool cached;
> struct list_head high_items;
> struct list_head low_items;
> struct mutex mutex;
> @@ -321,8 +311,7 @@ struct ion_page_pool {
> struct plist_node list;
>  };
>
> -struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int 
> order,
> -  bool cached);
> +struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int 
> order);
>  void ion_page_pool_destroy(struct ion_page_pool *pool);
>  struct page *ion_page_pool_alloc(struct ion_page_pool *pool);
>  void ion_page_pool_free(struct ion_page_pool *pool, struct page *page);
> diff --git a/drivers/staging/android/ion/ion_page_pool.c 
> b/drivers/staging/android/ion/ion_page_pool.c
> index 6d2caf0..db8f614 100644
> --- a/drivers/staging/android/ion/ion_page_pool.c
> +++ b/drivers/staging/android/ion/ion_page_pool.c
> @@ -123,8 +123,7 @@ int ion_page_pool_shrink(struct ion_page_pool *pool, 
> gfp_t gfp_mask,
> return freed;
>  }
>
> -struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int 
> order,
> -  bool cached)
> +struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int 
> order)
>  {
> struct ion_page_pool *pool = kmalloc(sizeof(*pool), GFP_KERNEL);
>
> @@ -138,8 +137,6 @@ struct ion_page_pool *ion_page_pool_create(gfp_t 
> gfp_mask, unsigned int order,
> pool->order = order;
> mutex_init(>mutex);
> plist_node_init(>list, order);
> -   if (cached)
> -   pool->cached = true;
>
> return pool;
>  }
> diff --git a/drivers/staging/android/ion/ion_system_heap.c 
> b/drivers/staging/android/ion/ion_system_heap.c
> index bc19cdd..701eb9f 100644
> --- a/drivers/staging/android/ion/ion_system_heap.c
> +++ b/drivers/staging/android/ion/ion_system_heap.c
> @@ -41,31 +41,16 @@ static inline unsigned int order_to_size(int order)
>
>  s

Re: [PATCH 1/2] staging: android: ion: Cleanup ion_page_pool_alloc_pages

[Sumit Semwal]

Hi Yisheng,

On 7 February 2018 at 09:29, Yisheng Xie <xieyishe...@huawei.com> wrote:
> ion_page_pool_alloc_pages calls alloc_pages to allocate pages for page
> pools. If alloc_pages return NULL, it will return NULL, or it will
> return the pages allocate from alloc_pages. So we can just return
> alloc_pages without any judgement.
>
With patch history comment addressed (same as the other patch you sent),
> Signed-off-by: Yisheng Xie <xieyishe...@huawei.com>
Please feel free to add my
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>

> ---
>  drivers/staging/android/ion/ion_page_pool.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion_page_pool.c 
> b/drivers/staging/android/ion/ion_page_pool.c
> index e3a6e32..6d2caf0 100644
> --- a/drivers/staging/android/ion/ion_page_pool.c
> +++ b/drivers/staging/android/ion/ion_page_pool.c
> @@ -11,13 +11,9 @@
>
>  #include "ion.h"
>
> -static void *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
> +static inline struct page *ion_page_pool_alloc_pages(struct ion_page_pool 
> *pool)
>  {
> -   struct page *page = alloc_pages(pool->gfp_mask, pool->order);
> -
> -   if (!page)
> -   return NULL;
> -   return page;
> +   return alloc_pages(pool->gfp_mask, pool->order);
>  }
>
>  static void ion_page_pool_free_pages(struct ion_page_pool *pool,
> --
> 1.7.12.4
>
Best,
Sumit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: android: ion: remove duplicate buffer field initializes

[Sumit Semwal]

Hello Todd,

Thanks for the patch.

On 21 April 2018 at 08:26, Todd Poynor <toddpoy...@google.com> wrote:
> As a result of various previous patches, ion_buffer_create() now
> has two sets of identical statements for initializing two fields of
> the buffer struct, next to each other.  Remove one set.
>
> Move the initialization of these two fields together with the
> statements that initialize the other two fields from the function
> parameters, prior to the heap allocate() call, for consistency.
>
> Signed-off-by: Todd Poynor <toddpoy...@google.com>

Acked-by: Sumit Semwal <sumit.sem...@linaro.org>

> ---
>  drivers/staging/android/ion/ion.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index e74db7902549..269a431646be 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -74,6 +74,8 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
> *heap,
>
> buffer->heap = heap;
> buffer->flags = flags;
> +   buffer->dev = dev;
> +   buffer->size = len;
>
> ret = heap->ops->allocate(heap, buffer, len, flags);
>
> @@ -93,11 +95,7 @@ static struct ion_buffer *ion_buffer_create(struct 
> ion_heap *heap,
> goto err1;
> }
>
> -   buffer->dev = dev;
> -   buffer->size = len;
>
> -   buffer->dev = dev;
> -   buffer->size = len;
> INIT_LIST_HEAD(>attachments);
> mutex_init(>lock);
> mutex_lock(>buffer_lock);
> --
> 2.17.0.484.g0c8726318c-goog
>


Best,
Sumit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap

[Sumit Semwal]

Hello everyone,

Sincere apologies for chiming in a bit late here, but was off due to
some health issues.

Also, adding Daniel Vetter to the mix, since he has been one of the
core guys who shaped up dma-buf as it is today.

On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis  wrote:

 On 1/21/19 5:22 AM, Brian Starkey wrote:
  Hi,
 
  Sorry for being a bit sporadic on this. I was out travelling last week
  with little time for email.
 
  On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
  On 1/17/19 7:11 PM, Liam Mark wrote:
  On Thu, 17 Jan 2019, Andrew F. Davis wrote:
 
  On 1/16/19 4:54 PM, Liam Mark wrote:
  On Wed, 16 Jan 2019, Andrew F. Davis wrote:
 
  On 1/16/19 9:19 AM, Brian Starkey wrote:
  Hi :-)
 
  On Tue, Jan 15, 2019 at 12:40:16PM
-0600, Andrew F. Davis wrote:
  On 1/15/19 12:38 PM, Andrew F.
Davis wrote:
  On 1/15/19 11:45 AM, Liam Mark wrote:
  On Tue, 15 Jan 2019,
Andrew F. Davis wrote:
 
  On 1/14/19 11:13 AM,
Liam Mark wrote:
  On Fri, 11 Jan
2019, Andrew F. Davis wrote:
 
  Buffers may
not be mapped from the CPU so skip cache maintenance here.
  Accesses
from the CPU to a cached heap should be bracketed with
 
{begin,end}_cpu_access calls so maintenance should not be needed
anyway.
 
 
Signed-off-by: Andrew F. Davis 
  ---
 
drivers/staging/android/ion/ion.c | 7 ---
   1 file
changed, 4 insertions(+), 3 deletions(-)
 
  diff --git
a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
  index
14e48f6eb734..09cb5a8e2b09 100644
  ---
a/drivers/staging/android/ion/ion.c
  +++
b/drivers/staging/android/ion/ion.c
  @@ -261,8
+261,8 @@ static struct sg_table *ion_map_dma_buf(struct
dma_buf_attachment *attachment,
 
table = a-table;
 
  - if
(!dma_map_sg(attachment-dev, table-sgl, table-nents,
  -
 direction))
  + if
(!dma_map_sg_attrs(attachment-dev, table-sgl, table-nents,
  +
   direction, DMA_ATTR_SKIP_CPU_SYNC))
 
  Unfortunately I
don't think you can do this for a couple reasons.
  You can't rely
on {begin,end}_cpu_access calls to do cache maintenance.
  If the calls to
{begin,end}_cpu_access were made before the call to
  dma_buf_attach
then there won't have been a device attached so the calls
  to
{begin,end}_cpu_access won't have done any cache maintenance.
 
 
  That should be okay
though, if you have no attachments (or all
  attachments are
IO-coherent) then there is no need for cache
  maintenance. Unless
you mean a sequence where a non-io-coherent device
  is attached later
after data has already been written. Does that
  sequence need supporting?
 
  Yes, but also I think
there are cases where CPU access can happen before
  in Android, but I will
focus on later for now.
 
  DMA-BUF doesn't have
to allocate the backing
  memory until
map_dma_buf() time, and that should only happen after all
  the devices have
attached so it can know where to put the buffer. So we
  shouldn't expect any
CPU access to buffers before all the devices are
  attached and mapped, right?
 
 
  Here is an example where
CPU access can happen later in Android.
 
  Camera device records
video - software post processing - video device
  (who does compression of
raw data) and writes to a file
 
  In this example assume
the buffer is cached and the devices are not
  IO-coherent (quite common).
 
 
  This is the start of the
problem, having cached mappings of memory that
  is also being accessed
non-coherently is going to cause issues one way
  or another. On top of the
speculative cache fills that have to be
  constantly fought back
against with CMOs like below; some coherent
  interconnects behave badly
when you mix coherent and non-coherent access
  (snoop filters get messed up).
 
  The solution is to either
always have the addresses marked non-coherent
  (like device memory, no-map
carveouts), or if you really want to use
  regular system memory
allocated at runtime, then all cached mappings of
  it need to be dropped, even
the kernel logical address (area as painful
  as that would be).
 
  Ouch :-( I wasn't aware about these
potential interconnect issues. How
  "real" is that? It seems that we
aren't really hitting that today on
  real devices.
 
 
  Sadly there is at least one real device
like this now (TI AM654). We
  spent some time working with the ARM
interconnect spec designers to see
  if this was allowed behavior, final
conclusion was mixing coherent and
  non-coherent accesses is never a good
idea.. So we have been working to
  try to minimize any cases of mixed
attributes [0], if a region is
  coherent then everyone in the system
needs to treat it as such and
  vice-versa, even clever CMO that work on
other systems wont save you
  here. :(
 
  [0]
https://github.com/ARM-software/arm-trusted-firmware/pull/1553
 
 
  "Never a good idea" - but I think it should still be well defined by
  the ARMv8 ARM (Section B2.8). Does this apply to your system?
 
  "If the mismatched attributes for a memory location all assign the
  same shareability attribute to