[PATCH v4 0/4] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[PATCH v4 0/4] Fixes for colorspace logic in exynos-gsc and s5p-mfc drivers

[Thibault Saunier]

Hello,

This patchset fixes a few issues on the colorspace logic for the exynos-gsc
and s5p-mfc drivers.

We now handle the colorspace in those drivers, and make sure to respect user setting if
possible.

We also now set the 'v4l2_pix_format:field' if userspace passed ANY, avoiding GStreamer
spamming error at us about the driver not following the standard.

This is the third version of the patch serie.

Best regards,

Thibault Saunier

Changes in v4:
- Reword commit message to better back our assumptions on specifications
- Use any colorspace provided by the user as it won't affect the way we
  handle our operations (guessing it if none is provided)
- Always use output colorspace on the capture side
- Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
  all other cases just use what userspace provided.

Changes in v3:
- Added 'Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>'
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in
- Do not check values in the g_fmt functions as Andrzej explained in previous review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

Javier Martinez Canillas (1):
  [media] exynos-gsc: Use 576p instead 720p as a threshold for
    colorspaces

Thibault Saunier (3):
  [media] exynos-gsc: Respect userspace colorspace setting in try_fmt
  [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT
    provided
  [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in
    try_fmt

 drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++++++++++++++-----
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 28 ++++++++++++++++++++++++++++
 3 files changed, 44 insertions(+), 5 deletions(-)

-- 
2.11.1

[PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

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

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
don't agree on the display resolution that should be used as a threshold.

>From EIA CEA 861B about colorimetry for various resolutions:

  - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
    The color space used by the 480-line, 576-line, 240-line, and 288-line
    formats will likely be based on SMPTE 170M [1].
  - 5.2 1080i, 1080p, and 720p
    The color space used by the high definition formats will likely be
    based on ITU-R BT.709-4

This indicates that in the case that userspace does not specify what
colorspace should be used, we should use 576p  as a threshold to set
V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is
only 'likely' and not a requirement it is the best guess we can make.

The stream should have been encoded with the information and userspace
has to pass it to the driver if it is not the case, otherwise we won't be
able to handle it properly anyhow.

Also, check for the resolution in G_FMT instead unconditionally setting
the V4L2_COLORSPACE_REC709 colorspace.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>

---

Changes in v4:
- Reword commit message to better back our assumptions on specifications

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous review
- Added 'Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>'

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 59a634201830..db7d9883861b 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
 
 	pix_mp->num_planes = fmt->num_planes;
 
-	if (pix_mp->width >= 1280) /* HD */
+	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
 		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
 	else /* SD */
 		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
@@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
 	pix_mp->height		= frame->f_height;
 	pix_mp->field		= V4L2_FIELD_NONE;
 	pix_mp->pixelformat	= frame->fmt->pixelformat;
-	pix_mp->colorspace	= V4L2_COLORSPACE_REC709;
 	pix_mp->num_planes	= frame->fmt->num_planes;
 
+	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+	else /* SD */
+		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
 	for (i = 0; i < pix_mp->num_planes; ++i) {
 		pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
 			frame->fmt->depth[i]) / 8;
-- 
2.11.1

Re: [PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Fabien DESSENNE]

Hi Thibault


On 13/02/17 20:08, Thibault Saunier wrote:
> From: Javier Martinez Canillas <javier@osg.samsung.com>
>
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
> don't agree on the display resolution that should be used as a threshold.
>
>  From EIA CEA 861B about colorimetry for various resolutions:
>
>    - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
>      The color space used by the 480-line, 576-line, 240-line, and 288-line
>      formats will likely be based on SMPTE 170M [1].
>    - 5.2 1080i, 1080p, and 720p
>      The color space used by the high definition formats will likely be
>      based on ITU-R BT.709-4
>
> This indicates that in the case that userspace does not specify what
> colorspace should be used, we should use 576p  as a threshold to set
> V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is

typo -> "V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M"


> only 'likely' and not a requirement it is the best guess we can make.
>
> The stream should have been encoded with the information and userspace
> has to pass it to the driver if it is not the case, otherwise we won't be
> able to handle it properly anyhow.
>
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
>
> ---
>
> Changes in v4:
> - Reword commit message to better back our assumptions on specifications
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous review
> - Added 'Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>'
>
> Changes in v2: None
>
>   drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 59a634201830..db7d9883861b 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
>   
>   	pix_mp->num_planes = fmt->num_planes;
>   
> -	if (pix_mp->width >= 1280) /* HD */
> +	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
>   		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
>   	else /* SD */
>   		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> @@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
>   	pix_mp->height		= frame->f_height;
>   	pix_mp->field		= V4L2_FIELD_NONE;
>   	pix_mp->pixelformat	= frame->fmt->pixelformat;
> -	pix_mp->colorspace	= V4L2_COLORSPACE_REC709;
>   	pix_mp->num_planes	= frame->fmt->num_planes;
>   
> +	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> +		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> +	else /* SD */
> +		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +
>   	for (i = 0; i < pix_mp->num_planes; ++i) {
>   		pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
>   			frame->fmt->depth[i]) / 8;

BR
Fabien

Re: [PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> From: Javier Martinez Canillas <javier@osg.samsung.com>
>
> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
> don't agree on the display resolution that should be used as a threshold.
>
> >From EIA CEA 861B about colorimetry for various resolutions:
>
>   - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
>     The color space used by the 480-line, 576-line, 240-line, and 288-line
>     formats will likely be based on SMPTE 170M [1].
>   - 5.2 1080i, 1080p, and 720p
>     The color space used by the high definition formats will likely be
>     based on ITU-R BT.709-4
>
> This indicates that in the case that userspace does not specify what
> colorspace should be used, we should use 576p  as a threshold to set
> V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is
> only 'likely' and not a requirement it is the best guess we can make.
>
> The stream should have been encoded with the information and userspace
> has to pass it to the driver if it is not the case, otherwise we won't be
> able to handle it properly anyhow.
>
> Also, check for the resolution in G_FMT instead unconditionally setting
> the V4L2_COLORSPACE_REC709 colorspace.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>

Hi Thibault,

Have you analyzed Hans response for the previous patchset [1] ?
I am not an expert in the subject but it seems he is right. GSCALER
datasheet uses term 'color space conversion' to describe conversions
between RGB and YCbCr, not for describe colorspaces as in V4L2.
GSC_(IN|OUT)_RGB_(HD|SD)_(WIDE|NARROW) macros used to set IN_CON and
OUT_CON registers of GSCALER are probably used incorrectly, they should
not be set according to pix_mp->colorspace but rather according to
pix_mp->ycbcr_enc and pix_mp->quantization. pix_mp->colorspace should be
just copied from output to capture side.

Please fix the patch accordingly, and if you are interested you can
prepare another patch to fix register setting.

[1]: https://lkml.org/lkml/2017/2/10/473

Regards
Andrzej

>
> ---
>
> Changes in v4:
> - Reword commit message to better back our assumptions on specifications
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous review
> - Added 'Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>'
>
> Changes in v2: None
>
>  drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 59a634201830..db7d9883861b 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
>  
>  	pix_mp->num_planes = fmt->num_planes;
>  
> -	if (pix_mp->width >= 1280) /* HD */
> +	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
>  		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
>  	else /* SD */
>  		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> @@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
>  	pix_mp->height		= frame->f_height;
>  	pix_mp->field		= V4L2_FIELD_NONE;
>  	pix_mp->pixelformat	= frame->fmt->pixelformat;
> -	pix_mp->colorspace	= V4L2_COLORSPACE_REC709;
>  	pix_mp->num_planes	= frame->fmt->num_planes;
>  
> +	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> +		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> +	else /* SD */
> +		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +
>  	for (i = 0; i < pix_mp->num_planes; ++i) {
>  		pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
>  			frame->fmt->depth[i]) / 8;

Re: [PATCH v4 1/4] [media] exynos-gsc: Use 576p instead 720p as a threshold for colorspaces

[Thibault Saunier]

Hello Andrzej,

On 02/21/2017 06:56 AM, Andrzej Hajda wrote:
> On 13.02.2017 20:08, Thibault Saunier wrote:
>> From: Javier Martinez Canillas <javier@osg.samsung.com>
>>
>> The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
>> should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers
>> don't agree on the display resolution that should be used as a threshold.
>>
>> >From EIA CEA 861B about colorimetry for various resolutions:
>>
>>    - 5.1 480p, 480i, 576p, 576i, 240p, and 288p
>>      The color space used by the 480-line, 576-line, 240-line, and 288-line
>>      formats will likely be based on SMPTE 170M [1].
>>    - 5.2 1080i, 1080p, and 720p
>>      The color space used by the high definition formats will likely be
>>      based on ITU-R BT.709-4
>>
>> This indicates that in the case that userspace does not specify what
>> colorspace should be used, we should use 576p  as a threshold to set
>> V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_REC709. Even if it is
>> only 'likely' and not a requirement it is the best guess we can make.
>>
>> The stream should have been encoded with the information and userspace
>> has to pass it to the driver if it is not the case, otherwise we won't be
>> able to handle it properly anyhow.
>>
>> Also, check for the resolution in G_FMT instead unconditionally setting
>> the V4L2_COLORSPACE_REC709 colorspace.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> Hi Thibault,
>
> Have you analyzed Hans response for the previous patchset [1] ?
> I am not an expert in the subject but it seems he is right. GSCALER
> datasheet uses term 'color space conversion' to describe conversions
> between RGB and YCbCr, not for describe colorspaces as in V4L2.
> GSC_(IN|OUT)_RGB_(HD|SD)_(WIDE|NARROW) macros used to set IN_CON and
> OUT_CON registers of GSCALER are probably used incorrectly, they should
> not be set according to pix_mp->colorspace but rather according to
> pix_mp->ycbcr_enc and pix_mp->quantization. pix_mp->colorspace should be
> just copied from output to capture side.
>
> Please fix the patch accordingly, and if you are interested you can
> prepare another patch to fix register setting.

OK, so what you describe here for the colorspace  is exactly what I am 
doing in my next patch right?
I am going to fixup them up as suggested in your other review.

I will also have a look at fixing register setting and figure out what 
you explained.

Thanks for the review.

Regards,

Thibault Saunier

> [1]: https://lkml.org/lkml/2017/2/10/473
>
> Regards
> Andrzej
>
>> ---
>>
>> Changes in v4:
>> - Reword commit message to better back our assumptions on specifications
>>
>> Changes in v3:
>> - Do not check values in the g_fmt functions as Andrzej explained in previous review
>> - Added 'Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>'
>>
>> Changes in v2: None
>>
>>   drivers/media/platform/exynos-gsc/gsc-core.c | 8 ++++++--
>>   1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
>> index 59a634201830..db7d9883861b 100644
>> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
>> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
>> @@ -472,7 +472,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
>>   
>>   	pix_mp->num_planes = fmt->num_planes;
>>   
>> -	if (pix_mp->width >= 1280) /* HD */
>> +	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
>>   		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
>>   	else /* SD */
>>   		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
>> @@ -519,9 +519,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
>>   	pix_mp->height		= frame->f_height;
>>   	pix_mp->field		= V4L2_FIELD_NONE;
>>   	pix_mp->pixelformat	= frame->fmt->pixelformat;
>> -	pix_mp->colorspace	= V4L2_COLORSPACE_REC709;
>>   	pix_mp->num_planes	= frame->fmt->num_planes;
>>   
>> +	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
>> +		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
>> +	else /* SD */
>> +		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
>> +
>>   	for (i = 0; i < pix_mp->num_planes; ++i) {
>>   		pix_mp->plane_fmt[i].bytesperline = (frame->f_width *
>>   			frame->fmt->depth[i]) / 8;
>

[PATCH v4 2/4] [media] exynos-gsc: Respect userspace colorspace setting in try_fmt

[Thibault Saunier]

User userspace provided by the user as we are only doing scaling and
color encoding conversion, we won't be able to transform the colorspace
itself and the colorspace won't mater in that operation.

Also always use output colorspace on the capture side.

Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>

---

Changes in v4:
- Use any colorspace provided by the user as it won't affect the way we
  handle our operations (guessing it if none is provided)
- Always use output colorspace on the capture side

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2: None

 drivers/media/platform/exynos-gsc/gsc-core.c | 14 ++++++++++----
 drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index db7d9883861b..772599de8c13 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
 	} else {
 		min_w = variant->pix_min->target_rot_dis_w;
 		min_h = variant->pix_min->target_rot_dis_h;
+		pix_mp->colorspace = ctx->out_colorspace;
 	}
 
 	pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
@@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
 
 	pix_mp->num_planes = fmt->num_planes;
 
-	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
-		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
-	else /* SD */
-		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+	if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+		if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+			pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+		else /* SD */
+			pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+	}
+
+	if (V4L2_TYPE_IS_OUTPUT(f->type))
+		ctx->out_colorspace = pix_mp->colorspace;
 
 	for (i = 0; i < pix_mp->num_planes; ++i) {
 		struct v4l2_plane_pix_format *plane_fmt = &pix_mp->plane_fmt[i];
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h b/drivers/media/platform/exynos-gsc/gsc-core.h
index 696217e9af66..715d9c9d8d30 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -376,6 +376,7 @@ struct gsc_ctx {
 	struct v4l2_ctrl_handler ctrl_handler;
 	struct gsc_ctrls	gsc_ctrls;
 	bool			ctrls_rdy;
+	enum v4l2_colorspace out_colorspace;
 };
 
 void gsc_set_prefbuf(struct gsc_dev *gsc, struct gsc_frame *frm);
-- 
2.11.1

Re: [PATCH v4 2/4] [media] exynos-gsc: Respect userspace colorspace setting in try_fmt

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> User userspace provided by the user as we are only doing scaling and
> color encoding conversion, we won't be able to transform the colorspace
> itself and the colorspace won't mater in that operation.
>
> Also always use output colorspace on the capture side.
>
> Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>

This patch can be squashed with previous one as the only thing to do is
to set output colorspace the same as capture colorspace.

--
Regards
Andrzej

>
> ---
>
> Changes in v4:
> - Use any colorspace provided by the user as it won't affect the way we
>   handle our operations (guessing it if none is provided)
> - Always use output colorspace on the capture side
>
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous review
> - Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in
>
> Changes in v2: None
>
>  drivers/media/platform/exynos-gsc/gsc-core.c | 14 ++++++++++----
>  drivers/media/platform/exynos-gsc/gsc-core.h |  1 +
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index db7d9883861b..772599de8c13 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
>  	} else {
>  		min_w = variant->pix_min->target_rot_dis_w;
>  		min_h = variant->pix_min->target_rot_dis_h;
> +		pix_mp->colorspace = ctx->out_colorspace;
>  	}
>  
>  	pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d",
> @@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f)
>  
>  	pix_mp->num_planes = fmt->num_planes;
>  
> -	if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> -		pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> -	else /* SD */
> -		pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +	if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
> +		if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
> +			pix_mp->colorspace = V4L2_COLORSPACE_REC709;
> +		else /* SD */
> +			pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
> +	}
> +
> +	if (V4L2_TYPE_IS_OUTPUT(f->type))
> +		ctx->out_colorspace = pix_mp->colorspace;
>  
>  	for (i = 0; i < pix_mp->num_planes; ++i) {
>  		struct v4l2_plane_pix_format *plane_fmt = &pix_mp->plane_fmt[i];
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h b/drivers/media/platform/exynos-gsc/gsc-core.h
> index 696217e9af66..715d9c9d8d30 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.h
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.h
> @@ -376,6 +376,7 @@ struct gsc_ctx {
>  	struct v4l2_ctrl_handler ctrl_handler;
>  	struct gsc_ctrls	gsc_ctrls;
>  	bool			ctrls_rdy;
> +	enum v4l2_colorspace out_colorspace;
>  };
>  
>  void gsc_set_prefbuf(struct gsc_dev *gsc, struct gsc_frame *frm);

[PATCH v4 3/4] [media] s5p-mfc: Set colorspace in VIDIO_{G,TRY}_FMT if DEFAULT provided

[Thibault Saunier]

The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace
should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV but the driver
didn't set the colorimetry when userspace provided
V4L2_COLORSPACE_DEFAULT.

Use 576p display resolution as a threshold to set this as suggested by
EIA CEA 861B.

Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>

---

Changes in v4:
- Set the colorspace only if the user passed V4L2_COLORSPACE_DEFAULT, in
  all other cases just use what userspace provided.

Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous review
- Set colorspace if user passed V4L2_COLORSPACE_DEFAULT in

Changes in v2: None

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

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 367ef8e8dbf0..0976c3e0a5ce 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -354,6 +354,11 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 		pix_mp->plane_fmt[0].sizeimage = ctx->luma_size;
 		pix_mp->plane_fmt[1].bytesperline = ctx->buf_width;
 		pix_mp->plane_fmt[1].sizeimage = ctx->chroma_size;
+
+		if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */
+			pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+		else /* SD */
+			pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
 	} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		/* This is run on OUTPUT
 		   The buffer contains compressed image
@@ -378,6 +383,7 @@ static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
 static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 {
 	struct s5p_mfc_dev *dev = video_drvdata(file);
+	struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
 	struct s5p_mfc_fmt *fmt;
 
 	mfc_debug(2, "Type is %d\n", f->type);
@@ -405,6 +411,14 @@ static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 			mfc_err("Unsupported format by this MFC version.\n");
 			return -EINVAL;
 		}
+
+		if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) {
+			if (pix_mp->width > 720 &&
+					pix_mp->height > 576) /* HD */
+				pix_mp->colorspace = V4L2_COLORSPACE_REC709;
+			else /* SD */
+				pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M;
+		}
 	}
 
 	return 0;
-- 
2.11.1

[PATCH v4 4/4] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Thibault Saunier]

It is required by the standard that the field order is set by the
driver.

Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>

---

Changes in v4: None
Changes in v3:
- Do not check values in the g_fmt functions as Andrzej explained in previous review

Changes in v2:
- Fix a silly build error that slipped in while rebasing the patches

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

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 0976c3e0a5ce..c954b34cb988 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -385,6 +385,20 @@ static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
 	struct s5p_mfc_dev *dev = video_drvdata(file);
 	struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
 	struct s5p_mfc_fmt *fmt;
+	enum v4l2_field field;
+
+	field = f->fmt.pix.field;
+	if (field == V4L2_FIELD_ANY) {
+		field = V4L2_FIELD_NONE;
+	} else if (field != V4L2_FIELD_NONE) {
+		mfc_debug(2, "Not supported field order(%d)\n", pix_mp->field);
+		return -EINVAL;
+	}
+
+	/* V4L2 specification suggests the driver corrects the format struct
+	 * if any of the dimensions is unsupported
+	 */
+	f->fmt.pix.field = field;
 
 	mfc_debug(2, "Type is %d\n", f->type);
 	if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
-- 
2.11.1

Re: [PATCH v4 4/4] [media] s5p-mfc: Check and set 'v4l2_pix_format:field' field in try_fmt

[Andrzej Hajda]

On 13.02.2017 20:08, Thibault Saunier wrote:
> It is required by the standard that the field order is set by the
> driver.
>
> Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - Do not check values in the g_fmt functions as Andrzej explained in previous review
>
> Changes in v2:
> - Fix a silly build error that slipped in while rebasing the patches
>
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 0976c3e0a5ce..c954b34cb988 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -385,6 +385,20 @@ static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
>  	struct s5p_mfc_dev *dev = video_drvdata(file);
>  	struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
>  	struct s5p_mfc_fmt *fmt;
> +	enum v4l2_field field;
> +
> +	field = f->fmt.pix.field;
> +	if (field == V4L2_FIELD_ANY) {
> +		field = V4L2_FIELD_NONE;
> +	} else if (field != V4L2_FIELD_NONE) {
> +		mfc_debug(2, "Not supported field order(%d)\n", pix_mp->field);
> +		return -EINVAL;
> +	}
> +
> +	/* V4L2 specification suggests the driver corrects the format struct
> +	 * if any of the dimensions is unsupported
> +	 */
> +	f->fmt.pix.field = field;

It looks like you missed my previous comment.
--
Regards
Andrzej

>  
>  	mfc_debug(2, "Type is %d\n", f->type);
>  	if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {