[PATCH 2/3] [media] s5p-mfc: remove unnecessary check in try_fmt

[ayaka]

We don't need to request the sizeimage or num_planes
in try_fmt.

Signed-off-by: ayaka 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index a66a9f9..2f76aba 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1043,10 +1043,6 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_err("failed to try output format\n");
return -EINVAL;
}
-   if (pix_fmt_mp->plane_fmt[0].sizeimage == 0) {
-   mfc_err("must be set encoding output size\n");
-   return -EINVAL;
-   }
if ((dev->variant->version_bit & fmt->versions) == 0) {
mfc_err("Unsupported format by this MFC version.\n");
return -EINVAL;
@@ -1060,11 +1056,6 @@ static int vidioc_try_fmt(struct file *file, void *priv, 
struct v4l2_format *f)
mfc_err("failed to try output format\n");
return -EINVAL;
}
-
-   if (fmt->num_planes != pix_fmt_mp->num_planes) {
-   mfc_err("failed to try output format\n");
-   return -EINVAL;
-   }
if ((dev->variant->version_bit & fmt->versions) == 0) {
mfc_err("Unsupported format by this MFC version.\n");
return -EINVAL;
-- 
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 3/3] [media] s5p-mfc: fix a typo in s5p_mfc_dec

[ayaka]

It is a cosmetic commit.

Signed-off-by: ayaka 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index f2d6376..391ed9c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -573,7 +573,7 @@ static int vidioc_reqbufs(struct file *file, void *priv,
struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
 
if (reqbufs->memory != V4L2_MEMORY_MMAP) {
-   mfc_err("Only V4L2_MEMORY_MAP is supported\n");
+   mfc_err("Only V4L2_MEMORY_MMAP is supported\n");
return -EINVAL;
}
 
-- 
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

[RESEND PATCH] [PATCH 0/3] A few patches make s5p-mfc work with Gstreamer

[ayaka]

A user-space application will follow the V4l2 document, but I meet
a problem when I test it with Gstreamer. I look at the V4l2
document, the driver check the external setting which the
document not cover, so that is what the second patch do.

The first patch comes from chromium project, but I didn't
find it is merged, so I sent it again with new kernel API.
But I have not test it with 4.6-rc6, as I meet sysmmu problem
there.

But all those patches have been confirmed at Linux 4.1.16.


ayaka (3):
  [media] s5p-mfc: Add handling of buffer freeing reqbufs request
  [media] s5p-mfc: remove unnecessary check in try_fmt
  [media] s5p-mfc: fix a typo in s5p_mfc_dec

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |  2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 12 +++-
 2 files changed, 4 insertions(+), 10 deletions(-)

-- 
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/3] [media] s5p-mfc: Add handling of buffer freeing reqbufs request

[ayaka]

The encoder forget the work to call hardware to release its buffers.
This patch came from chromium project. I just change its code
style and make the API match with new kernel.

Signed-off-by: ayaka 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 034b5c1..a66a9f9 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1144,7 +1144,10 @@ static int vidioc_reqbufs(struct file *file, void *priv,
return -EINVAL;
if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
if (reqbufs->count == 0) {
+   mfc_debug(2, "Freeing buffers\n");
ret = vb2_reqbufs(>vq_dst, reqbufs);
+   s5p_mfc_hw_call(dev->mfc_ops, release_codec_buffers,
+   ctx);
ctx->capture_state = QUEUE_FREE;
return ret;
}
-- 
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 PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers

[ayaka]

Please also notice those patches (A few patches make s5p-mfc work with 
Gstreamer)

 I resent to mail recently.
Without them, the encoder won't work with Gstreamer either. I hope it 
will be

merged as soon as possible.

在 2016年05月07日 06:11, Javier Martinez Canillas 写道:

From: ayaka 

User-space applications can use the VIDIOC_REQBUFS ioctl to determine if a
memory mapped, user pointer or DMABUF based I/O is supported by the driver.

So a set of VIDIOC_REQBUFS ioctl calls will be made with count 0 and then
the real VIDIOC_REQBUFS call with count == n. But for count 0, the driver
not only frees the buffer but also closes the MFC instance and s5p_mfc_ctx
state is set to MFCINST_FREE.

The VIDIOC_REQBUFS handler for the output device checks if the s5p_mfc_ctx
state is set to MFCINST_INIT (which happens on an VIDIOC_S_FMT) and fails
otherwise. So after a VIDIOC_REQBUFS(n), future VIDIOC_REQBUFS(n) calls
will fails unless a VIDIOC_S_FMT ioctl calls happens before the reqbufs.

But applications may first set the format and then attempt to determine
the I/O methods supported by the driver (for example Gstramer does it) so
the state won't be set to MFCINST_INIT again and VIDIOC_REQBUFS will fail.

To avoid this issue, only free the buffers on VIDIOC_REQBUFS(0) but don't
close the MFC instance to allow future VIDIOC_REQBUFS(n) calls to succeed.

Signed-off-by: ayaka 
[javier: Rewrote changelog to explain the problem more detailed]
Signed-off-by: Javier Martinez Canillas 

---
Hello,

This is a resend of a patch posted by Ayaka some time ago [0].
Without $SUBJECT, trying to decode a video using Gstramer fails
on an Exynos5422 Odroid XU4 board with following error message:

$ gst-launch-1.0 filesrc location=test.mov ! qtdemux ! h264parse ! 
v4l2video0dec ! videoconvert ! autovideosink

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
[ 3947.114756] vidioc_reqbufs:576: Only V4L2_MEMORY_MAP is supported
[ 3947.114771] vidioc_reqbufs:576: Only V4L2_MEMORY_MAP is supported
[ 3947.114903] reqbufs_output:484: Reqbufs called in an invalid state
[ 3947.114913] reqbufs_output:510: Failed allocating buffers for OUTPUT queue
ERROR: from element /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0: Failed 
to allocate required memory.
Additional debug info:
gstv4l2videodec.c(575): gst_v4l2_video_dec_handle_frame (): 
/GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0:
Buffer pool activation failed
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

[0]: https://patchwork.linuxtv.org/patch/32794/

Best regards,
Javier

  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index f2d6376ce618..8b9467de2d6a 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -474,7 +474,6 @@ static int reqbufs_output(struct s5p_mfc_dev *dev, struct 
s5p_mfc_ctx *ctx,
ret = vb2_reqbufs(>vq_src, reqbufs);
if (ret)
goto out;
-   s5p_mfc_close_mfc_inst(dev, ctx);
ctx->src_bufs_cnt = 0;
ctx->output_state = QUEUE_FREE;
} else if (ctx->output_state == QUEUE_FREE) {


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

Hello Dear

[Miss Zara]

My name is Miss Zara did you receive the mail i send to you last time? please 
get back to me ok my email zar...@live.com  to enable me to resend it back to 
you

Zara
--
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 PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers

[Nicolas Dufresne]

Thanks for re-submitting. See inline two typos to fix in teh comment.

cheers,
Nicolas

Le vendredi 06 mai 2016 à 18:11 -0400, Javier Martinez Canillas a écrit :
> From: ayaka 
> 
> User-space applications can use the VIDIOC_REQBUFS ioctl to determine if a
> memory mapped, user pointer or DMABUF based I/O is supported by the driver.
> 
> So a set of VIDIOC_REQBUFS ioctl calls will be made with count 0 and then
> the real VIDIOC_REQBUFS call with count == n. But for count 0, the driver
> not only frees the buffer but also closes the MFC instance and s5p_mfc_ctx
> state is set to MFCINST_FREE.
> 
> The VIDIOC_REQBUFS handler for the output device checks if the s5p_mfc_ctx
> state is set to MFCINST_INIT (which happens on an VIDIOC_S_FMT) and fails
> otherwise. So after a VIDIOC_REQBUFS(n), future VIDIOC_REQBUFS(n) calls
> will fails unless a VIDIOC_S_FMT ioctl calls happens before the reqbufs.
> 
> But applications may first set the format and then attempt to determine
> the I/O methods supported by the driver (for example Gstramer does it) so
 * GStreamer

> the state won't be set to MFCINST_INIT again and VIDIOC_REQBUFS will fail.
> 
> To avoid this issue, only free the buffers on VIDIOC_REQBUFS(0) but don't
> close the MFC instance to allow future VIDIOC_REQBUFS(n) calls to succeed.
> 
> Signed-off-by: ayaka 
> [javier: Rewrote changelog to explain the problem more detailed]
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> Hello,
> 
> This is a resend of a patch posted by Ayaka some time ago [0].
> Without $SUBJECT, trying to decode a video using Gstramer fails

* GStreamer again 

> on an Exynos5422 Odroid XU4 board with following error message:
> 
> $ gst-launch-1.0 filesrc location=test.mov ! qtdemux ! h264parse ! 
> v4l2video0dec ! videoconvert ! autovideosink
> 
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> [ 3947.114756] vidioc_reqbufs:576: Only V4L2_MEMORY_MAP is supported
> [ 3947.114771] vidioc_reqbufs:576: Only V4L2_MEMORY_MAP is supported
> [ 3947.114903] reqbufs_output:484: Reqbufs called in an invalid state
> [ 3947.114913] reqbufs_output:510: Failed allocating buffers for OUTPUT queue
> ERROR: from element /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0: 
> Failed to allocate required memory.
> Additional debug info:
> gstv4l2videodec.c(575): gst_v4l2_video_dec_handle_frame (): 
> /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0:
> Buffer pool activation failed
> ERROR: pipeline doesn't want to preroll.
> Setting pipeline to NULL ...
> Freeing pipeline ...
> 
> [0]: https://patchwork.linuxtv.org/patch/32794/
> 
> Best regards,
> Javier
> 
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index f2d6376ce618..8b9467de2d6a 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -474,7 +474,6 @@ static int reqbufs_output(struct s5p_mfc_dev *dev, struct 
> s5p_mfc_ctx *ctx,
>   ret = vb2_reqbufs(>vq_src, reqbufs);
>   if (ret)
>   goto out;
> - s5p_mfc_close_mfc_inst(dev, ctx);
>   ctx->src_bufs_cnt = 0;
>   ctx->output_state = QUEUE_FREE;
>   } else if (ctx->output_state == QUEUE_FREE) {

signature.asc
Description: This is a digitally signed message part

[RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers

[Javier Martinez Canillas]

From: ayaka 

User-space applications can use the VIDIOC_REQBUFS ioctl to determine if a
memory mapped, user pointer or DMABUF based I/O is supported by the driver.

So a set of VIDIOC_REQBUFS ioctl calls will be made with count 0 and then
the real VIDIOC_REQBUFS call with count == n. But for count 0, the driver
not only frees the buffer but also closes the MFC instance and s5p_mfc_ctx
state is set to MFCINST_FREE.

The VIDIOC_REQBUFS handler for the output device checks if the s5p_mfc_ctx
state is set to MFCINST_INIT (which happens on an VIDIOC_S_FMT) and fails
otherwise. So after a VIDIOC_REQBUFS(n), future VIDIOC_REQBUFS(n) calls
will fails unless a VIDIOC_S_FMT ioctl calls happens before the reqbufs.

But applications may first set the format and then attempt to determine
the I/O methods supported by the driver (for example Gstramer does it) so
the state won't be set to MFCINST_INIT again and VIDIOC_REQBUFS will fail.

To avoid this issue, only free the buffers on VIDIOC_REQBUFS(0) but don't
close the MFC instance to allow future VIDIOC_REQBUFS(n) calls to succeed.

Signed-off-by: ayaka 
[javier: Rewrote changelog to explain the problem more detailed]
Signed-off-by: Javier Martinez Canillas 

---
Hello,

This is a resend of a patch posted by Ayaka some time ago [0].
Without $SUBJECT, trying to decode a video using Gstramer fails
on an Exynos5422 Odroid XU4 board with following error message:

$ gst-launch-1.0 filesrc location=test.mov ! qtdemux ! h264parse ! 
v4l2video0dec ! videoconvert ! autovideosink

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
[ 3947.114756] vidioc_reqbufs:576: Only V4L2_MEMORY_MAP is supported
[ 3947.114771] vidioc_reqbufs:576: Only V4L2_MEMORY_MAP is supported
[ 3947.114903] reqbufs_output:484: Reqbufs called in an invalid state
[ 3947.114913] reqbufs_output:510: Failed allocating buffers for OUTPUT queue
ERROR: from element /GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0: Failed 
to allocate required memory.
Additional debug info:
gstv4l2videodec.c(575): gst_v4l2_video_dec_handle_frame (): 
/GstPipeline:pipeline0/v4l2video0dec:v4l2video0dec0:
Buffer pool activation failed
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

[0]: https://patchwork.linuxtv.org/patch/32794/

Best regards,
Javier

 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index f2d6376ce618..8b9467de2d6a 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -474,7 +474,6 @@ static int reqbufs_output(struct s5p_mfc_dev *dev, struct 
s5p_mfc_ctx *ctx,
ret = vb2_reqbufs(>vq_src, reqbufs);
if (ret)
goto out;
-   s5p_mfc_close_mfc_inst(dev, ctx);
ctx->src_bufs_cnt = 0;
ctx->output_state = QUEUE_FREE;
} else if (ctx->output_state == QUEUE_FREE) {
-- 
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: [RFC 08/22] videodev2.h: Add request field to v4l2_pix_format_mplane

[Sakari Ailus]

Hi Nicolas,

On Fri, May 06, 2016 at 12:33:11PM -0400, Nicolas Dufresne wrote:
> Le vendredi 06 mai 2016 à 13:53 +0300, Sakari Ailus a écrit :
> > From: Laurent Pinchart 
> > 
> > Let userspace specify a request ID when getting or setting formats.
> > The
> > support is limited to the multi-planar API at the moment, extending
> > it
> > to the single-planar API is possible if needed.
> > 
> > From a userspace point of view the API change is also minimized and
> > doesn't require any new ioctl.
> > 
> > Signed-off-by: Laurent Pinchart  > d.com>
> > ---
> >  include/uapi/linux/videodev2.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h
> > index ac28299..6260d0e 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -1972,6 +1972,7 @@ struct v4l2_plane_pix_format {
> >   * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr
> > encoding
> >   * @quantization:  enum v4l2_quantization, colorspace
> > quantization
> >   * @xfer_func: enum v4l2_xfer_func, colorspace
> > transfer function
> > + * @request:   request ID
> >   */
> >  struct v4l2_pix_format_mplane {
> >     __u32   width;
> > @@ -1986,7 +1987,8 @@ struct v4l2_pix_format_mplane {
> >     __u8ycbcr_enc;
> >     __u8quantization;
> >     __u8xfer_func;
> > -   __u8reserved[7];
> > +   __u8reserved[3];
> > +   __u32   request;
> 
> Shouldn't the request member be added before the padding ?

In this case, no. The reason is that struct fields are aligned in most ABIs
(and to my knowledge, all ABIs Linux supports by default work that way, some
have looser limitations) to the size of the field. The struct is packed so
unaligned access would work, too, but it'd be more expensive.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 v4] media: vb2-dma-contig: configure DMA max segment size properly

[Mauro Carvalho Chehab]

Em Wed, 04 May 2016 11:00:03 +0200
Marek Szyprowski  escreveu:

> This patch lets vb2-dma-contig memory allocator to configure DMA max
> segment size properly for the client device. Setting it is needed to let
> DMA-mapping subsystem to create a single, contiguous mapping in DMA
> address space. This is essential for all devices, which use dma-contig
> videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes
> of operations).
> 
> Signed-off-by: Marek Szyprowski 
> Acked-by: Sakari Ailus 
> ---
> Hello,
> 
> This patch is a follow-up of my previous attempts to let Exynos
> multimedia devices to work properly with shared buffers when IOMMU is
> enabled:
> 1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html
> 2. 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316
> 3. https://patchwork.linuxtv.org/patch/30870/
> 
> As sugested by Hans, configuring DMA max segment size should be done by
> videobuf2-dma-contig module instead of requiring all device drivers to
> do it on their own.
> 
> Here is some backgroud why this is done in videobuf2-dc not in the
> respective generic bus code:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html
> 
> Best regards,
> Marek Szyprowski
> 
> changelog:
> v4:
> - rebased onto media master tree
> - call vb2_dc_set_max_seg_size after allocating vb2 buf object
> 
> v3:
> - added FIXME note about possible memory leak
> 
> v2:
> - fixes typos and other language issues in the comments
> 
> v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 53 
> +-
>  1 file changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index 5361197f3e57..6291842a889f 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -448,6 +448,42 @@ static void vb2_dc_put_userptr(void *buf_priv)
>  }
>  
>  /*
> + * To allow mapping the scatter-list into a single chunk in the DMA
> + * address space, the device is required to have the DMA max segment
> + * size parameter set to a value larger than the buffer size. Otherwise,
> + * the DMA-mapping subsystem will split the mapping into max segment
> + * size chunks. This function increases the DMA max segment size
> + * parameter to let DMA-mapping map a buffer as a single chunk in DMA
> + * address space.
> + * This code assumes that the DMA-mapping subsystem will merge all
> + * scatterlist segments if this is really possible (for example when
> + * an IOMMU is available and enabled).
> + * Ideally, this parameter should be set by the generic bus code, but it
> + * is left with the default 64KiB value due to historical litmiations in
> + * other subsystems (like limited USB host drivers) and there no good
> + * place to set it to the proper value. It is done here to avoid fixing
> + * all the vb2-dc client drivers.
> + *
> + * FIXME: the allocated dma_params structure is leaked because there
> + * is completely no way to determine when to free it (dma_params might have
> + * been also already allocated by the bus code). However in typical
> + * use cases this function will be called for platform devices, which are
> + * not hot-plugged and exist all the time in the target system.
> + */
> +static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size)
> +{
> + if (!dev->dma_parms) {
> + dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);

Why don't you use devm_kzalloc() here? dma_parms will then be freed
if the device gets hot-unplugged/unbind.

And yes: it is possible to hot-unplug (actually, hot-unbind) a platform
device via sysfs.

Just assuming that only platform drivers will use dma-contig and adding
a memory leak here seems really ugly!

Regards,
Mauro
-- 
Thanks,
Mauro
--
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: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Fri, 6 May 2016 18:26:10 +0200
Markus Heiser  escreveu:

> Hi Mauro,
> 
> Am 06.05.2016 um 13:03 schrieb Mauro Carvalho Chehab 
> :
> > Yeah, it looks better, however table truncation seem to be
> > happening also on other parts, like the tables on this page:
> > 
> > 
> > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-packed-rgb.html
> > (original table: 
> > https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html)
> > This table should contain 32 bits, but only the first 7 bits are shown
> > 
> > and those (among others):
> > 
> > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-y41p.html
> > 
> > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/dev-sliced-vbi.html
> > 
> > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html
> > 
> > Hmm... after looking more carefully, it added a horizontal scroll bar.
> > That looks ugly, IMHO, and makes harder to understand its contents. The
> > last one, in particular 
> > (https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html),
> > is a big table on both horiz and vert dimensions. Try to read how the
> > bits are packed on a random line in the middle of the table, like
> > MEDIA_BUS_FMT_BGR565_2X8_LE and you'll understand what I mean.  
> 
> I know what you mean ;-) ... I'am also unhappy, but I will address this point
> later when it goes to finish the layout.
> 
> Currently lets focus on contend and (the two)extensions.

OK.

> > The table here looks weird (although it is correct):
> > 
> > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-srggb10p.html
> > (original table: 
> > https://linuxtv.org/downloads/v4l-dvb-apis/pixfmt-srggb10p.html)
> >   
> 
> I validated this and the other tables you mentioned above ... these are 
> all correct migrated ... it is 1:1 translated from DocBook ... they
> might be show different to this what you know from your docbook
> toolchain, because in the docbook-html you have no table grids and 
> wrong cellspans are not clear ... sometimes, like in the last example 
> you gave:
> 
>   
> 
> 
> 
> a colspec might ambiguous ... so there is no clear role to migrate.

Ok, that's what I was thinking. Ok, this can be fixed later manually,
where needed. Of course one way would be to disable grids on those
tables, but I would instead fix it.

> 
> > It seems that Sphinx is assuming something like "A4 portrait" for
> > the margins, while those big tables would only fit (in PDF) as
> > "A4 landscape".  
> 
> No, no, no ;-)
> 
> Sphinx assumes nothing about the layout, sphinx and the underlying
> docutils mostly juggling with nodes and the writers in e.g. the
> html-writer, outputs a clear HTML without any style but with classified 
> HTML tags. Styling is done in the presentation layer, in HTML, it is 
> done in CSS.

Hmm... Then there's something deadly wrong at CSS template, as it is
shown texts only at half of my horizontal res (1920).

Probably this is the culpit:

  .container { margin: 50px auto 40px auto; width: 600px; text-align: 
center; }

width is set to 600px, instead of using a percentage, like 100%
(or 90%).

> 
> > I guess the better would be to not limit the right
> > margin or to change it where those big tables happen, in order to
> > allow PDF generation.  
> 
> Generating PDF has nothing to do with generating HTML. To generate
> PDF there is a other writer, the latex2e writer, which produce 
> LaTeX markup from which you build PDF or other printed-like medias.

Ok.

>  
> > 
> > There are also some tables that went wrong. See the Color Sample
> > Location table at:
> > 
> > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-yuv444m.html
> > I'm pretty sure we'll need to fix some cases like that manually.
> > I didn't check, but perhaps, in this case, the DocBook were using 
> > empty columns just to make the table bigger. If so, this is not a
> > problem with the conversion, and should be manually fixed later.  
> 
> +1
> 
> Yes, lets do it manually later ... what I have in my POC is a automated
> process, it is hard to consider individuals in an automatic process.
> Making details *nicer* and making ambiguous markups clear is manually
> done in minutes where I need hours to implement this in a automated
> process.

Yeah, we should not try to fix everything via auto-scripts, and
spending time right now with manual fixes will be wasted, as we need
to run it at the latest media documentation, as changes might have
happened upstream.

> 
> Aside, from:  http://docutils.sourceforge.net/docs/peps/pep-0258.html
> 
> Docutils Project Model -- Project components and data flow:
> 
>  +---+
>  |Docutils:  |
>  | docutils.core.Publisher,  |
> 

Re: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hi Mauro,

Am 06.05.2016 um 13:03 schrieb Mauro Carvalho Chehab :
> Yeah, it looks better, however table truncation seem to be
> happening also on other parts, like the tables on this page:
> 
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-packed-rgb.html
>   (original table: 
> https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html)
> This table should contain 32 bits, but only the first 7 bits are shown
> 
> and those (among others):
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-y41p.html
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/dev-sliced-vbi.html
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html
> 
> Hmm... after looking more carefully, it added a horizontal scroll bar.
> That looks ugly, IMHO, and makes harder to understand its contents. The
> last one, in particular 
> (https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html),
> is a big table on both horiz and vert dimensions. Try to read how the
> bits are packed on a random line in the middle of the table, like
> MEDIA_BUS_FMT_BGR565_2X8_LE and you'll understand what I mean.

I know what you mean ;-) ... I'am also unhappy, but I will address this point
later when it goes to finish the layout.

Currently lets focus on contend and (the two)extensions.

> The table here looks weird (although it is correct):
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-srggb10p.html
>   (original table: 
> https://linuxtv.org/downloads/v4l-dvb-apis/pixfmt-srggb10p.html)
> 

I validated this and the other tables you mentioned above ... these are 
all correct migrated ... it is 1:1 translated from DocBook ... they
might be show different to this what you know from your docbook
toolchain, because in the docbook-html you have no table grids and 
wrong cellspans are not clear ... sometimes, like in the last example 
you gave:


  
  

a colspec might ambiguous ... so there is no clear role to migrate.

> It seems that Sphinx is assuming something like "A4 portrait" for
> the margins, while those big tables would only fit (in PDF) as
> "A4 landscape".

No, no, no ;-)

Sphinx assumes nothing about the layout, sphinx and the underlying
docutils mostly juggling with nodes and the writers in e.g. the
html-writer, outputs a clear HTML without any style but with classified 
HTML tags. Styling is done in the presentation layer, in HTML, it is 
done in CSS.

> I guess the better would be to not limit the right
> margin or to change it where those big tables happen, in order to
> allow PDF generation.

Generating PDF has nothing to do with generating HTML. To generate
PDF there is a other writer, the latex2e writer, which produce 
LaTeX markup from which you build PDF or other printed-like medias.
 
> 
> There are also some tables that went wrong. See the Color Sample
> Location table at:
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-yuv444m.html
> I'm pretty sure we'll need to fix some cases like that manually.
> I didn't check, but perhaps, in this case, the DocBook were using 
> empty columns just to make the table bigger. If so, this is not a
> problem with the conversion, and should be manually fixed later.

+1

Yes, lets do it manually later ... what I have in my POC is a automated
process, it is hard to consider individuals in an automatic process.
Making details *nicer* and making ambiguous markups clear is manually
done in minutes where I need hours to implement this in a automated
process.

Aside, from:  http://docutils.sourceforge.net/docs/peps/pep-0258.html

Docutils Project Model -- Project components and data flow:

 +---+
 |Docutils:  |
 | docutils.core.Publisher,  |
 | docutils.core.publish_*() |
 +---+
  /|\
 / | \
1,3,5   /6 |  \ 7
   ++   +-+   ++
   | READER | > | TRANSFORMER | > | WRITER |
   ++   +-+   ++
/ \\  |
   /   \\ |
 2/  4  \\ 8  |
+---+   ++++
| INPUT |   | PARSER || OUTPUT |
+---+   ++++


This is a bit simplified, because we use sphinx, which 
has "builders" and sits on top of this architecture.
But it might help to see, that processes like reading,
transforming and writing are discrete.

In short: readers (the reST file reader) are creating node trees,

Re: [RFC 08/22] videodev2.h: Add request field to v4l2_pix_format_mplane

[Nicolas Dufresne]

Le vendredi 06 mai 2016 à 13:53 +0300, Sakari Ailus a écrit :
> From: Laurent Pinchart 
> 
> Let userspace specify a request ID when getting or setting formats.
> The
> support is limited to the multi-planar API at the moment, extending
> it
> to the single-planar API is possible if needed.
> 
> From a userspace point of view the API change is also minimized and
> doesn't require any new ioctl.
> 
> Signed-off-by: Laurent Pinchart  d.com>
> ---
>  include/uapi/linux/videodev2.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/videodev2.h
> b/include/uapi/linux/videodev2.h
> index ac28299..6260d0e 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1972,6 +1972,7 @@ struct v4l2_plane_pix_format {
>   * @ycbcr_enc:   enum v4l2_ycbcr_encoding, Y'CbCr
> encoding
>   * @quantization:enum v4l2_quantization, colorspace
> quantization
>   * @xfer_func:   enum v4l2_xfer_func, colorspace
> transfer function
> + * @request: request ID
>   */
>  struct v4l2_pix_format_mplane {
>   __u32   width;
> @@ -1986,7 +1987,8 @@ struct v4l2_pix_format_mplane {
>   __u8ycbcr_enc;
>   __u8quantization;
>   __u8xfer_func;
> - __u8reserved[7];
> + __u8reserved[3];
> + __u32   request;

Shouldn't the request member be added before the padding ?

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

[GIT PULL 4.7] af9035

[Antti Palosaari]

The following changes since commit 45c175c4ae9695d6d2f30a45ab7f3866cfac184b:

  [media] tw686x: avoid going past array (2016-04-26 06:38:53 -0300)

are available in the git repository at:

  git://linuxtv.org/anttip/media_tree.git af9035

for you to fetch changes up to 9c3cda3783707e8028ec1335e9ec0a63edb4712b:

  af9035: correct eeprom offsets (2016-04-27 23:08:50 +0300)


Antti Palosaari (1):
  af9035: correct eeprom offsets

 drivers/media/usb/dvb-usb-v2/af9035.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

--
http://palosaari.fi/
--
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: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Fri, 06 May 2016, Markus Heiser  wrote:
> Am 06.05.2016 um 17:06 schrieb Jani Nikula :
>
>> On Fri, 06 May 2016, Markus Heiser  wrote:
>>> @Jonathan: what do you think? Should I prepare a patch
>>> with a basic reST (sphinx) build infrastructure, including
>>> 
>>> * a folder for sphinx docs:
>>> 
>>>  ./Documentation/sphinx/
>> 
>> I'm already working on a patch series taking a different approach. I
>> don't think we should hide the documentation under an extra folder named
>> after a tool. Actually, I'm strongly opposed to that.
>
> Could you post a link to a repo? / thanks

Very much a work-in-progress
https://cgit.freedesktop.org/~jani/drm/log/?h=sphinx

I was hoping to polish it a bit more before showing it to the world.

> There is no need for concurrency, let's work together on your repo. 
> Within my POC I realized similar building processes we will need in the
> kernel sources ... where you have cascading configuration. A base 
> configuration which fits for all common cases and (if needed) a 
> *per-book* configuration.
>
> At the end, when it comes to generate pdf books/articles, man pages 
> and e.g. texinfo files out of a sphinx-project you will need a build
> infrastructure like this.

...

> You will need on sphinx-project for each DocBook and one single 
> sphinx-project where you collect the .txt to .rst migrated files.

Surely you know more about Sphinx than I do, but I specifically would
like to include e.g. gpu documentation in the main build. I'm really
hoping we can have *additional* configuration files for special cases
(only) as needed.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
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: Kernel docs: muddying the waters a bit

[Markus Heiser]

Am 06.05.2016 um 17:06 schrieb Jani Nikula :

> On Fri, 06 May 2016, Markus Heiser  wrote:
>> @Jonathan: what do you think? Should I prepare a patch
>> with a basic reST (sphinx) build infrastructure, including
>> 
>> * a folder for sphinx docs:
>> 
>>  ./Documentation/sphinx/
> 
> I'm already working on a patch series taking a different approach. I
> don't think we should hide the documentation under an extra folder named
> after a tool. Actually, I'm strongly opposed to that.

Could you post a link to a repo? / thanks 

There is no need for concurrency, let's work together on your repo. 
Within my POC I realized similar building processes we will need in the
kernel sources ... where you have cascading configuration. A base 
configuration which fits for all common cases and (if needed) a 
*per-book* configuration.

At the end, when it comes to generate pdf books/articles, man pages 
and e.g. texinfo files out of a sphinx-project you will need a build
infrastructure like this.

> Instead, we should place the Sphinx stuff directly under Documentation,
> and have Sphinx recursively pick up all the *.rst files. We should
> promote gradually switching to lightweight markup and integration of the
> documents into one system. This process should be as little disruptive
> as possible.
> 
> If someone wants to convert a .txt document to .rst and get it processed
> by Sphinx, it should be as simple as renaming the file, doing the
> necessary edits, and adding it to a toctree. Imagine gradually
> converting the files under, say, Documentation/kbuild. Why should the
> .rst files be moved under another directory? They should stay alongside
> the .txt files under the same directory. There's bound to be a lot of
> people who'll never use Sphinx, and will expect to find the good old
> plain text files (albeit with some markup) where they always were.
> 

Ok, I agree with you in the fact that a additional "sphinx" folder
is unrewarding.

This means (e.g.) a migrated Documentation/DocBook/gpu book should placed
in Documentation/gpu ... but don' try to merge all (Doc-)Books and .txt-files
into one sphinx project!

You will need on sphinx-project for each DocBook and one single 
sphinx-project where you collect the .txt to .rst migrated files.

Am 06.05.2016 um 17:23 schrieb Mauro Carvalho Chehab :

> We won't avoid the need of moving things among directories, as we
> have lots of stuff under DocBook/ dir (btw, named after the toolchain).

Yes, it is named by the toolchain, but no one reads xml-files. Reading
text files is common.

> Ok, if we put the .rst files at Documentation, we very likely reduce
> the number of renames, but we'll increase the Makefile complexity,
> and the risk of breakages.

I don't see a great potential of breakages ...  if we place every book
in a separated folder and have one project which collects the .txt files
(see above).


--Markus--

--
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 00/22] Media request API

[Sakari Ailus]

On Fri, May 06, 2016 at 01:53:09PM +0300, Sakari Ailus wrote:
> My open questions and to-do items I'm aware of:
> 
> - Global ID space vs. file handles. Should requests be referred to by
>   global IDs or file handles specific to a process? V4L2 uses IDs but V4L2
>   devices (other than m2m) can meaningfully be used only by a single
>   program (or co-operative programs) at a time whereas the media device
>   could conceivably be accessed and used for different purposes by
>   multiple programs at the same time as the resources accessible through
>   the media device are numerous and often independent of each other. A
>   badly behaving application could disturb other applications using the
>   same media device even if no resource conflict exist by accessing the
>   same request IDs than other applications.
> 
> - Request completion and deletion. Should completed requests be deleted
>   automatically, or should the request return to an "empty" state after
>   completion? Applications typically have to create a new request right
>   after a completion of an earlier one, and sparing one additional IOCTL
>   call would be nice. (In current implementation the requests are deleted
>   in completion, but this would be a trivial change.)
> 
> - Video buffers vs. requests. In the current implementation, I'm using
>   VIDIOC_QBUF() from user space to associate buffers with requests. This
>   is convenient in drivers since the only extra steps to support requests
>   (vs. operation without requests) is to find the request and not really
>   queueing the buffer yet. What's noteworthy as well that the VB2 buffer
>   is in correct state after this when the request is queued.
> 
> - Subsystem framework specific request information. The requests are about
>   the media device, and struct media_device_request is free of e.g. V4L2
>   related information. Adding a pointer to V4L2 related data would make it
>   easier to add request handling related functionality to the V4L2
>   framework.
> 
> - MEDIA_IOC_REQUEST_CMD + (ALLOC/DELETE/QUEUE/APPLY) vs.
>   MEDIA_IOC_REQUEST_(ALLOC/DELETE/QUEUE/APPLY). Should we continue to have
>   a single IOCTL on the media device for requests, or should each
>   operation on a request have a distinct IOCTL? The current implementation
>   has a single IOCTL.
> 
> - VB2 queues are quite self-sufficient at the moment. Starting start in a
>   queue requires at least one queued buffer whereas a stream containing
>   multiple queues using requests could start e.g. by having a single
>   buffer in a request for three streaming queues. The functionality would
>   need to be relaxed to properly support requests.
> 
> - Limit number of allocated requests and dequeueable events to prevent
>   unintentional or intentional system memory exhaustion.

One matter to add here:

- Serialisation. How should access to various objects be handled? There
  might not be bugs in the current code, but supporting requests changing
  the Media device (graph) state would definitely benefit from abolishing
  the big graph_mutex.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Fri, 6 May 2016 18:06:49 +0300
Jani Nikula  escreveu:

> On Fri, 06 May 2016, Markus Heiser  wrote:
> > @Jonathan: what do you think? Should I prepare a patch
> > with a basic reST (sphinx) build infrastructure, including
> >
> > * a folder for sphinx docs:
> >
> >   ./Documentation/sphinx/  
> 
> I'm already working on a patch series taking a different approach. I
> don't think we should hide the documentation under an extra folder named
> after a tool. Actually, I'm strongly opposed to that.
> 
> Instead, we should place the Sphinx stuff directly under Documentation,
> and have Sphinx recursively pick up all the *.rst files. We should
> promote gradually switching to lightweight markup and integration of the
> documents into one system. This process should be as little disruptive
> as possible.

We won't avoid the need of moving things among directories, as we
have lots of stuff under DocBook/ dir (btw, named after the toolchain).

Ok, if we put the .rst files at Documentation, we very likely reduce
the number of renames, but we'll increase the Makefile complexity,
and the risk of breakages. One alternative would be to put the sphinx
stuff on a separate Makefile, but using multiple makefiles on a single
dir is not standard at the Kernel.

> If someone wants to convert a .txt document to .rst and get it processed
> by Sphinx, it should be as simple as renaming the file, doing the
> necessary edits, and adding it to a toctree. Imagine gradually
> converting the files under, say, Documentation/kbuild. Why should the
> .rst files be moved under another directory? They should stay alongside
> the .txt files under the same directory. There's bound to be a lot of
> people who'll never use Sphinx, and will expect to find the good old
> plain text files (albeit with some markup) where they always were.


Well, git will show the change as a rename, no matter if the
directory name changes or not (except if we keep the rst files
with .txt extension), but I agree with you that people will expect
to see text files at Documentation, and most will just read it without
caring to run Sphinx.

-- 
Thanks,
Mauro
--
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: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Fri, 6 May 2016 16:27:21 +0200
Markus Heiser  escreveu:

> Hi all, hi Jonathan,
> 
> Am 06.05.2016 um 15:42 schrieb Mauro Carvalho Chehab 
> :
> 
> > Em Fri, 6 May 2016 15:32:35 +0200
> > Markus Heiser  escreveu:
> >   
> >> Hi Mauro,
> >> 
> >> Am 06.05.2016 um 13:35 schrieb Mauro Carvalho Chehab 
> >> :
> >>   
> >>> Markus,
> >>> 
> >>> Em Fri, 6 May 2016 13:23:06 +0200
> >>> Markus Heiser  escreveu:
> >>>   
>  
>  In this conf.py you have to *register* your folder with the extensions.
>  A few words about the flat-table extension and a (future) kernel-doc 
>  one:
> >>> 
> >>> ...
> >>>   
>  The flat-table is a pure docutils (the layer below sphinx) extension 
>  which
>  is not application specific, so I will ask for moving it to the docutils 
>  upstream. 
> >>> 
> >>> So, if I understood well, your proposal is to have a conf.py and the
> >>> flat-table (plus other extensions) at the Kernel tree.
> >> 
> >> Each book (better call it root-node) is a Sphinx-project, each 
> >> Sphinx-project need a conf.py file (the build configuration file)
> >> in its reST-source tree.
> >> 
> >> * http://www.sphinx-doc.org/en/stable/config.html
> >>   
> >>> Assuming that docutils upstream receives the flat-table extension
> >>> (and eventually modifies it), while the new version doesn't arrive
> >>> all distros, we'll end by having some developers using the newer
> >>> docutils with the extension, plus others using the in-tree one.
> >>> 
> >>> Is there a way to specify at the conf.py what extension variant
> >>> should it use, in case of both the in-tree or the docutils have
> >>> the same?
> >> 
> >> The build configuration file is a regular python file, you can 
> >> implement conditions whatever you want/need.
> >>   
> >>> This could be trickier if they end by modifying the extension,
> >>> but we can always backport the latest version, if they change the
> >>> API.
> >> 
> >> As far as i know, the docutils API is stable since 2002. In the
> >> meantime there has been so many application build on it that
> >> it is not realistic, you will see a not backward compatibly 
> >> change.
> >> 
> >> The docutils project is conservative, very conservative, IMO to
> >> conservative.
> >> 
> >> Today I'am doubtful if it isn't better I would merge it sphinx
> >> upstream. I have to discuss this with some maintainers, but 
> >> before I have to persuade myself, that all aspects are covered
> >> and the implementations are robust. We are at the beginning and
> >> we should not fear about every bit which could happen in the future.
> >> 
> >> The sphinx / docutils bottom plate gives us a number of degrees 
> >> of freedom to find answers to question we have not yet asked. ;-)  
> > 
> > Ok. So, from what I understand, once Sphinx support is added at
> > Kernel upstream, we could convert the media docbook to
> > reST+flat-table extension, adding such extension either on a shared
> > place or only for the media DocBook build, together with its
> > conf.py.
> >   
> 
> Yes, in your media-conf you could decide to use a extension.
> 
> > Once it reaches upstream (either sphinx or docutils), we can
> > work to make it integrate better with upstream as needed.
> > 
> > Right?  
> 
> yes, right :-)
> 
> > If so, I'm ok with merging it as soon as possible.  
> 
> If we advice a merge of the flat-table directive we should 
> bundle this with the (to implement) "kernel-doc" directive ...
> 
> > In reST the directive might look like:
> > 
> >  -
> > Device Instance and Driver Handling
> > ===
> > 
> > .. kernel-doc::  drivers/gpu/drm/drm_drv.c
> >   :doc:  driver instance overview
> >   :exported:
> > 
> >  -  
> 
> and the patches from my kernel-doc perl script to produce
> reST from source code comments.
> 
> With this bundle within the kernel tree we have a good starting
> point to compose reST documents from scratch and to migrate book
> by book from DocBook to reST.
> 
> I insist to migrate book by book, because there are some
> broken books. Broken by that, that some sources have changed
> but not the corresponding documentation which use the comments
> of these sources ... grap "Ooops" in the builded (xml or rst) docs.
> 
> E.g. I greped the .rst file and found the following Oops in the migrated 
> books:
> 
> ./books/mtdnand/pubfunctions-000-012.rst:13:Oops
> ./books/scsi/mid_layer-000-001-016-003.rst:13:Oops
> ./books/s390-drivers/ccw-000-004-003.rst:13:Oops
> ./books/device-drivers/devdrivers-000-003-048.rst:13:Oops
> ./books/device-drivers/devdrivers-000-003-050.rst:13:Oops
> ./books/device-drivers/Basics-000-001-002.rst:13:Oops
> ./books/device-drivers/devdrivers-000-003-031.rst:13:Oops
> ./books/device-drivers/Basics-000-009-032.rst:13:Oops
> 

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Fri, 06 May 2016, Markus Heiser  wrote:
> @Jonathan: what do you think? Should I prepare a patch
> with a basic reST (sphinx) build infrastructure, including
>
> * a folder for sphinx docs:
>
>   ./Documentation/sphinx/

I'm already working on a patch series taking a different approach. I
don't think we should hide the documentation under an extra folder named
after a tool. Actually, I'm strongly opposed to that.

Instead, we should place the Sphinx stuff directly under Documentation,
and have Sphinx recursively pick up all the *.rst files. We should
promote gradually switching to lightweight markup and integration of the
documents into one system. This process should be as little disruptive
as possible.

If someone wants to convert a .txt document to .rst and get it processed
by Sphinx, it should be as simple as renaming the file, doing the
necessary edits, and adding it to a toctree. Imagine gradually
converting the files under, say, Documentation/kbuild. Why should the
.rst files be moved under another directory? They should stay alongside
the .txt files under the same directory. There's bound to be a lot of
people who'll never use Sphinx, and will expect to find the good old
plain text files (albeit with some markup) where they always were.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
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: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hi all, hi Jonathan,

Am 06.05.2016 um 15:42 schrieb Mauro Carvalho Chehab :

> Em Fri, 6 May 2016 15:32:35 +0200
> Markus Heiser  escreveu:
> 
>> Hi Mauro,
>> 
>> Am 06.05.2016 um 13:35 schrieb Mauro Carvalho Chehab 
>> :
>> 
>>> Markus,
>>> 
>>> Em Fri, 6 May 2016 13:23:06 +0200
>>> Markus Heiser  escreveu:
>>> 
 
 In this conf.py you have to *register* your folder with the extensions.
 A few words about the flat-table extension and a (future) kernel-doc one:  
>>> 
>>> ...
>>> 
 The flat-table is a pure docutils (the layer below sphinx) extension which
 is not application specific, so I will ask for moving it to the docutils 
 upstream.   
>>> 
>>> So, if I understood well, your proposal is to have a conf.py and the
>>> flat-table (plus other extensions) at the Kernel tree.  
>> 
>> Each book (better call it root-node) is a Sphinx-project, each 
>> Sphinx-project need a conf.py file (the build configuration file)
>> in its reST-source tree.
>> 
>> * http://www.sphinx-doc.org/en/stable/config.html
>> 
>>> Assuming that docutils upstream receives the flat-table extension
>>> (and eventually modifies it), while the new version doesn't arrive
>>> all distros, we'll end by having some developers using the newer
>>> docutils with the extension, plus others using the in-tree one.
>>> 
>>> Is there a way to specify at the conf.py what extension variant
>>> should it use, in case of both the in-tree or the docutils have
>>> the same?  
>> 
>> The build configuration file is a regular python file, you can 
>> implement conditions whatever you want/need.
>> 
>>> This could be trickier if they end by modifying the extension,
>>> but we can always backport the latest version, if they change the
>>> API.  
>> 
>> As far as i know, the docutils API is stable since 2002. In the
>> meantime there has been so many application build on it that
>> it is not realistic, you will see a not backward compatibly 
>> change.
>> 
>> The docutils project is conservative, very conservative, IMO to
>> conservative.
>> 
>> Today I'am doubtful if it isn't better I would merge it sphinx
>> upstream. I have to discuss this with some maintainers, but 
>> before I have to persuade myself, that all aspects are covered
>> and the implementations are robust. We are at the beginning and
>> we should not fear about every bit which could happen in the future.
>> 
>> The sphinx / docutils bottom plate gives us a number of degrees 
>> of freedom to find answers to question we have not yet asked. ;-)
> 
> Ok. So, from what I understand, once Sphinx support is added at
> Kernel upstream, we could convert the media docbook to
> reST+flat-table extension, adding such extension either on a shared
> place or only for the media DocBook build, together with its
> conf.py.
> 

Yes, in your media-conf you could decide to use a extension.

> Once it reaches upstream (either sphinx or docutils), we can
> work to make it integrate better with upstream as needed.
> 
> Right?

yes, right :-)

> If so, I'm ok with merging it as soon as possible.

If we advice a merge of the flat-table directive we should 
bundle this with the (to implement) "kernel-doc" directive ...

> In reST the directive might look like:
> 
>  -
> Device Instance and Driver Handling
> ===
> 
> .. kernel-doc::  drivers/gpu/drm/drm_drv.c
>   :doc:  driver instance overview
>   :exported:
> 
>  -

and the patches from my kernel-doc perl script to produce
reST from source code comments.

With this bundle within the kernel tree we have a good starting
point to compose reST documents from scratch and to migrate book
by book from DocBook to reST.

I insist to migrate book by book, because there are some
broken books. Broken by that, that some sources have changed
but not the corresponding documentation which use the comments
of these sources ... grap "Ooops" in the builded (xml or rst) docs.

E.g. I greped the .rst file and found the following Oops in the migrated books:

./books/mtdnand/pubfunctions-000-012.rst:13:Oops
./books/scsi/mid_layer-000-001-016-003.rst:13:Oops
./books/s390-drivers/ccw-000-004-003.rst:13:Oops
./books/device-drivers/devdrivers-000-003-048.rst:13:Oops
./books/device-drivers/devdrivers-000-003-050.rst:13:Oops
./books/device-drivers/Basics-000-001-002.rst:13:Oops
./books/device-drivers/devdrivers-000-003-031.rst:13:Oops
./books/device-drivers/Basics-000-009-032.rst:13:Oops
./books/kernel-api/kernel-lib-000-004-008.rst:13:Oops
./books/gadget/api-000-011-005.rst:13:Oops
./books/gadget/api-000-011-009.rst:13:Oops
./books/gadget/api-000-011-007.rst:13:Oops
./books/gadget/api-000-011-003.rst:13:Oops
./books/gadget/api-000-011-011.rst:13:Oops
./books/genericirq/intfunctions-000-009.rst:13:Oops

- Summarize 

@Jonathan: what do you think? Should I prepare a patch
with a basic reST (sphinx) build 

Re: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hi Jani,

I forget to mentioning, with a local copy of my kernel-doc script:

https://github.com/return42/sphkerneldoc/blob/master/scripts/kernel-doc

You could do reST markup in the source code comments and extract them.

This might be a interim workaround which helps you not to edit source 
code comments twice.

-- Markus--



Am 06.05.2016 um 13:23 schrieb Markus Heiser :

> 
> Hy Jani,
> 
> Am 04.05.2016 um 18:13 schrieb Jani Nikula :
> 
>>> Am 04.05.2016 um 17:09 schrieb Jonathan Corbet :
>>> 
 I think all of this makes sense.  It would be really nice to have the
 directives in the native sphinx language like that.  I *don't* think we
 need to aim for that at the outset; the docproc approach works until we can
 properly get rid of it.  What would be *really* nice would be to get
 support for the kernel-doc directive into the sphinx upstream.
>>> 
>>> No need for kernel-doc directive in sphinx upstream, later it will be 
>>> an extension which could be installed by a simple command like 
>>> "pip install kernel-doc-extensions" or similar.
>>> 
>>> I develop these required extension (and more) within my proof of concept
>>> on github ... this takes time ... if I finished all my tests and all is
>>> well, I will build the *kernel-doc-extensions* package and deploy it
>>> on https://pypi.python.org/pypi from where everyone could install this 
>>> with "pip".
>> 
>> I think we should go for vanilla sphinx at first, to make the setup step
>> as easy as possible for everyone. Even if it means still doing that ugly
>> docproc step to call kernel-doc. We can improve from there, and I
>> definitely appreciate your work on making this work with sphinx
>> extensions.
> 
> +1 
> 
>> That said, how would it work to include the kernel-doc extension in the
>> kernel source tree? Having things just work if sphinx is installed is
>> preferred over requiring installation of something extra from pypi. (I
>> know this may sound backwards for a lot of projects, but for kernel I'm
>> pretty sure this is how it should be done.)
> 
> Thats all right. Lets talk about the extension infrastructure by example:
> 
> First we have to chose a folder where we place all the *sphinx-documentation*
> I recommending:
> 
> /share/linux/Documentation/sphinx
> 
> Next we have to chose a folder where reST-extensions should take place, I
> would prefer ... or similar:
> 
> /share/linux/Documentation/sphinx/extensions
> 
> Lets say, you wan't to get in use of the "flat-table" extension.
> 
> Copy (only) the rstFlatTable.py file from my POC extension folder (ignore
> other extensions which might be there) ...
> 
> https://github.com/return42/sphkerneldoc/tree/master/doc/extensions
> 
> Now lets say you are writing on a gpu book, it wold be placed in the folder:
> 
> /share/linux/Documentation/sphinx/gpu
> 
> In this gpu-folder you have to place the conf.py config file, needed to
> setup the sphinx build environment.
> 
> /share/linux/Documentation/sphinx/gpu/conf.py
> 
> In this conf.py you have to *register* your folder with the extensions.
> 
>  
> 
>import os.path, sys
> 
>EXT_PATH  = "../extensions"  # the path of extension folder relative to 
> the conf.py file
>sys.path.insert(0, os.path.join(os.path.dirname(__file__), EXT_PATH)))
> 
># now import the "flat-table" extension, it will be self-registering to 
> docutils
> 
>import rstFlatTable
> 
>  
> 
> Thats all, you can run your sphinx-build command and the flat-tables in your
> reST sources should be handled as common tables.
> 
> ASIDE: 
> 
> You will find similar parts in your conf.py which you have created 
> with the sphinx-quickstart command. There, you will also find a block 
> looks like ...
> 
> extensions = [
>'sphinx.ext.autodoc'
> 
> ]
> 
> Don't try to add flat-table extension to this list. This list is a list
> of sphinx extensions, we will use it later for other *real* sphinx 
> extensions.
> 
> A few words about the flat-table extension and a (future) kernel-doc one:
> 
> The flat-table is a pure docutils (the layer below sphinx) extension which
> is not application specific, so I will ask for moving it to the docutils 
> upstream. 
> 
> The kernel-doc extension on the other side is a very (very) kernel specific
> application, this would never go to sphinx nor docutils upstream.
> 
> --Markus--
> 

--
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: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hy Jani,

Am 04.05.2016 um 18:13 schrieb Jani Nikula :

>> Am 04.05.2016 um 17:09 schrieb Jonathan Corbet :
>> 
>>> I think all of this makes sense.  It would be really nice to have the
>>> directives in the native sphinx language like that.  I *don't* think we
>>> need to aim for that at the outset; the docproc approach works until we can
>>> properly get rid of it.  What would be *really* nice would be to get
>>> support for the kernel-doc directive into the sphinx upstream.
>> 
>> No need for kernel-doc directive in sphinx upstream, later it will be 
>> an extension which could be installed by a simple command like 
>> "pip install kernel-doc-extensions" or similar.
>> 
>> I develop these required extension (and more) within my proof of concept
>> on github ... this takes time ... if I finished all my tests and all is
>> well, I will build the *kernel-doc-extensions* package and deploy it
>> on https://pypi.python.org/pypi from where everyone could install this 
>> with "pip".
> 
> I think we should go for vanilla sphinx at first, to make the setup step
> as easy as possible for everyone. Even if it means still doing that ugly
> docproc step to call kernel-doc. We can improve from there, and I
> definitely appreciate your work on making this work with sphinx
> extensions.

+1 

> That said, how would it work to include the kernel-doc extension in the
> kernel source tree? Having things just work if sphinx is installed is
> preferred over requiring installation of something extra from pypi. (I
> know this may sound backwards for a lot of projects, but for kernel I'm
> pretty sure this is how it should be done.)

Thats all right. Lets talk about the extension infrastructure by example:

First we have to chose a folder where we place all the *sphinx-documentation*
I recommending:

 /share/linux/Documentation/sphinx

Next we have to chose a folder where reST-extensions should take place, I
would prefer ... or similar:
 
 /share/linux/Documentation/sphinx/extensions

Lets say, you wan't to get in use of the "flat-table" extension.

Copy (only) the rstFlatTable.py file from my POC extension folder (ignore
other extensions which might be there) ...

 https://github.com/return42/sphkerneldoc/tree/master/doc/extensions

Now lets say you are writing on a gpu book, it wold be placed in the folder:

 /share/linux/Documentation/sphinx/gpu

In this gpu-folder you have to place the conf.py config file, needed to
setup the sphinx build environment.

 /share/linux/Documentation/sphinx/gpu/conf.py

In this conf.py you have to *register* your folder with the extensions.

 

import os.path, sys

EXT_PATH  = "../extensions"  # the path of extension folder relative to the 
conf.py file
sys.path.insert(0, os.path.join(os.path.dirname(__file__), EXT_PATH)))

# now import the "flat-table" extension, it will be self-registering to 
docutils

import rstFlatTable

 

Thats all, you can run your sphinx-build command and the flat-tables in your
reST sources should be handled as common tables.

ASIDE: 

You will find similar parts in your conf.py which you have created 
with the sphinx-quickstart command. There, you will also find a block 
looks like ...

extensions = [
'sphinx.ext.autodoc'

]

Don't try to add flat-table extension to this list. This list is a list
of sphinx extensions, we will use it later for other *real* sphinx 
extensions.

A few words about the flat-table extension and a (future) kernel-doc one:

The flat-table is a pure docutils (the layer below sphinx) extension which
is not application specific, so I will ask for moving it to the docutils 
upstream. 

The kernel-doc extension on the other side is a very (very) kernel specific
application, this would never go to sphinx nor docutils upstream.

--Markus--

--
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 15/22] media: Make events on request completion optional, disabled by default

[Sakari Ailus]

On Fri, May 06, 2016 at 01:53:24PM +0300, Sakari Ailus wrote:
> Add flags to requests. The first defined flag, MEDIA_REQ_FL_COMPLETE_EVENT
> is used to tell whether to queue an event on request completion. Unless
> the flag is set, no event is generated when a request completes.
> 
> Signed-off-by: Sakari Ailus 

This one nicely demonstrates variable size IOCTL argument support so I left
it there for the time being. To be merged with the previous patch in the
future, with struct media_request_cmd_0 removed.

> ---
>  drivers/media/media-device.c | 26 +-
>  include/media/media-device.h |  2 ++
>  include/uapi/linux/media.h   | 16 +---
>  3 files changed, 32 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 357c3cb..0b1ab88 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -284,7 +284,8 @@ static void media_device_request_delete(struct 
> media_device *mdev,
>  void media_device_request_complete(struct media_device *mdev,
>  struct media_device_request *req)
>  {
> - media_device_request_queue_event(mdev, req);
> + if (req->flags & MEDIA_REQ_FL_COMPLETE_EVENT)
> + media_device_request_queue_event(mdev, req);
>  
>   media_device_request_delete(mdev, req);
>  }
> @@ -292,8 +293,8 @@ EXPORT_SYMBOL_GPL(media_device_request_complete);
>  
>  static int media_device_request_queue_apply(
>   struct media_device *mdev, struct media_device_request *req,
> - int (*fn)(struct media_device *mdev,
> -   struct media_device_request *req))
> + u32 req_flags, int (*fn)(struct media_device *mdev,
> +  struct media_device_request *req))
>  {
>   unsigned long flags;
>   int rval = 0;
> @@ -302,10 +303,12 @@ static int media_device_request_queue_apply(
>   return -ENOSYS;
>  
>   spin_lock_irqsave(>req_lock, flags);
> - if (req->state != MEDIA_DEVICE_REQUEST_STATE_IDLE)
> + if (req->state != MEDIA_DEVICE_REQUEST_STATE_IDLE) {
>   rval = -EINVAL;
> - else
> + } else {
>   req->state = MEDIA_DEVICE_REQUEST_STATE_QUEUED;
> + req->flags = req_flags;
> + }
>   spin_unlock_irqrestore(>req_lock, flags);
>  
>   if (rval)
> @@ -358,12 +361,12 @@ static long media_device_request_cmd(struct 
> media_device *mdev,
>   break;
>  
>   case MEDIA_REQ_CMD_APPLY:
> - ret = media_device_request_queue_apply(mdev, req,
> + ret = media_device_request_queue_apply(mdev, req, cmd->flags,
>  mdev->ops->req_apply);
>   break;
>  
>   case MEDIA_REQ_CMD_QUEUE:
> - ret = media_device_request_queue_apply(mdev, req,
> + ret = media_device_request_queue_apply(mdev, req, cmd->flags,
>  mdev->ops->req_queue);
>   break;
>  
> @@ -930,13 +933,18 @@ static long __media_device_ioctl(
>   return ret;
>  }
>  
> +static const unsigned short media_request_cmd_sizes[] = {
> + sizeof(struct media_request_cmd_0),
> + 0
> +};
> +
>  static const struct media_ioctl_info ioctl_info[] = {
>   MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> - MEDIA_IOC(REQUEST_CMD, media_device_request_cmd, 0),
> + MEDIA_IOC_SZ(REQUEST_CMD, media_device_request_cmd, 0, 
> media_request_cmd_sizes),
>   MEDIA_IOC(DQEVENT, media_device_dqevent, 0),
>  };
>  
> @@ -985,7 +993,7 @@ static const struct media_ioctl_info compat_ioctl_info[] 
> = {
>   MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links, 
> MEDIA_IOC_FL_GRAPH_MUTEX, from_user_enum_links32, copy_arg_to_user_nop),
>   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> - MEDIA_IOC(REQUEST_CMD, media_device_request_cmd, 0),
> + MEDIA_IOC_SZ(REQUEST_CMD, media_device_request_cmd, 0, 
> media_request_cmd_sizes),
>   MEDIA_IOC(DQEVENT, media_device_dqevent, 0),
>  };
>  
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index e62ad13..fc91d2d 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -291,6 +291,7 @@ struct media_kevent {
>   * @state: The state of the request, MEDIA_DEVICE_REQUEST_STATE_*,
>   *  access to state serialised by mdev->req_lock
>   * @data: Per-entity data list
> + * 

[RFC 07/22] videodev2.h: Add request field to v4l2_buffer

[Sakari Ailus]

From: Hans Verkuil 

When queuing buffers allow for passing the request ID that
should be associated with this buffer. Split the u32 reserved2 field
into two u16 fields, one for request, one with the old reserved2 name.

Signed-off-by: Hans Verkuil 

Use full 32 bits for the request ID.

Signed-off-by: Sakari Ailus 
---
 drivers/media/usb/cpia2/cpia2_v4l.c   | 1 +
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c  | 4 ++--
 drivers/media/v4l2-core/videobuf2-v4l2.c  | 3 ++-
 include/media/videobuf2-v4l2.h| 2 ++
 include/uapi/linux/videodev2.h| 3 ++-
 6 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
b/drivers/media/usb/cpia2/cpia2_v4l.c
index 9caea83..01c596a 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -952,6 +952,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->request = 0;
buf->reserved2 = 0;
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 bacecbd..0315e0e 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;
+   __u32   request;
__u32   reserved;
 };
 
@@ -509,7 +509,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->request, >request) ||
put_user(kp->reserved, >reserved) ||
put_user(kp->length, >length))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 6bf5a3e..bf15580 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -443,13 +443,13 @@ static void v4l_print_buffer(const void *arg, bool 
write_only)
int i;
 
pr_cont("%02ld:%02d:%02d.%08ld index=%d, type=%s, "
-   "flags=0x%08x, field=%s, sequence=%d, memory=%s",
+   "request %u, flags=0x%08x, field=%s, sequence=%d, memory=%s",
p->timestamp.tv_sec / 3600,
(int)(p->timestamp.tv_sec / 60) % 60,
(int)(p->timestamp.tv_sec % 60),
(long)p->timestamp.tv_usec,
p->index,
-   prt_names(p->type, v4l2_type_names),
+   prt_names(p->type, v4l2_type_names), p->request,
p->flags, prt_names(p->field, v4l2_field_names),
p->sequence, prt_names(p->memory, v4l2_memory_names));
 
diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 91f5521..0721258 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -199,7 +199,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->request = vbuf->request;
b->reserved = 0;
 
if (q->is_multiplanar) {
@@ -317,6 +317,7 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
}
vb->timestamp = 0;
vbuf->sequence = 0;
+   vbuf->request = b->request;
 
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
if (b->memory == VB2_MEMORY_USERPTR) {
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index 3cc836f..b1ee91c 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -30,6 +30,7 @@
  * @field: enum v4l2_field; field order of the image in the buffer
  * @timecode:  frame timecode
  * @sequence:  sequence count of this frame
+ * @request:   request used by the buffer
  * Should contain enough information to be able to cover all the fields
  * of struct v4l2_buffer at videodev2.h
  */
@@ -40,6 +41,7 @@ struct vb2_v4l2_buffer {
__u32   field;
struct v4l2_timecodetimecode;
__u32

[RFC 15/22] media: Make events on request completion optional, disabled by default

[Sakari Ailus]

Add flags to requests. The first defined flag, MEDIA_REQ_FL_COMPLETE_EVENT
is used to tell whether to queue an event on request completion. Unless
the flag is set, no event is generated when a request completes.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 26 +-
 include/media/media-device.h |  2 ++
 include/uapi/linux/media.h   | 16 +---
 3 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 357c3cb..0b1ab88 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -284,7 +284,8 @@ static void media_device_request_delete(struct media_device 
*mdev,
 void media_device_request_complete(struct media_device *mdev,
   struct media_device_request *req)
 {
-   media_device_request_queue_event(mdev, req);
+   if (req->flags & MEDIA_REQ_FL_COMPLETE_EVENT)
+   media_device_request_queue_event(mdev, req);
 
media_device_request_delete(mdev, req);
 }
@@ -292,8 +293,8 @@ EXPORT_SYMBOL_GPL(media_device_request_complete);
 
 static int media_device_request_queue_apply(
struct media_device *mdev, struct media_device_request *req,
-   int (*fn)(struct media_device *mdev,
- struct media_device_request *req))
+   u32 req_flags, int (*fn)(struct media_device *mdev,
+struct media_device_request *req))
 {
unsigned long flags;
int rval = 0;
@@ -302,10 +303,12 @@ static int media_device_request_queue_apply(
return -ENOSYS;
 
spin_lock_irqsave(>req_lock, flags);
-   if (req->state != MEDIA_DEVICE_REQUEST_STATE_IDLE)
+   if (req->state != MEDIA_DEVICE_REQUEST_STATE_IDLE) {
rval = -EINVAL;
-   else
+   } else {
req->state = MEDIA_DEVICE_REQUEST_STATE_QUEUED;
+   req->flags = req_flags;
+   }
spin_unlock_irqrestore(>req_lock, flags);
 
if (rval)
@@ -358,12 +361,12 @@ static long media_device_request_cmd(struct media_device 
*mdev,
break;
 
case MEDIA_REQ_CMD_APPLY:
-   ret = media_device_request_queue_apply(mdev, req,
+   ret = media_device_request_queue_apply(mdev, req, cmd->flags,
   mdev->ops->req_apply);
break;
 
case MEDIA_REQ_CMD_QUEUE:
-   ret = media_device_request_queue_apply(mdev, req,
+   ret = media_device_request_queue_apply(mdev, req, cmd->flags,
   mdev->ops->req_queue);
break;
 
@@ -930,13 +933,18 @@ static long __media_device_ioctl(
return ret;
 }
 
+static const unsigned short media_request_cmd_sizes[] = {
+   sizeof(struct media_request_cmd_0),
+   0
+};
+
 static const struct media_ioctl_info ioctl_info[] = {
MEDIA_IOC(DEVICE_INFO, media_device_get_info, MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities, 
MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
MEDIA_IOC_FL_GRAPH_MUTEX),
-   MEDIA_IOC(REQUEST_CMD, media_device_request_cmd, 0),
+   MEDIA_IOC_SZ(REQUEST_CMD, media_device_request_cmd, 0, 
media_request_cmd_sizes),
MEDIA_IOC(DQEVENT, media_device_dqevent, 0),
 };
 
@@ -985,7 +993,7 @@ static const struct media_ioctl_info compat_ioctl_info[] = {
MEDIA_IOC_ARG(ENUM_LINKS32, media_device_enum_links, 
MEDIA_IOC_FL_GRAPH_MUTEX, from_user_enum_links32, copy_arg_to_user_nop),
MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
MEDIA_IOC_FL_GRAPH_MUTEX),
-   MEDIA_IOC(REQUEST_CMD, media_device_request_cmd, 0),
+   MEDIA_IOC_SZ(REQUEST_CMD, media_device_request_cmd, 0, 
media_request_cmd_sizes),
MEDIA_IOC(DQEVENT, media_device_dqevent, 0),
 };
 
diff --git a/include/media/media-device.h b/include/media/media-device.h
index e62ad13..fc91d2d 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -291,6 +291,7 @@ struct media_kevent {
  * @state: The state of the request, MEDIA_DEVICE_REQUEST_STATE_*,
  *access to state serialised by mdev->req_lock
  * @data: Per-entity data list
+ * @flags: Request specific flags, MEDIA_REQ_FL_*
  */
 struct media_device_request {
u32 id;
@@ -302,6 +303,7 @@ struct media_device_request {
struct list_head fh_list;
enum media_device_request_state state;
struct list_head data;
+   u32 flags;
 };
 
 /**
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index f6e1efe..4fab54d 100644

[RFC 16/22] media: Add poll support

[Sakari Ailus]

Implement poll for events. POLLPRI is used to notify users on incoming
events.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 0b1ab88..2a9bf80 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -956,6 +956,32 @@ static long media_device_ioctl(struct file *filp, unsigned 
int cmd,
ioctl_info, ARRAY_SIZE(ioctl_info));
 }
 
+unsigned int media_device_poll(struct file *filp, struct poll_table_struct 
*wait)
+{
+   struct media_device_fh *fh = media_device_fh(filp);
+   unsigned int poll_events = poll_requested_events(wait);
+   int ret = 0;
+
+   if (poll_events & (POLLIN | POLLOUT))
+   return POLLERR;
+
+   if (poll_events & POLLPRI) {
+   unsigned long flags;
+   bool empty;
+
+   spin_lock_irqsave(>kevents.lock, flags);
+   empty = list_empty(>kevents.head);
+   spin_unlock_irqrestore(>kevents.lock, flags);
+
+   if (empty)
+   poll_wait(filp, >kevents.wait, wait);
+   else
+   ret |= POLLPRI;
+   }
+
+   return ret;
+}
+
 #ifdef CONFIG_COMPAT
 
 struct media_links_enum32 {
@@ -1010,6 +1036,7 @@ static const struct media_file_operations 
media_device_fops = {
.owner = THIS_MODULE,
.open = media_device_open,
.ioctl = media_device_ioctl,
+   .poll = media_device_poll,
 #ifdef CONFIG_COMPAT
.compat_ioctl = media_device_compat_ioctl,
 #endif /* CONFIG_COMPAT */
-- 
1.9.1

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

[RFC 19/22] DocBook: media: Document the subdev selection API

[Sakari Ailus]

From: Laurent Pinchart 

Now that the subdev crop API is considered obsolete, the selection API
that replaces it deserves a full documentation instead of referring to
the crop API documentation.

Signed-off-by: Laurent Pinchart 
---
 .../media/v4l/vidioc-subdev-g-selection.xml| 37 ++
 1 file changed, 37 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml 
b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
index 8346b2e..faac955 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
@@ -63,6 +63,43 @@
 more information on how each selection target affects the image
 processing pipeline inside the subdevice.
 
+To retrieve a current selection rectangle applications set the
+pad field of a  to the
+desired pad number as reported by the media API, the
+which field to
+V4L2_SUBDEV_FORMAT_ACTIVE and the
+target to the target selection rectangle. They
+then call the VIDIOC_SUBDEV_G_SELECTION ioctl with a
+pointer to this structure. The driver fills the members of the
+r field or returns  if the input
+arguments are invalid, or if selection is not supported on the given pad.
+
+
+To change a current selection rectangle applications set the
+pad, which and
+target fields and all members of the
+r field. They then call the
+VIDIOC_SUBDEV_S_SELECTION ioctl with a pointer to this
+structure. The driver verifies the requested selection rectangle, adjusts 
it
+based on the hardware capabilities and configures the device. Upon return
+the  contains the current selection rectangle as
+would be returned by a VIDIOC_SUBDEV_G_SELECTION call.
+
+
+Applications can query the device capabilities by setting the
+which to
+V4L2_SUBDEV_FORMAT_TRY. When set, 'try' selection
+rectangles are not applied to the device by the driver, but are mangled
+exactly as active selection rectangles and stored in the sub-device file
+handle. Two applications querying the same sub-device would thus not
+interfere with each other.
+
+Drivers must not return an error solely because the requested
+selection rectangle doesn't match the device capabilities. They must 
instead
+modify the rectangle to match what the hardware can provide. The modified
+selection rectangle should be as close as possible to the original request.
+
+
 
   Types of selection targets
 
-- 
1.9.1

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

[RFC 08/22] videodev2.h: Add request field to v4l2_pix_format_mplane

[Sakari Ailus]

From: Laurent Pinchart 

Let userspace specify a request ID when getting or setting formats. The
support is limited to the multi-planar API at the moment, extending it
to the single-planar API is possible if needed.

>From a userspace point of view the API change is also minimized and
doesn't require any new ioctl.

Signed-off-by: Laurent Pinchart 
---
 include/uapi/linux/videodev2.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index ac28299..6260d0e 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1972,6 +1972,7 @@ struct v4l2_plane_pix_format {
  * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
  * @quantization:  enum v4l2_quantization, colorspace quantization
  * @xfer_func: enum v4l2_xfer_func, colorspace transfer function
+ * @request:   request ID
  */
 struct v4l2_pix_format_mplane {
__u32   width;
@@ -1986,7 +1987,8 @@ struct v4l2_pix_format_mplane {
__u8ycbcr_enc;
__u8quantization;
__u8xfer_func;
-   __u8reserved[7];
+   __u8reserved[3];
+   __u32   request;
 } __attribute__ ((packed));
 
 /**
-- 
1.9.1

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

[RFC 22/22] DocBook: media: Document request flags

[Sakari Ailus]

Signed-off-by: Sakari Ailus 
---
 .../DocBook/media/v4l/media-ioc-request-cmd.xml| 24 ++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml 
b/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml
index 4f4acea..14c0068 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml
@@ -132,6 +132,13 @@
MEDIA_REQ_CMD_ALLOC and by the application
for all other commands.
  
+ 
+   __u32
+   flags
+   Flags related to a request. See  for the list of
+   flags.
+ 

   
 
@@ -161,6 +168,23 @@

   
 
+
+
+  Media request flags
+  
+
+
+   
+ 
+   MEDIA_REQ_FL_COMPLETE_EVENT
+   Queue and event to the file handle on request
+   completion. This flag is relevant for
+   MEDIA_REQ_CMD_APPLY and
+   MEDIA_REQ_CMD_QUEUE commands.
+ 
+   
+  
+
   
 
   
-- 
1.9.1

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

[RFC 05/22] media: Add media_device_request_complete() to mark requests complete

[Sakari Ailus]

Once the request has been queued and later on completed, a driver will
mark the request complete by calling media_device_request_complete().

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 7 +++
 include/media/media-device.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 5b7bfcf..cbd3b8b 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -158,6 +158,13 @@ static void media_device_request_delete(struct 
media_device *mdev,
media_device_request_put(req);
 }
 
+void media_device_request_complete(struct media_device *mdev,
+  struct media_device_request *req)
+{
+   media_device_request_delete(mdev, req);
+}
+EXPORT_SYMBOL_GPL(media_device_request_complete);
+
 static int media_device_request_queue_apply(
struct media_device *mdev, struct media_device_request *req,
int (*fn)(struct media_device *mdev,
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 3167c52..d86fb8a 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -269,6 +269,7 @@ enum media_device_request_state {
MEDIA_DEVICE_REQUEST_STATE_IDLE,
MEDIA_DEVICE_REQUEST_STATE_QUEUED,
MEDIA_DEVICE_REQUEST_STATE_DELETED,
+   MEDIA_DEVICE_REQUEST_STATE_COMPLETE,
 };
 
 /**
@@ -764,5 +765,7 @@ struct media_device_request *
 media_device_request_find(struct media_device *mdev, u16 reqid);
 void media_device_request_get(struct media_device_request *req);
 void media_device_request_put(struct media_device_request *req);
+void media_device_request_complete(struct media_device *mdev,
+  struct media_device_request *req);
 
 #endif
-- 
1.9.1

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

[RFC 21/22] DocBook: media: Document media events (MEDIA_IOC_DQEVENT IOCTL)

[Sakari Ailus]

Add DocBook documentation for media events.

Signed-off-by: Sakari Ailus 
---
 .../DocBook/media/v4l/media-controller.xml |   1 +
 .../DocBook/media/v4l/media-ioc-dqevent.xml| 155 +
 2 files changed, 156 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/media-ioc-dqevent.xml

diff --git a/Documentation/DocBook/media/v4l/media-controller.xml 
b/Documentation/DocBook/media/v4l/media-controller.xml
index 2a5a5d0..aa78fcb 100644
--- a/Documentation/DocBook/media/v4l/media-controller.xml
+++ b/Documentation/DocBook/media/v4l/media-controller.xml
@@ -98,6 +98,7 @@
   
   
   
+  
   
   
   
diff --git a/Documentation/DocBook/media/v4l/media-ioc-dqevent.xml 
b/Documentation/DocBook/media/v4l/media-ioc-dqevent.xml
new file mode 100644
index 000..7d58491
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/media-ioc-dqevent.xml
@@ -0,0 +1,155 @@
+
+  
+ioctl MEDIA_IOC_DQEVENT
+
+  
+
+  
+MEDIA_IOC_DQEVENT
+Dequeue a media event
+  
+
+  
+
+  
+   int ioctl
+   int fd
+   int request
+   struct media_event *argp
+  
+
+  
+
+  
+Arguments
+
+
+  
+   fd
+   
+ File descriptor returned by
+ open().
+   
+  
+  
+   request
+   
+ MEDIA_IOC_DQEVENT
+   
+  
+  
+   argp
+   
+ 
+   
+  
+
+  
+
+  
+Description
+
+Dequeue a media event from a media device. Both non-blocking
+and blocking access is supported. poll(2)
+IOCTL may be used with poll event type
+POLLPRI to learn about dequeueable
+events.
+
+Media events are specific to file handle: they are delivered
+to and dequeued from each file handle separately.
+
+
+  struct media_event
+  
+
+   
+ 
+   __u32
+   type
+   
+   Type of the media event. Set by the driver. See
+for available media
+   event types.
+ 
+ 
+   __u32
+   sequence
+   
+   Event sequence number. The sequence number is file
+   handle specific and counts from zero until it wraps around
+   after reaching 32^2-1.
+ 
+ 
+   union
+   
+   
+   Anonymous union for event type specific data.
+ 
+ 
+   
+   struct _event_request_complete;
+   req_complete
+   Event data for
+   MEDIA_EVENT_REQUEST_COMPLETE event.
+   
+ 
+   
+  
+
+
+
+  Media event types
+  
+   
+   
+ 
+   MEDIA_EVENT_REQUEST_COMPLETE
+   1
+   A request has been completed. This media event type
+   has  associated with it. The
+   event is only queued to the file handle from which the
+   event was queued.
+   
+ 
+   
+  
+
+
+
+  struct 
media_event_request_complete
+  
+
+   
+ 
+   __u32
+   id
+   Request ID. The identifier of the request which has
+   been completed.
+ 
+ 
+   __s32
+   status
+   Negative error code of the completed request. See errno(2)
+   for possible error codes.
+ 
+   
+  
+
+
+  
+
+  
+
+
+
+  
+   ENOENT
+   
+ No events are available for dequeueing. This is returned
+ only when non-blocking I/O is used.
+ 
+   
+  
+
+  
+
-- 
1.9.1

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

[RFC 06/22] media: Add per-entity request data support

[Sakari Ailus]

From: Laurent Pinchart 

Allow subsystems to associate data with entities in each request. This
will be used by the V4L2 subdev core to store pad formats in requests.

Signed-off-by: Laurent Pinchart 

---

Changes since v0:

- Dereference requests without holding the list lock
- Remove requests from global list when closing the fh
---
 drivers/media/media-device.c | 82 ++--
 include/media/media-device.h |  7 
 include/media/media-entity.h | 12 +++
 3 files changed, 99 insertions(+), 2 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index cbd3b8b..10b9a4a 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -94,10 +94,16 @@ EXPORT_SYMBOL_GPL(media_device_request_get);
 
 static void media_device_request_release(struct kref *kref)
 {
+   struct media_entity_request_data *data, *next;
struct media_device_request *req =
container_of(kref, struct media_device_request, kref);
struct media_device *mdev = req->mdev;
 
+   list_for_each_entry_safe(data, next, >data, list) {
+   list_del(>list);
+   data->release(data);
+   }
+
ida_simple_remove(>req_ids, req->id);
 
mdev->ops->req_free(mdev, req);
@@ -109,6 +115,70 @@ void media_device_request_put(struct media_device_request 
*req)
 }
 EXPORT_SYMBOL_GPL(media_device_request_put);
 
+/**
+ * media_device_request_get_entity_data - Get per-entity data
+ * @req: The request
+ * @entity: The entity
+ *
+ * Search and return per-entity data (as a struct media_entity_request_data
+ * instance) associated with the given entity for the request, as previously
+ * registered by a call to media_device_request_set_entity_data().
+ *
+ * The caller is expected to hold a reference to the request. Per-entity data 
is
+ * not reference counted, the returned pointer will be valid only as long as 
the
+ * reference to the request is held.
+ *
+ * Return the data instance pointer or NULL if no data could be found.
+ */
+struct media_entity_request_data *
+media_device_request_get_entity_data(struct media_device_request *req,
+struct media_entity *entity)
+{
+   struct media_entity_request_data *data;
+   unsigned long flags;
+
+   spin_lock_irqsave(>mdev->req_lock, flags);
+
+   list_for_each_entry(data, >data, list) {
+   if (data->entity == entity)
+   goto done;
+   }
+
+   data = NULL;
+
+done:
+   spin_unlock_irqrestore(>mdev->req_lock, flags);
+   return data;
+}
+EXPORT_SYMBOL_GPL(media_device_request_get_entity_data);
+
+/**
+ * media_device_request_set_entity_data - Set per-entity data
+ * @req: The request
+ * @entity: The entity
+ * @data: The data
+ *
+ * Record the given per-entity data as being associated with the entity for the
+ * request.
+ *
+ * Only one per-entity data instance can be associated with a request. The
+ * caller is responsible for enforcing this requirement.
+ *
+ * Ownership of the per-entity data is transferred to the request when calling
+ * this function. The data will be freed automatically when the last reference
+ * to the request is released.
+ */
+void media_device_request_set_entity_data(struct media_device_request *req,
+   struct media_entity *entity, struct media_entity_request_data *data)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>mdev->req_lock, flags);
+   list_add_tail(>list, >data);
+   spin_unlock_irqrestore(>mdev->req_lock, flags);
+}
+EXPORT_SYMBOL_GPL(media_device_request_set_entity_data);
+
 static int media_device_request_alloc(struct media_device *mdev,
  struct media_device_fh *fh,
  struct media_request_cmd *cmd)
@@ -130,6 +200,7 @@ static int media_device_request_alloc(struct media_device 
*mdev,
req->mdev = mdev;
req->id = id;
kref_init(>kref);
+   INIT_LIST_HEAD(>data);
 
spin_lock_irqsave(>req_lock, flags);
list_add_tail(>list, >requests);
@@ -153,6 +224,7 @@ static void media_device_request_delete(struct media_device 
*mdev,
 
spin_lock_irqsave(>req_lock, flags);
list_del(>list);
+   list_del(>fh_list);
spin_unlock_irqrestore(>req_lock, flags);
 
media_device_request_put(req);
@@ -284,12 +356,18 @@ static int media_device_close(struct file *filp)
 {
struct media_device_fh *fh = media_device_fh(filp);
struct media_device *mdev = to_media_device(fh->fh.devnode);
-   struct media_device_request *req, *next;
 
spin_lock_irq(>req_lock);
-   list_for_each_entry_safe(req, next, >requests, fh_list) {
+   while (!list_empty(>requests)) {
+   struct media_device_request *req;
+
+   req = list_first_entry(>requests, 

[RFC 12/22] vb2: Add allow_requests flag

[Sakari Ailus]

From: Hans Verkuil 

The driver has to set allow_requests explicitly in order to allow
queuing or preparing buffers for a specific request ID.

Signed-off-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 5 +
 include/media/videobuf2-core.h   | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 0721258..bb135fc 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -174,6 +174,11 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, 
struct v4l2_buffer *b,
return -EINVAL;
}
 
+   if (!q->allow_requests && b->request) {
+   dprintk(1, "%s: unsupported request ID\n", opname);
+   return -EINVAL;
+   }
+
return __verify_planes_array(q->bufs[b->index], b);
 }
 
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 8a0f55b..41dab63 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -400,6 +400,7 @@ struct vb2_buf_ops {
  * @fileio_read_once:  report EOF after reading the first buffer
  * @fileio_write_immediately:  queue buffer after each write() call
  * @allow_zero_bytesused:  allow bytesused == 0 to be passed to the driver
+ * @allow_requests:allow request != 0 to be passed to the driver
  * @lock:  pointer to a mutex that protects the vb2_queue struct. The
  * driver can set this to a mutex to let the v4l2 core serialize
  * the queuing ioctls. If the driver wants to handle locking
@@ -463,6 +464,7 @@ struct vb2_queue {
unsignedfileio_read_once:1;
unsignedfileio_write_immediately:1;
unsignedallow_zero_bytesused:1;
+   unsignedallow_requests:1;
 
struct mutex*lock;
void*owner;
-- 
1.9.1

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

[RFC 09/22] v4l2-subdev.h: Add request field to format and selection structures

[Sakari Ailus]

From: Laurent Pinchart 

Let userspace specify a request ID when getting or setting formats or
selection rectangles.

>From a userspace point of view the API change is minimized and doesn't
require any new ioctl.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Sakari Ailus 
---
 include/uapi/linux/v4l2-subdev.h | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/v4l2-subdev.h b/include/uapi/linux/v4l2-subdev.h
index dbce2b554..dbb7c1d 100644
--- a/include/uapi/linux/v4l2-subdev.h
+++ b/include/uapi/linux/v4l2-subdev.h
@@ -32,10 +32,12 @@
  * enum v4l2_subdev_format_whence - Media bus format type
  * @V4L2_SUBDEV_FORMAT_TRY: try format, for negotiation only
  * @V4L2_SUBDEV_FORMAT_ACTIVE: active format, applied to the device
+ * @V4L2_SUBDEV_FORMAT_REQUEST: format stored in request
  */
 enum v4l2_subdev_format_whence {
V4L2_SUBDEV_FORMAT_TRY = 0,
V4L2_SUBDEV_FORMAT_ACTIVE = 1,
+   V4L2_SUBDEV_FORMAT_REQUEST = 2,
 };
 
 /**
@@ -43,12 +45,15 @@ enum v4l2_subdev_format_whence {
  * @which: format type (from enum v4l2_subdev_format_whence)
  * @pad: pad number, as reported by the media API
  * @format: media bus format (format code and frame size)
+ * @request: request ID (when which is set to V4L2_SUBDEV_FORMAT_REQUEST)
+ * @reserved: for future use, set to zero for now
  */
 struct v4l2_subdev_format {
__u32 which;
__u32 pad;
struct v4l2_mbus_framefmt format;
-   __u32 reserved[8];
+   __u32 request;
+   __u32 reserved[7];
 };
 
 /**
@@ -139,6 +144,7 @@ struct v4l2_subdev_frame_interval_enum {
  * defined in v4l2-common.h; V4L2_SEL_TGT_* .
  * @flags: constraint flags, defined in v4l2-common.h; V4L2_SEL_FLAG_*.
  * @r: coordinates of the selection window
+ * @request: request ID (when which is set to V4L2_SUBDEV_FORMAT_REQUEST)
  * @reserved: for future use, set to zero for now
  *
  * Hardware may use multiple helper windows to process a video stream.
@@ -151,7 +157,8 @@ struct v4l2_subdev_selection {
__u32 target;
__u32 flags;
struct v4l2_rect r;
-   __u32 reserved[8];
+   __u32 request;
+   __u32 reserved[7];
 };
 
 /* Backwards compatibility define --- to be removed */
-- 
1.9.1

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

[RFC 18/22] DocBook: media: Document the V4L2 request API

[Sakari Ailus]

From: Laurent Pinchart 

The V4L2 request API consists in extensions to existing V4L2 ioctls.
Document it.

Signed-off-by: Laurent Pinchart 
---
 Documentation/DocBook/media/v4l/common.xml |  2 +
 Documentation/DocBook/media/v4l/io.xml |  9 ++-
 Documentation/DocBook/media/v4l/request-api.xml| 90 ++
 .../DocBook/media/v4l/vidioc-prepare-buf.xml   |  9 +++
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|  6 ++
 5 files changed, 113 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/request-api.xml

diff --git a/Documentation/DocBook/media/v4l/common.xml 
b/Documentation/DocBook/media/v4l/common.xml
index 8b5e014..30cb0f2 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -1073,6 +1073,8 @@ dheight = format.fmt.pix.height;
 
   
 
+  
+
   
 Streaming Parameters
 
diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index e09025d..5695bc8 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -833,10 +833,13 @@ is the file descriptor associated with a DMABUF 
buffer.
  
  
__u32
-   reserved2
+   request

-   A place holder for future extensions. Drivers and 
applications
-must set this to 0.
+   ID of the request to associate the buffer to. Set by the
+   application for  and . Set to zero
+   by the application and the driver in all other cases. See
+for more information.
+   
  
  
__u32
diff --git a/Documentation/DocBook/media/v4l/request-api.xml 
b/Documentation/DocBook/media/v4l/request-api.xml
new file mode 100644
index 000..992f25a
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/request-api.xml
@@ -0,0 +1,90 @@
+
+
+  Experimental API for request handling
+
+  
+Experimental
+This is an experimental
+interface and may change in the future.
+  
+
+  
+Introduction
+
+It is often useful to apply certain settings when a buffer is about to be
+filled by the DMA capture of a video capture device, ensuring that those
+settings are applied in time for them to be used with that buffer.
+
+One of the prime use-cases of this is Android's CameraHAL v3 which
+requires per-frame configuration support. Other use-cases are possible as well:
+changing codec settings (bit rate, etc.) starting with a specific buffer,
+preparing a configuration to be applied at a certain time, etc.
+
+The request API is the way V4L2 solves this problem.
+
+  
+
+  
+Request Objects
+
+At the core of the request API is the request object. Applications store
+configuration parameters such as V4L2 controls, formats and selection 
rectangles
+in request objects and then associate those request objects for processing with
+specific buffers.
+
+Request objects are created and managed through the media controller
+device node. Details on request object management can be found in the
+media controller request API
+documentation and are outside the scope of the V4L2 request API. Once a request
+object is created it can be referenced by its ID in the V4L2 ioctls that 
support
+requests.
+
+Applications can store controls, subdev formats and subdev selection
+rectangles in requests. To do so they use the usual V4L2 ioctls
+,  and  
with
+the request field of the associated structure set to
+the request ID (for subdev formats and selection rectangles the
+which field need to be additionally set to
+V4L2_SUBDEV_FORMAT_REQUEST). Controls, formats and
+selection rectangles will be processed as usual but will be stored in the
+request instead of applied to the device.
+
+
+Parameters stored in requests can further be retrieved by calling the
+,  or 
+ioctls similarly with the request field of the
+associated structure set to the request ID.
+
+
+  
+
+  
+Applying Requests
+
+The simplest way to apply a request is to associated it with a buffer.
+This is done by setting the request field of the
+ to the request ID when queuing the buffer with the 
+ioctl.
+
+
+Once a buffer is queued with a non-zero request ID the driver will apply
+all parameters stored in the request atomically. The parameters are guaranteed
+to come in effect before the buffer starts being transferred and after all
+previous buffers have been complete.
+
+
+For devices with multiple video nodes requests might need to be applied
+synchronously with several buffers. This is achieved by first preparing (but 
not
+queuing) all the related buffers using the  ioctl with the
+request field of the  set to the 
request
+ID. Once this is done the request is queued using the
+MEDIA_REQ_CMD_QUEUE command of the 
+ioctl on the media controller device node. The driver will then queue all
+buffers prepared for the 

[RFC 03/22] media: Prevent queueing queued requests

[Sakari Ailus]

Verify that the request state is IDLE before queueing it. Also mark
requests queued when they're queued, and return the request to IDLE if
queueing it failed.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 43 +++
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 4fc1eb1..481e8e4 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -158,6 +158,37 @@ static void media_device_request_delete(struct 
media_device *mdev,
media_device_request_put(req);
 }
 
+static int media_device_request_queue_apply(
+   struct media_device *mdev, struct media_device_request *req,
+   int (*fn)(struct media_device *mdev,
+ struct media_device_request *req))
+{
+   unsigned long flags;
+   int rval = 0;
+
+   if (!fn)
+   return -ENOSYS;
+
+   spin_lock_irqsave(>req_lock, flags);
+   if (req->state != MEDIA_DEVICE_REQUEST_STATE_IDLE)
+   rval = -EINVAL;
+   else
+   req->state = MEDIA_DEVICE_REQUEST_STATE_QUEUED;
+   spin_unlock_irqrestore(>req_lock, flags);
+
+   if (rval)
+   return rval;
+
+   rval = fn(mdev, req);
+   if (rval) {
+   spin_lock_irqsave(>req_lock, flags);
+   req->state = MEDIA_DEVICE_REQUEST_STATE_IDLE;
+   spin_unlock_irqrestore(>req_lock, flags);
+   }
+
+   return rval;
+}
+
 static long media_device_request_cmd(struct media_device *mdev,
 struct file *filp,
 struct media_request_cmd *cmd)
@@ -186,17 +217,13 @@ static long media_device_request_cmd(struct media_device 
*mdev,
break;
 
case MEDIA_REQ_CMD_APPLY:
-   if (!mdev->ops->req_apply)
-   return -ENOSYS;
-
-   ret = mdev->ops->req_apply(mdev, req);
+   ret = media_device_request_queue_apply(mdev, req,
+  mdev->ops->req_apply);
break;
 
case MEDIA_REQ_CMD_QUEUE:
-   if (!mdev->ops->req_queue)
-   return -ENOSYS;
-
-   ret = mdev->ops->req_queue(mdev, req);
+   ret = media_device_request_queue_apply(mdev, req,
+  mdev->ops->req_queue);
break;
 
default:
-- 
1.9.1

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

[RFC 20/22] DocBook: media: Document the V4L2 subdev request API

[Sakari Ailus]

From: Laurent Pinchart 

The V4L2 subdev request API consists in extensions to existing V4L2
subdev ioctls. Document it.

Signed-off-by: Laurent Pinchart 
---
 .../DocBook/media/v4l/vidioc-subdev-g-fmt.xml  | 27 +++---
 .../media/v4l/vidioc-subdev-g-selection.xml| 24 +++
 2 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml 
b/Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml
index 781089c..5cf6d89 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml
@@ -91,6 +91,13 @@
 low-pass noise filter might crop pixels at the frame boundaries, modifying
 its output frame size.
 
+Applications can get and set formats stored in a request by setting
+the which field to
+V4L2_SUBDEV_FORMAT_REQUEST and the
+request to the request ID. See
+ for more information about the request
+API.
+
 Drivers must not return an error solely because the requested format
 doesn't match the device capabilities. They must instead modify the format
 to match what the hardware can provide. The modified format should be as
@@ -119,7 +126,15 @@
  
  
__u32
-   reserved[8]
+   request
+   Request ID, only valid when the 
which
+   field is set to V4L2_SUBDEV_FORMAT_REQUEST.
+   Applications and drivers must set the field to zero in all other
+   cases.
+ 
+ 
+   __u32
+   reserved[7]
Reserved for future extensions. Applications and drivers must
set the array to zero.
  
@@ -142,6 +157,11 @@
1
Active formats, applied to the hardware.
  
+ 
+   V4L2_SUBDEV_FORMAT_REQUEST
+   2
+   Request formats, used with the requests API.
+ 

   
 
@@ -165,8 +185,9 @@
EINVAL

  The  pad
- references a non-existing pad, or the which
- field references a non-existing format.
+ references a non-existing pad, the which
+ field references a non-existing format or the request ID references
+ a nonexistant request.

   
 
diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml 
b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
index faac955..c0fbfbe 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
@@ -94,6 +94,13 @@
 handle. Two applications querying the same sub-device would thus not
 interfere with each other.
 
+Applications can get and set selection rectangles stored in a request
+by setting the which field to
+V4L2_SUBDEV_FORMAT_REQUEST and the
+request to the request ID. See
+ for more information about the request
+API.
+
 Drivers must not return an error solely because the requested
 selection rectangle doesn't match the device capabilities. They must 
instead
 modify the rectangle to match what the hardware can provide. The modified
@@ -128,7 +135,7 @@
  
__u32
which
-   Active or try selection, from
+   Selection to be modified, from
.
  
  
@@ -155,7 +162,15 @@
  
  
__u32
-   reserved[8]
+   request
+   Request ID, only valid when the 
which
+   field is set to V4L2_SUBDEV_FORMAT_REQUEST.
+   Applications and drivers must set the field to zero in all other
+   cases.
+ 
+ 
+   __u32
+   reserved[7]
Reserved for future extensions. Applications and drivers must
set the array to zero.
  
@@ -187,8 +202,9 @@
  The 
  pad references a non-existing
  pad, the which field references a
- non-existing format, or the selection target is not
- supported on the given subdev pad.
+ non-existing format, the selection target is not supported on
+ the given subdev pad or the request ID references a nonexistant
+ request.

   
 
-- 
1.9.1

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

[RFC 17/22] DocBook: media: Document the media request API

[Sakari Ailus]

From: Laurent Pinchart 

The media request API is made of a new ioctl to implement request
management. Document it.

Signed-off-by: Laurent Pinchart 

Strip off the reserved fields.

Signed-off-by: Sakari Ailus 
---
 .../DocBook/media/v4l/media-controller.xml |   1 +
 .../DocBook/media/v4l/media-ioc-request-cmd.xml| 188 +
 2 files changed, 189 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml

diff --git a/Documentation/DocBook/media/v4l/media-controller.xml 
b/Documentation/DocBook/media/v4l/media-controller.xml
index 5f2fc07..2a5a5d0 100644
--- a/Documentation/DocBook/media/v4l/media-controller.xml
+++ b/Documentation/DocBook/media/v4l/media-controller.xml
@@ -101,5 +101,6 @@
   
   
   
+  
   
 
diff --git a/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml 
b/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml
new file mode 100644
index 000..4f4acea
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml
@@ -0,0 +1,188 @@
+
+  
+ioctl MEDIA_IOC_REQUEST_CMD
+
+  
+
+  
+MEDIA_IOC_REQUEST_CMD
+Manage media device requests
+  
+
+  
+
+  
+   int ioctl
+   int fd
+   int request
+   struct media_request_cmd 
*argp
+  
+
+  
+
+  
+Arguments
+
+
+  
+   fd
+   
+ File descriptor returned by
+ open().
+   
+  
+  
+   request
+   
+ MEDIA_IOC_REQUEST_CMD
+   
+  
+  
+   argp
+   
+ 
+   
+  
+
+  
+
+  
+Description
+
+The MEDIA_IOC_REQUEST_CMD ioctl allow applications to manage media
+device requests. A request is an object that can group media device
+configuration parameters, including subsystem-specific parameters, in order
+to apply all the parameters atomically. Applications are responsible for
+allocating and deleting requests, filling them with configuration 
parameters
+and (synchronously) applying or (asynchronously) queuing them.
+
+Request operations are performed by calling the MEDIA_IOC_REQUEST_CMD
+ioctl with a pointer to a  with the
+cmd set to the appropriate command.
+ lists the commands supported by
+the ioctl.
+
+The  request field
+contains the ID of the request on which the command operates. For the
+MEDIA_REQ_CMD_ALLOC command the field is set to zero
+by applications and filled by the driver. For all other commands the field
+is set by applications and left untouched by the driver.
+
+To allocate a new request applications use the
+MEDIA_REQ_CMD_ALLOC. The driver will allocate a new
+request and return its ID in the request field.
+
+
+Requests are reference-counted. A newly allocate request is 
referenced
+by the media device file handled on which it has been created, and can be
+later referenced by subsystem-specific operations using the request ID.
+Requests will thus be automatically deleted when they're not longer used
+after the media device file handle is closed.
+
+If a request isn't needed applications can delete it using the
+MEDIA_REQ_CMD_DELETE command. The driver will drop the
+reference to the request stored in the media device file handle. The 
request
+will not be usable through the MEDIA_IOC_REQUEST_CMD ioctl anymore, but 
will
+only be deleted when the last reference is released. If no other reference
+exists when the delete command is invoked the request will be deleted
+immediately.
+
+After creating a request applications should fill it with
+configuration parameters. This is performed through subsystem-specific
+request APIs outside the scope of the media controller API. See the
+appropriate subsystem APIs for more information, including how they 
interact
+with the MEDIA_IOC_REQUEST_CMD ioctl.
+
+Once a request contains all the desired configuration parameters it
+can be applied synchronously or queued asynchronously. To apply a request
+applications use the MEDIA_REQ_CMD_APPLY command. The
+driver will apply all configuration parameters stored in the request to the
+device atomically. The ioctl will return once all parameters have been
+applied, but it should be noted that they might not have fully taken effect
+yet.
+
+To queue a request applications use the
+MEDIA_REQ_CMD_QUEUE command. The driver will queue the
+request for processing and return immediately. The request will then be
+processed and applied after all previously queued requests.
+
+Once a request has been queued applications are not allowed to modify
+its configuration parameters until the request has been fully processed.
+Any attempt to do so will result in the related subsystem API returning
+an error. 

[RFC 11/22] v4l: subdev: Support the request API in format and selection operations

[Sakari Ailus]

From: Laurent Pinchart 

Store the formats and selection rectangles in per-entity request data.
This minimizes changes to drivers by reusing the v4l2_subdev_pad_config
infrastructure.

Signed-off-by: Laurent Pinchart 

Replace three if's for testing the same variable by a switch.

Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/v4l2-subdev.c | 225 +-
 include/media/v4l2-subdev.h   |  11 ++
 2 files changed, 180 insertions(+), 56 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
b/drivers/media/v4l2-core/v4l2-subdev.c
index 9cbd011..461c2ac 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -130,39 +130,182 @@ static int subdev_close(struct file *file)
 }
 
 #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
-static int check_format(struct v4l2_subdev *sd,
-   struct v4l2_subdev_format *format)
+static void subdev_request_data_release(struct media_entity_request_data *data)
 {
-   if (format->which != V4L2_SUBDEV_FORMAT_TRY &&
-   format->which != V4L2_SUBDEV_FORMAT_ACTIVE)
-   return -EINVAL;
+   struct v4l2_subdev_request_data *sddata =
+   to_v4l2_subdev_request_data(data);
 
-   if (format->pad >= sd->entity.num_pads)
-   return -EINVAL;
+   kfree(sddata->pad);
+   kfree(sddata);
+}
 
-   return 0;
+static struct v4l2_subdev_pad_config *
+subdev_request_pad_config(struct v4l2_subdev *sd,
+ struct media_device_request *req)
+{
+   struct media_entity_request_data *data;
+   struct v4l2_subdev_request_data *sddata;
+
+   data = media_device_request_get_entity_data(req, >entity);
+   if (data) {
+   sddata = to_v4l2_subdev_request_data(data);
+   return sddata->pad;
+   }
+
+   sddata = kzalloc(sizeof(*sddata), GFP_KERNEL);
+   if (!sddata)
+   return ERR_PTR(-ENOMEM);
+
+   sddata->data.release = subdev_request_data_release;
+
+   sddata->pad = v4l2_subdev_alloc_pad_config(sd);
+   if (sddata->pad == NULL) {
+   kfree(sddata);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   media_device_request_set_entity_data(req, >entity, >data);
+
+   return sddata->pad;
 }
 
-static int check_crop(struct v4l2_subdev *sd, struct v4l2_subdev_crop *crop)
+static int subdev_prepare_pad_config(struct v4l2_subdev *sd,
+struct v4l2_subdev_fh *fh,
+enum v4l2_subdev_format_whence which,
+unsigned int pad, unsigned int req_id,
+struct media_device_request **_req,
+struct v4l2_subdev_pad_config **_cfg)
 {
-   if (crop->which != V4L2_SUBDEV_FORMAT_TRY &&
-   crop->which != V4L2_SUBDEV_FORMAT_ACTIVE)
+   struct v4l2_subdev_pad_config *cfg;
+   struct media_device_request *req;
+
+   if (pad >= sd->entity.num_pads)
return -EINVAL;
 
-   if (crop->pad >= sd->entity.num_pads)
+   switch (which) {
+   case V4L2_SUBDEV_FORMAT_ACTIVE:
+   *_req = NULL;
+   *_cfg = NULL;
+   return 0;
+   case V4L2_SUBDEV_FORMAT_TRY:
+   *_req = NULL;
+   *_cfg = fh->pad;
+   return 0;
+   case V4L2_SUBDEV_FORMAT_REQUEST:
+   if (!sd->v4l2_dev->mdev)
+   return -EINVAL;
+
+   req = media_device_request_find(sd->v4l2_dev->mdev, req_id);
+   if (!req)
+   return -EINVAL;
+
+   cfg = subdev_request_pad_config(sd, req);
+   if (IS_ERR(cfg)) {
+   media_device_request_put(req);
+   return PTR_ERR(cfg);
+   }
+
+   *_req = req;
+   *_cfg = cfg;
+
+   return 0;
+   default:
return -EINVAL;
+   }
 
-   return 0;
 }
 
-static int check_selection(struct v4l2_subdev *sd,
-  struct v4l2_subdev_selection *sel)
+static int subdev_get_format(struct v4l2_subdev *sd,
+struct v4l2_subdev_fh *fh,
+struct v4l2_subdev_format *format)
+{
+   struct v4l2_subdev_pad_config *cfg;
+   struct media_device_request *req;
+   int ret;
+
+   ret = subdev_prepare_pad_config(sd, fh, format->which, format->pad,
+   format->request, , );
+   if (ret < 0)
+   return ret;
+
+   ret = v4l2_subdev_call(sd, pad, get_fmt, cfg, format);
+
+   if (req)
+   media_device_request_put(req);
+
+   return ret;
+}
+
+static int subdev_set_format(struct v4l2_subdev *sd,
+  

[RFC 01/22] media: Add request API

[Sakari Ailus]

From: Laurent Pinchart 

The request API allows bundling media device parameters with request
objects and applying them atomically, either synchronously or
asynchronously.

Signed-off-by: Laurent Pinchart 

---

Changes since v0:

- Make the request ID 32 bits wide internally

---

- Strip off the reserved fields

- Use __attribute__ ((packed)) for the IOCTL argument struct.

- Manage request ID space using ida_simple

- Fix compat handling for requests

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 194 ++-
 include/media/media-device.h |  41 +
 include/uapi/linux/media.h   |  11 +++
 3 files changed, 243 insertions(+), 3 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 3b9a1bf..4fc1eb1 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -41,6 +41,7 @@
 
 struct media_device_fh {
struct media_devnode_fh fh;
+   struct list_head requests;
 };
 
 static inline struct media_device_fh *media_device_fh(struct file *filp)
@@ -49,6 +50,170 @@ static inline struct media_device_fh 
*media_device_fh(struct file *filp)
 }
 
 /* 
-
+ * Requests
+ */
+
+/**
+ * media_device_request_find - Find a request based from its ID
+ * @mdev: The media device
+ * @reqid: The request ID
+ *
+ * Find and return the request associated with the given ID, or NULL if no such
+ * request exists.
+ *
+ * When the function returns a non-NULL request it increases its reference
+ * count. The caller is responsible for releasing the reference by calling
+ * media_device_request_put() on the request.
+ */
+struct media_device_request *
+media_device_request_find(struct media_device *mdev, u16 reqid)
+{
+   struct media_device_request *req;
+   unsigned long flags;
+   bool found = false;
+
+   spin_lock_irqsave(>req_lock, flags);
+   list_for_each_entry(req, >requests, list) {
+   if (req->id == reqid) {
+   kref_get(>kref);
+   found = true;
+   break;
+   }
+   }
+   spin_unlock_irqrestore(>req_lock, flags);
+
+   return found ? req : NULL;
+}
+EXPORT_SYMBOL_GPL(media_device_request_find);
+
+void media_device_request_get(struct media_device_request *req)
+{
+   kref_get(>kref);
+}
+EXPORT_SYMBOL_GPL(media_device_request_get);
+
+static void media_device_request_release(struct kref *kref)
+{
+   struct media_device_request *req =
+   container_of(kref, struct media_device_request, kref);
+   struct media_device *mdev = req->mdev;
+
+   ida_simple_remove(>req_ids, req->id);
+
+   mdev->ops->req_free(mdev, req);
+}
+
+void media_device_request_put(struct media_device_request *req)
+{
+   kref_put(>kref, media_device_request_release);
+}
+EXPORT_SYMBOL_GPL(media_device_request_put);
+
+static int media_device_request_alloc(struct media_device *mdev,
+ struct media_device_fh *fh,
+ struct media_request_cmd *cmd)
+{
+   struct media_device_request *req;
+   unsigned long flags;
+   int id = ida_simple_get(>req_ids, 1, 0, GFP_KERNEL);
+   int ret;
+
+   if (id < 0)
+   return id;
+
+   req = mdev->ops->req_alloc(mdev);
+   if (!req) {
+   ret = -ENOMEM;
+   goto out_ida_simple_remove;
+   }
+
+   req->mdev = mdev;
+   req->id = id;
+   kref_init(>kref);
+
+   spin_lock_irqsave(>req_lock, flags);
+   list_add_tail(>list, >requests);
+   list_add_tail(>fh_list, >requests);
+   spin_unlock_irqrestore(>req_lock, flags);
+
+   cmd->request = req->id;
+
+   return 0;
+
+out_ida_simple_remove:
+   ida_simple_remove(>req_ids, id);
+
+   return ret;
+}
+
+static void media_device_request_delete(struct media_device *mdev,
+   struct media_device_request *req)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>req_lock, flags);
+   list_del(>list);
+   spin_unlock_irqrestore(>req_lock, flags);
+
+   media_device_request_put(req);
+}
+
+static long media_device_request_cmd(struct media_device *mdev,
+struct file *filp,
+struct media_request_cmd *cmd)
+{
+   struct media_device_fh *fh = media_device_fh(filp);
+   struct media_device_request *req = NULL;
+   int ret;
+
+   if (!mdev->ops || !mdev->ops->req_alloc || !mdev->ops->req_free)
+   return -ENOTTY;
+
+   if (cmd->cmd != MEDIA_REQ_CMD_ALLOC) {
+   req = media_device_request_find(mdev, cmd->request);
+   if (!req)
+   return -EINVAL;
+ 

[RFC 00/22] Media request API

[Sakari Ailus]

Hello all,

Here's a set of patches to implement support for the request API that has
been discussed many, many times over the past few years. Some of the
patches are my own while some have been written by Laurent and Hans.

I've made a few changes to these patches and added more, mainly:

- Implement request state in the framework in order to prevent performing
  invalid actions on requests, e.g. deleting a queued request or queueing
  a request which is already queued.

- Use 32 bits for the request ID. As requests are global, a 16-bit space
  could become a limitation. The IDs are reserved using ida (as in
  linux/idr.h) instead of a counter. This way we can ensure that once the
  counter wraps around, we will continue to allocate unique IDs for new
  requests. 

- Add media events to signal applications on completed events. Only the
  file handle which queued the request is notified. I've chosen this
  instead of a request specific means to dequeue events as there isn't
  really anything to obtain other than the information that the request
  has been completed: there's no data related to it, no buffers as in
  V4L2. Some applications may not be interested in receiving such events
  so the events are optional, specific to the queued request.

- Add poll support to tell the user there are dequeueable events.

My own use case for this is a little bit more limited than for some
others, i.e. I only need to bind video buffers to requests. That is
currently functional with these patches.

My open questions and to-do items I'm aware of:

- Global ID space vs. file handles. Should requests be referred to by
  global IDs or file handles specific to a process? V4L2 uses IDs but V4L2
  devices (other than m2m) can meaningfully be used only by a single
  program (or co-operative programs) at a time whereas the media device
  could conceivably be accessed and used for different purposes by
  multiple programs at the same time as the resources accessible through
  the media device are numerous and often independent of each other. A
  badly behaving application could disturb other applications using the
  same media device even if no resource conflict exist by accessing the
  same request IDs than other applications.

- Request completion and deletion. Should completed requests be deleted
  automatically, or should the request return to an "empty" state after
  completion? Applications typically have to create a new request right
  after a completion of an earlier one, and sparing one additional IOCTL
  call would be nice. (In current implementation the requests are deleted
  in completion, but this would be a trivial change.)

- Video buffers vs. requests. In the current implementation, I'm using
  VIDIOC_QBUF() from user space to associate buffers with requests. This
  is convenient in drivers since the only extra steps to support requests
  (vs. operation without requests) is to find the request and not really
  queueing the buffer yet. What's noteworthy as well that the VB2 buffer
  is in correct state after this when the request is queued.

- Subsystem framework specific request information. The requests are about
  the media device, and struct media_device_request is free of e.g. V4L2
  related information. Adding a pointer to V4L2 related data would make it
  easier to add request handling related functionality to the V4L2
  framework.

- MEDIA_IOC_REQUEST_CMD + (ALLOC/DELETE/QUEUE/APPLY) vs.
  MEDIA_IOC_REQUEST_(ALLOC/DELETE/QUEUE/APPLY). Should we continue to have
  a single IOCTL on the media device for requests, or should each
  operation on a request have a distinct IOCTL? The current implementation
  has a single IOCTL.

- VB2 queues are quite self-sufficient at the moment. Starting start in a
  queue requires at least one queued buffer whereas a stream containing
  multiple queues using requests could start e.g. by having a single
  buffer in a request for three streaming queues. The functionality would
  need to be relaxed to properly support requests.

- Limit number of allocated requests and dequeueable events to prevent
  unintentional or intentional system memory exhaustion.

The patchset is dependent on two patchsets (Media device IOCTL handling
refactoring and Media device file handle support) I've posted lately:




The code can be found here in the branch called "request":



I intend to provide a test program for testing requests in the near
future.

Questions and comments are the most welcome!

-- 
Kind regards,
Sakari

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

[RFC 10/22] v4l: Support the request API in format operations

[Sakari Ailus]

From: Laurent Pinchart 

Store the formats in per-entity request data. The get and set format
operations are completely handled by the V4L2 core with help of the try
format driver operation.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 121 +++
 include/media/v4l2-dev.h |  13 
 2 files changed, 134 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index bf15580..533fac6 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1355,6 +1355,119 @@ static int v4l_enum_fmt(const struct v4l2_ioctl_ops 
*ops,
return ret;
 }
 
+#if defined(CONFIG_MEDIA_CONTROLLER)
+static void vdev_request_data_release(struct media_entity_request_data *data)
+{
+   struct video_device_request_data *vdata =
+   to_video_device_request_data(data);
+
+   kfree(vdata);
+}
+
+static int vdev_request_format(struct video_device *vdev, unsigned int req_id,
+  struct media_device_request **_req,
+  struct v4l2_pix_format_mplane **_fmt)
+{
+   struct media_entity_request_data *data;
+   struct video_device_request_data *vdata;
+   struct media_device_request *req;
+
+   if (!vdev->v4l2_dev || !vdev->v4l2_dev->mdev)
+   return -EINVAL;
+
+   req = media_device_request_find(vdev->v4l2_dev->mdev, req_id);
+   if (!req)
+   return -EINVAL;
+
+   *_req = req;
+
+   data = media_device_request_get_entity_data(req, >entity);
+   if (data) {
+   vdata = to_video_device_request_data(data);
+   *_fmt = >format;
+   return 0;
+   }
+
+   vdata = kzalloc(sizeof(*vdata), GFP_KERNEL);
+   if (!vdata) {
+   media_device_request_put(req);
+   return -ENOMEM;
+   }
+
+   vdata->data.release = vdev_request_data_release;
+
+   media_device_request_set_entity_data(req, >entity, >data);
+
+   *_fmt = >format;
+   return 0;
+}
+
+static int v4l_g_req_mplane_fmt(const struct v4l2_ioctl_ops *ops,
+   struct file *file, void *fh,
+   struct v4l2_format *fmt)
+{
+   struct video_device *vdev = video_devdata(file);
+   struct v4l2_pix_format_mplane *format;
+   struct media_device_request *req;
+   int ret;
+
+   ret = vdev_request_format(vdev, fmt->fmt.pix_mp.request,
+ , );
+   if (ret < 0)
+   return ret;
+
+   fmt->fmt.pix_mp = *format;
+   media_device_request_put(req);
+   return 0;
+}
+
+static int v4l_s_req_mplane_fmt(const struct v4l2_ioctl_ops *ops,
+   struct file *file, void *fh,
+   struct v4l2_format *fmt)
+{
+   int (*try_op)(struct file *file, void *fh, struct v4l2_format *fmt);
+   struct video_device *vdev = video_devdata(file);
+   struct v4l2_pix_format_mplane *format;
+   struct media_device_request *req;
+   int ret;
+
+   if (fmt->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+   try_op = ops->vidioc_try_fmt_vid_cap_mplane;
+   else
+   try_op = ops->vidioc_try_fmt_vid_out_mplane;
+
+   if (unlikely(!try_op))
+   return -ENOSYS;
+
+   ret = try_op(file, fh, fmt);
+   if (ret < 0)
+   return ret;
+
+   ret = vdev_request_format(vdev, fmt->fmt.pix_mp.request,
+ , );
+   if (ret < 0)
+   return ret;
+
+   *format = fmt->fmt.pix_mp;
+   media_device_request_put(req);
+   return 0;
+}
+#else
+static int v4l_g_req_mplane_fmt(const struct v4l2_ioctl_ops *ops,
+   struct file *file, void *fh,
+   struct v4l2_format *fmt)
+{
+   return -ENOSYS;
+}
+
+static int v4l_s_req_mplane_fmt(const struct v4l2_ioctl_ops *ops,
+   struct file *file, void *fh,
+   struct v4l2_format *fmt)
+{
+   return -ENOSYS;
+}
+#endif
+
 static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
 {
@@ -1402,6 +1515,8 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
if (unlikely(!is_rx || !is_vid || 
!ops->vidioc_g_fmt_vid_cap_mplane))
break;
+   if (p->fmt.pix_mp.request)
+   return v4l_g_req_mplane_fmt(ops, file, fh, p);
return ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!is_rx || !is_vid || 
!ops->vidioc_g_fmt_vid_overlay))
@@ -1426,6 +1541,8 @@ 

[RFC 02/22] media: Add media device request state

[Sakari Ailus]

Signed-off-by: Sakari Ailus 
---
 include/media/media-device.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/media/media-device.h b/include/media/media-device.h
index 49c3367a..acb2481 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -265,6 +265,11 @@ struct ida;
 struct device;
 struct media_device;
 
+enum media_device_request_state {
+   MEDIA_DEVICE_REQUEST_STATE_IDLE,
+   MEDIA_DEVICE_REQUEST_STATE_QUEUED,
+};
+
 /**
  * struct media_device_request - Media device request
  * @id: Request ID
@@ -272,6 +277,8 @@ struct media_device;
  * @kref: Reference count
  * @list: List entry in the media device requests list
  * @fh_list: List entry in the media file handle requests list
+ * @state: The state of the request, MEDIA_DEVICE_REQUEST_STATE_*,
+ *access to state serialised by mdev->req_lock
  */
 struct media_device_request {
u32 id;
@@ -279,6 +286,7 @@ struct media_device_request {
struct kref kref;
struct list_head list;
struct list_head fh_list;
+   enum media_device_request_state state;
 };
 
 /**
-- 
1.9.1

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

[RFC 14/22] media: Add MEDIA_IOC_DQEVENT

[Sakari Ailus]

Events on a media device tell about completion of requests. Blocking and
non-blocking operation is supported.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 114 +--
 include/media/media-device.h |  11 +
 include/uapi/linux/media.h   |  17 +++
 3 files changed, 137 insertions(+), 5 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 10b9a4a..357c3cb 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -23,6 +23,7 @@
 /* We need to access legacy defines from linux/media.h */
 #define __NEED_MEDIA_LEGACY_API
 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -42,6 +44,12 @@
 struct media_device_fh {
struct media_devnode_fh fh;
struct list_head requests;
+   struct {
+   spinlock_t lock;
+   struct list_head head;
+   wait_queue_head_t wait;
+   atomic_t sequence;
+   } kevents;
 };
 
 static inline struct media_device_fh *media_device_fh(struct file *filp)
@@ -92,6 +100,33 @@ void media_device_request_get(struct media_device_request 
*req)
 }
 EXPORT_SYMBOL_GPL(media_device_request_get);
 
+static void media_device_request_queue_event(struct media_device *mdev,
+struct media_device_request *req)
+{
+   struct media_kevent *kev = req->kev;
+   struct media_event *ev = >ev;
+   struct media_device_fh *fh;
+   unsigned long flags;
+
+   spin_lock_irqsave(>req_lock, flags);
+   if (!req->filp) {
+   spin_unlock_irqrestore(>req_lock, flags);
+   return;
+   }
+   fh = media_device_fh(req->filp);
+
+   ev->sequence = atomic_inc_return(>kevents.sequence);
+   ev->type = MEDIA_EVENT_TYPE_REQUEST_COMPLETE;
+   ev->req_complete.id = req->id;
+   ev->req_complete.status = 0;
+
+   list_add(>list, >kevents.head);
+   req->kev = NULL;
+   req->state = MEDIA_DEVICE_REQUEST_STATE_COMPLETE;
+   wake_up(>kevents.wait);
+   spin_unlock_irqrestore(>req_lock, flags);
+}
+
 static void media_device_request_release(struct kref *kref)
 {
struct media_entity_request_data *data, *next;
@@ -106,6 +141,9 @@ static void media_device_request_release(struct kref *kref)
 
ida_simple_remove(>req_ids, req->id);
 
+   kfree(req->kev);
+   req->kev = NULL;
+
mdev->ops->req_free(mdev, req);
 }
 
@@ -180,10 +218,12 @@ void media_device_request_set_entity_data(struct 
media_device_request *req,
 EXPORT_SYMBOL_GPL(media_device_request_set_entity_data);
 
 static int media_device_request_alloc(struct media_device *mdev,
- struct media_device_fh *fh,
+ struct file *filp,
  struct media_request_cmd *cmd)
 {
+   struct media_device_fh *fh = media_device_fh(filp);
struct media_device_request *req;
+   struct media_kevent *kev;
unsigned long flags;
int id = ida_simple_get(>req_ids, 1, 0, GFP_KERNEL);
int ret;
@@ -191,14 +231,22 @@ static int media_device_request_alloc(struct media_device 
*mdev,
if (id < 0)
return id;
 
+   kev = kzalloc(sizeof(*kev), GFP_KERNEL);
+   if (!kev) {
+   ret = -ENOMEM;
+   goto out_ida_simple_remove;
+   }
+
req = mdev->ops->req_alloc(mdev);
if (!req) {
ret = -ENOMEM;
-   goto out_ida_simple_remove;
+   goto out_kev_free;
}
 
req->mdev = mdev;
req->id = id;
+   req->filp = filp;
+   req->kev = kev;
kref_init(>kref);
INIT_LIST_HEAD(>data);
 
@@ -211,6 +259,9 @@ static int media_device_request_alloc(struct media_device 
*mdev,
 
return 0;
 
+out_kev_free:
+   kfree(kev);
+
 out_ida_simple_remove:
ida_simple_remove(>req_ids, id);
 
@@ -233,6 +284,8 @@ static void media_device_request_delete(struct media_device 
*mdev,
 void media_device_request_complete(struct media_device *mdev,
   struct media_device_request *req)
 {
+   media_device_request_queue_event(mdev, req);
+
media_device_request_delete(mdev, req);
 }
 EXPORT_SYMBOL_GPL(media_device_request_complete);
@@ -272,7 +325,6 @@ static long media_device_request_cmd(struct media_device 
*mdev,
 struct file *filp,
 struct media_request_cmd *cmd)
 {
-   struct media_device_fh *fh = media_device_fh(filp);
struct media_device_request *req = NULL;
unsigned long flags;
int ret;
@@ -288,7 +340,7 @@ static long media_device_request_cmd(struct media_device 
*mdev,
 
switch (cmd->cmd) {
case MEDIA_REQ_CMD_ALLOC:
-  

[RFC 13/22] vb2: Add helper function to check for request buffers

[Sakari Ailus]

From: Laurent Pinchart 

The vb2_queue_has_request() function will check whether a buffer has
been prepared for the given request ID.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c | 17 +
 include/media/videobuf2-v4l2.h   |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index bb135fc..6c1c4bf 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -790,6 +790,23 @@ void vb2_queue_release(struct vb2_queue *q)
 }
 EXPORT_SYMBOL_GPL(vb2_queue_release);
 
+bool vb2_queue_has_request(struct vb2_queue *q, unsigned int request)
+{
+   unsigned int i;
+
+   for (i = 0; i < q->num_buffers; i++) {
+   struct vb2_buffer *vb = q->bufs[i];
+   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+
+   if (vb->state == VB2_BUF_STATE_PREPARED &&
+   vbuf->request == request)
+   return true;
+   }
+
+   return false;
+}
+EXPORT_SYMBOL_GPL(vb2_queue_has_request);
+
 /**
  * vb2_poll() - implements poll userspace operation
  * @q: videobuf2 queue
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index b1ee91c..7727c52 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -68,6 +68,8 @@ void vb2_queue_release(struct vb2_queue *q);
 unsigned int vb2_poll(struct vb2_queue *q, struct file *file,
poll_table *wait);
 
+bool vb2_queue_has_request(struct vb2_queue *q, unsigned int request);
+
 /*
  * The following functions are not part of the vb2 core API, but are simple
  * helper functions that you can use in your struct v4l2_file_operations,
-- 
1.9.1

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

[RFC 04/22] media: Only requests in IDLE state may be deleted

[Sakari Ailus]

Prevent deleting queued requests. Also mark deleted requests as such by
adding a new state for them.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-device.c | 14 --
 include/media/media-device.h |  1 +
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 481e8e4..5b7bfcf 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -195,6 +195,7 @@ static long media_device_request_cmd(struct media_device 
*mdev,
 {
struct media_device_fh *fh = media_device_fh(filp);
struct media_device_request *req = NULL;
+   unsigned long flags;
int ret;
 
if (!mdev->ops || !mdev->ops->req_alloc || !mdev->ops->req_free)
@@ -212,8 +213,17 @@ static long media_device_request_cmd(struct media_device 
*mdev,
break;
 
case MEDIA_REQ_CMD_DELETE:
-   media_device_request_delete(mdev, req);
-   ret = 0;
+   spin_lock_irqsave(>req_lock, flags);
+   if (req->state == MEDIA_DEVICE_REQUEST_STATE_IDLE) {
+   ret = 0;
+   req->state = MEDIA_DEVICE_REQUEST_STATE_DELETED;
+   } else {
+   ret = -EINVAL;
+   }
+   spin_unlock_irqrestore(>req_lock, flags);
+
+   if (!ret)
+   media_device_request_delete(mdev, req);
break;
 
case MEDIA_REQ_CMD_APPLY:
diff --git a/include/media/media-device.h b/include/media/media-device.h
index acb2481..3167c52 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -268,6 +268,7 @@ struct media_device;
 enum media_device_request_state {
MEDIA_DEVICE_REQUEST_STATE_IDLE,
MEDIA_DEVICE_REQUEST_STATE_QUEUED,
+   MEDIA_DEVICE_REQUEST_STATE_DELETED,
 };
 
 /**
-- 
1.9.1

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

Re: Kernel docs: muddying the waters a bit

[Markus Heiser]

Hi Mauro,

Am 04.05.2016 um 18:15 schrieb Mauro Carvalho Chehab :

> Em Wed, 4 May 2016 11:34:08 +0200
> Markus Heiser  escreveu:
> 
>> Hi all, (hi Jonathan, please take note of my offer below)
>> 
>> Am 03.05.2016 um 16:31 schrieb Daniel Vetter :
>> 
>>> Hi all,
>>> 
>>> So sounds like moving ahead with rst/sphinx is the option that should
>>> allow us to address everyone's concerns eventually? Of course the
>>> first one won't have it all (media seems really tricky), ...  
>> 
>> BTW: Mauro mentioned that ASCII-art tables are not diff-friendly ... 
>> For this, I wrote the "flat-table" reST-directive, which adds 
>> missing cells automatically:
>> 
>> doc:
>> http://return42.github.io/sphkerneldoc/articles/table_concerns.html#flat-table
>> source: 
>> https://github.com/return42/sphkerneldoc/blob/master/doc/extensions/rstFlatTable.py
> 
> Yeah, this should address the lack of a proper way to markup cell/row
> spans, providing the additional bits for the tables we have at media.
> 
> Yet, there are some issues with table conversions. See below.
> Some tables, like the one here:
>   
> https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/control.html
> 
> are truncated (tested with Mozilla and Chrome), and part of the information is
> lost due to that.

Not a problem of rendering. This was a bug in the magration from DocBook to 
reST. 
You might remember that we have discussed, that some of the tables are better
marked-up as definition lists. This was (the last) one I forgot to convert to 
a definition list ... I hope it was the last one, if not and you find more 
or other broken parts, please inform me (on the linux-tv mailing, or direct).

--Markus--

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