All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Gustavo Padovan <gustavo@padovan.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org,
	"Daniel Stone" <daniels@collabora.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Riley Andrews" <riandrews@android.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	"Arve Hjønnevåg" <arve@android.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"John Harrison" <John.C.Harrison@Intel.com>
Subject: Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO
Date: Thu, 3 Mar 2016 15:59:45 +0100	[thread overview]
Message-ID: <56D85161.6070503@linux.intel.com> (raw)
In-Reply-To: <1457015665-7534-1-git-send-email-gustavo@padovan.org>

Op 03-03-16 om 15:34 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer
>
> Now num_fences can be filled by the caller to inform how many fences it
> wants to retrieve from the kernel. If the num_fences passed is greater
> than zero info->sync_fence_info should point to a buffer with enough space
> to fit all fences.
>
> However if num_fences passed to the kernel is 0, the kernel will reply
> with number of fences of the sync_file.
>
> Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
> in a first call with num_fences = 0 userspace will receive the actual
> number of fences in the num_fences filed.
>
> Then it can allocate a buffer with the correct size on sync_fence_info and
> call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
> in the sync_file.
>
> Also, info->sync_fence_info was converted to __u64 pointer to prevent
> 32bit compatibility issues.
For this patch and 6/6:

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Gustavo Padovan <gustavo@padovan.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
	dri-devel@lists.freedesktop.org,
	"Daniel Stone" <daniels@collabora.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Riley Andrews" <riandrews@android.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Rob Clark" <robdclark@gmail.com>,
	"Greg Hackmann" <ghackmann@google.com>,
	"John Harrison" <John.C.Harrison@Intel.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>
Subject: Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO
Date: Thu, 3 Mar 2016 15:59:45 +0100	[thread overview]
Message-ID: <56D85161.6070503@linux.intel.com> (raw)
In-Reply-To: <1457015665-7534-1-git-send-email-gustavo@padovan.org>

Op 03-03-16 om 15:34 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer
>
> Now num_fences can be filled by the caller to inform how many fences it
> wants to retrieve from the kernel. If the num_fences passed is greater
> than zero info->sync_fence_info should point to a buffer with enough space
> to fit all fences.
>
> However if num_fences passed to the kernel is 0, the kernel will reply
> with number of fences of the sync_file.
>
> Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
> in a first call with num_fences = 0 userspace will receive the actual
> number of fences in the num_fences filed.
>
> Then it can allocate a buffer with the correct size on sync_fence_info and
> call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
> in the sync_file.
>
> Also, info->sync_fence_info was converted to __u64 pointer to prevent
> 32bit compatibility issues.
For this patch and 6/6:

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

  reply	other threads:[~2016-03-03 14:59 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 19:52 [PATCH v6 1/6] staging/android: add num_fences field to struct sync_file_info Gustavo Padovan
2016-03-02 19:52 ` Gustavo Padovan
2016-03-02 19:52 ` [PATCH v6 2/6] staging/android: rename SYNC_IOC_FENCE_INFO Gustavo Padovan
2016-03-02 19:52   ` Gustavo Padovan
2016-03-02 19:52 ` [PATCH v6 3/6] staging/android: remove redundant comments on sync_merge_data Gustavo Padovan
2016-03-02 19:52   ` Gustavo Padovan
2016-03-02 19:52 ` [PATCH v6 4/6] staging/android: align struct sync_merge_data to a multiple of 64-bits Gustavo Padovan
2016-03-02 19:52   ` Gustavo Padovan
2016-03-02 21:40   ` Gustavo Padovan
2016-03-02 21:40     ` Gustavo Padovan
2016-03-02 19:52 ` [PATCH v6 5/6] staging/android: refactor SYNC_IOC_FILE_INFO Gustavo Padovan
2016-03-02 19:52   ` Gustavo Padovan
2016-03-03  9:29   ` Maarten Lankhorst
2016-03-03 14:34   ` [PATCH] " Gustavo Padovan
2016-03-03 14:34     ` Gustavo Padovan
2016-03-03 14:59     ` Maarten Lankhorst [this message]
2016-03-03 14:59       ` Maarten Lankhorst
2016-03-02 19:52 ` [PATCH v6 6/6] staging/android: add flags member to sync ioctl structs Gustavo Padovan
2016-03-02 21:51   ` [PATCH] " Gustavo Padovan
2016-03-02 21:51     ` Gustavo Padovan
2016-03-03 14:37     ` Gustavo Padovan
2016-03-03 14:37       ` Gustavo Padovan
2016-03-03 16:17       ` Greg Kroah-Hartman
2016-03-03 16:17         ` Greg Kroah-Hartman
2016-03-03 19:14         ` Gustavo Padovan
2016-03-03 19:42           ` Gustavo Padovan
2016-03-03 19:42             ` Gustavo Padovan
2016-03-03 20:01         ` Ville Syrjälä
2016-03-03 20:01           ` Ville Syrjälä
2016-03-03 20:54         ` Rob Clark
2016-03-03 20:54           ` Rob Clark
2016-03-03 21:47           ` Rob Clark
2016-03-03 21:47             ` Rob Clark
2016-03-04 16:40         ` Daniel Vetter
2016-03-04 16:40           ` Daniel Vetter
2016-03-11 21:59           ` Greg Kroah-Hartman
2016-03-05 12:58         ` Emil Velikov
2016-03-05 12:58           ` Emil Velikov
  -- strict thread matches above, loose matches on Subject: below --
2016-02-26 18:31 [PATCH v4 4/5] staging/android: refactor SYNC_IOC_FILE_INFO Gustavo Padovan
2016-02-26 21:00 ` [PATCH] " Gustavo Padovan
2016-02-26 21:00   ` Gustavo Padovan
2016-02-27  2:18   ` Emil Velikov
2016-02-27  2:18     ` Emil Velikov
2016-02-27 15:25     ` Gustavo Padovan
2016-02-27 15:25       ` Gustavo Padovan
2016-02-29  8:34       ` Emil Velikov
2016-02-29  8:34         ` Emil Velikov
2016-02-29  8:26   ` Maarten Lankhorst
2016-02-29  8:26     ` Maarten Lankhorst
2016-02-29 22:08     ` Gustavo Padovan
2016-02-29 22:08       ` Gustavo Padovan
2016-03-01  8:35       ` Maarten Lankhorst
2016-03-01  8:35         ` Maarten Lankhorst
2016-03-01 11:55         ` Gustavo Padovan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D85161.6070503@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=John.C.Harrison@Intel.com \
    --cc=arve@android.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=gustavo@padovan.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riandrews@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.