linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers
@ 2016-05-06 22:11 Javier Martinez Canillas
  2016-05-07  1:25 ` Nicolas Dufresne
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: Javier Martinez Canillas @ 2016-05-06 22:11 UTC (permalink / raw)
  To: linux-kernel
  Cc: Marek Szyprowski, Nicolas Dufresne, ayaka, Shuah Khan,
	Javier Martinez Canillas, Mauro Carvalho Chehab, Kamil Debski,
	Jeongtae Park, Kyungmin Park, linux-arm-kernel, linux-media

From: ayaka <ayaka@soulik.info>

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 <ayaka@soulik.info>
[javier: Rewrote changelog to explain the problem more detailed]
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

---
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(&ctx->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


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers
  2016-05-06 22:11 [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers Javier Martinez Canillas
@ 2016-05-07  1:25 ` Nicolas Dufresne
  2016-05-09 12:48   ` Javier Martinez Canillas
  2016-05-07  5:09 ` ayaka
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 6+ messages in thread
From: Nicolas Dufresne @ 2016-05-07  1:25 UTC (permalink / raw)
  To: Javier Martinez Canillas, linux-kernel
  Cc: Marek Szyprowski, ayaka, Shuah Khan, Mauro Carvalho Chehab,
	Kamil Debski, Jeongtae Park, Kyungmin Park, linux-arm-kernel,
	linux-media

[-- Attachment #1: Type: text/plain, Size: 3447 bytes --]

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 <ayaka@soulik.info>
> 
> 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 <ayaka@soulik.info>
> [javier: Rewrote changelog to explain the problem more detailed]
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> 
> ---
> 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(&ctx->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) {

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers
  2016-05-06 22:11 [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers Javier Martinez Canillas
  2016-05-07  1:25 ` Nicolas Dufresne
@ 2016-05-07  5:09 ` ayaka
  2016-05-09 12:54 ` Nicolas Dufresne
  2016-05-24 10:21 ` Marek Szyprowski
  3 siblings, 0 replies; 6+ messages in thread
From: ayaka @ 2016-05-07  5:09 UTC (permalink / raw)
  To: linux-kernel
  Cc: Javier Martinez Canillas, Marek Szyprowski, Nicolas Dufresne,
	Shuah Khan, Mauro Carvalho Chehab, Kamil Debski, Jeongtae Park,
	Kyungmin Park, linux-arm-kernel, linux-media

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 <ayaka@soulik.info>
>
> 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 <ayaka@soulik.info>
> [javier: Rewrote changelog to explain the problem more detailed]
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
> 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(&ctx->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) {


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers
  2016-05-07  1:25 ` Nicolas Dufresne
@ 2016-05-09 12:48   ` Javier Martinez Canillas
  0 siblings, 0 replies; 6+ messages in thread
From: Javier Martinez Canillas @ 2016-05-09 12:48 UTC (permalink / raw)
  To: Nicolas Dufresne, linux-kernel
  Cc: Marek Szyprowski, ayaka, Shuah Khan, Mauro Carvalho Chehab,
	Kamil Debski, Jeongtae Park, Kyungmin Park, linux-arm-kernel,
	linux-media

Hello Nicolas,

Thanks for your feedback.

On 05/06/2016 09:25 PM, Nicolas Dufresne wrote:
> Thanks for re-submitting. See inline two typos to fix in teh comment.
>

You are welcome, as we talked in IRC you needed this to make video decoding
in your Exynos4412 Odroid X2 board, so it would be great if you can provide
your Reviewed or Acked by tags.
 
> cheers,
> Nicolas
> 
> Le vendredi 06 mai 2016 à 18:11 -0400, Javier Martinez Canillas a écrit :
>> From: ayaka <ayaka@soulik.info>
>>
>> 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
>

Right, sorry about that. I'll wait for other people feedback and fix in v2.

>> 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 <ayaka@soulik.info>
>> [javier: Rewrote changelog to explain the problem more detailed]
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>
>> ---
>> 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 
>

Yes, this is not that important since the comments between the --- separator
and the actual diff is stripped and doesn't end in the commit message.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers
  2016-05-06 22:11 [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers Javier Martinez Canillas
  2016-05-07  1:25 ` Nicolas Dufresne
  2016-05-07  5:09 ` ayaka
@ 2016-05-09 12:54 ` Nicolas Dufresne
  2016-05-24 10:21 ` Marek Szyprowski
  3 siblings, 0 replies; 6+ messages in thread
From: Nicolas Dufresne @ 2016-05-09 12:54 UTC (permalink / raw)
  To: Javier Martinez Canillas, linux-kernel
  Cc: Marek Szyprowski, ayaka, Shuah Khan, Mauro Carvalho Chehab,
	Kamil Debski, Jeongtae Park, Kyungmin Park, linux-arm-kernel,
	linux-media

[-- Attachment #1: Type: text/plain, Size: 3485 bytes --]

Le vendredi 06 mai 2016 à 18:11 -0400, Javier Martinez Canillas a
écrit :
> From: ayaka <ayaka@soulik.info>
> 
> 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 <ayaka@soulik.info>
> [javier: Rewrote changelog to explain the problem more detailed]
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

I just tested this change, it also seems correct.

Acked-by: Nicolas Dufresne <nicolas@collabora.com>

> 
> ---
> 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(&ctx->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) {

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers
  2016-05-06 22:11 [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers Javier Martinez Canillas
                   ` (2 preceding siblings ...)
  2016-05-09 12:54 ` Nicolas Dufresne
@ 2016-05-24 10:21 ` Marek Szyprowski
  3 siblings, 0 replies; 6+ messages in thread
From: Marek Szyprowski @ 2016-05-24 10:21 UTC (permalink / raw)
  To: Javier Martinez Canillas, linux-kernel
  Cc: Nicolas Dufresne, ayaka, Shuah Khan, Mauro Carvalho Chehab,
	Kamil Debski, Jeongtae Park, Kyungmin Park, linux-arm-kernel,
	linux-media

Hello,


On 2016-05-07 00:11, Javier Martinez Canillas wrote:
> From: ayaka <ayaka@soulik.info>
>
> 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 <ayaka@soulik.info>
> [javier: Rewrote changelog to explain the problem more detailed]
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

>
> ---
> 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(&ctx->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) {

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-05-24 10:21 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-06 22:11 [RESEND PATCH] [media] s5p-mfc: don't close instance after free OUTPUT buffers Javier Martinez Canillas
2016-05-07  1:25 ` Nicolas Dufresne
2016-05-09 12:48   ` Javier Martinez Canillas
2016-05-07  5:09 ` ayaka
2016-05-09 12:54 ` Nicolas Dufresne
2016-05-24 10:21 ` Marek Szyprowski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).