from:"Gustavo Padovan"

Re: [PATCH] android: fix warning when releasing active sync point

2015-12-15 Thread Gustavo Padovan

2015-12-15 Daniel Vetter :

> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokhov wrote:
> > Userspace can close the sync device while there are still active fence
> > points, in which case kernel produces the following warning:
> > 
> > [   43.853176] [ cut here ]
> > [   43.857834] WARNING: CPU: 0 PID: 892 at 
> > /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439
> >  android_fence_release+0x88/0x104()
> > [   43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 
> > 3.18.0-07661-g0550ce9 #1
> > [   43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
> > [   43.885834] Call trace:
> > [   43.888294] [] dump_backtrace+0x0/0x10c
> > [   43.893697] [] show_stack+0x10/0x1c
> > [   43.898756] [] dump_stack+0x74/0xb8
> > [   43.903814] [] warn_slowpath_common+0x84/0xb0
> > [   43.909736] [] warn_slowpath_null+0x14/0x20
> > [   43.915482] [] android_fence_release+0x84/0x104
> > [   43.921582] [] fence_release+0x104/0x134
> > [   43.927066] [] sync_fence_free+0x74/0x9c
> > [   43.932552] [] sync_fence_release+0x34/0x48
> > [   43.938304] [] __fput+0x100/0x1b8
> > [   43.943185] [] fput+0x8/0x14
> > [   43.947982] [] task_work_run+0xb0/0xe4
> > [   43.953297] [] do_notify_resume+0x44/0x5c
> > [   43.958867] ---[ end trace 5a2aa4027cc5d171 ]---
> > 
> > Let's fix it by introducing a new optional callback (disable_signaling)
> > to fence operations so that drivers can do proper clean ups when we
> > remove last callback for given fence.
> > 
> > Reviewed-by: Andrew Bresticker 
> > Signed-off-by: Dmitry Torokhov 
> > ---
> >  drivers/dma-buf/fence.c| 6 +-
> >  drivers/staging/android/sync.c | 8 
> >  include/linux/fence.h  | 2 ++
> >  3 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
> > index 7b05dbe..0ed73ad 100644
> > --- a/drivers/dma-buf/fence.c
> > +++ b/drivers/dma-buf/fence.c
> > @@ -304,8 +304,12 @@ fence_remove_callback(struct fence *fence, struct 
> > fence_cb *cb)
> > spin_lock_irqsave(fence->lock, flags);
> >  
> > ret = !list_empty(>node);
> > -   if (ret)
> > +   if (ret) {
> > list_del_init(>node);
> > +   if (list_empty(>cb_list))
> > +   if (fence->ops->disable_signaling)
> > +   fence->ops->disable_signaling(fence);
> 
> What exactly is the bug here? A fence with no callbacks registered any
> more shouldn't have any problem. Why exactly does this blow up?

The WARN_ON is probably this one:
https://android.googlesource.com/kernel/common/+/android-3.18/drivers/staging/android/sync.c#433

I've been wondering in the last few days if this warning is really
necessary. If the user is closing a sync_timeline that has unsignalled
fences it should probably be aware of that already. Then I think it is
okay to remove the the sync_pt from the active_list at the release-time.
In fact I've already prepared a patch doing that. Thoughts?  

Gustavo
--
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] android: fix warning when releasing active sync point

2015-12-15 Thread Gustavo Padovan

2015-12-14 Dmitry Torokhov :

> Userspace can close the sync device while there are still active fence
> points, in which case kernel produces the following warning:
> 
> [   43.853176] [ cut here ]
> [   43.857834] WARNING: CPU: 0 PID: 892 at 
> /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439
>  android_fence_release+0x88/0x104()
> [   43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 
> 3.18.0-07661-g0550ce9 #1
> [   43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
> [   43.885834] Call trace:
> [   43.888294] [] dump_backtrace+0x0/0x10c
> [   43.893697] [] show_stack+0x10/0x1c
> [   43.898756] [] dump_stack+0x74/0xb8
> [   43.903814] [] warn_slowpath_common+0x84/0xb0
> [   43.909736] [] warn_slowpath_null+0x14/0x20
> [   43.915482] [] android_fence_release+0x84/0x104
> [   43.921582] [] fence_release+0x104/0x134
> [   43.927066] [] sync_fence_free+0x74/0x9c
> [   43.932552] [] sync_fence_release+0x34/0x48
> [   43.938304] [] __fput+0x100/0x1b8
> [   43.943185] [] fput+0x8/0x14
> [   43.947982] [] task_work_run+0xb0/0xe4
> [   43.953297] [] do_notify_resume+0x44/0x5c
> [   43.958867] ---[ end trace 5a2aa4027cc5d171 ]---

This crash report seems to be for a 3.18 kernel. Can you reproduce it
on upstream kernel as well?

Gustavo
--
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 2/2] dma-buf/sync_file: improve Kconfig description for Sync Files

2016-05-31 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>

We've got a complaint saying that the description was quite obtuse and
indeed it was. This patch tries to improve it.

Cc: Dave Jones <da...@codemonkey.org.uk>
Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
---
 drivers/dma-buf/Kconfig | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 9824bc4..7e2d2c4 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -1,11 +1,20 @@
 menu "DMABUF options"
 
 config SYNC_FILE
-   bool "sync_file support for fences"
+   bool "Explicit Synchronization Framework"
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.
+ The Sync File Framework adds explicit syncronization via
+ userspace. It enables send/receive 'struct fence' objects to/from
+ userspace via Sync File fds for synchronization between drivers via
+ userspace components. It has been ported from Android.
+
+ The first and main user for this is graphics in which a fence is
+ associated with a buffer. When a job is submitted to the GPU a fence
+ is attached to the buffer and is transfered via userspace, using Sync
+ Files fds, to the DRM driver for example. More details at
+ Documentation/sync_file.txt.
+
 endmenu
-- 
2.5.5

--
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] MAINTAINERS: add entry for the Sync File Framework

2016-05-31 Thread Gustavo Padovan

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.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Acked-by: Sumit Semwal <sumit.sem...@linaro.org>
Acked-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index fb487d9..0891228 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3677,6 +3677,17 @@ 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: Sumit Semwal <sumit.sem...@linaro.org>
+R: Gustavo Padovan <gust...@padovan.org>
+S: Maintained
+L: linux-media@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

--
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

2016-04-11 Thread Gustavo Padovan

Hi Luis,

2016-04-11 Luis de Bethencourt <lui...@osg.samsung.com>:

> The members child_list and active_list were added to the fence struct
> without descriptions for the Documentation. Adding these.
> 
> Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
> Signed-off-by: Luis de Bethencourt <lui...@osg.samsung.com>
> Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> ---
> 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.pado...@collabora.co.uk>

Gustavo
--
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 4/6] [media] tw5864: improve subscribe event handling

2017-02-15 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

We already check for the V4L2_EVENT_CTRL inside
v4l2_ctrl_subscribe_event() so just move this function to the default:
branch of the switch and let it does the job for us.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/pci/tw5864/tw5864-video.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/tw5864/tw5864-video.c 
b/drivers/media/pci/tw5864/tw5864-video.c
index 9421216..6d5ed8e 100644
--- a/drivers/media/pci/tw5864/tw5864-video.c
+++ b/drivers/media/pci/tw5864/tw5864-video.c
@@ -664,15 +664,14 @@ static int tw5864_subscribe_event(struct v4l2_fh *fh,
  const struct v4l2_event_subscription *sub)
 {
switch (sub->type) {
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_MOTION_DET:
/*
 * Allow for up to 30 events (1 second for NTSC) to be stored.
 */
return v4l2_event_subscribe(fh, sub, 30, NULL);
+   default:
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
-   return -EINVAL;
 }
 
 static void tw5864_frame_interval_set(struct tw5864_input *input)
-- 
2.9.3

[PATCH 5/6] [media] vivid: improve subscribe event handling

2017-02-15 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

We already check for the V4L2_EVENT_CTRL inside
v4l2_ctrl_subscribe_event() so just move this fuction to the default:
branch of the switch and let it does the job for us.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/platform/vivid/vivid-vid-out.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-vid-out.c 
b/drivers/media/platform/vivid/vivid-vid-out.c
index 7ba52ee..1a33730 100644
--- a/drivers/media/platform/vivid/vivid-vid-out.c
+++ b/drivers/media/platform/vivid/vivid-vid-out.c
@@ -1172,14 +1172,12 @@ int vidioc_subscribe_event(struct v4l2_fh *fh,
const struct v4l2_event_subscription *sub)
 {
switch (sub->type) {
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_SOURCE_CHANGE:
if (fh->vdev->vfl_dir == VFL_DIR_RX)
return v4l2_src_change_event_subscribe(fh, sub);
break;
default:
-   break;
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
return -EINVAL;
 }
-- 
2.9.3

[PATCH 3/6] [media] solo6x10: improve subscribe event handling

2017-02-15 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

We already check for the V4L2_EVENT_CTRL inside
v4l2_ctrl_subscribe_event() so just move the function to the default:
branch of the switch and let it does the job for us.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c 
b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
index 25a2137..25f9f2e 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
@@ -1140,14 +1140,13 @@ static int solo_subscribe_event(struct v4l2_fh *fh,
 {
 
switch (sub->type) {
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_MOTION_DET:
/* Allow for up to 30 events (1 second for NTSC) to be
 * stored. */
return v4l2_event_subscribe(fh, sub, 30, NULL);
+   default:
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
-   return -EINVAL;
 }
 
 static const struct v4l2_file_operations solo_enc_fops = {
-- 
2.9.3

[PATCH 2/6] [media] ivtv: improve subscribe_event handling

2017-02-15 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Simplify logic and call v4l2_ctrl_subscribe_event() directly instead
of copying its content over to ivtv_subscribe_event().

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/pci/ivtv/ivtv-ioctl.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/pci/ivtv/ivtv-ioctl.c 
b/drivers/media/pci/ivtv/ivtv-ioctl.c
index f956188..670462d 100644
--- a/drivers/media/pci/ivtv/ivtv-ioctl.c
+++ b/drivers/media/pci/ivtv/ivtv-ioctl.c
@@ -1506,10 +1506,8 @@ static int ivtv_subscribe_event(struct v4l2_fh *fh, 
const struct v4l2_event_subs
case V4L2_EVENT_VSYNC:
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 0, NULL);
-   case V4L2_EVENT_CTRL:
-   return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
default:
-   return -EINVAL;
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
 }
 
-- 
2.9.3

[PATCH 1/6] [media] vb2: only check ret if we assigned it

2017-02-15 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Move the ret check to the right level under if (pb). It is not
used by the code before that point if pb is NULL.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 7c1d390..94afbbf9 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -984,11 +984,12 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const 
void *pb)
 
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
/* Copy relevant information provided by the userspace */
-   if (pb)
+   if (pb) {
ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
 vb, pb, planes);
-   if (ret)
-   return ret;
+   if (ret)
+   return ret;
+   }
 
for (plane = 0; plane < vb->num_planes; ++plane) {
/* Skip the plane if already verified */
@@ -1101,11 +1102,12 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
 
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
/* Copy relevant information provided by the userspace */
-   if (pb)
+   if (pb) {
ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
 vb, pb, planes);
-   if (ret)
-   return ret;
+   if (ret)
+   return ret;
+   }
 
for (plane = 0; plane < vb->num_planes; ++plane) {
struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
-- 
2.9.3

[PATCH 6/6] [media] go7007: improve subscribe event handling

2017-02-15 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

We already check for the V4L2_EVENT_CTRL inside
v4l2_ctrl_subscribe_event() so just move this function to the default:
branch of the switch and let it does the job for us.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/usb/go7007/go7007-v4l2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/go7007/go7007-v4l2.c 
b/drivers/media/usb/go7007/go7007-v4l2.c
index 4eaba0c..ed5ec97 100644
--- a/drivers/media/usb/go7007/go7007-v4l2.c
+++ b/drivers/media/usb/go7007/go7007-v4l2.c
@@ -792,14 +792,13 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
 {
 
switch (sub->type) {
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_MOTION_DET:
/* Allow for up to 30 events (1 second for NTSC) to be
 * stored. */
return v4l2_event_subscribe(fh, sub, 30, NULL);
+   default:
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
-   return -EINVAL;
 }
 
 
-- 
2.9.3

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

2016-08-29 Thread Gustavo Padovan

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
--
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/sw_sync: mark sync_timeline_create() static

2016-09-25 Thread Gustavo Padovan

Hi Baoyou,

2016-09-22 Greg Kroah-Hartman <gre...@linuxfoundation.org>:

> On Tue, Sep 20, 2016 at 06:23:33PM +0530, Sumit Semwal wrote:
> > 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?
> 
> If someone resends it to me with the needed acks and reviewed-by, I
> will.

Could please resend this to Greg with all the acks and reviewed-by in
the commit message? Thanks.

Gustavo

--
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/sw_sync: mark sync_timeline_create() static

2016-09-20 Thread Gustavo Padovan

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.

Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>

Gustavo

--
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 v2 9/9] drm: mali-dp: Add writeback out-fence support

2016-10-27 Thread Gustavo Padovan

2016-10-27 Brian Starkey <brian.star...@arm.com>:

> On Wed, Oct 26, 2016 at 07:43:57PM -0200, Gustavo Padovan wrote:
> > 2016-10-26 Brian Starkey <brian.star...@arm.com>:
> > 
> > > If userspace has asked for an out-fence for the writeback, we add a
> > > fence to malidp_mw_job, to be signaled when the writeback job has
> > > completed.
> > > 
> > > Signed-off-by: Brian Starkey <brian.star...@arm.com>
> > > ---
> > >  drivers/gpu/drm/arm/malidp_hw.c |5 -
> > >  drivers/gpu/drm/arm/malidp_mw.c |   18 +-
> > >  drivers/gpu/drm/arm/malidp_mw.h |3 +++
> > >  3 files changed, 24 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/arm/malidp_hw.c 
> > > b/drivers/gpu/drm/arm/malidp_hw.c
> > > index 1689547..3032226 100644
> > > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > > @@ -707,8 +707,11 @@ static irqreturn_t malidp_se_irq(int irq, void *arg)
> > >   unsigned long irqflags;
> > >   /*
> > >* We can't unreference the framebuffer here, so we queue it
> > > -  * up on our threaded handler.
> > > +  * up on our threaded handler. However, signal the fence
> > > +  * as soon as possible
> > >*/
> > > + malidp_mw_job_signal(drm, malidp->current_mw, 0);
> > 
> > Drivers should not deal with fences directly. We need some sort of
> > drm_writeback_finished() that will do the signalling for you.
> > 
> 
> With a signature like this?
>   drm_writeback_finished(struct drm_connector_state *state);
> 
> I'll have to think about how to achieve that. The state isn't
> refcounted and the driver isn't in charge of it's lifetime. I'm not
> sure how/where to ensure the state doesn't get destroyed before its
> been signaled.

Maybe we should do something similar to the crtc vblank handlers and
even hide the connector_state. Those helpers only take the crtc.
They are able to hold ref to the event as well.

Gustavo
--
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 v2 9/9] drm: mali-dp: Add writeback out-fence support

2016-10-26 Thread Gustavo Padovan

2016-10-26 Brian Starkey :

> If userspace has asked for an out-fence for the writeback, we add a
> fence to malidp_mw_job, to be signaled when the writeback job has
> completed.
> 
> Signed-off-by: Brian Starkey 
> ---
>  drivers/gpu/drm/arm/malidp_hw.c |5 -
>  drivers/gpu/drm/arm/malidp_mw.c |   18 +-
>  drivers/gpu/drm/arm/malidp_mw.h |3 +++
>  3 files changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 1689547..3032226 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -707,8 +707,11 @@ static irqreturn_t malidp_se_irq(int irq, void *arg)
>   unsigned long irqflags;
>   /*
>* We can't unreference the framebuffer here, so we queue it
> -  * up on our threaded handler.
> +  * up on our threaded handler. However, signal the fence
> +  * as soon as possible
>*/
> + malidp_mw_job_signal(drm, malidp->current_mw, 0);

Drivers should not deal with fences directly. We need some sort of 
drm_writeback_finished() that will do the signalling for you.

Gustavo

--
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 v2 7/9] drm: atomic: factor out common out-fence operations

2016-10-26 Thread Gustavo Padovan

2016-10-26 Brian Starkey :

> Some parts of setting up the CRTC out-fence can be re-used for
> writeback out-fences. Factor this out into a separate function.
> 
> Signed-off-by: Brian Starkey 
> ---
>  drivers/gpu/drm/drm_atomic.c |   64 
> +++---
>  1 file changed, 42 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f434f34..3f8fc97 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1693,37 +1693,46 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_atomic_clean_old_fb);
>  
> -static int crtc_setup_out_fence(struct drm_crtc *crtc,
> - struct drm_crtc_state *crtc_state,
> - struct drm_out_fence_state *fence_state)
> +static struct fence *get_crtc_fence(struct drm_crtc *crtc,
> + struct drm_crtc_state *crtc_state)
>  {
>   struct fence *fence;
>  
> - fence_state->fd = get_unused_fd_flags(O_CLOEXEC);
> - if (fence_state->fd < 0) {
> - return fence_state->fd;
> - }
> -
> - fence_state->out_fence_ptr = crtc_state->out_fence_ptr;
> - crtc_state->out_fence_ptr = NULL;
> -
> - if (put_user(fence_state->fd, fence_state->out_fence_ptr))
> - return -EFAULT;
> -
>   fence = kzalloc(sizeof(*fence), GFP_KERNEL);
>   if (!fence)
> - return -ENOMEM;
> + return NULL;
>  
>   fence_init(fence, _crtc_fence_ops, >fence_lock,
>  crtc->fence_context, ++crtc->fence_seqno);
>  
> + crtc_state->event->base.fence = fence_get(fence);
> +
> + return fence;
> +}
> +
> +static int setup_out_fence(struct drm_out_fence_state *fence_state,
> +u64 __user *out_fence_ptr,
> +struct fence *fence)
> +{
> + int ret;
> +
> + DRM_DEBUG_ATOMIC("Putting out-fence %p into user ptr: %p\n",
> +  fence, out_fence_ptr);
> +
> + fence_state->fd = get_unused_fd_flags(O_CLOEXEC);
> + if (fence_state->fd < 0)
> + return fence_state->fd;
> +
> + ret = put_user(fence_state->fd, out_fence_ptr);
> + if (ret)
> + return ret;
> +
> + fence_state->out_fence_ptr = out_fence_ptr;
> +
>   fence_state->sync_file = sync_file_create(fence);
> - if(!fence_state->sync_file) {
> - fence_put(fence);
> + if (!fence_state->sync_file)
>   return -ENOMEM;
> - }
>  
> - crtc_state->event->base.fence = fence_get(fence);
>   return 0;
>  }
>  
> @@ -1896,10 +1905,21 @@ retry:
>   }
>  
>   if (crtc_state->out_fence_ptr) {
> - ret = crtc_setup_out_fence(crtc, crtc_state,
> -_state[fence_idx++]);
> - if (ret)
> + struct fence *fence = get_crtc_fence(crtc, crtc_state);
> + if (!fence) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + ret = setup_out_fence(_state[fence_idx++],
> +   crtc_state->out_fence_ptr,
> +   fence);
> + if (ret) {
> + fence_put(fence);
>   goto out;
> + }
> +
> + crtc_state->out_fence_ptr = NULL;

Yes, this split makes sense. I can break crtc_setup_out_fence() in
my out_fence patch already.

Gustavo

--
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 v2 7/9] drm: atomic: factor out common out-fence operations

2016-10-26 Thread Gustavo Padovan

2016-10-26 Brian Starkey :

> Some parts of setting up the CRTC out-fence can be re-used for
> writeback out-fences. Factor this out into a separate function.
> 
> Signed-off-by: Brian Starkey 
> ---
>  drivers/gpu/drm/drm_atomic.c |   64 
> +++---
>  1 file changed, 42 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f434f34..3f8fc97 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1693,37 +1693,46 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_atomic_clean_old_fb);
>  
> -static int crtc_setup_out_fence(struct drm_crtc *crtc,
> - struct drm_crtc_state *crtc_state,
> - struct drm_out_fence_state *fence_state)
> +static struct fence *get_crtc_fence(struct drm_crtc *crtc,
> + struct drm_crtc_state *crtc_state)
>  {
>   struct fence *fence;
>  
> - fence_state->fd = get_unused_fd_flags(O_CLOEXEC);
> - if (fence_state->fd < 0) {
> - return fence_state->fd;
> - }
> -
> - fence_state->out_fence_ptr = crtc_state->out_fence_ptr;
> - crtc_state->out_fence_ptr = NULL;
> -
> - if (put_user(fence_state->fd, fence_state->out_fence_ptr))
> - return -EFAULT;
> -
>   fence = kzalloc(sizeof(*fence), GFP_KERNEL);
>   if (!fence)
> - return -ENOMEM;
> + return NULL;
>  
>   fence_init(fence, _crtc_fence_ops, >fence_lock,
>  crtc->fence_context, ++crtc->fence_seqno);
>  
> + crtc_state->event->base.fence = fence_get(fence);
> +
> + return fence;
> +}
> +
> +static int setup_out_fence(struct drm_out_fence_state *fence_state,
> +u64 __user *out_fence_ptr,
> +struct fence *fence)
> +{
> + int ret;
> +
> + DRM_DEBUG_ATOMIC("Putting out-fence %p into user ptr: %p\n",
> +  fence, out_fence_ptr);

%p should be kept for your internal debug only. Make sure to remove
anything that exposes kernel address when sending patches.

Gustavo

--
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 v2 8/9] drm: writeback: Add out-fences for writeback connectors

2016-10-26 Thread Gustavo Padovan

2016-10-26 Brian Starkey :

> Add the OUT_FENCE_PTR property to writeback connectors, to enable
> userspace to get a fence which will signal once the writeback is
> complete.
> 
> A timeline is added to drm_connector for use by the writeback
> out-fences. It is up to drivers to check for a fence in the
> connector_state and signal the it appropriately when their writeback has
> finished.
> 
> It is not allowed to request an out-fence without a framebuffer attached
> to the connector.
> 
> Signed-off-by: Brian Starkey 
> ---
>  drivers/gpu/drm/drm_atomic.c|   60 +++---
>  drivers/gpu/drm/drm_atomic_helper.c |5 ++-
>  drivers/gpu/drm/drm_writeback.c |   80 
> +++
>  include/drm/drm_connector.h |   14 ++
>  include/drm/drm_writeback.h |2 +
>  5 files changed, 155 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3f8fc97..061ea13 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "drm_crtc_internal.h"
> @@ -646,6 +647,12 @@ static int drm_atomic_connector_check(struct 
> drm_connector *connector,
>   return -EINVAL;
>   }
>  
> + if (state->out_fence && !state->fb) {
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence 
> without framebuffer\n",
> +  connector->base.id, connector->name);
> + return -EINVAL;
> + }
> +
>   return 0;
>  }
>  
> @@ -1047,6 +1054,8 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   drm_atomic_set_fb_for_connector(state, fb);
>   if (fb)
>   drm_framebuffer_unreference(fb);
> + } else if (property == config->prop_out_fence_ptr) {
> + state->out_fence_ptr = u64_to_user_ptr(val);

We need to move this out of the conn_state. For my v6 on CRTC out fences
I added drm_atomic_set_out_fence_for_crtc() and
drm_atomic_get_out_fence_for_crtc(). See padovan/fences.

>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1088,6 +1097,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   } else if (property == config->writeback_fb_id_property) {
>   /* Writeback framebuffer is one-shot, write and forget */
>   *val = 0;
> + } else if (property == config->prop_out_fence_ptr) {
> + *val = 0;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> @@ -1736,6 +1747,39 @@ static int setup_out_fence(struct drm_out_fence_state 
> *fence_state,
>   return 0;
>  }
>  
> +static int setup_connector_out_fences(struct drm_atomic_state *state,
> +   struct drm_out_fence_state *fence_state,
> +   int *fence_idx)
> +{
> + struct drm_connector *conn;
> + struct drm_connector_state *conn_state;
> + int i, ret;
> +
> + for_each_connector_in_state(state, conn, conn_state, i) {
> + struct fence *fence;
> +
> + if (!conn_state->out_fence_ptr)
> + continue;
> +
> + fence = drm_writeback_get_out_fence(conn, conn_state);
> + if (!fence)
> + return -ENOMEM;
> +
> + ret = setup_out_fence(_state[(*fence_idx)++],
> +   conn_state->out_fence_ptr,
> +   fence);
> + if (ret) {
> + fence_put(fence);
> + return ret;
> + }
> +
> + /* One-time usage only */
> + conn_state->out_fence_ptr = NULL;
> + }
> +
> + return 0;
> +}
> +
>  int drm_mode_atomic_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv)
>  {
> @@ -1868,8 +1912,8 @@ retry:
>   drm_mode_object_unreference(obj);
>   }
>  
> - fence_state = kcalloc(dev->mode_config.num_crtc, sizeof(*fence_state),
> -   GFP_KERNEL);
> + fence_state = kcalloc(dev->mode_config.num_crtc + state->num_connector,
> +   sizeof(*fence_state), GFP_KERNEL);
>   if (!fence_state) {
>   ret = -ENOMEM;
>   goto out;
> @@ -1929,10 +1973,16 @@ retry:
>* Below we call drm_atomic_state_free for it.
>*/
>   ret = drm_atomic_check_only(state);
> - } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> - ret =

Re: [RFC 00/10] V4L2 explicit synchronization support

2017-04-06 Thread Gustavo Padovan

Hi Javier,

2017-04-05 Javier Martinez Canillas <jav...@osg.samsung.com>:

> Hello Gustavo,
> 
> On 04/05/2017 11:09 AM, Gustavo Padovan wrote:
> > 2017-04-03 Javier Martinez Canillas <jav...@osg.samsung.com>:
> > 
> >> Hello Mauro and Gustavo,
> >>
> >> On 04/03/2017 07:16 AM, Mauro Carvalho Chehab wrote:
> >>> Hi Gustavo,
> >>>
> >>> Em Mon, 13 Mar 2017 16:20:25 -0300
> >>> Gustavo Padovan <gust...@padovan.org> escreveu:
> >>>
> >>>> From: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>>>
> >>>> Hi,
> >>>>
> >>>> This RFC adds support for Explicit Synchronization of shared buffers in 
> >>>> V4L2.
> >>>> It uses the Sync File Framework[1] as vector to communicate the fences
> >>>> between kernel and userspace.
> >>>
> >>> Thanks for your work!
> >>>
> >>> I looked on your patchset, and I didn't notice anything really weird
> >>> there. So, instead on reviewing patch per patch, I prefer to discuss
> >>> about the requirements and API, as depending on it, the code base will
> >>> change a lot.
> >>>
> >>
> >> Agree that's better to first set on an uAPI and then implement based on 
> >> that.
> >>  
> >>> I'd like to do some tests with it on devices with mem2mem drivers.
> >>> My plan is to use an Exynos board for such thing, but I guess that
> >>> the DRM driver for it currently doesn't. I'm seeing internally if someone
> >>> could be sure that Exynos driver upstream will become ready for such
> >>> tests.
> >>>
> >>
> >> Not sure if you should try to do testing before agreeing on an uAPI and
> >> implementation.
> >>
> >>> Javier wrote some patches last year meant to implement implicit
> >>> fences support. What we noticed is that, while his mechanism worked
> >>> fine for pure capture and pure output devices, when we added a mem2mem
> >>> device, on a DMABUF+fences pipeline, e. g.:
> >>>
> >>>   sensor -> [m2m] -> DRM
> >>>
> >>> End everything using fences/DMABUF, the fences mechanism caused dead
> >>> locks on existing userspace apps.
> >>>
> >>> A m2m device has both capture and output devnodes. Both should be
> >>> queued/dequeued. The capture queue is synchronized internally at the
> >>> driver with the output buffer[1].
> >>>
> >>> [1] The names here are counter-intuitive: "capture" is a devnode
> >>> where userspace receives a video stream; "output" is a devnode where
> >>> userspace feeds a video stream.
> >>>
> >>> The problem is that adding implicit fences changed the behavior of
> >>> the ioctls, causing gstreamer to wait forever for buffers to be ready.
> >>>
> >>
> >> The problem was related to trying to make user-space unaware of the 
> >> implicit
> >> fences support, and so it tried to QBUF a buffer that had already a pending
> >> fence. A workaround was to block the second QBUF ioctl if the buffer had a
> >> pending fence, but this caused the mentioned deadlock since GStreamer 
> >> wasn't
> >> expecting the QBUF ioctl to block.
> >>
> >>> I suspect that, even with explicit fences, the behavior of Q/DQ
> >>> will be incompatible with the current behavior (or will require some
> >>> dirty hacks to make it identical). 
> > 
> > For QBUF the only difference is that we set flags for fences and pass
> > and receives in and out fences. For DQBUF the behavior is exactly the
> > same. What incompatibles or hacks do you see?
> > 
> > I had the expectation that the flags would be for userspace to learn
> > about any different behavior.
> > 
> >>>
> >>> So, IMHO, the best would be to use a new set of ioctls, when fences are
> >>> used (like VIDIOC_QFENCE/DQFENCE).
> >>>
> >>
> >> For explicit you can check if there's an input-fence so is different than
> >> implicit, but still I agree that it would be better to have specific 
> >> ioctls.
> > 
> > I'm pretty new to v4l2 so I don't know all use cases yet, but what I
> > thought was to just add extra flags to QBUF to mark when using fences
> > instead of having userspace  to setup completely new ioctls for fences

Re: [RFC 00/10] V4L2 explicit synchronization support

2017-04-05 Thread Gustavo Padovan

2017-04-03 Javier Martinez Canillas <jav...@osg.samsung.com>:

> Hello Mauro and Gustavo,
> 
> On 04/03/2017 07:16 AM, Mauro Carvalho Chehab wrote:
> > Hi Gustavo,
> > 
> > Em Mon, 13 Mar 2017 16:20:25 -0300
> > Gustavo Padovan <gust...@padovan.org> escreveu:
> > 
> >> From: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>
> >> Hi,
> >>
> >> This RFC adds support for Explicit Synchronization of shared buffers in 
> >> V4L2.
> >> It uses the Sync File Framework[1] as vector to communicate the fences
> >> between kernel and userspace.
> > 
> > Thanks for your work!
> > 
> > I looked on your patchset, and I didn't notice anything really weird
> > there. So, instead on reviewing patch per patch, I prefer to discuss
> > about the requirements and API, as depending on it, the code base will
> > change a lot.
> >
> 
> Agree that's better to first set on an uAPI and then implement based on that.
>  
> > I'd like to do some tests with it on devices with mem2mem drivers.
> > My plan is to use an Exynos board for such thing, but I guess that
> > the DRM driver for it currently doesn't. I'm seeing internally if someone
> > could be sure that Exynos driver upstream will become ready for such
> > tests.
> >
> 
> Not sure if you should try to do testing before agreeing on an uAPI and
> implementation.
> 
> > Javier wrote some patches last year meant to implement implicit
> > fences support. What we noticed is that, while his mechanism worked
> > fine for pure capture and pure output devices, when we added a mem2mem
> > device, on a DMABUF+fences pipeline, e. g.:
> > 
> > sensor -> [m2m] -> DRM
> > 
> > End everything using fences/DMABUF, the fences mechanism caused dead
> > locks on existing userspace apps.
> >
> > A m2m device has both capture and output devnodes. Both should be
> > queued/dequeued. The capture queue is synchronized internally at the
> > driver with the output buffer[1].
> > 
> > [1] The names here are counter-intuitive: "capture" is a devnode
> > where userspace receives a video stream; "output" is a devnode where
> > userspace feeds a video stream.
> > 
> > The problem is that adding implicit fences changed the behavior of
> > the ioctls, causing gstreamer to wait forever for buffers to be ready.
> >
> 
> The problem was related to trying to make user-space unaware of the implicit
> fences support, and so it tried to QBUF a buffer that had already a pending
> fence. A workaround was to block the second QBUF ioctl if the buffer had a
> pending fence, but this caused the mentioned deadlock since GStreamer wasn't
> expecting the QBUF ioctl to block.
> 
> > I suspect that, even with explicit fences, the behavior of Q/DQ
> > will be incompatible with the current behavior (or will require some
> > dirty hacks to make it identical). 

For QBUF the only difference is that we set flags for fences and pass
and receives in and out fences. For DQBUF the behavior is exactly the
same. What incompatibles or hacks do you see?

I had the expectation that the flags would be for userspace to learn
about any different behavior.

> >
> > So, IMHO, the best would be to use a new set of ioctls, when fences are
> > used (like VIDIOC_QFENCE/DQFENCE).
> > 
> 
> For explicit you can check if there's an input-fence so is different than
> implicit, but still I agree that it would be better to have specific ioctls.

I'm pretty new to v4l2 so I don't know all use cases yet, but what I
thought was to just add extra flags to QBUF to mark when using fences
instead of having userspace  to setup completely new ioctls for fences.
The burden for userspace should be smaller with flags.

> 
> >>
> >> I'm sending this to start the discussion on the best approach to implement
> >> Explicit Synchronization, please check the TODO/OPEN section below.
> >>
> >> Explicit Synchronization allows us to control the synchronization of
> >> shared buffers from userspace by passing fences to the kernel and/or 
> >> receiving them from the the kernel.
> >>
> >> Fences passed to the kernel are named in-fences and the kernel should wait
> >> them to signal before using the buffer. On the other side, the kernel 
> >> creates
> >> out-fences for every buffer it receives from userspace. This fence is sent 
> >> back
> >> to userspace and it will signal when the capture, for example, has 
> >> finished.
> >>
> >> Signalling an out-fence in V4L2 would

Re: [RFC 01/10] [media] vb2: add explicit fence user API

2017-04-05 Thread Gustavo Padovan

Hi Philipp,

2017-04-03 Philipp Zabel <p.za...@pengutronix.de>:

> Hi Gustavo,
> 
> On Mon, 2017-03-13 at 16:20 -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Turn the reserved2 field into fence_fd that we will use to send
> > an in-fence to the kernel return an out-fence from the kernel to
> > userspace.
> > 
> > Two new flags were added, V4L2_BUF_FLAG_IN_FENCE and
> > V4L2_BUF_FLAG_OUT_FENCE. They should be used when setting in-fence and
> > out-fence, respectively.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ++--
> >  drivers/media/v4l2-core/videobuf2-v4l2.c  | 2 +-
> >  include/uapi/linux/videodev2.h| 6 --
> >  3 files changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> > b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > index eac9565..0a522cb 100644
> > --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > @@ -348,7 +348,7 @@ struct v4l2_buffer32 {
> > __s32   fd;
> > } m;
> > __u32   length;
> > -   __u32   reserved2;
> > +   __s32   fence_fd;
> > __u32   reserved;
> >  };
> >  
> > @@ -511,7 +511,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
> > struct v4l2_buffer32 __user
> > put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
> > copy_to_user(>timecode, >timecode, sizeof(struct 
> > v4l2_timecode)) ||
> > put_user(kp->sequence, >sequence) ||
> > -   put_user(kp->reserved2, >reserved2) ||
> > +   put_user(kp->fence_fd, >fence_fd) ||
> > put_user(kp->reserved, >reserved) ||
> > put_user(kp->length, >length))
> > return -EFAULT;
> > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> > b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > index 3529849..d23c1bf 100644
> > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > @@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> > void *pb)
> > b->timestamp = ns_to_timeval(vb->timestamp);
> > b->timecode = vbuf->timecode;
> > b->sequence = vbuf->sequence;
> > -   b->reserved2 = 0;
> > +   b->fence_fd = -1;
> > b->reserved = 0;
> >  
> > if (q->is_multiplanar) {
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 45184a2..3b6cfa6 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -911,7 +911,7 @@ struct v4l2_buffer {
> > __s32   fd;
> > } m;
> > __u32   length;
> > -   __u32   reserved2;
> > +   __s32   fence_fd;
> > __u32   reserved;
> >  };
> >  
> > @@ -946,8 +946,10 @@ struct v4l2_buffer {
> >  #define V4L2_BUF_FLAG_TSTAMP_SRC_MASK  0x0007
> >  #define V4L2_BUF_FLAG_TSTAMP_SRC_EOF   0x
> >  #define V4L2_BUF_FLAG_TSTAMP_SRC_SOE   0x0001
> > +#define V4L2_BUF_FLAG_IN_FENCE 0x0010
> > +#define V4L2_BUF_FLAG_OUT_FENCE0x0020
> >  /* mem2mem encoder/decoder */
> > -#define V4L2_BUF_FLAG_LAST 0x0010
> > +#define V4L2_BUF_FLAG_LAST 0x0040
> 
> This is not just a sentinel, it is a meaningful flag that must not be
> changed. It indicates the last buffer produced by a hardware codec.

Oh, I wouldn't be able to figure out it myself! Thanks.

Gustavo

Re: [RFC 00/10] V4L2 explicit synchronization support

2017-04-05 Thread Gustavo Padovan

Hi Sakari,

2017-04-04 Sakari Ailus <sakari.ai...@iki.fi>:

> Hi Gustavo,
> 
> Thank you for the patchset. Please see my comments below.
> 
> On Mon, Mar 13, 2017 at 04:20:25PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Hi,
> > 
> > This RFC adds support for Explicit Synchronization of shared buffers in 
> > V4L2.
> > It uses the Sync File Framework[1] as vector to communicate the fences
> > between kernel and userspace.
> > 
> > I'm sending this to start the discussion on the best approach to implement
> > Explicit Synchronization, please check the TODO/OPEN section below.
> > 
> > Explicit Synchronization allows us to control the synchronization of
> > shared buffers from userspace by passing fences to the kernel and/or 
> > receiving them from the the kernel.
> > 
> > Fences passed to the kernel are named in-fences and the kernel should wait
> > them to signal before using the buffer. On the other side, the kernel 
> > creates
> > out-fences for every buffer it receives from userspace. This fence is sent 
> > back
> > to userspace and it will signal when the capture, for example, has finished.
> > 
> > Signalling an out-fence in V4L2 would mean that the job on the buffer is 
> > done
> > and the buffer can be used by other drivers.
> 
> Shouldn't you be able to add two fences to the buffer, one in and one out?
> I.e. you'd have the buffer passed from another device to a V4L2 device and
> on to a third device.
> 
> (Or, two fences per a plane, as you elaborated below.)

The out one should be created by V4L2 in this case, sent to userspace
and then sent to third device. Another options is what we've been
calling future fences in DRM. Where we may have a syscall to create this
out-fence for us and then we could pass both in and out fence to the
device. But that can be supported later along with what this RFC
proposes.


> 
> > 
> > Current RFC implementation
> > --
> > 
> > The current implementation is not intended to be more than a PoC to start
> > the discussion on how Explicit Synchronization should be supported in V4L2.
> > 
> > The first patch proposes an userspace API for fences, then on patch 2
> > we prepare to the addition of in-fences in patch 3, by introducing the
> > infrastructure on vb2 to wait on an in-fence signal before queueing the 
> > buffer
> > in the driver.
> > 
> > Patch 4 fix uvc v4l2 event handling and patch 5 configure q->dev for vivid
> > drivers to enable to subscribe and dequeue events on it.
> > 
> > Patches 6-7 enables support to notify BUF_QUEUED events, i.e., let userspace
> > know that particular buffer was enqueued in the driver. This is needed,
> > because we return the out-fence fd as an out argument in QBUF, but at the 
> > time
> > it returns we don't know to which buffer the fence will be attached thus
> > the BUF_QUEUED event tells which buffer is associated to the fence received 
> > in
> > QBUF by userspace.
> > 
> > Patches 8 and 9 add more fence infrastructure to support out-fences and 
> > finally
> > patch 10 adds support to out-fences.
> > 
> > TODO/OPEN:
> > --
> > 
> > * For this first implementation we will keep the ordering of the buffers 
> > queued
> > in videobuf2, that means we will only enqueue buffer whose fence was 
> > signalled
> > if that buffer is the first one in the queue. Otherwise it has to wait 
> > until it
> > is the first one. This is not implmented yet. Later we could create a flag 
> > to
> > allow unordered queing in the drivers from vb2 if needed.
> > 
> > * Should we have out-fences per-buffer or per-plane? or both? In this RFC, 
> > for
> > simplicity they are per-buffer, but Mauro and Javier raised the option of
> > doing per-plane fences. That could benefit mem2mem and V4L2 <-> GPU 
> > operation
> > at least on cases when we have Capture hw that releases the Y frame before 
> > the
> > other frames for example. When using V4L2 per-plane out-fences to 
> > communicate
> > with KMS they would need to be merged together as currently the DRM Plane
> > interface only supports one fence per DRM Plane.
> > 
> > In-fences should be per-buffer as the DRM only has per-buffer fences, but
> > in case of mem2mem operations per-plane fences might be useful?
> > 
> > So should we have both ways, per-plane and per-buffer, or just one of them
> > for now?
> 
> The data_offset field is only present in struct v4l2_plane, i.e. it is only
> available through using the multi-planar API even if you just have a single
> plane.

I didn't get why you mentioned the data_offset field. :)

Gustavo

[RFC 07/10] [media] v4l: add support to BUF_QUEUED event

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Implement the needed pieces to let userspace subscribe for
V4L2_EVENT_BUF_QUEUED events. Videobuf2 will queue the event for the
DQEVENT ioctl.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/v4l2-ctrls.c |  6 +-
 drivers/media/v4l2-core/videobuf2-core.c | 15 +++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b9e08e3..1be554b 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3413,8 +3413,12 @@ EXPORT_SYMBOL(v4l2_ctrl_log_status);
 int v4l2_ctrl_subscribe_event(struct v4l2_fh *fh,
const struct v4l2_event_subscription *sub)
 {
-   if (sub->type == V4L2_EVENT_CTRL)
+   switch (sub->type) {
+   case V4L2_EVENT_CTRL:
return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
+   case V4L2_EVENT_BUF_QUEUED:
+   return v4l2_event_subscribe(fh, sub, 0, NULL);
+   }
return -EINVAL;
 }
 EXPORT_SYMBOL(v4l2_ctrl_subscribe_event);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index e0e7109..d9cb777 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -25,6 +25,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -1221,6 +1222,18 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
return ret;
 }
 
+static void vb2_buffer_queued_event(struct vb2_buffer *vb)
+{
+   struct video_device *vdev = to_video_device(vb->vb2_queue->dev);
+   struct v4l2_event event;
+
+   memset(, 0, sizeof(event));
+   event.type = V4L2_EVENT_BUF_QUEUED;
+   event.u.buf_queued.index = vb->index;
+
+   v4l2_event_queue(vdev, );
+}
+
 /**
  * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
  */
@@ -1239,6 +1252,8 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
 
call_void_vb_qop(vb, buf_queue, vb);
+
+   vb2_buffer_queued_event(vb);
 }
 
 static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
-- 
2.9.3

[RFC 09/10] [media] vb2: add infrastructure to support out-fences

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 31 +++
 include/media/videobuf2-core.h   |  5 +
 2 files changed, 36 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index d9cb777..54b1404 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -23,8 +23,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -1315,6 +1318,34 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned 
int index, void *pb)
 }
 EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
 
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
+{
+   struct vb2_buffer *vb = q->bufs[index];
+
+   vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+   if (vb->out_fence_fd < 0)
+   return vb->out_fence_fd;
+
+   vb->out_fence = vb2_fence_alloc();
+   if (!vb->out_fence)
+   goto err;
+
+   vb->sync_file = sync_file_create(vb->out_fence);
+   if (!vb->sync_file) {
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   goto err;
+   }
+
+   return 0;
+
+err:
+   put_unused_fd(vb->out_fence_fd);
+   vb->out_fence_fd = -1;
+   return -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(vb2_setup_out_fence);
+
 /**
  * vb2_start_streaming() - Attempt to start streaming.
  * @q: videobuf2 queue
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index fe2de99..efdc390 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -263,6 +263,10 @@ struct vb2_buffer {
 
struct dma_fence*in_fence;
struct dma_fence_cb fence_cb;
+
+   struct dma_fence*out_fence;
+   struct sync_file*sync_file;
+   int out_fence_fd;
 #ifdef CONFIG_VIDEO_ADV_DEBUG
/*
 * Counters for how often these buffer-related ops are
@@ -710,6 +714,7 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
vb2_memory memory,
  */
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb);
 
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index);
 /**
  * vb2_core_qbuf() - Queue a buffer from userspace
  *
-- 
2.9.3

[RFC 02/10] [media] vb2: split out queueing from vb_core_qbuf()

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

In order to support explicit synchronization we need to divide
vb2_core_qbuf() in two parts one, to be executed before the fence
signals and another one after that, to do the actual queueing of
the buffer.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 65 ++--
 1 file changed, 36 insertions(+), 29 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 94afbbf9..0e30fcd 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1363,29 +1363,10 @@ static int vb2_start_streaming(struct vb2_queue *q)
return ret;
 }
 
-int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
+static int __vb2_core_qbuf(struct vb2_buffer *vb, struct vb2_queue *q)
 {
-   struct vb2_buffer *vb;
int ret;
 
-   vb = q->bufs[index];
-
-   switch (vb->state) {
-   case VB2_BUF_STATE_DEQUEUED:
-   ret = __buf_prepare(vb, pb);
-   if (ret)
-   return ret;
-   break;
-   case VB2_BUF_STATE_PREPARED:
-   break;
-   case VB2_BUF_STATE_PREPARING:
-   dprintk(1, "buffer still being prepared\n");
-   return -EINVAL;
-   default:
-   dprintk(1, "invalid buffer state %d\n", vb->state);
-   return -EINVAL;
-   }
-
/*
 * Add to the queued buffers list, a buffer will stay on it until
 * dequeued in dqbuf.
@@ -1395,11 +1376,6 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
q->waiting_for_buffers = false;
vb->state = VB2_BUF_STATE_QUEUED;
 
-   if (pb)
-   call_void_bufop(q, copy_timestamp, vb, pb);
-
-   trace_vb2_qbuf(q, vb);
-
/*
 * If already streaming, give the buffer to driver for processing.
 * If not, the buffer will be given to driver on next streamon.
@@ -1407,10 +1383,6 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
if (q->start_streaming_called)
__enqueue_in_driver(vb);
 
-   /* Fill buffer information for the userspace */
-   if (pb)
-   call_void_bufop(q, fill_user_buffer, vb, pb);
-
/*
 * If streamon has been called, and we haven't yet called
 * start_streaming() since not enough buffers were queued, and
@@ -1427,6 +1399,41 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
dprintk(1, "qbuf of buffer %d succeeded\n", vb->index);
return 0;
 }
+
+int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
+{
+   struct vb2_buffer *vb;
+   int ret;
+
+   vb = q->bufs[index];
+
+   switch (vb->state) {
+   case VB2_BUF_STATE_DEQUEUED:
+   ret = __buf_prepare(vb, pb);
+   if (ret)
+   return ret;
+   break;
+   case VB2_BUF_STATE_PREPARED:
+   break;
+   case VB2_BUF_STATE_PREPARING:
+   dprintk(1, "buffer still being prepared\n");
+   return -EINVAL;
+   default:
+   dprintk(1, "invalid buffer state %d\n", vb->state);
+   return -EINVAL;
+   }
+
+   if (pb)
+   call_void_bufop(q, copy_timestamp, vb, pb);
+
+   trace_vb2_qbuf(q, vb);
+
+   /* Fill buffer information for the userspace */
+   if (pb)
+   call_void_bufop(q, fill_user_buffer, vb, pb);
+
+   return __vb2_core_qbuf(vb, q);
+}
 EXPORT_SYMBOL_GPL(vb2_core_qbuf);
 
 /**
-- 
2.9.3

[RFC 10/10] [media] vb2: add out-fence support to QBUF

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence for the buffer and return it to userspace on the fence_fd
field.

The fence is signaled on buffer_done(), when the job on the buffer is
finished.

TODO: clean up on __vb2_queue_cancel()

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c |  6 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c | 15 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 54b1404..ca8abcc 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -356,6 +356,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
}
+   vb->out_fence_fd = -1;
q->bufs[vb->index] = vb;
 
/* Allocate video buffer memory for the MMAP type */
@@ -940,6 +941,11 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
__enqueue_in_driver(vb);
return;
default:
+   dma_fence_signal(vb->out_fence);
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   vb->out_fence_fd = -1;
+
/* Inform any processes that may be waiting for buffers */
wake_up(>done_wq);
break;
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index c164aa0..1b43d9f 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -204,9 +204,14 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->fence_fd = -1;
+   b->fence_fd = vb->out_fence_fd;
b->reserved = 0;
 
+   if (vb->sync_file) {
+   fd_install(vb->out_fence_fd, vb->sync_file->file);
+   vb->sync_file = NULL;
+   }
+
if (q->is_multiplanar) {
/*
 * Fill in plane-related data if userspace provided an array
@@ -577,6 +582,14 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
return -EINVAL;
}
 
+   if (b->flags & V4L2_BUF_FLAG_OUT_FENCE) {
+   ret = vb2_setup_out_fence(q, b->index);
+   if (ret) {
+   dma_fence_put(fence);
+   return ret;
+   }
+   }
+
return ret ? ret : vb2_core_qbuf(q, b->index, b, fence);
 }
 EXPORT_SYMBOL_GPL(vb2_qbuf);
-- 
2.9.3

[RFC 03/10] [media] vb2: add in-fence support to QBUF

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Receive in-fence from userspace and support for waiting on them
before queueing the buffer for the driver.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/Kconfig|  1 +
 drivers/media/v4l2-core/videobuf2-core.c | 24 
 drivers/media/v4l2-core/videobuf2-v4l2.c | 14 +-
 include/media/videobuf2-core.h   |  7 ++-
 4 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 3512316..7c5a0e0 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -5,6 +5,7 @@
 menuconfig MEDIA_SUPPORT
tristate "Multimedia support"
depends on HAS_IOMEM
+   select SYNC_FILE
help
  If you want to use Webcams, Video grabber devices and/or TV devices
  enable this option and other options below.
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 0e30fcd..e0e7109 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1400,7 +1400,18 @@ static int __vb2_core_qbuf(struct vb2_buffer *vb, struct 
vb2_queue *q)
return 0;
 }
 
-int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
+static void vb2_qbuf_fence_cb(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+   struct vb2_buffer *vb = container_of(cb, struct vb2_buffer, fence_cb);
+
+   dma_fence_put(vb->in_fence);
+   vb->in_fence = NULL;
+
+   __vb2_core_qbuf(vb, vb->vb2_queue);
+}
+
+int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
+ struct dma_fence *fence)
 {
struct vb2_buffer *vb;
int ret;
@@ -1432,6 +1443,11 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
if (pb)
call_void_bufop(q, fill_user_buffer, vb, pb);
 
+   vb->in_fence = fence;
+   if (fence && !dma_fence_add_callback(fence, >fence_cb,
+vb2_qbuf_fence_cb))
+   return 0;
+
return __vb2_core_qbuf(vb, q);
 }
 EXPORT_SYMBOL_GPL(vb2_core_qbuf);
@@ -2246,7 +2262,7 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
read)
 * Queue all buffers.
 */
for (i = 0; i < q->num_buffers; i++) {
-   ret = vb2_core_qbuf(q, i, NULL);
+   ret = vb2_core_qbuf(q, i, NULL, NULL);
if (ret)
goto err_reqbufs;
fileio->bufs[i].queued = 1;
@@ -2425,7 +2441,7 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, 
char __user *data, size_
 
if (copy_timestamp)
b->timestamp = ktime_get_ns();
-   ret = vb2_core_qbuf(q, index, NULL);
+   ret = vb2_core_qbuf(q, index, NULL, NULL);
dprintk(5, "vb2_dbuf result: %d\n", ret);
if (ret)
return ret;
@@ -2528,7 +2544,7 @@ static int vb2_thread(void *data)
if (copy_timestamp)
vb->timestamp = ktime_get_ns();;
if (!threadio->stop)
-   ret = vb2_core_qbuf(q, vb->index, NULL);
+   ret = vb2_core_qbuf(q, vb->index, NULL, NULL);
call_void_qop(q, wait_prepare, q);
if (ret || threadio->stop)
break;
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index d23c1bf..c164aa0 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -557,6 +558,7 @@ EXPORT_SYMBOL_GPL(vb2_create_bufs);
 
 int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
 {
+   struct dma_fence *fence = NULL;
int ret;
 
if (vb2_fileio_is_active(q)) {
@@ -565,7 +567,17 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
}
 
ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
-   return ret ? ret : vb2_core_qbuf(q, b->index, b);
+
+   if (b->flags & V4L2_BUF_FLAG_IN_FENCE) {
+   if (b->memory != VB2_MEMORY_DMABUF)
+   return -EINVAL;
+
+   fence = sync_file_get_fence(b->fence_fd);
+   if (!fence)
+   return -EINVAL;
+   }
+
+   return ret ? ret : vb2_core_qbuf(q, b->index, b, fence);
 }
 EXPORT_SYMBOL_GPL(vb2_qbuf);
 
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index ac5898a..fe2de99 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -16,6 +16,7 @@
 #includ

[RFC 04/10] [media] uvc: enable subscriptions to other events

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Call v4l2_ctrl_subscribe_event to subscribe to more events supported by
v4l.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 3e7e283..dfa0ccd 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -1240,7 +1240,7 @@ static int uvc_ioctl_subscribe_event(struct v4l2_fh *fh,
case V4L2_EVENT_CTRL:
return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
default:
-   return -EINVAL;
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
 }
 
-- 
2.9.3

[RFC 01/10] [media] vb2: add explicit fence user API

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel return an out-fence from the kernel to
userspace.

Two new flags were added, V4L2_BUF_FLAG_IN_FENCE and
V4L2_BUF_FLAG_OUT_FENCE. They should be used when setting in-fence and
out-fence, respectively.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c  | 2 +-
 include/uapi/linux/videodev2.h| 6 --
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index eac9565..0a522cb 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -348,7 +348,7 @@ struct v4l2_buffer32 {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -511,7 +511,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, struct 
v4l2_buffer32 __user
put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
copy_to_user(>timecode, >timecode, sizeof(struct 
v4l2_timecode)) ||
put_user(kp->sequence, >sequence) ||
-   put_user(kp->reserved2, >reserved2) ||
+   put_user(kp->fence_fd, >fence_fd) ||
put_user(kp->reserved, >reserved) ||
put_user(kp->length, >length))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 3529849..d23c1bf 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->reserved2 = 0;
+   b->fence_fd = -1;
b->reserved = 0;
 
if (q->is_multiplanar) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 45184a2..3b6cfa6 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -911,7 +911,7 @@ struct v4l2_buffer {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -946,8 +946,10 @@ struct v4l2_buffer {
 #define V4L2_BUF_FLAG_TSTAMP_SRC_MASK  0x0007
 #define V4L2_BUF_FLAG_TSTAMP_SRC_EOF   0x
 #define V4L2_BUF_FLAG_TSTAMP_SRC_SOE   0x0001
+#define V4L2_BUF_FLAG_IN_FENCE 0x0010
+#define V4L2_BUF_FLAG_OUT_FENCE0x0020
 /* mem2mem encoder/decoder */
-#define V4L2_BUF_FLAG_LAST 0x0010
+#define V4L2_BUF_FLAG_LAST 0x0040
 
 /**
  * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor
-- 
2.9.3

[RFC 00/10] V4L2 explicit synchronization support

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Hi,

This RFC adds support for Explicit Synchronization of shared buffers in V4L2.
It uses the Sync File Framework[1] as vector to communicate the fences
between kernel and userspace.

I'm sending this to start the discussion on the best approach to implement
Explicit Synchronization, please check the TODO/OPEN section below.

Explicit Synchronization allows us to control the synchronization of
shared buffers from userspace by passing fences to the kernel and/or 
receiving them from the the kernel.

Fences passed to the kernel are named in-fences and the kernel should wait
them to signal before using the buffer. On the other side, the kernel creates
out-fences for every buffer it receives from userspace. This fence is sent back
to userspace and it will signal when the capture, for example, has finished.

Signalling an out-fence in V4L2 would mean that the job on the buffer is done
and the buffer can be used by other drivers.

Current RFC implementation
--

The current implementation is not intended to be more than a PoC to start
the discussion on how Explicit Synchronization should be supported in V4L2.

The first patch proposes an userspace API for fences, then on patch 2
we prepare to the addition of in-fences in patch 3, by introducing the
infrastructure on vb2 to wait on an in-fence signal before queueing the buffer
in the driver.

Patch 4 fix uvc v4l2 event handling and patch 5 configure q->dev for vivid
drivers to enable to subscribe and dequeue events on it.

Patches 6-7 enables support to notify BUF_QUEUED events, i.e., let userspace
know that particular buffer was enqueued in the driver. This is needed,
because we return the out-fence fd as an out argument in QBUF, but at the time
it returns we don't know to which buffer the fence will be attached thus
the BUF_QUEUED event tells which buffer is associated to the fence received in
QBUF by userspace.

Patches 8 and 9 add more fence infrastructure to support out-fences and finally
patch 10 adds support to out-fences.

TODO/OPEN:
--

* For this first implementation we will keep the ordering of the buffers queued
in videobuf2, that means we will only enqueue buffer whose fence was signalled
if that buffer is the first one in the queue. Otherwise it has to wait until it
is the first one. This is not implmented yet. Later we could create a flag to
allow unordered queing in the drivers from vb2 if needed.

* Should we have out-fences per-buffer or per-plane? or both? In this RFC, for
simplicity they are per-buffer, but Mauro and Javier raised the option of
doing per-plane fences. That could benefit mem2mem and V4L2 <-> GPU operation
at least on cases when we have Capture hw that releases the Y frame before the
other frames for example. When using V4L2 per-plane out-fences to communicate
with KMS they would need to be merged together as currently the DRM Plane
interface only supports one fence per DRM Plane.

In-fences should be per-buffer as the DRM only has per-buffer fences, but
in case of mem2mem operations per-plane fences might be useful?

So should we have both ways, per-plane and per-buffer, or just one of them
for now?

* other open topics are how to deal with hw-fences and Request API.

Comments are welcome!

Regards,

Gustavo

---
Gustavo Padovan (9):
  [media] vb2: add explicit fence user API
  [media] vb2: split out queueing from vb_core_qbuf()
  [media] vb2: add in-fence support to QBUF
  [media] uvc: enable subscriptions to other events
  [media] vivid: assign the specific device to the vb2_queue->dev
  [media] v4l: add V4L2_EVENT_BUF_QUEUED event
  [media] v4l: add support to BUF_QUEUED event
  [media] vb2: add infrastructure to support out-fences
  [media] vb2: add out-fence support to QBUF

Javier Martinez Canillas (1):
  [media] vb2: add videobuf2 dma-buf fence helpers

 drivers/media/Kconfig |   1 +
 drivers/media/platform/vivid/vivid-core.c |  10 +-
 drivers/media/usb/uvc/uvc_v4l2.c  |   2 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |   4 +-
 drivers/media/v4l2-core/v4l2-ctrls.c  |   6 +-
 drivers/media/v4l2-core/videobuf2-core.c  | 139 --
 drivers/media/v4l2-core/videobuf2-v4l2.c  |  29 +-
 include/media/videobuf2-core.h|  12 ++-
 include/media/videobuf2-fence.h   |  49 +
 include/uapi/linux/videodev2.h|  12 ++-
 10 files changed, 218 insertions(+), 46 deletions(-)
 create mode 100644 include/media/videobuf2-fence.h

-- 
2.9.3

[RFC 05/10] [media] vivid: assign the specific device to the vb2_queue->dev

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Instead of assign the global v4l2 device assigned the specific device,
this was causing trouble when using using V4L2 events with vivid
devices. The queue device should be the same one we opened in userspace.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/platform/vivid/vivid-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index ef344b9..8843170 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1070,7 +1070,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vid_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1090,7 +1090,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vid_out_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1110,7 +1110,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vbi_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1130,7 +1130,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vbi_out_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1149,7 +1149,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 8;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >sdr_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
-- 
2.9.3

[RFC 06/10] [media] v4l: add V4L2_EVENT_BUF_QUEUED event

2017-03-13 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Add a new event the userspace can subscribe to receive notifications
about when a buffer was enqueued onto the driver. The event provides
the index of the enqueued buffer.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 include/uapi/linux/videodev2.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 3b6cfa6..5b44fd0 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2133,6 +2133,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_FRAME_SYNC  4
 #define V4L2_EVENT_SOURCE_CHANGE   5
 #define V4L2_EVENT_MOTION_DET  6
+#define V4L2_EVENT_BUF_QUEUED  7
 #define V4L2_EVENT_PRIVATE_START   0x0800
 
 /* Payload for V4L2_EVENT_VSYNC */
@@ -2185,6 +2186,10 @@ struct v4l2_event_motion_det {
__u32 region_mask;
 };
 
+struct v4l2_event_buf_queued {
+   __u32 index;
+};
+
 struct v4l2_event {
__u32   type;
union {
@@ -2193,6 +2198,7 @@ struct v4l2_event {
struct v4l2_event_frame_syncframe_sync;
struct v4l2_event_src_changesrc_change;
struct v4l2_event_motion_detmotion_det;
+   struct v4l2_event_buf_queuedbuf_queued;
__u8data[64];
} u;
__u32   pending;
-- 
2.9.3

[RFC 08/10] [media] vb2: add videobuf2 dma-buf fence helpers

2017-03-13 Thread Gustavo Padovan

From: Javier Martinez Canillas <jav...@osg.samsung.com>

Add a videobuf2-fence.h header file that contains different helpers
for DMA buffer sharing explicit fence support in videobuf2.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 include/media/videobuf2-fence.h | 49 +
 1 file changed, 49 insertions(+)
 create mode 100644 include/media/videobuf2-fence.h

diff --git a/include/media/videobuf2-fence.h b/include/media/videobuf2-fence.h
new file mode 100644
index 000..ed5612c
--- /dev/null
+++ b/include/media/videobuf2-fence.h
@@ -0,0 +1,49 @@
+/*
+ * videobuf2-fence.h - DMA buffer sharing fence helpers for videobuf 2
+ *
+ * Copyright (C) 2016 Samsung Electronics
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+static DEFINE_SPINLOCK(vb2_fence_lock);
+
+static inline const char *vb2_fence_get_driver_name(struct dma_fence *fence)
+{
+   return "vb2_fence";
+}
+
+static inline const char *vb2_fence_get_timeline_name(struct dma_fence *fence)
+{
+   return "vb2_fence_timeline";
+}
+
+static inline bool vb2_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+static const struct dma_fence_ops vb2_fence_ops = {
+   .get_driver_name = vb2_fence_get_driver_name,
+   .get_timeline_name = vb2_fence_get_timeline_name,
+   .enable_signaling = vb2_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
+static inline struct dma_fence *vb2_fence_alloc(void)
+{
+   struct dma_fence *vb2_fence = kzalloc(sizeof(*vb2_fence), GFP_KERNEL);
+
+   if (!vb2_fence)
+   return NULL;
+
+   dma_fence_init(vb2_fence, _fence_ops, _fence_lock,
+  dma_fence_context_alloc(1), 1);
+
+   return vb2_fence;
+}
-- 
2.9.3

Re: [PATCH] dma-buf: fence debugging

2017-03-31 Thread Gustavo Padovan

Hi Russell,

2017-03-31 Russell King :

> Add debugfs output to report shared and exclusive fences on a dma_buf
> object.  This produces output such as:
> 
> Dma-buf Objects:
> sizeflags   modecount   exp_name
> 0829440000050005drm
> Exclusive fence: etnaviv 134000.gpu signalled
> Attached Devices:
> gpu-subsystem
> Total 1 devices attached
> 
> 
> Total 1 objects, 8294400 bytes
> 
> 
> Signed-off-by: Russell King 
> ---
>  drivers/dma-buf/dma-buf.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletions(-)

Applied to to drm-misc-next.

> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b792827b..f72aaacbe023 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1059,7 +1059,11 @@ static int dma_buf_debug_show(struct seq_file *s, void 
> *unused)
>   int ret;
>   struct dma_buf *buf_obj;
>   struct dma_buf_attachment *attach_obj;
> - int count = 0, attach_count;
> + struct reservation_object *robj;
> + struct reservation_object_list *fobj;
> + struct dma_fence *fence;
> + unsigned seq;

Our maintainer tools warned about this line, so I made it "unsigned
int"

Gustavo

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-07-11 Thread Gustavo Padovan

2017-07-11 Hans Verkuil <hverk...@xs4all.nl>:

> On 10/07/17 22:26, Gustavo Padovan wrote:
> > 2017-07-10 Gustavo Padovan <gust...@padovan.org>:
> > 
> >> 2017-07-07 Hans Verkuil <hverk...@xs4all.nl>:
> >>
> >>> On 07/07/2017 04:00 AM, Gustavo Padovan wrote:
> >>>> 2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:
> >>>>
> >>>>> On 06/16/17 09:39, Gustavo Padovan wrote:
> >>>>>> From: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>>>>>
> >>>>>> Receive in-fence from userspace and add support for waiting on them
> >>>>>> before queueing the buffer to the driver. Buffers are only queued
> >>>>>> to the driver once they are ready. A buffer is ready when its
> >>>>>> in-fence signals.
> >>>>>>
> >>>>>> v2:
> >>>>>>- fix vb2_queue_or_prepare_buf() ret check
> >>>>>>- remove check for VB2_MEMORY_DMABUF only (Javier)
> >>>>>>- check num of ready buffers to start streaming
> >>>>>>- when queueing, start from the first ready buffer
> >>>>>>- handle queue cancel
> >>>>>>
> >>>>>> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>>>>> ---
> >>>>>>   drivers/media/Kconfig|  1 +
> >>>>>>   drivers/media/v4l2-core/videobuf2-core.c | 97 
> >>>>>> +---
> >>>>>>   drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
> >>>>>>   include/media/videobuf2-core.h   |  7 ++-
> >>>>>>   4 files changed, 99 insertions(+), 21 deletions(-)
> >>>>>>
> >>>>>
> >>>>> 
> >>>>>
> >>>>>> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> >>>>>> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> >>>>>> index 110fb45..e6ad77f 100644
> >>>>>> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> >>>>>> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> >>>>>> @@ -23,6 +23,7 @@
> >>>>>>   #include 
> >>>>>>   #include 
> >>>>>>   #include 
> >>>>>> +#include 
> >>>>>>   #include 
> >>>>>>   #include 
> >>>>>> @@ -560,6 +561,7 @@ EXPORT_SYMBOL_GPL(vb2_create_bufs);
> >>>>>>   int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
> >>>>>>   {
> >>>>>> +  struct dma_fence *fence = NULL;
> >>>>>>int ret;
> >>>>>>if (vb2_fileio_is_active(q)) {
> >>>>>> @@ -568,7 +570,18 @@ int vb2_qbuf(struct vb2_queue *q, struct 
> >>>>>> v4l2_buffer *b)
> >>>>>>}
> >>>>>>ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
> >>>>>> -  return ret ? ret : vb2_core_qbuf(q, b->index, b);
> >>>>>> +  if (ret)
> >>>>>> +  return ret;
> >>>>>> +
> >>>>>> +  if (b->flags & V4L2_BUF_FLAG_IN_FENCE) {
> >>>>>> +  fence = sync_file_get_fence(b->fence_fd);
> >>>>>> +  if (!fence) {
> >>>>>> +  dprintk(1, "failed to get in-fence from fd\n");
> >>>>>> +  return -EINVAL;
> >>>>>> +  }
> >>>>>> +  }
> >>>>>> +
> >>>>>> +  return ret ? ret : vb2_core_qbuf(q, b->index, b, fence);
> >>>>>>   }
> >>>>>>   EXPORT_SYMBOL_GPL(vb2_qbuf);
> >>>>>
> >>>>> You need to adapt __fill_v4l2_buffer so it sets the IN_FENCE buffer flag
> >>>>> if there is a fence pending. It should also fill in fence_fd.
> >>>>
> >>>> It was userspace who sent the fence_fd in the first place. Why do we
> >>>> need to send it back? The initial plan was - from a userspace point of 
> >>>> view
> >>>> - to send the in-fence in the fence_fd field and receive the out-fence
> >>>>   i

Re: [PATCH 09/12] [media] vivid: mark vivid queues as ordered

2017-07-10 Thread Gustavo Padovan

2017-07-07 Shuah Khan <shua...@osg.samsung.com>:

> On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > To enable vivid to be used with explicit synchronization we need
> > to mark its queues as ordered.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/platform/vivid/vivid-core.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/media/platform/vivid/vivid-core.c 
> > b/drivers/media/platform/vivid/vivid-core.c
> > index 8843170..c7bef90 100644
> > --- a/drivers/media/platform/vivid/vivid-core.c
> > +++ b/drivers/media/platform/vivid/vivid-core.c
> > @@ -1063,6 +1063,7 @@ static int vivid_create_instance(struct 
> > platform_device *pdev, int inst)
> > q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE 
> > :
> > V4L2_BUF_TYPE_VIDEO_CAPTURE;
> > q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
> > +   q->ordered = 1;
> 
> How will the driver ensure ordered buffers? Are there more changes needed
> in this driver?

The driver can't requeue a buffer if it mark itself as ordered. It has
to ensure that.

Gustavo

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-07-10 Thread Gustavo Padovan

2017-07-07 Hans Verkuil <hverk...@xs4all.nl>:

> On 07/07/2017 04:00 AM, Gustavo Padovan wrote:
> > 2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:
> > 
> > > On 06/16/17 09:39, Gustavo Padovan wrote:
> > > > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > > > 
> > > > Receive in-fence from userspace and add support for waiting on them
> > > > before queueing the buffer to the driver. Buffers are only queued
> > > > to the driver once they are ready. A buffer is ready when its
> > > > in-fence signals.
> > > > 
> > > > v2:
> > > > - fix vb2_queue_or_prepare_buf() ret check
> > > > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > > > - check num of ready buffers to start streaming
> > > > - when queueing, start from the first ready buffer
> > > > - handle queue cancel
> > > > 
> > > > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > > > ---
> > > >   drivers/media/Kconfig|  1 +
> > > >   drivers/media/v4l2-core/videobuf2-core.c | 97 
> > > > +---
> > > >   drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
> > > >   include/media/videobuf2-core.h   |  7 ++-
> > > >   4 files changed, 99 insertions(+), 21 deletions(-)
> > > > 
> > > 
> > > 
> > > 
> > > > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> > > > b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > > > index 110fb45..e6ad77f 100644
> > > > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > > > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > > > @@ -23,6 +23,7 @@
> > > >   #include 
> > > >   #include 
> > > >   #include 
> > > > +#include 
> > > >   #include 
> > > >   #include 
> > > > @@ -560,6 +561,7 @@ EXPORT_SYMBOL_GPL(vb2_create_bufs);
> > > >   int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
> > > >   {
> > > > +   struct dma_fence *fence = NULL;
> > > > int ret;
> > > > if (vb2_fileio_is_active(q)) {
> > > > @@ -568,7 +570,18 @@ int vb2_qbuf(struct vb2_queue *q, struct 
> > > > v4l2_buffer *b)
> > > > }
> > > > ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
> > > > -   return ret ? ret : vb2_core_qbuf(q, b->index, b);
> > > > +   if (ret)
> > > > +   return ret;
> > > > +
> > > > +   if (b->flags & V4L2_BUF_FLAG_IN_FENCE) {
> > > > +   fence = sync_file_get_fence(b->fence_fd);
> > > > +   if (!fence) {
> > > > +   dprintk(1, "failed to get in-fence from fd\n");
> > > > +   return -EINVAL;
> > > > +   }
> > > > +   }
> > > > +
> > > > +   return ret ? ret : vb2_core_qbuf(q, b->index, b, fence);
> > > >   }
> > > >   EXPORT_SYMBOL_GPL(vb2_qbuf);
> > > 
> > > You need to adapt __fill_v4l2_buffer so it sets the IN_FENCE buffer flag
> > > if there is a fence pending. It should also fill in fence_fd.
> > 
> > It was userspace who sent the fence_fd in the first place. Why do we
> > need to send it back? The initial plan was - from a userspace point of view
> > - to send the in-fence in the fence_fd field and receive the out-fence
> >   in the same field.
> > 
> > As per setting the IN_FENCE flag, that is racy, as the fence can signal
> > just after we called __fill_v4l2_buffer. Why is it important to set it?
> 
> Because when running VIDIOC_QUERYBUF it should return the current state of
> the buffer, including whether it has a fence. You can do something like
> v4l2-ctl --list-buffers to see how many buffers are queued up and the state
> of each buffer. Can be useful to e.g. figure out why a video capture seems
> to stall. Knowing that all queued buffers are all waiting for a fence is
> very useful information. Whether the fence_fd should also be set here or
> only in dqbuf is something I don't know (not enough knowledge about how
> fences are supposed to work). The IN/OUT_FENCE flags should definitely be
> reported though.

I didn't know about this usecase. Thanks for explaining. It certainly
makes sense to set the IN/OUT_FENCE flags here. Regarding the fence_fd
I would expect the application to know the fence fd associated to than
buffer. If we expect an application other than the one which issued
QBUF than I'd say we also need to provide the fd on VIDIOC_QUERYBUF
for inspection purposes. Is that the case?

Gustavo

Re: [PATCH 07/12] [media] v4l: add support to BUF_QUEUED event

2017-07-10 Thread Gustavo Padovan

2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:

> On 06/30/17 14:04, Mauro Carvalho Chehab wrote:
> > Em Fri, 16 Jun 2017 16:39:10 +0900
> > Gustavo Padovan <gust...@padovan.org> escreveu:
> > 
> >> From: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>
> >> Implement the needed pieces to let userspace subscribe for
> >> V4L2_EVENT_BUF_QUEUED events. Videobuf2 will queue the event for the
> >> DQEVENT ioctl.
> >>
> >> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> >> ---
> >>  drivers/media/v4l2-core/v4l2-ctrls.c |  6 +-
> >>  drivers/media/v4l2-core/videobuf2-core.c | 15 +++
> >>  2 files changed, 20 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> >> b/drivers/media/v4l2-core/v4l2-ctrls.c
> >> index 5aed7bd..f55b5da 100644
> >> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> >> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> >> @@ -3435,8 +3435,12 @@ EXPORT_SYMBOL(v4l2_ctrl_log_status);
> >>  int v4l2_ctrl_subscribe_event(struct v4l2_fh *fh,
> >>const struct v4l2_event_subscription *sub)
> >>  {
> >> -  if (sub->type == V4L2_EVENT_CTRL)
> >> +  switch (sub->type) {
> >> +  case V4L2_EVENT_CTRL:
> >>return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
> >> +  case V4L2_EVENT_BUF_QUEUED:
> >> +  return v4l2_event_subscribe(fh, sub, 0, NULL);
> >> +  }
> >>return -EINVAL;
> >>  }
> >>  EXPORT_SYMBOL(v4l2_ctrl_subscribe_event);
> >> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> >> b/drivers/media/v4l2-core/videobuf2-core.c
> >> index 29aa9d4..00d9c35 100644
> >> --- a/drivers/media/v4l2-core/videobuf2-core.c
> >> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> >> @@ -25,6 +25,7 @@
> >>  #include 
> >>  
> >>  #include 
> >> +#include 
> >>  #include 
> >>  
> >>  #include 
> >> @@ -1221,6 +1222,18 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
> >> const void *pb)
> >>return ret;
> >>  }
> >>  
> >> +static void vb2_buffer_queued_event(struct vb2_buffer *vb)
> >> +{
> >> +  struct video_device *vdev = to_video_device(vb->vb2_queue->dev);
> >> +  struct v4l2_event event;
> >> +
> >> +  memset(, 0, sizeof(event));
> >> +  event.type = V4L2_EVENT_BUF_QUEUED;
> >> +  event.u.buf_queued.index = vb->index;
> >> +
> >> +  v4l2_event_queue(vdev, );
> >> +}
> >> +
> > 
> > It doesn't sound right to add a V4L2 event to VB2 core. The hole point
> > of splitting the core from V4L2 specific stuff is to allow VB2 to be
> > used by non-V4L2 APIs[1]. Please move this to videobuf2-v4l2.
> 
> Good point. So this should be a callback to the higher level.
> 
> One thing I was wondering about: v4l2_event_queue sends the event to all
> open filehandles of the video node that subscribed to this event. Is that
> what we want? Or should we use v4l2_event_queue_fh to only send it to the
> vb2 queue owner? I don't know what is best. I think it is OK to send it
> to anyone that is interested. If nothing else it will help debugging.

I don't have any preference here, I'll keep it as is - sending events to
anyone - if no one objects.

Gustavo

Re: [PATCH 04/12] [media] uvc: enable subscriptions to other events

2017-07-10 Thread Gustavo Padovan

2017-07-07 Shuah Khan <shua...@osg.samsung.com>:

> On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Call v4l2_ctrl_subscribe_event to subscribe to more events supported by
> > v4l.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> > b/drivers/media/usb/uvc/uvc_v4l2.c
> > index 3e7e283..dfa0ccd 100644
> > --- a/drivers/media/usb/uvc/uvc_v4l2.c
> > +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> > @@ -1240,7 +1240,7 @@ static int uvc_ioctl_subscribe_event(struct v4l2_fh 
> > *fh,
> > case V4L2_EVENT_CTRL:
> > return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
> > default:
> > -   return -EINVAL;
> > +   return v4l2_ctrl_subscribe_event(fh, sub);
> 
> This looks incorrect. With this change driver will be subscribing to all
> v4l2 events? Is this the intent?

The intent was to enable this driver to subscribe to BUF_QUEUED events. 
It is the only one who can't at the moment. I'll review this.

Gustavo

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-07-10 Thread Gustavo Padovan

2017-07-07 Hans Verkuil <hverk...@xs4all.nl>:

> On 07/07/2017 03:53 AM, Gustavo Padovan wrote:
> > > 
> > > > help
> > > >   If you want to use Webcams, Video grabber devices and/or TV 
> > > > devices
> > > >   enable this option and other options below.
> > > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > > > b/drivers/media/v4l2-core/videobuf2-core.c
> > > > index ea83126..29aa9d4 100644
> > 
> > > > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > > > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > > > @@ -1279,6 +1279,22 @@ static int __buf_prepare(struct vb2_buffer *vb, 
> > > > const void *pb)
> > > > return 0;
> > > >   }
> > > > +static int __get_num_ready_buffers(struct vb2_queue *q)
> > > > +{
> > > > +   struct vb2_buffer *vb;
> > > > +   int ready_count = 0;
> > > > +
> > > > +   /* count num of buffers ready in front of the queued_list */
> > > > +   list_for_each_entry(vb, >queued_list, queued_entry) {
> > > > +   if (vb->in_fence && 
> > > > !dma_fence_is_signaled(vb->in_fence))
> > > > +   break;
> > > 
> > > Obviously the break is wrong as Mauro mentioned.
> > 
> > I replied this in the other email to Mauro, if a fence is not signaled
> > it is not ready te be queued by the driver nor is all buffers following
> > it. Hence the break. They need all to be in order and in front of the
> > queue.
> > 
> > In any case I'll check this again as now there is two people saying I'm
> > wrong! :)
> 
> I think this comes back to the 'ordered' requirement and what that means
> exactly. In this particular case if I have buffers queued up in vb2 without
> a fence (or the fence was signaled), why shouldn't it possible to queue them
> up to the driver right away?
> 
> Of course, if all buffers are waiting for a fence, then 
> __get_num_ready_buffers
> returns 0 and nothing happens.
> 
> My understanding is that the ordered requirement is for the hardware,
> i.e. queueing buffers A, B, C to ordered hardware requires that they come
> out in the same order.

That is correct. I thought I had to queue to the hardware in the order we
receive from userspace. So that makes that loop indeed wrong, as we
should queue the buffers right away.

The ordered requirement is for the OUT_FENCE side because after we queue
the buffer to the hardware and send the BUF_QUEUED event out userspace
might just go ahead and issue an DRM Atomic Request containing that
buffer and the out-fence fd received. DRM then needs to wait on that
fence before any scanout, but it may wait after the scanout is not
allowed to fail anymore.

Thus if a buffer requeuing happens at buffer_done() the fence won't
signal and DRM/KMS won't have a buffer to display. That is reason behind
it.

Alternatively we can ignore this and live with the fact that sometimes a
requeuing may affect the scanout pipeline.

Gustavo

Re: [PATCH 05/12] [media] vivid: assign the specific device to the vb2_queue->dev

2017-07-10 Thread Gustavo Padovan

2017-07-07 Shuah Khan <shua...@osg.samsung.com>:

> On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Instead of assigning the global v4l2 device, assign the specific device.
> > This was causing trouble when using using V4L2 events with vivid
> > devices. The device's queue should be the same we opened in userspace.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/platform/vivid/vivid-core.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vivid/vivid-core.c 
> > b/drivers/media/platform/vivid/vivid-core.c
> > index ef344b9..8843170 100644
> > --- a/drivers/media/platform/vivid/vivid-core.c
> > +++ b/drivers/media/platform/vivid/vivid-core.c
> > @@ -1070,7 +1070,7 @@ static int vivid_create_instance(struct 
> > platform_device *pdev, int inst)
> > q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > q->min_buffers_needed = 2;
> > q->lock = >mutex;
> > -   q->dev = dev->v4l2_dev.dev;
> > +   q->dev = >vid_cap_dev.dev;
> 
> Does this work in all cases? My concern is that in some code paths
> q->dev might be used to initiate release perhaps.
> 
> Fore example v4l2_dev.release is vivid_dev_release()
> dev->v4l2_dev.release = vivid_dev_release;
> 
> vid_cap_dev release is video_device_release_empty
> 
> This is one difference, but there might be others and the code paths
> that might depend on q->dev being the v4l2_dev.dev which is the global
> dev.

Sure, I'll check this again.

Gustavo

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-07-10 Thread Gustavo Padovan

2017-07-10 Gustavo Padovan <gust...@padovan.org>:

> 2017-07-07 Hans Verkuil <hverk...@xs4all.nl>:
> 
> > On 07/07/2017 04:00 AM, Gustavo Padovan wrote:
> > > 2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:
> > > 
> > > > On 06/16/17 09:39, Gustavo Padovan wrote:
> > > > > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > > > > 
> > > > > Receive in-fence from userspace and add support for waiting on them
> > > > > before queueing the buffer to the driver. Buffers are only queued
> > > > > to the driver once they are ready. A buffer is ready when its
> > > > > in-fence signals.
> > > > > 
> > > > > v2:
> > > > >   - fix vb2_queue_or_prepare_buf() ret check
> > > > >   - remove check for VB2_MEMORY_DMABUF only (Javier)
> > > > >   - check num of ready buffers to start streaming
> > > > >   - when queueing, start from the first ready buffer
> > > > >   - handle queue cancel
> > > > > 
> > > > > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > > > > ---
> > > > >   drivers/media/Kconfig|  1 +
> > > > >   drivers/media/v4l2-core/videobuf2-core.c | 97 
> > > > > +---
> > > > >   drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
> > > > >   include/media/videobuf2-core.h   |  7 ++-
> > > > >   4 files changed, 99 insertions(+), 21 deletions(-)
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> > > > > b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > > > > index 110fb45..e6ad77f 100644
> > > > > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > > > > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > > > > @@ -23,6 +23,7 @@
> > > > >   #include 
> > > > >   #include 
> > > > >   #include 
> > > > > +#include 
> > > > >   #include 
> > > > >   #include 
> > > > > @@ -560,6 +561,7 @@ EXPORT_SYMBOL_GPL(vb2_create_bufs);
> > > > >   int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
> > > > >   {
> > > > > + struct dma_fence *fence = NULL;
> > > > >   int ret;
> > > > >   if (vb2_fileio_is_active(q)) {
> > > > > @@ -568,7 +570,18 @@ int vb2_qbuf(struct vb2_queue *q, struct 
> > > > > v4l2_buffer *b)
> > > > >   }
> > > > >   ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
> > > > > - return ret ? ret : vb2_core_qbuf(q, b->index, b);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + if (b->flags & V4L2_BUF_FLAG_IN_FENCE) {
> > > > > + fence = sync_file_get_fence(b->fence_fd);
> > > > > + if (!fence) {
> > > > > + dprintk(1, "failed to get in-fence from fd\n");
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + return ret ? ret : vb2_core_qbuf(q, b->index, b, fence);
> > > > >   }
> > > > >   EXPORT_SYMBOL_GPL(vb2_qbuf);
> > > > 
> > > > You need to adapt __fill_v4l2_buffer so it sets the IN_FENCE buffer flag
> > > > if there is a fence pending. It should also fill in fence_fd.
> > > 
> > > It was userspace who sent the fence_fd in the first place. Why do we
> > > need to send it back? The initial plan was - from a userspace point of 
> > > view
> > > - to send the in-fence in the fence_fd field and receive the out-fence
> > >   in the same field.
> > > 
> > > As per setting the IN_FENCE flag, that is racy, as the fence can signal
> > > just after we called __fill_v4l2_buffer. Why is it important to set it?
> > 
> > Because when running VIDIOC_QUERYBUF it should return the current state of
> > the buffer, including whether it has a fence. You can do something like
> > v4l2-ctl --list-buffers to see how many buffers are queued up and the state
> > of each buffer. Can be useful to e.g. figure out why a video capture seems
> > to stall. Knowing that all queued buffers are all waiting for a fence is
> > very useful information. Whether the fence_fd should also be set here or
> > only in dqbuf is something I don't know (not enough knowledge about how
> > fences are supposed to work). The IN/OUT_FENCE flags should definitely be
> > reported though.
> 
> I didn't know about this usecase. Thanks for explaining. It certainly
> makes sense to set the IN/OUT_FENCE flags here. Regarding the fence_fd
> I would expect the application to know the fence fd associated to than
> buffer. If we expect an application other than the one which issued
> QBUF than I'd say we also need to provide the fd on VIDIOC_QUERYBUF
> for inspection purposes. Is that the case?

I just realized that if we want to also set the in-fence fd here we
actually need to get a new unused fd, as either it is a different pid or
the app already closed the fd it was using previously. Given this extra
complication I'd say we shouldn't set fence fd unless someone has an
usecase in mind.

Gustavo

Re: [PATCH 12/12] [media] vb2: add out-fence support to QBUF

2017-07-10 Thread Gustavo Padovan

2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:

> On 06/16/17 09:39, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
> > an out_fence for the buffer and return it to userspace on the fence_fd
> > field. It only works with ordered queues.
> > 
> > The fence is signaled on buffer_done(), when the job on the buffer is
> > finished.
> > 
> > v2: check if the queue is ordered.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c |  6 ++
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 22 +-
> >  2 files changed, 27 insertions(+), 1 deletion(-)
> > 
> 
> 
> 
> > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> > b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > index e6ad77f..e2733dd 100644
> > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > @@ -204,9 +204,14 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> > void *pb)
> > b->timestamp = ns_to_timeval(vb->timestamp);
> > b->timecode = vbuf->timecode;
> > b->sequence = vbuf->sequence;
> > -   b->fence_fd = -1;
> > +   b->fence_fd = vb->out_fence_fd;
> 
> I forgot to ask: can a buffer have both an in and an out fence? If so, then we
> have a problem here since we can report only one fence fd.
> 
> If it is not allowed, then we need a check for that somewhere.

It is perfect fine to have both, I just wasn't expecting to get them out
from the kernel at the same time. In-fence is set by userspace in the
fence_fd field and then sent to the kernel, the field is then reused to
send the out-fence created in the kernel to userspace. That is how GPU
drivers do it.

Gustavo

Re: [PATCH 07/12] [media] v4l: add support to BUF_QUEUED event

2017-07-03 Thread Gustavo Padovan

Hi Mauro,

2017-06-30 Mauro Carvalho Chehab <mche...@osg.samsung.com>:

> Em Fri, 16 Jun 2017 16:39:10 +0900
> Gustavo Padovan <gust...@padovan.org> escreveu:
> 
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Implement the needed pieces to let userspace subscribe for
> > V4L2_EVENT_BUF_QUEUED events. Videobuf2 will queue the event for the
> > DQEVENT ioctl.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c |  6 +-
> >  drivers/media/v4l2-core/videobuf2-core.c | 15 +++
> >  2 files changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 5aed7bd..f55b5da 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -3435,8 +3435,12 @@ EXPORT_SYMBOL(v4l2_ctrl_log_status);
> >  int v4l2_ctrl_subscribe_event(struct v4l2_fh *fh,
> > const struct v4l2_event_subscription *sub)
> >  {
> > -   if (sub->type == V4L2_EVENT_CTRL)
> > +   switch (sub->type) {
> > +   case V4L2_EVENT_CTRL:
> > return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
> > +   case V4L2_EVENT_BUF_QUEUED:
> > +   return v4l2_event_subscribe(fh, sub, 0, NULL);
> > +   }
> > return -EINVAL;
> >  }
> >  EXPORT_SYMBOL(v4l2_ctrl_subscribe_event);
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 29aa9d4..00d9c35 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -25,6 +25,7 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include 
> > @@ -1221,6 +1222,18 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
> > const void *pb)
> > return ret;
> >  }
> >  
> > +static void vb2_buffer_queued_event(struct vb2_buffer *vb)
> > +{
> > +   struct video_device *vdev = to_video_device(vb->vb2_queue->dev);
> > +   struct v4l2_event event;
> > +
> > +   memset(, 0, sizeof(event));
> > +   event.type = V4L2_EVENT_BUF_QUEUED;
> > +   event.u.buf_queued.index = vb->index;
> > +
> > +   v4l2_event_queue(vdev, );
> > +}
> > +
> 
> It doesn't sound right to add a V4L2 event to VB2 core. The hole point
> of splitting the core from V4L2 specific stuff is to allow VB2 to be
> used by non-V4L2 APIs[1]. Please move this to videobuf2-v4l2.

Yes, that makes sense.  My lack of understanding of v4l2 core didn't me
allow realize that. I'll move it to videobuf2-v4l2.

Gustavo

Re: [PATCH 00/12] V4L2 explicit synchronization support

2017-07-03 Thread Gustavo Padovan

Hi Mauro,

2017-06-30 Mauro Carvalho Chehab <mche...@osg.samsung.com>:

> Em Fri, 16 Jun 2017 16:39:03 +0900
> Gustavo Padovan <gust...@padovan.org> escreveu:
> 
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Hi,
> > 
> > This adds support for Explicit Synchronization of shared buffers in V4L2.
> > It uses the Sync File Framework[1] as vector to communicate the fences
> > between kernel and userspace.
> > 
> > Explicit Synchronization allows us to control the synchronization of
> > shared buffers from userspace by passing fences to the kernel and/or 
> > receiving them from the the kernel.
> > 
> > Fences passed to the kernel are named in-fences and the kernel should wait
> > them to signal before using the buffer. On the other side, the kernel 
> > creates
> > out-fences for every buffer it receives from userspace. This fence is sent 
> > back
> > to userspace and it will signal when the capture, for example, has finished.
> > 
> > Signalling an out-fence in V4L2 would mean that the job on the buffer is 
> > done
> > and the buffer can be used by other drivers.
> > 
> > The first patch proposes an userspace API for fences, then on patch 2
> > we prepare to the addition of in-fences in patch 3, by introducing the
> > infrastructure on vb2 to wait on an in-fence signal before queueing the 
> > buffer
> > in the driver.
> > 
> > Patch 4 fix uvc v4l2 event handling and patch 5 configure q->dev for vivid
> > drivers to enable to subscribe and dequeue events on it.
> > 
> > Patches 6-7 enables support to notify BUF_QUEUED events, i.e., let userspace
> > know that particular buffer was enqueued in the driver. This is needed,
> > because we return the out-fence fd as an out argument in QBUF, but at the 
> > time
> > it returns we don't know to which buffer the fence will be attached thus
> > the BUF_QUEUED event tells which buffer is associated to the fence received 
> > in
> > QBUF by userspace.
> > 
> > Patches 8-9 add support to mark queues as ordered. Finally patches 10 and 11
> > add more fence infrastructure to support out-fences and finally patch 12 
> > adds
> > support to out-fences.
> > 
> > Changelog are detailed in each patch.
> > 
> > Please review! Thanks.
> 
> Just reviewed the series. Most patches look good.
> 
> I have one additional concern: if the changes here won't cause any
> bad behaviors if fences is not available for some VB2 non V4L2 client.
> I'm actually thinking on this:
> 
>   https://patchwork.linuxtv.org/patch/31613/
> 
> From what I saw, after this patch series, someone could try to 
> inconditionally open an out fences fd for a driver. Maybe this
> should be denied by default, enabling such feature only if the
> VB2 "client" (e. g. videobuf-v4l2) supports it.

Yes, I think we can just reject the request if this non-VB2 client
tries to use the arg flags for fences.

Gustavo

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-07-03 Thread Gustavo Padovan

Hi Mauro,

2017-06-30 Mauro Carvalho Chehab <mche...@osg.samsung.com>:

> Em Fri, 16 Jun 2017 16:39:06 +0900
> Gustavo Padovan <gust...@padovan.org> escreveu:
> 
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers are only queued
> > to the driver once they are ready. A buffer is ready when its
> > in-fence signals.
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/Kconfig|  1 +
> >  drivers/media/v4l2-core/videobuf2-core.c | 97 
> > +---
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
> >  include/media/videobuf2-core.h   |  7 ++-
> >  4 files changed, 99 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> > index 55d9c2b..3cd1d3d 100644
> > --- a/drivers/media/Kconfig
> > +++ b/drivers/media/Kconfig
> > @@ -11,6 +11,7 @@ config CEC_NOTIFIER
> >  menuconfig MEDIA_SUPPORT
> > tristate "Multimedia support"
> > depends on HAS_IOMEM
> > +   select SYNC_FILE
> > help
> >   If you want to use Webcams, Video grabber devices and/or TV devices
> >   enable this option and other options below.
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index ea83126..29aa9d4 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -1279,6 +1279,22 @@ static int __buf_prepare(struct vb2_buffer *vb, 
> > const void *pb)
> > return 0;
> >  }
> >  
> > +static int __get_num_ready_buffers(struct vb2_queue *q)
> > +{
> > +   struct vb2_buffer *vb;
> > +   int ready_count = 0;
> > +
> > +   /* count num of buffers ready in front of the queued_list */
> > +   list_for_each_entry(vb, >queued_list, queued_entry) {
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   break;
> > +
> > +   ready_count++;
> 
> Hmm... maybe that's one of the reasons why out of order explicit fences is not
> working. With the current logic, if explicit fences is enabled, this function
> will always return 0 or 1, even if more buffers are ready.
> 
> IMHO, the correct logic here should be, instead:
> 
>   if (!vb->in_fence || dma_fence_is_signaled(vb->in_fence))
>   ready_count++;

If we do like you propose then we will be getting the wrong ready_count
and queue buffers unordered (in the next two places this code snipet
appears.

In this function I want to know how many ready buffers are in the front
of the buffer. A buffer will be ready if:

* it has no fence
* it has a fence but it was signaled already

Then we start walking the queue looking for such buffers in order and
stop as soon as we find a buffer that doesn't meet these criteria. Hence
the 'break' command to interrupt the loop. If we don't break we may
queue the next buffer on the queue (if it matches the criteria) without
queueing the current one. So we really need break out from the loop
here.

> 
> > +   }
> > +
> > +   return ready_count;
> > +}
> > +
> >  int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
> >  {
> > struct vb2_buffer *vb;
> > @@ -1324,8 +1340,15 @@ static int vb2_start_streaming(struct vb2_queue *q)
> >  * If any buffers were queued before streamon,
> >  * we can now pass them to driver for processing.
> >  */
> > -   list_for_each_entry(vb, >queued_list, queued_entry)
> > +   list_for_each_entry(vb, >queued_list, queued_entry) {
> > +   if (vb->state != VB2_BUF_STATE_QUEUED)
> > +   continue;
> > +
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   break;
> > +
> > __enqueue_in_driver(vb);
> 
> Same as before, the correct logic here seems to be:
> 
>   if (!vb->in_fence || dma_fence_is_signaled(vb->in_fence))
>   __enque

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-07-06 Thread Gustavo Padovan

2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:

> On 06/16/17 09:39, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers are only queued
> > to the driver once they are ready. A buffer is ready when its
> > in-fence signals.
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/Kconfig|  1 +
> >  drivers/media/v4l2-core/videobuf2-core.c | 97 
> > +---
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
> >  include/media/videobuf2-core.h   |  7 ++-
> >  4 files changed, 99 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> > index 55d9c2b..3cd1d3d 100644
> > --- a/drivers/media/Kconfig
> > +++ b/drivers/media/Kconfig
> > @@ -11,6 +11,7 @@ config CEC_NOTIFIER
> >  menuconfig MEDIA_SUPPORT
> > tristate "Multimedia support"
> > depends on HAS_IOMEM
> > +   select SYNC_FILE
> 
> Is this the right place for this? Shouldn't this be selected in
> 'config VIDEOBUF2_CORE'?
> 
> Fences are specific to vb2 after all.

Definitely.

> 
> > help
> >   If you want to use Webcams, Video grabber devices and/or TV devices
> >   enable this option and other options below.
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index ea83126..29aa9d4 100644

> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -1279,6 +1279,22 @@ static int __buf_prepare(struct vb2_buffer *vb, 
> > const void *pb)
> > return 0;
> >  }
> >  
> > +static int __get_num_ready_buffers(struct vb2_queue *q)
> > +{
> > +   struct vb2_buffer *vb;
> > +   int ready_count = 0;
> > +
> > +   /* count num of buffers ready in front of the queued_list */
> > +   list_for_each_entry(vb, >queued_list, queued_entry) {
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   break;
> 
> Obviously the break is wrong as Mauro mentioned.

I replied this in the other email to Mauro, if a fence is not signaled
it is not ready te be queued by the driver nor is all buffers following
it. Hence the break. They need all to be in order and in front of the
queue.

In any case I'll check this again as now there is two people saying I'm
wrong! :)

> 
> > +
> > +   ready_count++;
> > +   }
> > +
> > +   return ready_count;
> > +}
> > +
> >  int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
> >  {
> > struct vb2_buffer *vb;
> > @@ -1324,8 +1340,15 @@ static int vb2_start_streaming(struct vb2_queue *q)
> >  * If any buffers were queued before streamon,
> >  * we can now pass them to driver for processing.
> >  */
> > -   list_for_each_entry(vb, >queued_list, queued_entry)
> > +   list_for_each_entry(vb, >queued_list, queued_entry) {
> > +   if (vb->state != VB2_BUF_STATE_QUEUED)
> > +   continue;
> 
> I think this test is unnecessary.

It might be indeed. It is necessary in __vb2_core_qbuf() so I think I
just copied it here without thinking.

> 
> > +
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   break;
> > +
> > __enqueue_in_driver(vb);
> 
> I would move the above test (after fixing it as Mauro said) to 
> __enqueue_in_driver.
> I.e. if this is waiting for a fence then __enqueue_in_driver does nothing.

Yes, having this check inside __enqueue_in_driver() makes it looks much
nicer.

> 
> > +   }
> >  
> > /* Tell the driver to start streaming */
> > q->start_streaming_called = 1;
> > @@ -1369,33 +1392,55 @@ static int vb2_start_streaming(struct vb2_queue *q)
> >  
> >  static int __vb2_core_qbuf(struct vb2_buffer *vb, struct vb2_queue *q)
> >  {
> > +   struct vb2_buffer *b;
> > int ret;
> >  
> > /*
> >  * If already

Re: [PATCH 02/12] [media] vb2: split out queueing from vb_core_qbuf()

2017-07-06 Thread Gustavo Padovan

2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:

> On 06/16/17 09:39, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > In order to support explicit synchronization we need to divide
> > vb2_core_qbuf() in two parts, one to be executed before the fence
> > signals and another one to do the actual queueing of the buffer.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/v4l2-core/videobuf2-core.c | 51 
> > ++--
> >  1 file changed, 29 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 3107e21..ea83126 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -1367,6 +1367,34 @@ static int vb2_start_streaming(struct vb2_queue *q)
> > return ret;
> >  }
> >  
> > +static int __vb2_core_qbuf(struct vb2_buffer *vb, struct vb2_queue *q)
> > +{
> > +   int ret;
> > +
> > +   /*
> > +* If already streaming, give the buffer to driver for processing.
> > +* If not, the buffer will be given to driver on next streamon.
> > +*/
> > +   if (q->start_streaming_called)
> > +   __enqueue_in_driver(vb);
> > +
> > +   /*
> > +* If streamon has been called, and we haven't yet called
> > +* start_streaming() since not enough buffers were queued, and
> > +* we now have reached the minimum number of queued buffers,
> > +* then we can finally call start_streaming().
> > +*/
> > +   if (q->streaming && !q->start_streaming_called &&
> > +   q->queued_count >= q->min_buffers_needed) {
> > +   ret = vb2_start_streaming(q);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +
> > +   dprintk(1, "qbuf of buffer %d succeeded\n", vb->index);
> > +   return 0;
> > +}
> > +
> >  int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
> >  {
> > struct vb2_buffer *vb;
> > @@ -1404,32 +1432,11 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
> > index, void *pb)
> >  
> > trace_vb2_qbuf(q, vb);
> >  
> > -   /*
> > -* If already streaming, give the buffer to driver for processing.
> > -* If not, the buffer will be given to driver on next streamon.
> > -*/
> > -   if (q->start_streaming_called)
> > -   __enqueue_in_driver(vb);
> > -
> > /* Fill buffer information for the userspace */
> > if (pb)
> > call_void_bufop(q, fill_user_buffer, vb, pb);
> 
> This should be called *after* the __vb2_core_qbuf call. That call changes
> vb->state which is used by buffer to fill in v4l2_buffer. So the order
> should be swapped here to ensure we return the latest state of the buffer.

I didn't pay attention to that detail. The reason why I put it here is
that later when in-fences are introduced we will only call
__vb2_core_qbuf() after the fence signals and that may happen after we
returned to userspace. I'll look into possible ways to solve this
problem.

Gustavo

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-07-06 Thread Gustavo Padovan

2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:

> On 07/03/17 20:16, Gustavo Padovan wrote:
> >>> @@ -1436,6 +1481,11 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned 
> >>> int index, void *pb)
> >>>   if (pb)
> >>>   call_void_bufop(q, fill_user_buffer, vb, pb);
> >>>  
> >>> + vb->in_fence = fence;
> >>> + if (fence && !dma_fence_add_callback(fence, >fence_cb,
> >>> +  vb2_qbuf_fence_cb))
> >>> + return 0;
> >>
> >> Maybe we should provide some error or debug log here or a WARN_ON(), if 
> >> dma_fence_add_callback() fails instead of silently ignore any errors.
> > 
> > This is not an error. If the if succeeds it mean we have installed a
> > callback for the fence. If not, it means the fence signaled already and
> > we don't can call __vb2_core_qbuf right away.
> 
> I had the same question as Mauro. After looking at the dma_fence_add_callback
> code I see what you mean, but a comment would certainly be helpful.

Sure, I'll add a comment explaining it.

> 
> Also, should you set vb->in_fence to NULL if the fence signaled already?
> I'm not sure if you need to call 'dma_fence_put(vb->in_fence);' as well.
> You would know that better than I do.

You got it right. I should be doing that.

Gustavo

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-07-06 Thread Gustavo Padovan

2017-07-06 Hans Verkuil <hverk...@xs4all.nl>:

> On 06/16/17 09:39, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers are only queued
> > to the driver once they are ready. A buffer is ready when its
> > in-fence signals.
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/Kconfig|  1 +
> >  drivers/media/v4l2-core/videobuf2-core.c | 97 
> > +---
> >  drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
> >  include/media/videobuf2-core.h   |  7 ++-
> >  4 files changed, 99 insertions(+), 21 deletions(-)
> > 
> 
> 
> 
> > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> > b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > index 110fb45..e6ad77f 100644
> > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > @@ -23,6 +23,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -560,6 +561,7 @@ EXPORT_SYMBOL_GPL(vb2_create_bufs);
> >  
> >  int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
> >  {
> > +   struct dma_fence *fence = NULL;
> > int ret;
> >  
> > if (vb2_fileio_is_active(q)) {
> > @@ -568,7 +570,18 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer 
> > *b)
> > }
> >  
> > ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
> > -   return ret ? ret : vb2_core_qbuf(q, b->index, b);
> > +   if (ret)
> > +   return ret;
> > +
> > +   if (b->flags & V4L2_BUF_FLAG_IN_FENCE) {
> > +   fence = sync_file_get_fence(b->fence_fd);
> > +   if (!fence) {
> > +   dprintk(1, "failed to get in-fence from fd\n");
> > +   return -EINVAL;
> > +   }
> > +   }
> > +
> > +   return ret ? ret : vb2_core_qbuf(q, b->index, b, fence);
> >  }
> >  EXPORT_SYMBOL_GPL(vb2_qbuf);
> 
> You need to adapt __fill_v4l2_buffer so it sets the IN_FENCE buffer flag
> if there is a fence pending. It should also fill in fence_fd.

It was userspace who sent the fence_fd in the first place. Why do we
need to send it back? The initial plan was - from a userspace point of view
- to send the in-fence in the fence_fd field and receive the out-fence
 in the same field.

As per setting the IN_FENCE flag, that is racy, as the fence can signal
just after we called __fill_v4l2_buffer. Why is it important to set it?

Gustavo

Re: [PATCH] dma-buf: avoid scheduling on fence status query v2

2017-04-27 Thread Gustavo Padovan

2017-04-26 Christian König :

> Am 26.04.2017 um 16:46 schrieb Andres Rodriguez:
> > When a timeout of zero is specified, the caller is only interested in
> > the fence status.
> > 
> > In the current implementation, dma_fence_default_wait will always call
> > schedule_timeout() at least once for an unsignaled fence. This adds a
> > significant overhead to a fence status query.
> > 
> > Avoid this overhead by returning early if a zero timeout is specified.
> > 
> > v2: move early return after enable_signaling
> > 
> > Signed-off-by: Andres Rodriguez 
> 
> Reviewed-by: Christian König 

pushed to drm-misc-next. Thanks all.

Gustavo

Re: [PATCH 04/12] [media] uvc: enable subscriptions to other events

2017-07-25 Thread Gustavo Padovan

2017-07-10 Gustavo Padovan <gust...@padovan.org>:

> 2017-07-07 Shuah Khan <shua...@osg.samsung.com>:
> 
> > On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > > 
> > > Call v4l2_ctrl_subscribe_event to subscribe to more events supported by
> > > v4l.
> > > 
> > > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > > ---
> > >  drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> > > b/drivers/media/usb/uvc/uvc_v4l2.c
> > > index 3e7e283..dfa0ccd 100644
> > > --- a/drivers/media/usb/uvc/uvc_v4l2.c
> > > +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> > > @@ -1240,7 +1240,7 @@ static int uvc_ioctl_subscribe_event(struct v4l2_fh 
> > > *fh,
> > >   case V4L2_EVENT_CTRL:
> > >   return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
> > >   default:
> > > - return -EINVAL;
> > > + return v4l2_ctrl_subscribe_event(fh, sub);
> > 
> > This looks incorrect. With this change driver will be subscribing to all
> > v4l2 events? Is this the intent?
> 
> The intent was to enable this driver to subscribe to BUF_QUEUED events. 
> It is the only one who can't at the moment. I'll review this.

This change do not enable all events, the only new event added is the
BUF_QUEUED. v4l2_ctrl_subscribe_event() only add V4L2_EVENT_CTRL and
V4L2_EVENT_BUF_QUEUED, but the V4L2_EVENT_CTRL case can't be accessed
tere is this situation.

Gustavo

Re: [PATCH 05/12] [media] vivid: assign the specific device to the vb2_queue->dev

2017-07-25 Thread Gustavo Padovan

2017-07-07 Shuah Khan <shua...@osg.samsung.com>:

> On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Instead of assigning the global v4l2 device, assign the specific device.
> > This was causing trouble when using using V4L2 events with vivid
> > devices. The device's queue should be the same we opened in userspace.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---
> >  drivers/media/platform/vivid/vivid-core.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vivid/vivid-core.c 
> > b/drivers/media/platform/vivid/vivid-core.c
> > index ef344b9..8843170 100644
> > --- a/drivers/media/platform/vivid/vivid-core.c
> > +++ b/drivers/media/platform/vivid/vivid-core.c
> > @@ -1070,7 +1070,7 @@ static int vivid_create_instance(struct 
> > platform_device *pdev, int inst)
> > q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > q->min_buffers_needed = 2;
> > q->lock = >mutex;
> > -   q->dev = dev->v4l2_dev.dev;
> > +   q->dev = >vid_cap_dev.dev;
> 
> Does this work in all cases? My concern is that in some code paths
> q->dev might be used to initiate release perhaps.
> 
> Fore example v4l2_dev.release is vivid_dev_release()
> dev->v4l2_dev.release = vivid_dev_release;
> 
> vid_cap_dev release is video_device_release_empty
> 
> This is one difference, but there might be others and the code paths
> that might depend on q->dev being the v4l2_dev.dev which is the global
> dev.

The release call comes from the v4l2-core as we pass the v4l2 device on
v4l2_register_device(). q->dev is in just one ocasion and setting it to
a different device doesn't change the behavior. That code just check if
it is queued or not.

Gustavo

Re: [RFC 00/10] V4L2 explicit synchronization support

2017-06-09 Thread Gustavo Padovan

Hi Mauro,

2017-06-08 Mauro Carvalho Chehab <mche...@osg.samsung.com>:

> Hi Gustavo,
> 
> Em Wed, 24 May 2017 21:31:01 -0300
> Gustavo Padovan <gust...@padovan.org> escreveu:
> 
> > Hi all,
> > 
> > I've been working on the v2 of this series, but I think I hit a blocker
> > when trying to cover the case where the driver asks to requeue the
> > buffer. It is related to the out-fence side.
> > 
> > In the current implementation we return on QBUF an out-fence fd that is not
> > tied to any buffer, because we don't know the queueing order until the
> > buffer is queued to the driver. Then when the buffer is queued we use
> > the BUF_QUEUED event to notify userspace of the index of the buffer,
> > so now userspace knows the buffer associated to the out-fence fd
> > received earlier.
> > 
> > Userspace goes ahead and send a DRM Atomic Request to the kernel to
> > display that buffer on the screen once the fence signals. If it is 
> > a nonblocking request the fence waiting is past the check phase, thus
> > it isn't allowed to fail anymore.
> > 
> > But now, what happens if the V4L2 driver calls buffer_done() asking
> > to requeue the buffer. That means the operation failed and can't
> > signal the fence, starving the DRM side.
> > 
> > We need to fix that. The only way I can see is to guarantee ordering of
> > buffers when out-fences are used. Ordering is something that HAL3 needs
> > to so maybe there is more than one reason to do it like this. I'm not
> > a V4L2 expert, so I don't know all the consequences of such a change.
> > 
> > Any other ideas?
> > 
> > The current patchset is at:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences
> 
> Currently, nothing warrants that buffers will be returned in order,
> but that should be the case of most drivers. I guess the main
> exception would be mem2mem codec drivers. On those, the driver
> or the hardware may opt to reorder the buffers.
> 
> If this is a mandatory requirement for explicit fences to work, then
> we'll need to be able to explicitly enable it, per driver, and
> clearly document that drivers using it *should* warrant that the
> dequeued buffer will follow the queued order.

It is mandatory in the sense it won't work properly and make DRM fail an
atomic commit if a buffer is requeued. So it is fair to ask drivers to
guarantee ordering is a good thing. Then later we can deal with the
drivers that can't. 

> 
> We may need to modify VB2 in order to enforce it or return an
> error if the order doesn't match.

Yeah, I'll look into how to do this.

Gustavo

Re: [RFC 00/10] V4L2 explicit synchronization support

2017-06-09 Thread Gustavo Padovan

2017-06-08 Shuah Khan <shuahk...@gmail.com>:

> Hi Gustavo,
> 
> On Thu, Jun 8, 2017 at 2:17 PM, Mauro Carvalho Chehab
> <mche...@osg.samsung.com> wrote:
> > Hi Gustavo,
> >
> > Em Wed, 24 May 2017 21:31:01 -0300
> > Gustavo Padovan <gust...@padovan.org> escreveu:
> >
> >> Hi all,
> >>
> >> I've been working on the v2 of this series, but I think I hit a blocker
> >> when trying to cover the case where the driver asks to requeue the
> >> buffer. It is related to the out-fence side.
> >>
> >> In the current implementation we return on QBUF an out-fence fd that is not
> >> tied to any buffer, because we don't know the queueing order until the
> >> buffer is queued to the driver. Then when the buffer is queued we use
> >> the BUF_QUEUED event to notify userspace of the index of the buffer,
> >> so now userspace knows the buffer associated to the out-fence fd
> >> received earlier.
> >>
> >> Userspace goes ahead and send a DRM Atomic Request to the kernel to
> >> display that buffer on the screen once the fence signals. If it is
> >> a nonblocking request the fence waiting is past the check phase, thus
> >> it isn't allowed to fail anymore.
> >>
> >> But now, what happens if the V4L2 driver calls buffer_done() asking
> >> to requeue the buffer. That means the operation failed and can't
> >> signal the fence, starving the DRM side.
> >>
> >> We need to fix that. The only way I can see is to guarantee ordering of
> >> buffers when out-fences are used. Ordering is something that HAL3 needs
> >> to so maybe there is more than one reason to do it like this. I'm not
> >> a V4L2 expert, so I don't know all the consequences of such a change.
> >>
> >> Any other ideas?
> >>
> >> The current patchset is at:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences
> 
> Do you plan to send the v2 out? I did a quick review and have a few comments.
> 
> [media] vb2: split out queueing from vb_core_qbuf()
> 
> It changes the sequence a bit.
> 
> /* Fill buffer information for the userspace */
>   if (pb)
>   call_void_bufop(q, fill_user_buffer, vb, pb);
> 
> With the changes - user information is filled before __enqueue_in_driver(vb);

Without my changes it also fills it before __enqueue_in_driver() when
start_streaming wasn't called yet. So I don't think it really matters.

> 
> Anyway, it might be a good idea to send the v2 out for review and we can 
> review
> patches in detail. I am hoping to test your patch series on odroid-xu4
> next week.
> Could you please add me to the thread as well as include me when you send
> v2 and subsequent versions.

I will send a v2 as soon as I can, but from Thursday next week until
the 25th I'll be on vacation.

Gustavo

Re: [PATCH 08/12] [media] vb2: add 'ordered' property to queues

2017-06-26 Thread Gustavo Padovan

Hi Nicolas,

2017-06-16 Nicolas Dufresne <nico...@ndufresne.ca>:

> Le vendredi 16 juin 2017 à 16:39 +0900, Gustavo Padovan a écrit :
> > > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > For explicit synchronization (and soon for HAL3/Request API) we need
> > the v4l2-driver to guarantee the ordering which the buffer were queued
> > by userspace. This is already true for many drivers, but we never had
> > the need to say it.
> 
> Phrased this way, that sound like a statement that a m2m decoder
> handling b-frame will just never be supported. I think decoders are a
> very important use case for explicit synchronization.
> 
> What I believe happens with decoders is simply that the allocation
> order (the order in which empty buffers are retrieved from the queue)
> will be different then the actual presentation order. Also, multiple
> buffers endup being filled at the same time. Some firmware may inform
> of the new order at the last minute, making indeed the fence useless,
> but these are firmware and the information can be known earlier. Also,
> this information would be known by userspace for the case (up-coming,
> see STM patches and Rockchip comments [0]) or state-less decoder,
> because it is available while parsing the bitstream. For this last
> scenarios, the fact that ordering is not the same should disable the
> fences since userspace can know which fences to wait for first. Those
> drivers would need to set "ordered" to 0, which would be counter
> intuitive.
> 
> I think this use case is too important to just ignore it. I would
> expect that we at least have a todo with something sensible as a plan
> to cover this.

We definitely need to cover these usecases, I sent the patchset in a
hurry just before going on vacation and forget to lay down any plan for
other things. But for now, I believe we need refine the implementation
of the most common case and then look at expanding it.

Gustavo

Re: [PATCH 01/12] [media] vb2: add explicit fence user API

2017-06-26 Thread Gustavo Padovan

2017-06-18 kbuild test robot <l...@intel.com>:

> Hi Gustavo,
> 
> [auto build test ERROR on linuxtv-media/master]
> [also build test ERROR on v4.12-rc5 next-20170616]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Gustavo-Padovan/vb2-add-explicit-fence-user-API/20170618-210740
> base:   git://linuxtv.org/media_tree.git master
> config: x86_64-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c: In function 
> 'atomisp_qbuf':
> >> drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1297:10: 
> >> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
> >> 'reserved'?
>  (buf->reserved2 & ATOMISP_BUFFER_HAS_PER_FRAME_SETTING)) {
>  ^~
>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1299:50: 
> error: 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 
> 'reserved'?
>   pipe->frame_request_config_id[buf->index] = buf->reserved2 &
>  ^~
>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c: In function 
> 'atomisp_dqbuf':
>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1483:5: error: 
> 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 'reserved'?
>  buf->reserved2 = pipe->frame_config_id[buf->index];
> ^~
>In file included from include/linux/printk.h:329:0,
> from include/linux/kernel.h:13,
> from include/linux/delay.h:21,
> from 
> drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:24:
>drivers/staging/media//atomisp/pci/atomisp2/atomisp_ioctl.c:1488:6: error: 
> 'struct v4l2_buffer' has no member named 'reserved2'; did you mean 'reserved'?
>   buf->reserved2);
>  ^

Ouch! Seems the reserved2 was burned down by 2 drivers accessing it
without any care for the uAPI. I'll change my patches to use the
'reserved' field instead.

Gustavo

Re: [RFC 00/10] V4L2 explicit synchronization support

2017-05-24 Thread Gustavo Padovan

Hi all,

I've been working on the v2 of this series, but I think I hit a blocker
when trying to cover the case where the driver asks to requeue the
buffer. It is related to the out-fence side.

In the current implementation we return on QBUF an out-fence fd that is not
tied to any buffer, because we don't know the queueing order until the
buffer is queued to the driver. Then when the buffer is queued we use
the BUF_QUEUED event to notify userspace of the index of the buffer,
so now userspace knows the buffer associated to the out-fence fd
received earlier.

Userspace goes ahead and send a DRM Atomic Request to the kernel to
display that buffer on the screen once the fence signals. If it is 
a nonblocking request the fence waiting is past the check phase, thus
it isn't allowed to fail anymore.

But now, what happens if the V4L2 driver calls buffer_done() asking
to requeue the buffer. That means the operation failed and can't
signal the fence, starving the DRM side.

We need to fix that. The only way I can see is to guarantee ordering of
buffers when out-fences are used. Ordering is something that HAL3 needs
to so maybe there is more than one reason to do it like this. I'm not
a V4L2 expert, so I don't know all the consequences of such a change.

Any other ideas?

The current patchset is at:

https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences

Regards,

Gustavo

2017-03-13 Gustavo Padovan <gust...@padovan.org>:

> From: Gustavo Padovan <gustavo.pado...@collabora.com>
> 
> Hi,
> 
> This RFC adds support for Explicit Synchronization of shared buffers in V4L2.
> It uses the Sync File Framework[1] as vector to communicate the fences
> between kernel and userspace.
> 
> I'm sending this to start the discussion on the best approach to implement
> Explicit Synchronization, please check the TODO/OPEN section below.
> 
> Explicit Synchronization allows us to control the synchronization of
> shared buffers from userspace by passing fences to the kernel and/or 
> receiving them from the the kernel.
> 
> Fences passed to the kernel are named in-fences and the kernel should wait
> them to signal before using the buffer. On the other side, the kernel creates
> out-fences for every buffer it receives from userspace. This fence is sent 
> back
> to userspace and it will signal when the capture, for example, has finished.
> 
> Signalling an out-fence in V4L2 would mean that the job on the buffer is done
> and the buffer can be used by other drivers.
> 
> Current RFC implementation
> --
> 
> The current implementation is not intended to be more than a PoC to start
> the discussion on how Explicit Synchronization should be supported in V4L2.
> 
> The first patch proposes an userspace API for fences, then on patch 2
> we prepare to the addition of in-fences in patch 3, by introducing the
> infrastructure on vb2 to wait on an in-fence signal before queueing the buffer
> in the driver.
> 
> Patch 4 fix uvc v4l2 event handling and patch 5 configure q->dev for vivid
> drivers to enable to subscribe and dequeue events on it.
> 
> Patches 6-7 enables support to notify BUF_QUEUED events, i.e., let userspace
> know that particular buffer was enqueued in the driver. This is needed,
> because we return the out-fence fd as an out argument in QBUF, but at the time
> it returns we don't know to which buffer the fence will be attached thus
> the BUF_QUEUED event tells which buffer is associated to the fence received in
> QBUF by userspace.
> 
> Patches 8 and 9 add more fence infrastructure to support out-fences and 
> finally
> patch 10 adds support to out-fences.
> 
> TODO/OPEN:
> --
> 
> * For this first implementation we will keep the ordering of the buffers 
> queued
> in videobuf2, that means we will only enqueue buffer whose fence was signalled
> if that buffer is the first one in the queue. Otherwise it has to wait until 
> it
> is the first one. This is not implmented yet. Later we could create a flag to
> allow unordered queing in the drivers from vb2 if needed.
> 
> * Should we have out-fences per-buffer or per-plane? or both? In this RFC, for
> simplicity they are per-buffer, but Mauro and Javier raised the option of
> doing per-plane fences. That could benefit mem2mem and V4L2 <-> GPU operation
> at least on cases when we have Capture hw that releases the Y frame before the
> other frames for example. When using V4L2 per-plane out-fences to communicate
> with KMS they would need to be merged together as currently the DRM Plane
> interface only supports one fence per DRM Plane.
> 
> In-fences should be per-buffer as the DRM only has per-buffer fences, but
> in case of mem2mem operations per-plane fences might be useful?
> 
> So sh

[PATCH 02/12] [media] vb2: split out queueing from vb_core_qbuf()

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

In order to support explicit synchronization we need to divide
vb2_core_qbuf() in two parts, one to be executed before the fence
signals and another one to do the actual queueing of the buffer.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 51 ++--
 1 file changed, 29 insertions(+), 22 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 3107e21..ea83126 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1367,6 +1367,34 @@ static int vb2_start_streaming(struct vb2_queue *q)
return ret;
 }
 
+static int __vb2_core_qbuf(struct vb2_buffer *vb, struct vb2_queue *q)
+{
+   int ret;
+
+   /*
+* If already streaming, give the buffer to driver for processing.
+* If not, the buffer will be given to driver on next streamon.
+*/
+   if (q->start_streaming_called)
+   __enqueue_in_driver(vb);
+
+   /*
+* If streamon has been called, and we haven't yet called
+* start_streaming() since not enough buffers were queued, and
+* we now have reached the minimum number of queued buffers,
+* then we can finally call start_streaming().
+*/
+   if (q->streaming && !q->start_streaming_called &&
+   q->queued_count >= q->min_buffers_needed) {
+   ret = vb2_start_streaming(q);
+   if (ret)
+   return ret;
+   }
+
+   dprintk(1, "qbuf of buffer %d succeeded\n", vb->index);
+   return 0;
+}
+
 int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
 {
struct vb2_buffer *vb;
@@ -1404,32 +1432,11 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
 
trace_vb2_qbuf(q, vb);
 
-   /*
-* If already streaming, give the buffer to driver for processing.
-* If not, the buffer will be given to driver on next streamon.
-*/
-   if (q->start_streaming_called)
-   __enqueue_in_driver(vb);
-
/* Fill buffer information for the userspace */
if (pb)
call_void_bufop(q, fill_user_buffer, vb, pb);
 
-   /*
-* If streamon has been called, and we haven't yet called
-* start_streaming() since not enough buffers were queued, and
-* we now have reached the minimum number of queued buffers,
-* then we can finally call start_streaming().
-*/
-   if (q->streaming && !q->start_streaming_called &&
-   q->queued_count >= q->min_buffers_needed) {
-   ret = vb2_start_streaming(q);
-   if (ret)
-   return ret;
-   }
-
-   dprintk(1, "qbuf of buffer %d succeeded\n", vb->index);
-   return 0;
+   return __vb2_core_qbuf(vb, q);
 }
 EXPORT_SYMBOL_GPL(vb2_core_qbuf);
 
-- 
2.9.4

[PATCH 01/12] [media] vb2: add explicit fence user API

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel and return an out-fence from the kernel to
userspace.

Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending a fence to the kernel to be waited on, and
V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c  | 2 +-
 include/uapi/linux/videodev2.h| 4 +++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 6f52970..8f6ab85 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -367,7 +367,7 @@ struct v4l2_buffer32 {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -530,7 +530,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, struct 
v4l2_buffer32 __user
put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
copy_to_user(>timecode, >timecode, sizeof(struct 
v4l2_timecode)) ||
put_user(kp->sequence, >sequence) ||
-   put_user(kp->reserved2, >reserved2) ||
+   put_user(kp->fence_fd, >fence_fd) ||
put_user(kp->reserved, >reserved) ||
put_user(kp->length, >length))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 0c06699..110fb45 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->reserved2 = 0;
+   b->fence_fd = -1;
b->reserved = 0;
 
if (q->is_multiplanar) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2b8feb8..750d511 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -916,7 +916,7 @@ struct v4l2_buffer {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -953,6 +953,8 @@ struct v4l2_buffer {
 #define V4L2_BUF_FLAG_TSTAMP_SRC_SOE   0x0001
 /* mem2mem encoder/decoder */
 #define V4L2_BUF_FLAG_LAST 0x0010
+#define V4L2_BUF_FLAG_IN_FENCE 0x0020
+#define V4L2_BUF_FLAG_OUT_FENCE0x0040
 
 /**
  * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor
-- 
2.9.4

[PATCH 07/12] [media] v4l: add support to BUF_QUEUED event

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Implement the needed pieces to let userspace subscribe for
V4L2_EVENT_BUF_QUEUED events. Videobuf2 will queue the event for the
DQEVENT ioctl.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/v4l2-ctrls.c |  6 +-
 drivers/media/v4l2-core/videobuf2-core.c | 15 +++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 5aed7bd..f55b5da 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3435,8 +3435,12 @@ EXPORT_SYMBOL(v4l2_ctrl_log_status);
 int v4l2_ctrl_subscribe_event(struct v4l2_fh *fh,
const struct v4l2_event_subscription *sub)
 {
-   if (sub->type == V4L2_EVENT_CTRL)
+   switch (sub->type) {
+   case V4L2_EVENT_CTRL:
return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
+   case V4L2_EVENT_BUF_QUEUED:
+   return v4l2_event_subscribe(fh, sub, 0, NULL);
+   }
return -EINVAL;
 }
 EXPORT_SYMBOL(v4l2_ctrl_subscribe_event);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 29aa9d4..00d9c35 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -25,6 +25,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -1221,6 +1222,18 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const 
void *pb)
return ret;
 }
 
+static void vb2_buffer_queued_event(struct vb2_buffer *vb)
+{
+   struct video_device *vdev = to_video_device(vb->vb2_queue->dev);
+   struct v4l2_event event;
+
+   memset(, 0, sizeof(event));
+   event.type = V4L2_EVENT_BUF_QUEUED;
+   event.u.buf_queued.index = vb->index;
+
+   v4l2_event_queue(vdev, );
+}
+
 /**
  * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
  */
@@ -1234,6 +1247,8 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
trace_vb2_buf_queue(q, vb);
 
call_void_vb_qop(vb, buf_queue, vb);
+
+   vb2_buffer_queued_event(vb);
 }
 
 static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
-- 
2.9.4

[PATCH 12/12] [media] vb2: add out-fence support to QBUF

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence for the buffer and return it to userspace on the fence_fd
field. It only works with ordered queues.

The fence is signaled on buffer_done(), when the job on the buffer is
finished.

v2: check if the queue is ordered.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c |  6 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c | 22 +-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 21cc4ed..a57902ee 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -356,6 +356,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
}
+   vb->out_fence_fd = -1;
q->bufs[vb->index] = vb;
 
/* Allocate video buffer memory for the MMAP type */
@@ -940,6 +941,11 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
__enqueue_in_driver(vb);
return;
default:
+   dma_fence_signal(vb->out_fence);
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   vb->out_fence_fd = -1;
+
/* Inform any processes that may be waiting for buffers */
wake_up(>done_wq);
break;
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index e6ad77f..e2733dd 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -204,9 +204,14 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->fence_fd = -1;
+   b->fence_fd = vb->out_fence_fd;
b->reserved = 0;
 
+   if (vb->sync_file) {
+   fd_install(vb->out_fence_fd, vb->sync_file->file);
+   vb->sync_file = NULL;
+   }
+
if (q->is_multiplanar) {
/*
 * Fill in plane-related data if userspace provided an array
@@ -581,6 +586,21 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
}
}
 
+   if (b->flags & V4L2_BUF_FLAG_OUT_FENCE) {
+   if (!q->ordered) {
+   dprintk(1, "can't use out-fences with unordered 
queues\n");
+   dma_fence_put(fence);
+   return -EINVAL;
+   }
+
+   ret = vb2_setup_out_fence(q, b->index);
+   if (ret) {
+   dprintk(1, "failed to set up out-fence\n");
+   dma_fence_put(fence);
+   return ret;
+   }
+   }
+
return ret ? ret : vb2_core_qbuf(q, b->index, b, fence);
 }
 EXPORT_SYMBOL_GPL(vb2_qbuf);
-- 
2.9.4

[PATCH 05/12] [media] vivid: assign the specific device to the vb2_queue->dev

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Instead of assigning the global v4l2 device, assign the specific device.
This was causing trouble when using using V4L2 events with vivid
devices. The device's queue should be the same we opened in userspace.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/platform/vivid/vivid-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index ef344b9..8843170 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1070,7 +1070,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vid_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1090,7 +1090,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vid_out_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1110,7 +1110,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vbi_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1130,7 +1130,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vbi_out_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1149,7 +1149,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 8;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >sdr_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
-- 
2.9.4

[PATCH 06/12] [media] v4l: add V4L2_EVENT_BUF_QUEUED event

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Add a new event the userspace can subscribe to receive notifications
when a buffer is queued onto the driver. The event provides the index of
the queued buffer.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 include/uapi/linux/videodev2.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 750d511..c2eda75 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2150,6 +2150,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_FRAME_SYNC  4
 #define V4L2_EVENT_SOURCE_CHANGE   5
 #define V4L2_EVENT_MOTION_DET  6
+#define V4L2_EVENT_BUF_QUEUED  7
 #define V4L2_EVENT_PRIVATE_START   0x0800
 
 /* Payload for V4L2_EVENT_VSYNC */
@@ -2202,6 +2203,10 @@ struct v4l2_event_motion_det {
__u32 region_mask;
 };
 
+struct v4l2_event_buf_queued {
+   __u32 index;
+};
+
 struct v4l2_event {
__u32   type;
union {
@@ -2210,6 +2215,7 @@ struct v4l2_event {
struct v4l2_event_frame_syncframe_sync;
struct v4l2_event_src_changesrc_change;
struct v4l2_event_motion_detmotion_det;
+   struct v4l2_event_buf_queuedbuf_queued;
__u8data[64];
} u;
__u32   pending;
-- 
2.9.4

[PATCH 08/12] [media] vb2: add 'ordered' property to queues

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

For explicit synchronization (and soon for HAL3/Request API) we need
the v4l2-driver to guarantee the ordering which the buffer were queued
by userspace. This is already true for many drivers, but we never had
the need to say it.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 include/media/videobuf2-core.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index aa43e43..a8b800e 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -491,6 +491,9 @@ struct vb2_buf_ops {
  * @last_buffer_dequeued: used in poll() and DQBUF to immediately return if the
  * last decoded buffer was already dequeued. Set for capture queues
  * when a buffer with the V4L2_BUF_FLAG_LAST is dequeued.
+ * @ordered: if the driver can guarantee that the queue will be ordered or not.
+ * The default is not ordered unless the driver sets this flag. It
+ * is mandatory for using explicit fences.
  * @fileio:file io emulator internal data, used only if emulator is active
  * @threadio:  thread io internal data, used only if thread is active
  */
@@ -541,6 +544,7 @@ struct vb2_queue {
unsigned intis_output:1;
unsigned intcopy_timestamp:1;
unsigned intlast_buffer_dequeued:1;
+   unsigned intordered:1;
 
struct vb2_fileio_data  *fileio;
struct vb2_threadio_data*threadio;
-- 
2.9.4

[PATCH 00/12] V4L2 explicit synchronization support

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Hi,

This adds support for Explicit Synchronization of shared buffers in V4L2.
It uses the Sync File Framework[1] as vector to communicate the fences
between kernel and userspace.

Explicit Synchronization allows us to control the synchronization of
shared buffers from userspace by passing fences to the kernel and/or 
receiving them from the the kernel.

Fences passed to the kernel are named in-fences and the kernel should wait
them to signal before using the buffer. On the other side, the kernel creates
out-fences for every buffer it receives from userspace. This fence is sent back
to userspace and it will signal when the capture, for example, has finished.

Signalling an out-fence in V4L2 would mean that the job on the buffer is done
and the buffer can be used by other drivers.

The first patch proposes an userspace API for fences, then on patch 2
we prepare to the addition of in-fences in patch 3, by introducing the
infrastructure on vb2 to wait on an in-fence signal before queueing the buffer
in the driver.

Patch 4 fix uvc v4l2 event handling and patch 5 configure q->dev for vivid
drivers to enable to subscribe and dequeue events on it.

Patches 6-7 enables support to notify BUF_QUEUED events, i.e., let userspace
know that particular buffer was enqueued in the driver. This is needed,
because we return the out-fence fd as an out argument in QBUF, but at the time
it returns we don't know to which buffer the fence will be attached thus
the BUF_QUEUED event tells which buffer is associated to the fence received in
QBUF by userspace.

Patches 8-9 add support to mark queues as ordered. Finally patches 10 and 11
add more fence infrastructure to support out-fences and finally patch 12 adds
support to out-fences.

Changelog are detailed in each patch.

Please review! Thanks.

Gustavo

[1] drivers/dma-buf/sync_file.c
---
Gustavo Padovan (11):
  [media] vb2: add explicit fence user API
  [media] vb2: split out queueing from vb_core_qbuf()
  [media] vb2: add in-fence support to QBUF
  [media] uvc: enable subscriptions to other events
  [media] vivid: assign the specific device to the vb2_queue->dev
  [media] v4l: add V4L2_EVENT_BUF_QUEUED event
  [media] v4l: add support to BUF_QUEUED event
  [media] vb2: add 'ordered' property to queues
  [media] vivid: mark vivid queues as ordered
  [media] vb2: add infrastructure to support out-fences
  [media] vb2: add out-fence support to QBUF

Javier Martinez Canillas (1):
  [media] vb2: add videobuf2 dma-buf fence helpers

 drivers/media/Kconfig |   1 +
 drivers/media/platform/vivid/vivid-core.c |  15 ++-
 drivers/media/usb/uvc/uvc_v4l2.c  |   2 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |   4 +-
 drivers/media/v4l2-core/v4l2-ctrls.c  |   6 +-
 drivers/media/v4l2-core/videobuf2-core.c  | 172 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c  |  37 +-
 include/media/videobuf2-core.h|  16 ++-
 include/media/videobuf2-fence.h   |  49 
 include/uapi/linux/videodev2.h|  10 +-
 10 files changed, 272 insertions(+), 40 deletions(-)
 create mode 100644 include/media/videobuf2-fence.h

-- 
2.9.4

[PATCH 03/12] [media] vb2: add in-fence support to QBUF

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers are only queued
to the driver once they are ready. A buffer is ready when its
in-fence signals.

v2:
- fix vb2_queue_or_prepare_buf() ret check
- remove check for VB2_MEMORY_DMABUF only (Javier)
- check num of ready buffers to start streaming
- when queueing, start from the first ready buffer
- handle queue cancel

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/Kconfig|  1 +
 drivers/media/v4l2-core/videobuf2-core.c | 97 +---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
 include/media/videobuf2-core.h   |  7 ++-
 4 files changed, 99 insertions(+), 21 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 55d9c2b..3cd1d3d 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -11,6 +11,7 @@ config CEC_NOTIFIER
 menuconfig MEDIA_SUPPORT
tristate "Multimedia support"
depends on HAS_IOMEM
+   select SYNC_FILE
help
  If you want to use Webcams, Video grabber devices and/or TV devices
  enable this option and other options below.
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index ea83126..29aa9d4 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1279,6 +1279,22 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
return 0;
 }
 
+static int __get_num_ready_buffers(struct vb2_queue *q)
+{
+   struct vb2_buffer *vb;
+   int ready_count = 0;
+
+   /* count num of buffers ready in front of the queued_list */
+   list_for_each_entry(vb, >queued_list, queued_entry) {
+   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
+   break;
+
+   ready_count++;
+   }
+
+   return ready_count;
+}
+
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
 {
struct vb2_buffer *vb;
@@ -1324,8 +1340,15 @@ static int vb2_start_streaming(struct vb2_queue *q)
 * If any buffers were queued before streamon,
 * we can now pass them to driver for processing.
 */
-   list_for_each_entry(vb, >queued_list, queued_entry)
+   list_for_each_entry(vb, >queued_list, queued_entry) {
+   if (vb->state != VB2_BUF_STATE_QUEUED)
+   continue;
+
+   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
+   break;
+
__enqueue_in_driver(vb);
+   }
 
/* Tell the driver to start streaming */
q->start_streaming_called = 1;
@@ -1369,33 +1392,55 @@ static int vb2_start_streaming(struct vb2_queue *q)
 
 static int __vb2_core_qbuf(struct vb2_buffer *vb, struct vb2_queue *q)
 {
+   struct vb2_buffer *b;
int ret;
 
/*
 * If already streaming, give the buffer to driver for processing.
 * If not, the buffer will be given to driver on next streamon.
 */
-   if (q->start_streaming_called)
-   __enqueue_in_driver(vb);
 
-   /*
-* If streamon has been called, and we haven't yet called
-* start_streaming() since not enough buffers were queued, and
-* we now have reached the minimum number of queued buffers,
-* then we can finally call start_streaming().
-*/
-   if (q->streaming && !q->start_streaming_called &&
-   q->queued_count >= q->min_buffers_needed) {
-   ret = vb2_start_streaming(q);
-   if (ret)
-   return ret;
+   if (q->start_streaming_called) {
+   list_for_each_entry(b, >queued_list, queued_entry) {
+   if (b->state != VB2_BUF_STATE_QUEUED)
+   continue;
+
+   if (b->in_fence && !dma_fence_is_signaled(b->in_fence))
+   break;
+
+   __enqueue_in_driver(b);
+   }
+   } else {
+   /*
+* If streamon has been called, and we haven't yet called
+* start_streaming() since not enough buffers were queued, and
+* we now have reached the minimum number of queued buffers
+* that are ready, then we can finally call start_streaming().
+*/
+   if (q->streaming &&
+   __get_num_ready_buffers(q) >= q->min_buffers_needed) {
+   ret = vb2_start_streaming(q);
+   if (ret)
+   return ret;
+

[PATCH 11/12] [media] vb2: add infrastructure to support out-fences

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 31 +++
 include/media/videobuf2-core.h   |  5 +
 2 files changed, 36 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 00d9c35..21cc4ed 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -23,8 +23,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -1335,6 +1338,34 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned 
int index, void *pb)
 }
 EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
 
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index)
+{
+   struct vb2_buffer *vb = q->bufs[index];
+
+   vb->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+   if (vb->out_fence_fd < 0)
+   return vb->out_fence_fd;
+
+   vb->out_fence = vb2_fence_alloc();
+   if (!vb->out_fence)
+   goto err;
+
+   vb->sync_file = sync_file_create(vb->out_fence);
+   if (!vb->sync_file) {
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   goto err;
+   }
+
+   return 0;
+
+err:
+   put_unused_fd(vb->out_fence_fd);
+   vb->out_fence_fd = -1;
+   return -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(vb2_setup_out_fence);
+
 /**
  * vb2_start_streaming() - Attempt to start streaming.
  * @q: videobuf2 queue
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index a8b800e..5f3e3eb 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -263,6 +263,10 @@ struct vb2_buffer {
 
struct dma_fence*in_fence;
struct dma_fence_cb fence_cb;
+
+   struct dma_fence*out_fence;
+   struct sync_file*sync_file;
+   int out_fence_fd;
 #ifdef CONFIG_VIDEO_ADV_DEBUG
/*
 * Counters for how often these buffer-related ops are
@@ -714,6 +718,7 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
vb2_memory memory,
  */
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb);
 
+int vb2_setup_out_fence(struct vb2_queue *q, unsigned int index);
 /**
  * vb2_core_qbuf() - Queue a buffer from userspace
  *
-- 
2.9.4

[PATCH 10/12] [media] vb2: add videobuf2 dma-buf fence helpers

2017-06-16 Thread Gustavo Padovan

From: Javier Martinez Canillas <jav...@osg.samsung.com>

Add a videobuf2-fence.h header file that contains different helpers
for DMA buffer sharing explicit fence support in videobuf2.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 include/media/videobuf2-fence.h | 49 +
 1 file changed, 49 insertions(+)
 create mode 100644 include/media/videobuf2-fence.h

diff --git a/include/media/videobuf2-fence.h b/include/media/videobuf2-fence.h
new file mode 100644
index 000..ed5612c
--- /dev/null
+++ b/include/media/videobuf2-fence.h
@@ -0,0 +1,49 @@
+/*
+ * videobuf2-fence.h - DMA buffer sharing fence helpers for videobuf 2
+ *
+ * Copyright (C) 2016 Samsung Electronics
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+static DEFINE_SPINLOCK(vb2_fence_lock);
+
+static inline const char *vb2_fence_get_driver_name(struct dma_fence *fence)
+{
+   return "vb2_fence";
+}
+
+static inline const char *vb2_fence_get_timeline_name(struct dma_fence *fence)
+{
+   return "vb2_fence_timeline";
+}
+
+static inline bool vb2_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+static const struct dma_fence_ops vb2_fence_ops = {
+   .get_driver_name = vb2_fence_get_driver_name,
+   .get_timeline_name = vb2_fence_get_timeline_name,
+   .enable_signaling = vb2_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
+static inline struct dma_fence *vb2_fence_alloc(void)
+{
+   struct dma_fence *vb2_fence = kzalloc(sizeof(*vb2_fence), GFP_KERNEL);
+
+   if (!vb2_fence)
+   return NULL;
+
+   dma_fence_init(vb2_fence, _fence_ops, _fence_lock,
+  dma_fence_context_alloc(1), 1);
+
+   return vb2_fence;
+}
-- 
2.9.4

[PATCH 04/12] [media] uvc: enable subscriptions to other events

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Call v4l2_ctrl_subscribe_event to subscribe to more events supported by
v4l.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 3e7e283..dfa0ccd 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -1240,7 +1240,7 @@ static int uvc_ioctl_subscribe_event(struct v4l2_fh *fh,
case V4L2_EVENT_CTRL:
return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
default:
-   return -EINVAL;
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
 }
 
-- 
2.9.4

[PATCH 09/12] [media] vivid: mark vivid queues as ordered

2017-06-16 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

To enable vivid to be used with explicit synchronization we need
to mark its queues as ordered.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/platform/vivid/vivid-core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index 8843170..c7bef90 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1063,6 +1063,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE 
:
V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vid_cap_qops;
@@ -1083,6 +1084,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE :
V4L2_BUF_TYPE_VIDEO_OUTPUT;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vid_out_qops;
@@ -1103,6 +1105,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->has_raw_vbi_cap ? V4L2_BUF_TYPE_VBI_CAPTURE :
  V4L2_BUF_TYPE_SLICED_VBI_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vbi_cap_qops;
@@ -1123,6 +1126,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->has_raw_vbi_out ? V4L2_BUF_TYPE_VBI_OUTPUT :
  V4L2_BUF_TYPE_SLICED_VBI_OUTPUT;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vbi_out_qops;
@@ -1142,6 +1146,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q = >vb_sdr_cap_q;
q->type = V4L2_BUF_TYPE_SDR_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _sdr_cap_qops;
-- 
2.9.4

Re: [PATCH 4/4] dma-buf: Use seq_putc() in two functions

2017-05-08 Thread Gustavo Padovan

Hi Markus,

Thank for your patches.

2017-05-08 SF Markus Elfring <elfr...@users.sourceforge.net>:

> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Mon, 8 May 2017 10:55:42 +0200
> 
> Three single characters (line breaks) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/dma-buf/sync_debug.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.com>

Gustavo

Re: [PATCH 3/4] dma-buf: Adjust a null pointer check in dma_buf_attach()

2017-05-08 Thread Gustavo Padovan

2017-05-08 SF Markus Elfring <elfr...@users.sourceforge.net>:

> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Mon, 8 May 2017 10:54:17 +0200
> 
> The script "checkpatch.pl" pointed information out like the following.
> 
> Comparison to NULL could be written "!attach"
> 
> Thus adjust this expression.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/dma-buf/dma-buf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.com>

Gustavo

Re: [PATCH 1/4] dma-buf: Combine two function calls into one in dma_buf_debug_show()

2017-05-08 Thread Gustavo Padovan

2017-05-08 SF Markus Elfring <elfr...@users.sourceforge.net>:

> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Mon, 8 May 2017 10:32:44 +0200
> 
> A bit of data was put into a sequence by two separate function calls.
> Print the same data by a single function call instead.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/dma-buf/dma-buf.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.com>

Gustavo

Re: [PATCH 2/4] dma-buf: Improve a size determination in dma_buf_attach()

2017-05-08 Thread Gustavo Padovan

2017-05-08 SF Markus Elfring <elfr...@users.sourceforge.net>:

> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Mon, 8 May 2017 10:50:09 +0200
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/dma-buf/dma-buf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.com>

Gustavo

Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

2017-09-11 Thread Gustavo Padovan

2017-09-11 Hans Verkuil <hverk...@xs4all.nl>:

> On 09/11/2017 03:18 PM, Gustavo Padovan wrote:
> > 2017-09-11 Hans Verkuil <hverk...@xs4all.nl>:
> > 
> >> On 09/11/2017 12:50 PM, Hans Verkuil wrote:
> >>> On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
> >>>> From: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>>>
> >>>> Add section to VIDIOC_QBUF about it
> >>>>
> >>>> v2:
> >>>>  - mention that fences are files (Hans)
> >>>>  - rework for the new API
> >>>>
> >>>> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>>> ---
> >>>>  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
> >>>> 
> >>>>  1 file changed, 31 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
> >>>> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >>>> index 1f3612637200..fae0b1431672 100644
> >>>> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >>>> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >>>> @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no 
> >>>> buffer is available.
> >>>>  The struct :c:type:`v4l2_buffer` structure is specified in
> >>>>  :ref:`buffer`.
> >>>>  
> >>>> +Explicit Synchronization
> >>>> +
> >>>> +
> >>>> +Explicit Synchronization allows us to control the synchronization of
> >>>> +shared buffers from userspace by passing fences to the kernel and/or
> >>>> +receiving them from it. Fences passed to the kernel are named in-fences 
> >>>> and
> >>>> +the kernel should wait them to signal before using the buffer, i.e., 
> >>>> queueing
> >>>
> >>> wait them -> wait on them
> >>>
> >>> (do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 
> >>> 100% sure)
> >>>
> >>>> +it to the driver. On the other side, the kernel can create out-fences 
> >>>> for the
> >>>> +buffers it queues to the drivers, out-fences signal when the driver is
> >>>
> >>> Start a new sentence here: ...drivers. Out-fences...
> >>>
> >>>> +finished with buffer, that is the buffer is ready. The fence are 
> >>>> represented
> >>>
> >>> s/that is/i.e/
> >>>
> >>> s/The fence/The fences/
> >>>
> >>>> +by file and passed as file descriptor to userspace.
> >>>
> >>> s/by file/as a file/
> >>> s/as file/as a file/
> >>>
> >>>> +
> >>>> +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` 
> >>>> ioctl
> >>>> +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
> >>>> +flags and the `fence_fd` field. If an in-fence needs to be passed to 
> >>>> the kernel,
> >>>> +`fence_fd` should be set to the fence file descriptor number and the
> >>>> +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both 
> >>>> will
> >>>
> >>> s/Failure to set both/Setting one but not the other/
> >>>
> >>>> +cause ``VIDIOC_QBUF`` to return with error.
> >>>> +
> >>>> +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
> >>>> should
> >>>> +be set to notify it that the next queued buffer should have a fence 
> >>>> attached to
> >>>> +it. That means the out-fence may not be associated with the buffer in 
> >>>> the
> >>>> +current ``VIDIOC_QBUF`` ioctl call because the ordering in which 
> >>>> videobuf2 core
> >>>> +queues the buffers to the drivers can't be guaranteed. To become aware 
> >>>> of the
> >>>> +of the next queued buffer and the out-fence attached to it the
> >>>> +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
> >>>> +for every buffer queued to the V4L2 driver.
> >>>
> >>> This makes no sense.
> >>>
> >>> Setting this flag means IMHO that when *this* buffer is queued up to the 
> >>> driver,
> >>> then it should send the BU

Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

2017-09-11 Thread Gustavo Padovan

2017-09-11 Hans Verkuil <hverk...@xs4all.nl>:

> On 09/11/2017 12:50 PM, Hans Verkuil wrote:
> > On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
> >> From: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>
> >> Add section to VIDIOC_QBUF about it
> >>
> >> v2:
> >>- mention that fences are files (Hans)
> >>- rework for the new API
> >>
> >> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> >> ---
> >>  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
> >> 
> >>  1 file changed, 31 insertions(+)
> >>
> >> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
> >> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> index 1f3612637200..fae0b1431672 100644
> >> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no 
> >> buffer is available.
> >>  The struct :c:type:`v4l2_buffer` structure is specified in
> >>  :ref:`buffer`.
> >>  
> >> +Explicit Synchronization
> >> +
> >> +
> >> +Explicit Synchronization allows us to control the synchronization of
> >> +shared buffers from userspace by passing fences to the kernel and/or
> >> +receiving them from it. Fences passed to the kernel are named in-fences 
> >> and
> >> +the kernel should wait them to signal before using the buffer, i.e., 
> >> queueing
> > 
> > wait them -> wait on them
> > 
> > (do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 
> > 100% sure)
> > 
> >> +it to the driver. On the other side, the kernel can create out-fences for 
> >> the
> >> +buffers it queues to the drivers, out-fences signal when the driver is
> > 
> > Start a new sentence here: ...drivers. Out-fences...
> > 
> >> +finished with buffer, that is the buffer is ready. The fence are 
> >> represented
> > 
> > s/that is/i.e/
> > 
> > s/The fence/The fences/
> > 
> >> +by file and passed as file descriptor to userspace.
> > 
> > s/by file/as a file/
> > s/as file/as a file/
> > 
> >> +
> >> +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
> >> +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
> >> +flags and the `fence_fd` field. If an in-fence needs to be passed to the 
> >> kernel,
> >> +`fence_fd` should be set to the fence file descriptor number and the
> >> +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both will
> > 
> > s/Failure to set both/Setting one but not the other/
> > 
> >> +cause ``VIDIOC_QBUF`` to return with error.
> >> +
> >> +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
> >> should
> >> +be set to notify it that the next queued buffer should have a fence 
> >> attached to
> >> +it. That means the out-fence may not be associated with the buffer in the
> >> +current ``VIDIOC_QBUF`` ioctl call because the ordering in which 
> >> videobuf2 core
> >> +queues the buffers to the drivers can't be guaranteed. To become aware of 
> >> the
> >> +of the next queued buffer and the out-fence attached to it the
> >> +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
> >> +for every buffer queued to the V4L2 driver.
> > 
> > This makes no sense.
> > 
> > Setting this flag means IMHO that when *this* buffer is queued up to the 
> > driver,
> > then it should send the BUF_QUEUED event with an out fence.
> > 
> > I.e. it signals that userspace wants to have the out-fence. The requirement 
> > w.r.t.
> > ordering is that the BUF_QUEUED events have to be in order, but that is 
> > something
> > that the driver can ensure in the case it is doing internal re-ordering.
> > 
> > This requirement is something that needs to be documented here, BTW.
> > 
> > Anyway, the flag shouldn't refer to some 'next buffer', since that's very 
> > confusing.
> 
> Just ignore this comment. I assume v4 will implement it like this.

What approach do you mean by "like this". I'm confused now. :)

In fact, I was in doubt between these two different approaches here.
Should the flag mean *this* or the *next* buffer? The buffers can still
be reordered at the videobuf2 level, because they m

[PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Add section to VIDIOC_QBUF about it

v2:
- mention that fences are files (Hans)
- rework for the new API

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
 1 file changed, 31 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
index 1f3612637200..fae0b1431672 100644
--- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
@@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no buffer 
is available.
 The struct :c:type:`v4l2_buffer` structure is specified in
 :ref:`buffer`.
 
+Explicit Synchronization
+
+
+Explicit Synchronization allows us to control the synchronization of
+shared buffers from userspace by passing fences to the kernel and/or
+receiving them from it. Fences passed to the kernel are named in-fences and
+the kernel should wait them to signal before using the buffer, i.e., queueing
+it to the driver. On the other side, the kernel can create out-fences for the
+buffers it queues to the drivers, out-fences signal when the driver is
+finished with buffer, that is the buffer is ready. The fence are represented
+by file and passed as file descriptor to userspace.
+
+The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
+using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
+flags and the `fence_fd` field. If an in-fence needs to be passed to the 
kernel,
+`fence_fd` should be set to the fence file descriptor number and the
+``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both will
+cause ``VIDIOC_QBUF`` to return with error.
+
+To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag should
+be set to notify it that the next queued buffer should have a fence attached to
+it. That means the out-fence may not be associated with the buffer in the
+current ``VIDIOC_QBUF`` ioctl call because the ordering in which videobuf2 core
+queues the buffers to the drivers can't be guaranteed. To become aware of the
+of the next queued buffer and the out-fence attached to it the
+``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
+for every buffer queued to the V4L2 driver.
+
+At streamoff the out-fences will either signal normally if the drivers wait
+for the operations on the buffers to finish or signal with error if the
+driver cancel the pending operations.
 
 Return Value
 
-- 
2.13.5

[PATCH v3 08/15] [media] vb2: add .buffer_queued() to notify queueing in the driver

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

With the upcoming explicit synchronization support to V4L2 we need a
way to notify userspace when buffers are queued to the driver - buffers
with fences attached to it can only be queued once the fence signal, so
the queueing to the driver might be deferred.

Yet, userspace still wants to be notified, so the buffer_queued() callback
was added to vb2_buf_ops for that purpose.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 include/media/videobuf2-core.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 41cda762ff0a..5ed8d3402474 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -415,6 +415,8 @@ struct vb2_ops {
  * will return an error.
  * @copy_timestamp:copy the timestamp from a userspace structure to
  * the vb2_buffer struct.
+ * @buffer_queued: VB2 uses this to notify the VB2-client that the buffer
+ * was queued to the driver.
  */
 struct vb2_buf_ops {
int (*verify_planes_array)(struct vb2_buffer *vb, const void *pb);
@@ -422,6 +424,7 @@ struct vb2_buf_ops {
int (*fill_vb2_buffer)(struct vb2_buffer *vb, const void *pb,
struct vb2_plane *planes);
void (*copy_timestamp)(struct vb2_buffer *vb, const void *pb);
+   void (*buffer_queued)(struct vb2_buffer *vb);
 };
 
 /**
-- 
2.13.5

[PATCH v3 15/15] [media] vb2: add out-fence support to QBUF

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create
an out_fence and sent to userspace on the V4L2_EVENT_BUF_QUEUED when
the buffer is queued to the driver.

The out fence fd returned references the next buffer to be queued to the
driver and not the buffer in the actual QBUF call. So there a list in
videobuf2 core to keep track of the sync_file and fence created and assign
them to buffers when they are queued to the V4L2 driver.

The fence is signaled on buffer_done(), when the job on the buffer is
finished.

v4:
- return the out_fence_fd in the BUF_QUEUED event(Hans)

v3: - add WARN_ON_ONCE(q->ordered) on requeueing (Hans)
- set the OUT_FENCE flag if there is a fence pending (Hans)
- call fd_install() after vb2_core_qbuf() (Hans)
- clean up fence if vb2_core_qbuf() fails (Hans)
- add list to store sync_file and fence for the next queued buffer

v2: check if the queue is ordered.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 51 
 drivers/media/v4l2-core/videobuf2-v4l2.c | 24 ++-
 include/media/videobuf2-core.h   | 11 +++
 3 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 34adf1916194..ab58170776bc 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -353,6 +354,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
vb2_memory memory,
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
}
+   vb->out_fence_fd = -1;
q->bufs[vb->index] = vb;
 
/* Allocate video buffer memory for the MMAP type */
@@ -933,10 +935,24 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
case VB2_BUF_STATE_QUEUED:
return;
case VB2_BUF_STATE_REQUEUEING:
+   /*
+* Explicit synchronization requires ordered queues for now,
+* so WARN_ON if we are requeuing on an ordered queue.
+*/
+   if (vb->out_fence)
+   WARN_ON_ONCE(q->ordered);
+
if (q->start_streaming_called)
__enqueue_in_driver(vb);
return;
default:
+   if (state == VB2_BUF_STATE_ERROR)
+   dma_fence_set_error(vb->out_fence, -ENOENT);
+   dma_fence_signal(vb->out_fence);
+   dma_fence_put(vb->out_fence);
+   vb->out_fence = NULL;
+   vb->out_fence_fd = -1;
+
/* Inform any processes that may be waiting for buffers */
wake_up(>done_wq);
break;
@@ -1224,10 +1240,21 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
const void *pb)
 static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
+   struct vb2_fence *fence;
 
if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
return;
 
+   spin_lock(>out_fence_lock);
+   fence = list_first_entry(>out_fence_list, struct vb2_fence, entry);
+   if (fence) {
+   vb->out_fence = dma_fence_get(fence->out_fence);
+   vb->out_fence_fd = fence->out_fence_fd;
+   list_del(>entry);
+   kfree(fence);
+   }
+   spin_unlock(>out_fence_lock);
+
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(>owned_by_drv_count);
 
@@ -1348,6 +1375,8 @@ int vb2_setup_out_fence(struct vb2_queue *q)
list_add_tail(>entry, >out_fence_list);
spin_unlock(>out_fence_lock);
 
+   fence->files = current->files;
+
return 0;
 
 err_fence:
@@ -1450,6 +1479,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb,
  struct dma_fence *fence)
 {
struct vb2_buffer *vb;
+   struct vb2_fence *vb2_fence;
int ret;
 
vb = q->bufs[index];
@@ -1513,6 +1543,15 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb,
goto err;
}
 
+   spin_lock(>out_fence_lock);
+   vb2_fence = list_last_entry(>out_fence_list, struct vb2_fence,
+entry);
+   spin_unlock(>out_fence_lock);
+   if (vb2_fence)
+   fd_install(vb2_fence->out_fence_fd,
+  vb2_fence->sync_file->file);
+
+
/*
 * For explicit synchro

[PATCH v3 05/15] [media] uvc: enable subscriptions to other events

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Call v4l2_ctrl_subscribe_event to subscribe to the BUF_QUEUED event as
well.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 3e7e283a44a8..dfa0ccdcf849 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -1240,7 +1240,7 @@ static int uvc_ioctl_subscribe_event(struct v4l2_fh *fh,
case V4L2_EVENT_CTRL:
return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
default:
-   return -EINVAL;
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
 }
 
-- 
2.13.5

[PATCH v3 04/15] [media] vb2: add in-fence support to QBUF

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers are only queued
to the driver once they are ready. A buffer is ready when its
in-fence signals.

v4:
- Add a comment about dma_fence_add_callback() not returning a
error (Hans)
- Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
- select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
- Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
- Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
-  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
vb2_start_streaming() (Hans)
- set IN_FENCE flags on __fill_v4l2_buffer (Hans)
- Queue buffers to the driver as soon as they are ready (Hans)
- call fill_user_buffer() after queuing the buffer (Hans)
- add err: label to clean up fence
- add dma_fence_wait() before calling vb2_start_streaming()

v3: - document fence parameter
- remove ternary if at vb2_qbuf() return (Mauro)
- do not change if conditions behaviour (Mauro)

v2:
- fix vb2_queue_or_prepare_buf() ret check
- remove check for VB2_MEMORY_DMABUF only (Javier)
- check num of ready buffers to start streaming
- when queueing, start from the first ready buffer
- handle queue cancel

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/Kconfig  |   1 +
 drivers/media/v4l2-core/videobuf2-core.c | 103 +++
 drivers/media/v4l2-core/videobuf2-v4l2.c |  27 +++-
 include/media/videobuf2-core.h   |  11 +++-
 4 files changed, 127 insertions(+), 15 deletions(-)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index a35c33686abf..3f988c407c80 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -83,6 +83,7 @@ config VIDEOBUF_DVB
 # Used by drivers that need Videobuf2 modules
 config VIDEOBUF2_CORE
select DMA_SHARED_BUFFER
+   select SYNC_FILE
tristate
 
 config VIDEOBUF2_MEMOPS
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 60f8b582396a..b19c1bc4b083 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1222,6 +1222,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
 
+   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
+   return;
+
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(>owned_by_drv_count);
 
@@ -1273,6 +1276,20 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
return 0;
 }
 
+static int __get_num_ready_buffers(struct vb2_queue *q)
+{
+   struct vb2_buffer *vb;
+   int ready_count = 0;
+
+   /* count num of buffers ready in front of the queued_list */
+   list_for_each_entry(vb, >queued_list, queued_entry) {
+   if (!vb->in_fence || dma_fence_is_signaled(vb->in_fence))
+   ready_count++;
+   }
+
+   return ready_count;
+}
+
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
 {
struct vb2_buffer *vb;
@@ -1361,7 +1378,19 @@ static int vb2_start_streaming(struct vb2_queue *q)
return ret;
 }
 
-int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
+static void vb2_qbuf_fence_cb(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+   struct vb2_buffer *vb = container_of(cb, struct vb2_buffer, fence_cb);
+
+   dma_fence_put(vb->in_fence);
+   vb->in_fence = NULL;
+
+   if (vb->vb2_queue->start_streaming_called)
+   __enqueue_in_driver(vb);
+}
+
+int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
+ struct dma_fence *fence)
 {
struct vb2_buffer *vb;
int ret;
@@ -1372,16 +1401,18 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
case VB2_BUF_STATE_DEQUEUED:
ret = __buf_prepare(vb, pb);
if (ret)
-   return ret;
+   goto err;
break;
case VB2_BUF_STATE_PREPARED:
break;
case VB2_BUF_STATE_PREPARING:
dprintk(1, "buffer still being prepared\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err;
default:
dprintk(1, "invalid buffer state %d\n", vb->state);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err;
}
 
/*
@@ -1392,6 +1423,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
q->queued_c

[PATCH v3 02/15] [media] vb2: add explicit fence user API

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel and return an out-fence from the kernel to
userspace.

Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending a fence to the kernel to be waited on, and
V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.

v2: add documentation

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 Documentation/media/uapi/v4l/buffer.rst   | 19 +++
 drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
 include/uapi/linux/videodev2.h|  4 +++-
 5 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ae6ee73f151c..664507ad06c6 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -648,6 +648,25 @@ Buffer Flags
   - Start Of Exposure. The buffer timestamp has been taken when the
exposure of the frame has begun. This is only valid for the
``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
+* .. _`V4L2-BUF-FLAG-IN-FENCE`:
+
+  - ``V4L2_BUF_FLAG_IN_FENCE``
+  - 0x0020
+  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
+   won't be queued to the driver until the fence signals.
+
+* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
+
+  - ``V4L2_BUF_FLAG_OUT_FENCE``
+  - 0x0040
+  - Request a fence for the next buffer to be queued to V4L2 driver.
+   The fence received back through the ``fence_fd`` field  doesn't
+   necessarily relate to the current buffer in the
+   :ref:`VIDIOC_QBUF ` ioctl. Although, most of the time
+   the fence will relate to the current buffer it can't be guaranteed.
+   So to tell userspace which buffer is associated to the out_fence,
+   one should listen for the ``V4L2_EVENT_BUF_QUEUED`` event that
+   provide the id of the buffer when it is queued to the V4L2 driver.
 
 
 
diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
b/drivers/media/usb/cpia2/cpia2_v4l.c
index 3dedd83f0b19..6cde686bf44c 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct 
v4l2_buffer *buf)
buf->sequence = cam->buffers[buf->index].seq;
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
buf->length = cam->frame_size;
-   buf->reserved2 = 0;
+   buf->fence_fd = -1;
buf->reserved = 0;
memset(>timecode, 0, sizeof(buf->timecode));
 
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 821f2aa299ae..d624fb5df130 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -370,7 +370,7 @@ struct v4l2_buffer32 {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -533,8 +533,8 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, struct 
v4l2_buffer32 __user
put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
copy_to_user(>timecode, >timecode, sizeof(struct 
v4l2_timecode)) ||
put_user(kp->sequence, >sequence) ||
-   put_user(kp->reserved2, >reserved2) ||
put_user(kp->reserved, >reserved) ||
+   put_user(kp->fence_fd, >fence_fd) ||
put_user(kp->length, >length))
return -EFAULT;
 
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 0c0669976bdc..110fb45fef6f 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->reserved2 = 0;
+   b->fence_fd = -1;
b->reserved = 0;
 
if (q->is_multiplanar) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 185d6a0acc06..e5abab9a908c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -924,7 +924,7 @@ struct v4l2_buffer {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32

[PATCH v3 03/15] [media] vb2: check earlier if stream can be started

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

To support explicit synchronization we need to run all operations that can
fail before we queue the buffer to the driver. With fences the queueing
will be delayed if the fence is not signaled yet and it will be better if
such callback do not fail.

For that we move the vb2_start_streaming() before the queuing for the
buffer may happen.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index cb115ba6a1d2..60f8b582396a 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1399,29 +1399,27 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
trace_vb2_qbuf(q, vb);
 
/*
-* If already streaming, give the buffer to driver for processing.
-* If not, the buffer will be given to driver on next streamon.
-*/
-   if (q->start_streaming_called)
-   __enqueue_in_driver(vb);
-
-   /* Fill buffer information for the userspace */
-   if (pb)
-   call_void_bufop(q, fill_user_buffer, vb, pb);
-
-   /*
 * If streamon has been called, and we haven't yet called
 * start_streaming() since not enough buffers were queued, and
 * we now have reached the minimum number of queued buffers,
 * then we can finally call start_streaming().
+*
+* If already streaming, give the buffer to driver for processing.
+* If not, the buffer will be given to driver on next streamon.
 */
if (q->streaming && !q->start_streaming_called &&
q->queued_count >= q->min_buffers_needed) {
ret = vb2_start_streaming(q);
if (ret)
return ret;
+   } else if (q->start_streaming_called) {
+   __enqueue_in_driver(vb);
}
 
+   /* Fill buffer information for the userspace */
+   if (pb)
+   call_void_bufop(q, fill_user_buffer, vb, pb);
+
dprintk(2, "qbuf of buffer %d succeeded\n", vb->index);
return 0;
 }
-- 
2.13.5

[PATCH v3 07/15] [media] v4l: add V4L2_EVENT_BUF_QUEUED event

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Add a new event the userspace can subscribe to receive notifications
when a buffer is queued onto the driver. The event provides the index of
the queued buffer.

v2: - Add missing Documentation (Mauro)

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 Documentation/media/uapi/v4l/vidioc-dqevent.rst | 23 +++
 Documentation/media/videodev2.h.rst.exceptions  |  1 +
 include/uapi/linux/videodev2.h  | 11 +++
 3 files changed, 35 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
index fcd9c933870d..55f9dbdca6ec 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -78,6 +78,10 @@ call.
   - ``src_change``
   - Event data for event V4L2_EVENT_SOURCE_CHANGE.
 * -
+  - struct :c:type:`v4l2_event_buf_queued`
+  - ``buf_queued``
+  - Event data for event V4L2_EVENT_BUF_QUEUED.
+* -
   - __u8
   - ``data``\ [64]
   - Event data. Defined by the event type. The union should be used to
@@ -337,6 +341,25 @@ call.
each cell in the motion detection grid, then that all cells are
automatically assigned to the default region 0.
 
+.. c:type:: v4l2_event_buf_queued
+
+.. flat-table:: struct v4l2_event_buf_queued
+:header-rows:  0
+:stub-columns: 0
+:widths:   1 1 2
+
+* - __u32
+  - ``index``
+  - The index of the buffer that was queued to the driver.
+* - __s32
+  - ``out_fence_fd``
+  - The out-fence file descriptor of the buffer that was queued to
+   the driver. It will signal when the buffer is ready, or if an
+   error happens.
+
+
+
+.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
 
 .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8686ac..4e014b1d0317 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -462,6 +462,7 @@ replace define V4L2_EVENT_CTRL event-type
 replace define V4L2_EVENT_FRAME_SYNC event-type
 replace define V4L2_EVENT_SOURCE_CHANGE event-type
 replace define V4L2_EVENT_MOTION_DET event-type
+replace define V4L2_EVENT_BUF_QUEUED event-type
 replace define V4L2_EVENT_PRIVATE_START event-type
 
 replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index e5abab9a908c..e2ec0b66f490 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2158,6 +2158,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_FRAME_SYNC  4
 #define V4L2_EVENT_SOURCE_CHANGE   5
 #define V4L2_EVENT_MOTION_DET  6
+#define V4L2_EVENT_BUF_QUEUED  7
 #define V4L2_EVENT_PRIVATE_START   0x0800
 
 /* Payload for V4L2_EVENT_VSYNC */
@@ -2210,6 +2211,15 @@ struct v4l2_event_motion_det {
__u32 region_mask;
 };
 
+/**
+ * struct v4l2_event_buf_queued - buffer queued in the driver event
+ * @index: index of the buffer queued in the driver
+ */
+struct v4l2_event_buf_queued {
+   __u32 index;
+   __s32 out_fence_fd;
+};
+
 struct v4l2_event {
__u32   type;
union {
@@ -2218,6 +2228,7 @@ struct v4l2_event {
struct v4l2_event_frame_syncframe_sync;
struct v4l2_event_src_changesrc_change;
struct v4l2_event_motion_detmotion_det;
+   struct v4l2_event_buf_queuedbuf_queued;
__u8data[64];
} u;
__u32   pending;
-- 
2.13.5

[PATCH v3 11/15] [media] vivid: mark vivid queues as ordered

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

To enable vivid to be used with explicit synchronization we need
to mark its queues as ordered. vivid queues are already ordered by
default so we no changes are needed.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
Acked-by: Hans Verkuil <hans.verk...@cisco.com>
---
 drivers/media/platform/vivid/vivid-core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index 608bcceed463..239790e8ccc6 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1063,6 +1063,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE 
:
V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vid_cap_qops;
@@ -1083,6 +1084,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE :
V4L2_BUF_TYPE_VIDEO_OUTPUT;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vid_out_qops;
@@ -1103,6 +1105,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->has_raw_vbi_cap ? V4L2_BUF_TYPE_VBI_CAPTURE :
  V4L2_BUF_TYPE_SLICED_VBI_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vbi_cap_qops;
@@ -1123,6 +1126,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->type = dev->has_raw_vbi_out ? V4L2_BUF_TYPE_VBI_OUTPUT :
  V4L2_BUF_TYPE_SLICED_VBI_OUTPUT;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _vbi_out_qops;
@@ -1142,6 +1146,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q = >vb_sdr_cap_q;
q->type = V4L2_BUF_TYPE_SDR_CAPTURE;
q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
+   q->ordered = 1;
q->drv_priv = dev;
q->buf_struct_size = sizeof(struct vivid_buffer);
q->ops = _sdr_cap_qops;
-- 
2.13.5

[PATCH v3 10/15] [media] vb2: add 'ordered' property to queues

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

For explicit synchronization (and soon for HAL3/Request API) we need
the v4l2-driver to guarantee the ordering in which the buffers were queued
by userspace. This is already true for many drivers, but we never needed
to say it.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 include/media/videobuf2-core.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 5ed8d3402474..20099dc22f26 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -508,6 +508,9 @@ struct vb2_buf_ops {
  * @last_buffer_dequeued: used in poll() and DQBUF to immediately return if the
  * last decoded buffer was already dequeued. Set for capture queues
  * when a buffer with the V4L2_BUF_FLAG_LAST is dequeued.
+ * @ordered: if the driver can guarantee that the queue will be ordered or not.
+ * The default is not ordered unless the driver sets this flag. It
+ * is mandatory for using explicit fences.
  * @fileio:file io emulator internal data, used only if emulator is active
  * @threadio:  thread io internal data, used only if thread is active
  */
@@ -560,6 +563,7 @@ struct vb2_queue {
unsigned intis_output:1;
unsigned intcopy_timestamp:1;
unsigned intlast_buffer_dequeued:1;
+   unsigned intordered:1;
 
struct vb2_fileio_data  *fileio;
struct vb2_threadio_data*threadio;
-- 
2.13.5

[PATCH v3 09/15] [media] v4l: add support to BUF_QUEUED event

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Implement the needed pieces to let userspace subscribe for
V4L2_EVENT_BUF_QUEUED events. Videobuf2 will queue the event for the
DQEVENT ioctl.

v3: - Do not call v4l2 event API from vb2 (Mauro)

v2: - Use VIDEO_MAX_FRAME to allocate room for events at
v4l2_event_subscribe() (Hans)

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/v4l2-ctrls.c |  6 +-
 drivers/media/v4l2-core/videobuf2-core.c |  2 ++
 drivers/media/v4l2-core/videobuf2-v4l2.c | 14 ++
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index dd1db678718c..17d4b9e3eec6 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3438,8 +3438,12 @@ EXPORT_SYMBOL(v4l2_ctrl_log_status);
 int v4l2_ctrl_subscribe_event(struct v4l2_fh *fh,
const struct v4l2_event_subscription *sub)
 {
-   if (sub->type == V4L2_EVENT_CTRL)
+   switch (sub->type) {
+   case V4L2_EVENT_CTRL:
return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
+   case V4L2_EVENT_BUF_QUEUED:
+   return v4l2_event_subscribe(fh, sub, VIDEO_MAX_FRAME, NULL);
+   }
return -EINVAL;
 }
 EXPORT_SYMBOL(v4l2_ctrl_subscribe_event);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index b19c1bc4b083..bbbae0eed567 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1231,6 +1231,8 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
trace_vb2_buf_queue(q, vb);
 
call_void_vb_qop(vb, buf_queue, vb);
+
+   call_void_bufop(q, buffer_queued, vb);
 }
 
 static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 8c322cd1b346..bbfcd054e6f6 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -138,6 +138,19 @@ static void __copy_timestamp(struct vb2_buffer *vb, const 
void *pb)
}
 };
 
+static void __buffer_queued(struct vb2_buffer *vb)
+{
+   struct video_device *vdev = to_video_device(vb->vb2_queue->dev);
+   struct v4l2_fh *fh = vdev->queue->owner;
+   struct v4l2_event event;
+
+   memset(, 0, sizeof(event));
+   event.type = V4L2_EVENT_BUF_QUEUED;
+   event.u.buf_queued.index = vb->index;
+
+   v4l2_event_queue_fh(fh, );
+}
+
 static void vb2_warn_zero_bytesused(struct vb2_buffer *vb)
 {
static bool check_once;
@@ -455,6 +468,7 @@ static const struct vb2_buf_ops v4l2_buf_ops = {
.fill_user_buffer   = __fill_v4l2_buffer,
.fill_vb2_buffer= __fill_vb2_buffer,
.copy_timestamp = __copy_timestamp,
+   .buffer_queued  = __buffer_queued,
 };
 
 /**
-- 
2.13.5

[PATCH v3 06/15] [media] vivid: assign the specific device to the vb2_queue->dev

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Instead of assigning the global v4l2 device, assign the specific device.
This was causing trouble when using using V4L2 events with vivid
devices. The device's queue should be the same we opened in userspace.

This is needed for the upcoming V4L2_EVENT_BUF_QUEUED support. The current
vivid code isn't wrong, it just needs to be changed so V4L2_EVENT_BUF_QUEUED
can be supported. The change doesn't affect any other behaviour of vivid.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
Acked-by: Hans Verkuil <hans.verk...@cisco.com>
---
 drivers/media/platform/vivid/vivid-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-core.c 
b/drivers/media/platform/vivid/vivid-core.c
index 5f316a5e38db..608bcceed463 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1070,7 +1070,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vid_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1090,7 +1090,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vid_out_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1110,7 +1110,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vbi_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1130,7 +1130,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 2;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >vbi_out_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
@@ -1149,7 +1149,7 @@ static int vivid_create_instance(struct platform_device 
*pdev, int inst)
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q->min_buffers_needed = 8;
q->lock = >mutex;
-   q->dev = dev->v4l2_dev.dev;
+   q->dev = >sdr_cap_dev.dev;
 
ret = vb2_queue_init(q);
if (ret)
-- 
2.13.5

[PATCH v3 14/15] fs/files: export close_fd() symbol

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Rename __close_fd() to close_fd() and export it to be able close files
in modules using file descriptors.

The usecase that motivates this change happens in V4L2 where we send
events to userspace with a fd that has file installed in it. But if for
some reason we have to cancel the video stream we need to close the files
that haven't been shared with userspace yet. Thus the export of
close_fd() becomes necessary.

fd_install() happens when we call an ioctl to queue a buffer, but we only
share the fd with userspace later, and that may happen in a kernel thread
instead.

Cc: Alexander Viro <v...@zeniv.linux.org.uk>
Cc: linux-fsde...@vger.kernel.org
Cc: Riley Andrews <riandr...@android.com>
Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
This is more like a question, I don't know how unhappy people will be with
this proposal to expose close_fd(). I'm all ears for more interesting
ways of doing it!
---
 drivers/android/binder.c | 2 +-
 fs/file.c| 5 +++--
 fs/open.c| 2 +-
 include/linux/fdtable.h  | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index f7665c31feca..5a9bc73012df 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -440,7 +440,7 @@ static long task_close_fd(struct binder_proc *proc, 
unsigned int fd)
if (proc->files == NULL)
return -ESRCH;
 
-   retval = __close_fd(proc->files, fd);
+   retval = close_fd(proc->files, fd);
/* can't restart close syscall because file table entry was cleared */
if (unlikely(retval == -ERESTARTSYS ||
 retval == -ERESTARTNOINTR ||
diff --git a/fs/file.c b/fs/file.c
index 1fc7fbbb4510..111d387ac190 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -618,7 +618,7 @@ EXPORT_SYMBOL(fd_install);
 /*
  * The same warnings as for __alloc_fd()/__fd_install() apply here...
  */
-int __close_fd(struct files_struct *files, unsigned fd)
+int close_fd(struct files_struct *files, unsigned fd)
 {
struct file *file;
struct fdtable *fdt;
@@ -640,6 +640,7 @@ int __close_fd(struct files_struct *files, unsigned fd)
spin_unlock(>file_lock);
return -EBADF;
 }
+EXPORT_SYMBOL(close_fd);
 
 void do_close_on_exec(struct files_struct *files)
 {
@@ -856,7 +857,7 @@ int replace_fd(unsigned fd, struct file *file, unsigned 
flags)
struct files_struct *files = current->files;
 
if (!file)
-   return __close_fd(files, fd);
+   return close_fd(files, fd);
 
if (fd >= rlimit(RLIMIT_NOFILE))
return -EBADF;
diff --git a/fs/open.c b/fs/open.c
index 35bb784763a4..30907d967443 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1152,7 +1152,7 @@ EXPORT_SYMBOL(filp_close);
  */
 SYSCALL_DEFINE1(close, unsigned int, fd)
 {
-   int retval = __close_fd(current->files, fd);
+   int retval = close_fd(current->files, fd);
 
/* can't restart close syscall because file table entry was cleared */
if (unlikely(retval == -ERESTARTSYS ||
diff --git a/include/linux/fdtable.h b/include/linux/fdtable.h
index 6e84b2cae6ad..511fd38d5e4b 100644
--- a/include/linux/fdtable.h
+++ b/include/linux/fdtable.h
@@ -115,7 +115,7 @@ extern int __alloc_fd(struct files_struct *files,
  unsigned start, unsigned end, unsigned flags);
 extern void __fd_install(struct files_struct *files,
  unsigned int fd, struct file *file);
-extern int __close_fd(struct files_struct *files,
+extern int close_fd(struct files_struct *files,
  unsigned int fd);
 
 extern struct kmem_cache *files_cachep;
-- 
2.13.5

[PATCH v3 13/15] [media] vb2: add infrastructure to support out-fences

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Add vb2_setup_out_fence() and the needed members to struct vb2_buffer.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 55 
 include/media/videobuf2-core.h   | 34 
 2 files changed, 89 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index bbbae0eed567..34adf1916194 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -23,8 +23,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -1317,6 +1320,58 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned 
int index, void *pb)
 }
 EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
 
+int vb2_setup_out_fence(struct vb2_queue *q)
+{
+   struct vb2_fence *fence;
+
+   fence = kzalloc(sizeof(*fence), GFP_KERNEL);
+   if (!fence)
+   return -ENOMEM;
+
+   fence->out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+   if (fence->out_fence_fd < 0) {
+   kfree(fence);
+   return fence->out_fence_fd;
+   }
+
+   fence->out_fence = vb2_fence_alloc();
+   if (!fence->out_fence)
+   goto err_fence;
+
+   fence->sync_file = sync_file_create(fence->out_fence);
+   if (!fence->sync_file) {
+   dma_fence_put(fence->out_fence);
+   goto err_fence;
+   }
+
+   spin_lock(>out_fence_lock);
+   list_add_tail(>entry, >out_fence_list);
+   spin_unlock(>out_fence_lock);
+
+   return 0;
+
+err_fence:
+   kfree(fence);
+   put_unused_fd(fence->out_fence_fd);
+   return -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(vb2_setup_out_fence);
+
+void vb2_cleanup_out_fence(struct vb2_queue *q)
+{
+   struct vb2_fence *fence;
+
+   spin_lock(>out_fence_lock);
+   fence = list_last_entry(>out_fence_list,
+   struct vb2_fence, entry);
+   put_unused_fd(fence->out_fence_fd);
+   fput(fence->sync_file->file);
+   list_del(>entry);
+   spin_unlock(>out_fence_lock);
+   kfree(fence);
+}
+EXPORT_SYMBOL_GPL(vb2_cleanup_out_fence);
+
 /**
  * vb2_start_streaming() - Attempt to start streaming.
  * @q: videobuf2 queue
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 20099dc22f26..84e5e7216a1e 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -427,6 +427,24 @@ struct vb2_buf_ops {
void (*buffer_queued)(struct vb2_buffer *vb);
 };
 
+/*
+ * struct vb2_fence - storage for fence data before queueing to the driver.
+ *
+ * @out_fence_fd:  the fd where to install the sync_file
+ * @out_fence: the fence associated to the sync_file
+ * @sync_file: the sync_file to be shared with userspace via the
+ * out_fence_fd
+ * @files: stores files struct for cleanup purposes
+ * @entry: the list head element for the out_fence_list
+ */
+struct vb2_fence {
+   int out_fence_fd;
+   struct dma_fence *out_fence;
+   struct sync_file *sync_file;
+   struct files_struct *files;
+   struct list_head entry;
+};
+
 /**
  * struct vb2_queue - a videobuf queue
  *
@@ -734,6 +752,22 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
vb2_memory memory,
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb);
 
 /**
+ * vb2_setup_out_fence() - setup new out-fence
+ * @q: The vb2_queue where to setup it
+ *
+ * Setup the file descriptor, the fence and the sync_file for the next
+ * buffer to be queued and add everything to the tail of the q->out_fence_list.
+ */
+int vb2_setup_out_fence(struct vb2_queue *q);
+
+/**
+ * vb2_cleanup_out_fence() - cleanup out-fence
+ * @q: The vb2_queue to use for cleanup
+ *
+ * Clean up the last fence on the list. Used only when QBUF fails.
+ */
+void vb2_cleanup_out_fence(struct vb2_queue *q);
+/**
  * vb2_core_qbuf() - Queue a buffer from userspace
  *
  * @q: videobuf2 queue
-- 
2.13.5

[PATCH v3 12/15] [media] vb2: add videobuf2 dma-buf fence helpers

2017-09-07 Thread Gustavo Padovan

From: Javier Martinez Canillas <jav...@osg.samsung.com>

Add a videobuf2-fence.h header file that contains different helpers
for DMA buffer sharing explicit fence support in videobuf2.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 include/media/videobuf2-fence.h | 49 +
 1 file changed, 49 insertions(+)
 create mode 100644 include/media/videobuf2-fence.h

diff --git a/include/media/videobuf2-fence.h b/include/media/videobuf2-fence.h
new file mode 100644
index ..ed5612ca03d6
--- /dev/null
+++ b/include/media/videobuf2-fence.h
@@ -0,0 +1,49 @@
+/*
+ * videobuf2-fence.h - DMA buffer sharing fence helpers for videobuf 2
+ *
+ * Copyright (C) 2016 Samsung Electronics
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+static DEFINE_SPINLOCK(vb2_fence_lock);
+
+static inline const char *vb2_fence_get_driver_name(struct dma_fence *fence)
+{
+   return "vb2_fence";
+}
+
+static inline const char *vb2_fence_get_timeline_name(struct dma_fence *fence)
+{
+   return "vb2_fence_timeline";
+}
+
+static inline bool vb2_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+static const struct dma_fence_ops vb2_fence_ops = {
+   .get_driver_name = vb2_fence_get_driver_name,
+   .get_timeline_name = vb2_fence_get_timeline_name,
+   .enable_signaling = vb2_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
+static inline struct dma_fence *vb2_fence_alloc(void)
+{
+   struct dma_fence *vb2_fence = kzalloc(sizeof(*vb2_fence), GFP_KERNEL);
+
+   if (!vb2_fence)
+   return NULL;
+
+   dma_fence_init(vb2_fence, _fence_ops, _fence_lock,
+  dma_fence_context_alloc(1), 1);
+
+   return vb2_fence;
+}
-- 
2.13.5

[PATCH v3 00/15] V4L2 Explicit Synchronization support

2017-09-07 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Hi,

Refer to the documentation on the first patch for the details. The previous
iteration is here: 
https://www.mail-archive.com/linux-media@vger.kernel.org/msg118077.html

The 2nd patch proposes an userspace API for fences, then on patch 3 we
prepare to the addition of in-fences in patch 4, by introducing the
infrastructure on vb2 to wait on an in-fence signal before queueing the
buffer in the driver.

Patch 5 fix uvc v4l2 event handling and patch 6 configure q->dev for
vivid drivers to enable to subscribe and dequeue events on it.

Patches 7-9 enables support to notify BUF_QUEUED events, the event send
to userspace the out-fence fd and the index of the buffer that was queued.

Patches 10-11 add support to mark queues as ordered. Finally patches 12
and 13 add more fence infrastructure to support out-fences, patch 13 exposes
close_fd() and patch 14 adds support to out-fences. 

It only works for ordered queues for now, see open question at the end
of the letter.

Test tool can be found at:
https://git.collabora.com/cgit/user/padovan/v4l2-test.git/

Main Changes


* out-fences: change in behavior: the out-fence fd now comes out of the
BUF_QUEUED event along with the buffer id.

All other changes are recorded on the patches' commit messages.

Open Questions
--

* non-ordered devices, like m2m: I've been thinking a lot about those
  and one possibility is to have a way to tell userspace that the queue
  is not ordered and then associate the fence with the current buffer in
  QBUF instead of the next one to be queued. Of course, there won't be
  any ordering between the fences. But it may be enough for userspace to
  take advantage of Explicit Synchronization in such cases. Any
  thoughts?

* OUTPUT devices and in-fence. If I understood OUTPUT devices correctly
  it is desirable to queue the buffers to the driver in the same order
  we received them from userspace. If that is correct, shouldn't we add
  some mechanism to prevent buffer whose fence signaled to jump ahead of
  others?

Gustavo Padovan (14):
  [media] v4l: Document explicit synchronization behaviour
  [media] vb2: add explicit fence user API
  [media] vb2: check earlier if stream can be started
  [media] vb2: add in-fence support to QBUF
  [media] uvc: enable subscriptions to other events
  [media] vivid: assign the specific device to the vb2_queue->dev
  [media] v4l: add V4L2_EVENT_BUF_QUEUED event
  [media] vb2: add .buffer_queued() to notify queueing in the driver
  [media] v4l: add support to BUF_QUEUED event
  [media] vb2: add 'ordered' property to queues
  [media] vivid: mark vivid queues as ordered
  [media] vb2: add infrastructure to support out-fences
  fs/files: export close_fd() symbol
  [media] vb2: add out-fence support to QBUF

Javier Martinez Canillas (1):
  [media] vb2: add videobuf2 dma-buf fence helpers

 Documentation/media/uapi/v4l/buffer.rst |  19 ++
 Documentation/media/uapi/v4l/vidioc-dqevent.rst |  23 +++
 Documentation/media/uapi/v4l/vidioc-qbuf.rst|  31 
 Documentation/media/videodev2.h.rst.exceptions  |   1 +
 drivers/android/binder.c|   2 +-
 drivers/media/platform/vivid/vivid-core.c   |  15 +-
 drivers/media/usb/cpia2/cpia2_v4l.c |   2 +-
 drivers/media/usb/uvc/uvc_v4l2.c|   2 +-
 drivers/media/v4l2-core/Kconfig |   1 +
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c   |   4 +-
 drivers/media/v4l2-core/v4l2-ctrls.c|   6 +-
 drivers/media/v4l2-core/videobuf2-core.c| 221 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c|  63 ++-
 fs/file.c   |   5 +-
 fs/open.c   |   2 +-
 include/linux/fdtable.h |   2 +-
 include/media/videobuf2-core.h  |  63 ++-
 include/media/videobuf2-fence.h |  49 ++
 include/uapi/linux/videodev2.h  |  15 +-
 19 files changed, 489 insertions(+), 37 deletions(-)
 create mode 100644 include/media/videobuf2-fence.h

-- 
2.13.5

Re: [PATCH v3 14/15] fs/files: export close_fd() symbol

2017-09-07 Thread Gustavo Padovan

2017-09-07 Al Viro <v...@zeniv.linux.org.uk>:

> On Thu, Sep 07, 2017 at 03:42:25PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Rename __close_fd() to close_fd() and export it to be able close files
> > in modules using file descriptors.
> > 
> > The usecase that motivates this change happens in V4L2 where we send
> > events to userspace with a fd that has file installed in it. But if for
> > some reason we have to cancel the video stream we need to close the files
> > that haven't been shared with userspace yet. Thus the export of
> > close_fd() becomes necessary.
> > 
> > fd_install() happens when we call an ioctl to queue a buffer, but we only
> > share the fd with userspace later, and that may happen in a kernel thread
> > instead.
> 
> NAK.  As soon as the reference is in descriptor table, you *can't* do anything
> to it.  This "sharing" part is complete BS - being _told_ that descriptor is
> there does not matter at all.  That descriptor might be hit with dup2() as
> soon as fd_install() has happened.  Or be closed, or any number of other 
> things.
> 
> You can not take it back.  Once fd_install() is done, it's fucking done, 
> period.
> If V4L2 requires removing it from descriptor table, it's a shitty API and 
> needs
> to be fixed.

Sorry for my lack of knowledge here and thank you for the explanation,
things are a lot clear to me. For some reasons I were trying to delay
the sharing of the fd to a event later. I can delay the install of it
but that my require __fd_install() to be available and exportedi as it
may happen in a thread, but I believe you wouldn't be okay with that either,
is that so?

Gustavo

Re: [PATCH v3 14/15] fs/files: export close_fd() symbol

2017-09-07 Thread Gustavo Padovan

On Fri, 2017-09-08 at 00:09 +0200, Hans Verkuil wrote:
> On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Rename __close_fd() to close_fd() and export it to be able close
> > files
> > in modules using file descriptors.
> > 
> > The usecase that motivates this change happens in V4L2 where we
> > send
> > events to userspace with a fd that has file installed in it. But if
> > for
> > some reason we have to cancel the video stream we need to close the
> > files
> > that haven't been shared with userspace yet. Thus the export of
> > close_fd() becomes necessary.
> > 
> > fd_install() happens when we call an ioctl to queue a buffer, but
> > we only
> > share the fd with userspace later, and that may happen in a kernel
> > thread
> > instead.
> 
> This isn't the way to do this.
> 
> You should only create the out fence file descriptor when userspace
> dequeues
> (i.e. calls VIDIOC_DQEVENT) the BUF_QUEUED event. That's when you
> give it to
> userspace and at that moment closing the fd is the responsibility of
> userspace.
> There is no point creating it earlier anyway since userspace can't
> get to it
> until it dequeues the event.
> 
> It does mean some more work in the V4L2 core since you need to hook
> into the
> DQEVENT code in order to do this.

Right, that makes a lot more sense. I'll change the implementation so
it can reflecting that. Thanks.

Gustavo

Re: [PATCH v2 14/14] [media] v4l: Document explicit synchronization behaviour

2017-09-04 Thread Gustavo Padovan

2017-09-02 Hans Verkuil <hverk...@xs4all.nl>:

> On 09/01/2017 08:21 PM, Gustavo Padovan wrote:
> > Hi Hans,
> > 
> > 2017-09-01 Hans Verkuil <hverk...@xs4all.nl>:
> > 
> >> Hi Gustavo,
> >>
> >> I think I concentrate on this last patch first. Once I fully understand 
> >> this
> >> I can review the code. Remember, it's been a while for me since I last 
> >> looked
> >> at fences, so forgive me if I ask stupid questions. On the other hand, 
> >> others
> >> with a similar lack of understanding of fences probably have similar 
> >> questions,
> >> so it is a good indication where the documentation needs improvement :-)
> > 
> > Please ask as many as you want, those are the best questions. :)
> > 
> >>
> >> On 01/09/17 03:50, Gustavo Padovan wrote:
> >>> From: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>>
> >>> Add section to VIDIOC_QBUF about it
> >>>
> >>> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> >>> ---q
> >>>  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 30 
> >>> 
> >>>  1 file changed, 30 insertions(+)
> >>>
> >>> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
> >>> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >>> index 1f3612637200..6bd960d3972b 100644
> >>> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >>> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >>> @@ -117,6 +117,36 @@ immediately with an ``EAGAIN`` error code when no 
> >>> buffer is available.
> >>>  The struct :c:type:`v4l2_buffer` structure is specified in
> >>>  :ref:`buffer`.
> >>>  
> >>> +Explicit Synchronization
> >>> +
> >>> +
> >>> +Explicit Synchronization allows us to control the synchronization of
> >>> +shared buffers from userspace by passing fences to the kernel and/or
> >>> +receiving them from it. Fences passed to the kernel are named in-fences 
> >>> and
> >>> +the kernel should wait them to signal before using the buffer, i.e., 
> >>> queueing
> >>> +it to the driver. On the other side, the kernel can create out-fences 
> >>> for the
> >>> +buffers it queues to the drivers, out-fences signal when the driver is
> >>> +finished with buffer, that is the buffer is ready.
> >>
> >> This should add a line explaining that fences are represented by file 
> >> descriptors.
> > 
> > Okay.
> > 
> >>
> >>> +
> >>> +The in-fences and out-fences are communicated at the ``VIDIOC_QBUF`` 
> >>> ioctl
> >>> +using the ``V4L2_BUF_FLAG_IN_FENCE`` and ``V4L2_BUF_FLAG_OUT_FENCE`` 
> >>> buffer
> >>> +flags and the `fence_fd` field. If an in-fence needs to be passed to the 
> >>> kernel,
> >>> +`fence_fd` should be set to the fence file descriptor number and the
> >>> +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well.
> >>
> >> Is it possible to have both flags at the same time? Or are they mutually 
> >> exclusive?
> >>
> >> If only V4L2_BUF_FLAG_IN_FENCE is set, then what is the value of fence_fd 
> >> after
> >> the QBUF call? -1?
> > 
> > Yes, it is -1.
> > 
> >>
> >>> +
> >>> +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
> >>> should
> >>> +be set and the `fence_fd` field will be returned with the out-fence file
> >>> +descriptor related to the next buffer to be queued internally to the V4L2
> >>> +driver. That means the out-fence may not be associated with the buffer 
> >>> in the
> >>> +current ``VIDIOC_QBUF`` ioctl call because the ordering in which 
> >>> videobuf2 core
> >>> +queues the buffers to the drivers can't be guaranteed. To become aware 
> >>> of the
> >>> +buffer with which the out-fence will be attached the 
> >>> ``V4L2_EVENT_BUF_QUEUED``
> >>> +should be used. It will trigger an event for every buffer queued to the 
> >>> V4L2
> >>> +driver.
> >>
> >> General question: does it even make sense to use an out-fence if you don't 
> >> know with
> >> what buffer is it associated? I mean, QBUF returns an out fence, but only 
> >> some
&

Re: [PATCH v2 14/14] [media] v4l: Document explicit synchronization behaviour

2017-09-01 Thread Gustavo Padovan

Hi Hans,

2017-09-01 Hans Verkuil <hverk...@xs4all.nl>:

> Hi Gustavo,
> 
> I think I concentrate on this last patch first. Once I fully understand this
> I can review the code. Remember, it's been a while for me since I last looked
> at fences, so forgive me if I ask stupid questions. On the other hand, others
> with a similar lack of understanding of fences probably have similar 
> questions,
> so it is a good indication where the documentation needs improvement :-)

Please ask as many as you want, those are the best questions. :)

> 
> On 01/09/17 03:50, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.pado...@collabora.com>
> > 
> > Add section to VIDIOC_QBUF about it
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
> > ---q
> >  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 30 
> > 
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
> > b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> > index 1f3612637200..6bd960d3972b 100644
> > --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> > +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> > @@ -117,6 +117,36 @@ immediately with an ``EAGAIN`` error code when no 
> > buffer is available.
> >  The struct :c:type:`v4l2_buffer` structure is specified in
> >  :ref:`buffer`.
> >  
> > +Explicit Synchronization
> > +
> > +
> > +Explicit Synchronization allows us to control the synchronization of
> > +shared buffers from userspace by passing fences to the kernel and/or
> > +receiving them from it. Fences passed to the kernel are named in-fences and
> > +the kernel should wait them to signal before using the buffer, i.e., 
> > queueing
> > +it to the driver. On the other side, the kernel can create out-fences for 
> > the
> > +buffers it queues to the drivers, out-fences signal when the driver is
> > +finished with buffer, that is the buffer is ready.
> 
> This should add a line explaining that fences are represented by file 
> descriptors.

Okay.

> 
> > +
> > +The in-fences and out-fences are communicated at the ``VIDIOC_QBUF`` ioctl
> > +using the ``V4L2_BUF_FLAG_IN_FENCE`` and ``V4L2_BUF_FLAG_OUT_FENCE`` buffer
> > +flags and the `fence_fd` field. If an in-fence needs to be passed to the 
> > kernel,
> > +`fence_fd` should be set to the fence file descriptor number and the
> > +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well.
> 
> Is it possible to have both flags at the same time? Or are they mutually 
> exclusive?
> 
> If only V4L2_BUF_FLAG_IN_FENCE is set, then what is the value of fence_fd 
> after
> the QBUF call? -1?

Yes, it is -1.

> 
> > +
> > +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
> > should
> > +be set and the `fence_fd` field will be returned with the out-fence file
> > +descriptor related to the next buffer to be queued internally to the V4L2
> > +driver. That means the out-fence may not be associated with the buffer in 
> > the
> > +current ``VIDIOC_QBUF`` ioctl call because the ordering in which videobuf2 
> > core
> > +queues the buffers to the drivers can't be guaranteed. To become aware of 
> > the
> > +buffer with which the out-fence will be attached the 
> > ``V4L2_EVENT_BUF_QUEUED``
> > +should be used. It will trigger an event for every buffer queued to the 
> > V4L2
> > +driver.
> 
> General question: does it even make sense to use an out-fence if you don't 
> know with
> what buffer is it associated? I mean, QBUF returns an out fence, but only some
> time later are you informed about a buffer being queued. It also looks like 
> userspace
> has to keep track of the issued out-fences and the queued buffers and map them
> accordingly.
> 
> If the out-fence cannot be used until you know the buffer as well, then 
> wouldn't
> it make more sense if the out-fence and the buffer index are both sent by the
> event? Of course, in that case the event can only be sent to the owner file 
> handle
> of the streaming device node, but that's OK, we have that.
> 
> Setting the OUT_FENCE flag will just cause this event to be sent whenever that
> buffer is queued internally.
> 
> Sorry if this just shows a complete lack of understanding of fences on my 
> side,
> that's perfectly possible.

Right, I can not think of anything that prevents what you are saying to
work. I built it this way initially because on my lack of understanding
of V4L2 (seems we complement each other here :) because I thought we
needed

[PATCH v2 01/14] [media] vb2: add explicit fence user API

2017-08-31 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Turn the reserved2 field into fence_fd that we will use to send
an in-fence to the kernel and return an out-fence from the kernel to
userspace.

Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
when sending a fence to the kernel to be waited on, and
V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.

v2: add documentation

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 Documentation/media/uapi/v4l/buffer.rst   | 19 +++
 drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
 include/uapi/linux/videodev2.h|  4 +++-
 5 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst 
b/Documentation/media/uapi/v4l/buffer.rst
index ae6ee73f151c..664507ad06c6 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -648,6 +648,25 @@ Buffer Flags
   - Start Of Exposure. The buffer timestamp has been taken when the
exposure of the frame has begun. This is only valid for the
``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
+* .. _`V4L2-BUF-FLAG-IN-FENCE`:
+
+  - ``V4L2_BUF_FLAG_IN_FENCE``
+  - 0x0020
+  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
+   won't be queued to the driver until the fence signals.
+
+* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
+
+  - ``V4L2_BUF_FLAG_OUT_FENCE``
+  - 0x0040
+  - Request a fence for the next buffer to be queued to V4L2 driver.
+   The fence received back through the ``fence_fd`` field  doesn't
+   necessarily relate to the current buffer in the
+   :ref:`VIDIOC_QBUF ` ioctl. Although, most of the time
+   the fence will relate to the current buffer it can't be guaranteed.
+   So to tell userspace which buffer is associated to the out_fence,
+   one should listen for the ``V4L2_EVENT_BUF_QUEUED`` event that
+   provide the id of the buffer when it is queued to the V4L2 driver.
 
 
 
diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
b/drivers/media/usb/cpia2/cpia2_v4l.c
index 3dedd83f0b19..6cde686bf44c 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct 
v4l2_buffer *buf)
buf->sequence = cam->buffers[buf->index].seq;
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
buf->length = cam->frame_size;
-   buf->reserved2 = 0;
+   buf->fence_fd = -1;
buf->reserved = 0;
memset(>timecode, 0, sizeof(buf->timecode));
 
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 821f2aa299ae..d624fb5df130 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -370,7 +370,7 @@ struct v4l2_buffer32 {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32   reserved;
 };
 
@@ -533,8 +533,8 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, struct 
v4l2_buffer32 __user
put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
copy_to_user(>timecode, >timecode, sizeof(struct 
v4l2_timecode)) ||
put_user(kp->sequence, >sequence) ||
-   put_user(kp->reserved2, >reserved2) ||
put_user(kp->reserved, >reserved) ||
+   put_user(kp->fence_fd, >fence_fd) ||
put_user(kp->length, >length))
return -EFAULT;
 
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 0c0669976bdc..110fb45fef6f 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
b->timestamp = ns_to_timeval(vb->timestamp);
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
-   b->reserved2 = 0;
+   b->fence_fd = -1;
b->reserved = 0;
 
if (q->is_multiplanar) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 185d6a0acc06..e5abab9a908c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -924,7 +924,7 @@ struct v4l2_buffer {
__s32   fd;
} m;
__u32   length;
-   __u32   reserved2;
+   __s32   fence_fd;
__u32

[PATCH v2 03/14] [media] vb2: add in-fence support to QBUF

2017-08-31 Thread Gustavo Padovan

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Receive in-fence from userspace and add support for waiting on them
before queueing the buffer to the driver. Buffers are only queued
to the driver once they are ready. A buffer is ready when its
in-fence signals.

v4:
- Add a comment about dma_fence_add_callback() not returning a
error (Hans)
- Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
- select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
- Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
- Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
-  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
vb2_start_streaming() (Hans)
- set IN_FENCE flags on __fill_v4l2_buffer (Hans)
- Queue buffers to the driver as soon as they are ready (Hans)
- call fill_user_buffer() after queuing the buffer (Hans)
- add err: label to clean up fence
- add dma_fence_wait() before calling vb2_start_streaming()

v3: - document fence parameter
- remove ternary if at vb2_qbuf() return (Mauro)
- do not change if conditions behaviour (Mauro)

v2:
- fix vb2_queue_or_prepare_buf() ret check
- remove check for VB2_MEMORY_DMABUF only (Javier)
- check num of ready buffers to start streaming
- when queueing, start from the first ready buffer
- handle queue cancel

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/media/v4l2-core/Kconfig  |   1 +
 drivers/media/v4l2-core/videobuf2-core.c | 103 +++
 drivers/media/v4l2-core/videobuf2-v4l2.c |  27 +++-
 include/media/videobuf2-core.h   |   8 ++-
 4 files changed, 124 insertions(+), 15 deletions(-)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index a35c33686abf..3f988c407c80 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -83,6 +83,7 @@ config VIDEOBUF_DVB
 # Used by drivers that need Videobuf2 modules
 config VIDEOBUF2_CORE
select DMA_SHARED_BUFFER
+   select SYNC_FILE
tristate
 
 config VIDEOBUF2_MEMOPS
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 60f8b582396a..b19c1bc4b083 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1222,6 +1222,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb->vb2_queue;
 
+   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
+   return;
+
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(>owned_by_drv_count);
 
@@ -1273,6 +1276,20 @@ static int __buf_prepare(struct vb2_buffer *vb, const 
void *pb)
return 0;
 }
 
+static int __get_num_ready_buffers(struct vb2_queue *q)
+{
+   struct vb2_buffer *vb;
+   int ready_count = 0;
+
+   /* count num of buffers ready in front of the queued_list */
+   list_for_each_entry(vb, >queued_list, queued_entry) {
+   if (!vb->in_fence || dma_fence_is_signaled(vb->in_fence))
+   ready_count++;
+   }
+
+   return ready_count;
+}
+
 int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
 {
struct vb2_buffer *vb;
@@ -1361,7 +1378,19 @@ static int vb2_start_streaming(struct vb2_queue *q)
return ret;
 }
 
-int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
+static void vb2_qbuf_fence_cb(struct dma_fence *f, struct dma_fence_cb *cb)
+{
+   struct vb2_buffer *vb = container_of(cb, struct vb2_buffer, fence_cb);
+
+   dma_fence_put(vb->in_fence);
+   vb->in_fence = NULL;
+
+   if (vb->vb2_queue->start_streaming_called)
+   __enqueue_in_driver(vb);
+}
+
+int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
+ struct dma_fence *fence)
 {
struct vb2_buffer *vb;
int ret;
@@ -1372,16 +1401,18 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
case VB2_BUF_STATE_DEQUEUED:
ret = __buf_prepare(vb, pb);
if (ret)
-   return ret;
+   goto err;
break;
case VB2_BUF_STATE_PREPARED:
break;
case VB2_BUF_STATE_PREPARING:
dprintk(1, "buffer still being prepared\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err;
default:
dprintk(1, "invalid buffer state %d\n", vb->state);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err;
}
 
/*
@@ -1392,6 +1423,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
q->queued_c

1 2 3 >

1 - 100 of 207 matches

Mail list logo