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 v2 01/11] dma-buf/sync_file: de-stage sync_file
Date: Wed, 27 Jan 2016 15:31:03 +0100	[thread overview]
Message-ID: <56A8D4A7.1070409@linux.intel.com> (raw)
In-Reply-To: <1453901439-19467-2-git-send-email-gustavo@padovan.org>

Hey,

Op 27-01-16 om 14:30 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> sync_file is useful to connect one or more fences to the file. The file is
> used by userspace to track fences.
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
Is there a value in keeping the abi unchanged?
If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read.

Looking at the patch, it seems you kept SYNC_IOC_WAIT, won't it be better to remove it, and only support waiting with polling?
The code for polling should already work.

It's very unclear what format @driver_data has. I kept it for compatibility with android, but it's not clear to me how a userspace consumer would print it.
Is there a usecase for this, or could it be removed from fence and sync_file?

~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://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 v2 01/11] dma-buf/sync_file: de-stage sync_file
Date: Wed, 27 Jan 2016 15:31:03 +0100	[thread overview]
Message-ID: <56A8D4A7.1070409@linux.intel.com> (raw)
In-Reply-To: <1453901439-19467-2-git-send-email-gustavo@padovan.org>

Hey,

Op 27-01-16 om 14:30 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> sync_file is useful to connect one or more fences to the file. The file is
> used by userspace to track fences.
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
Is there a value in keeping the abi unchanged?
If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read.

Looking at the patch, it seems you kept SYNC_IOC_WAIT, won't it be better to remove it, and only support waiting with polling?
The code for polling should already work.

It's very unclear what format @driver_data has. I kept it for compatibility with android, but it's not clear to me how a userspace consumer would print it.
Is there a usecase for this, or could it be removed from fence and sync_file?

~Maarten

  reply	other threads:[~2016-01-27 14:31 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 13:30 [PATCH v2 00/11] sync framework de-staging: part 2 - de-stage Gustavo Padovan
2016-01-27 13:30 ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 14:31   ` Maarten Lankhorst [this message]
2016-01-27 14:31     ` Maarten Lankhorst
2016-01-27 17:03     ` Gustavo Padovan
2016-01-27 17:03       ` Gustavo Padovan
2016-01-27 18:17       ` Emil Velikov
2016-01-27 20:25         ` Gustavo Padovan
2016-01-27 20:25           ` Gustavo Padovan
2016-01-27 21:41           ` Greg Hackmann
2016-01-27 21:41             ` Greg Hackmann
2016-01-28  9:23             ` Daniel Vetter
2016-01-28  9:23               ` Daniel Vetter
2016-01-29 17:46               ` Greg Hackmann
2016-01-27 13:30 ` [PATCH v2 02/11] staging/android: store last signaled value on sync timeline Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 03/11] staging/android: remove .fill_driver_data() timeline ops Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 04/11] staging/android: remove .{fence, timeline}_value_str() from timeline_ops Gustavo Padovan
2016-01-27 13:30   ` [PATCH v2 04/11] staging/android: remove .{fence,timeline}_value_str() " Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 05/11] staging/android: remove struct sync_timeline_ops Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 06/11] staging/android: remove sw_sync_timeline and sw_sync_pt Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 07/11] staging/android: remove sw_sync.[ch] files Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 08/11] staging/android: rename android_fence to timeline_fence Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 09/11] dma-buf/sync_timeline: de-stage sync_timeline Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 10/11] dma-buf/sync_file: bring debug back to sync file Gustavo Padovan
2016-01-27 13:30   ` Gustavo Padovan
2016-01-27 13:30 ` [PATCH v2 11/11] dma-buf/sync_file: bring sync_dump() back Gustavo Padovan
2016-01-27 13:30   ` 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=56A8D4A7.1070409@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.