Re: [PATCH 4/4] media: imx-pxp: Start using the format VUYA32 instead of YUV32

From: Hans Verkuil <hverkuil@xs4all.nl>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>, linux-media@vger.kernel.org
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [PATCH 4/4] media: imx-pxp: Start using the format VUYA32 instead of YUV32
Date: Fri, 8 Feb 2019 10:15:44 +0100	[thread overview]
Message-ID: <5119be5b-4480-68f5-bb50-900eca9eb10f@xs4all.nl> (raw)
In-Reply-To: <20190208031846.14453-5-vivek.kasireddy@intel.com>

On 2/8/19 4:18 AM, Vivek Kasireddy wrote:
> Buffers generated with YUV32 format seems to be incorrect, hence use
> VUYA32 instead.
> 
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>

Philipp, I wonder whether VUYA32 or VUYX32 should be used? I think the alpha
channel is completely ignored on the source side and on the destination side
it is probably set by some fixed value?

Note that there exists a control V4L2_CID_ALPHA_COMPONENT that can be used
to let userspace specify the generated alpha value.

What if both source and destination formats have an alpha channel? Can the
hardware preserved the alpha values?

Regards,

	Hans

> ---
>  drivers/media/platform/imx-pxp.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/imx-pxp.c b/drivers/media/platform/imx-pxp.c
> index f087dc4fc729..70adbe38f802 100644
> --- a/drivers/media/platform/imx-pxp.c
> +++ b/drivers/media/platform/imx-pxp.c
> @@ -90,7 +90,7 @@ static struct pxp_fmt formats[] = {
>  		.depth	= 16,
>  		.types	= MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
>  	}, {
> -		.fourcc = V4L2_PIX_FMT_YUV32,
> +		.fourcc = V4L2_PIX_FMT_VUYA32,
>  		.depth	= 32,
>  		.types	= MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
>  	}, {
> @@ -236,7 +236,7 @@ static u32 pxp_v4l2_pix_fmt_to_ps_format(u32 v4l2_pix_fmt)
>  	case V4L2_PIX_FMT_RGB555:  return BV_PXP_PS_CTRL_FORMAT__RGB555;
>  	case V4L2_PIX_FMT_RGB444:  return BV_PXP_PS_CTRL_FORMAT__RGB444;
>  	case V4L2_PIX_FMT_RGB565:  return BV_PXP_PS_CTRL_FORMAT__RGB565;
> -	case V4L2_PIX_FMT_YUV32:   return BV_PXP_PS_CTRL_FORMAT__YUV1P444;
> +	case V4L2_PIX_FMT_VUYA32:  return BV_PXP_PS_CTRL_FORMAT__YUV1P444;
>  	case V4L2_PIX_FMT_UYVY:    return BV_PXP_PS_CTRL_FORMAT__UYVY1P422;
>  	case V4L2_PIX_FMT_YUYV:    return BM_PXP_PS_CTRL_WB_SWAP |
>  					  BV_PXP_PS_CTRL_FORMAT__UYVY1P422;
> @@ -265,7 +265,7 @@ static u32 pxp_v4l2_pix_fmt_to_out_format(u32 v4l2_pix_fmt)
>  	case V4L2_PIX_FMT_RGB555:   return BV_PXP_OUT_CTRL_FORMAT__RGB555;
>  	case V4L2_PIX_FMT_RGB444:   return BV_PXP_OUT_CTRL_FORMAT__RGB444;
>  	case V4L2_PIX_FMT_RGB565:   return BV_PXP_OUT_CTRL_FORMAT__RGB565;
> -	case V4L2_PIX_FMT_YUV32:    return BV_PXP_OUT_CTRL_FORMAT__YUV1P444;
> +	case V4L2_PIX_FMT_VUYA32:   return BV_PXP_OUT_CTRL_FORMAT__YUV1P444;
>  	case V4L2_PIX_FMT_UYVY:     return BV_PXP_OUT_CTRL_FORMAT__UYVY1P422;
>  	case V4L2_PIX_FMT_VYUY:     return BV_PXP_OUT_CTRL_FORMAT__VYUY1P422;
>  	case V4L2_PIX_FMT_GREY:     return BV_PXP_OUT_CTRL_FORMAT__Y8;
> @@ -281,7 +281,7 @@ static u32 pxp_v4l2_pix_fmt_to_out_format(u32 v4l2_pix_fmt)
>  static bool pxp_v4l2_pix_fmt_is_yuv(u32 v4l2_pix_fmt)
>  {
>  	switch (v4l2_pix_fmt) {
> -	case V4L2_PIX_FMT_YUV32:
> +	case V4L2_PIX_FMT_VUYA32:
>  	case V4L2_PIX_FMT_UYVY:
>  	case V4L2_PIX_FMT_YUYV:
>  	case V4L2_PIX_FMT_VYUY:
> 