All of lore.kernel.org
 help / color / mirror / Atom feed
From: josh.wu@atmel.com (Josh Wu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/5] media: atmel-isi: support RGB565 output when sensor output YUV formats
Date: Mon, 19 Oct 2015 10:50:44 +0800	[thread overview]
Message-ID: <56245A84.6070907@atmel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1510190357000.26684@axis700.grange>

Dear Guennadi,

On 10/19/2015 10:03 AM, Guennadi Liakhovetski wrote:
> Hi Josh,
>
> On Wed, 14 Oct 2015, Josh Wu wrote:
>
>> Dear Guennadi,
>>
>> Thanks for the review.
>>
>> On 10/5/2015 1:02 AM, Guennadi Liakhovetski wrote:
>>> On Tue, 22 Sep 2015, Josh Wu wrote:
>>>
>>>> This patch enable Atmel ISI preview path to convert the YUV to RGB format.
>>>>
>>>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
>>>> ---
>>>>
>>>>    drivers/media/platform/soc_camera/atmel-isi.c | 38
>>>> ++++++++++++++++++++-------
>>>>    1 file changed, 29 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
>>>> b/drivers/media/platform/soc_camera/atmel-isi.c
>>>> index e87d354..e33a16a 100644
>>>> --- a/drivers/media/platform/soc_camera/atmel-isi.c
>>>> +++ b/drivers/media/platform/soc_camera/atmel-isi.c
>>>> @@ -201,13 +201,20 @@ static bool is_supported(struct soc_camera_device
>>>> *icd,
>>>>    	case V4L2_PIX_FMT_UYVY:
>>>>    	case V4L2_PIX_FMT_YVYU:
>>>>    	case V4L2_PIX_FMT_VYUY:
>>>> +	/* RGB */
>>>> +	case V4L2_PIX_FMT_RGB565:
>>>>    		return true;
>>>> -	/* RGB, TODO */
>>>>    	default:
>>>>    		return false;
>>>>    	}
>>>>    }
>>>>    +static bool is_output_rgb(const struct soc_mbus_pixelfmt *host_fmt)
>>>> +{
>>>> +	return host_fmt->fourcc == V4L2_PIX_FMT_RGB565 ||
>>>> +			host_fmt->fourcc == V4L2_PIX_FMT_RGB32;
>>>> +}
>>>> +
>>> Why not just pass fourcc to this function? Or maybe just embed it in
>>> start_streaming - it won't clutter it a lot.
>> I think pass fourcc to the function is good.
>> Since configure_geometry() is hardware related, and the enable_preview_path is
>> also hardware related, so I prefer initialize enable_preview_path in
>> configure_geometry().
> But you don't, you do it in start_streaming() below.

Right, then I'll move it to configure_geometry() in v2..

> But actually my
> comment was not about _where_ to do it, but whether this calculation is
> worth a separate function. I would just perform this calculation directly
> where you're calling it:
>
> static ... start_streaming(...)
> {
> 	...
> 	u32 fourcc = icd->current_fmt->host_fmt->fourcc;
>
> 	isi->enable_preview_path = fourcc == V4L2_PIX_FMT_RGB565 ||
> 				fourcc == V4L2_PIX_FMT_RGB32;

I thought this "function" might be called in other place, but actually 
no one call it.
So yes, I think there is no need to have such separated function. I'll 
fix it in v2. Thanks.

Best Regards,
Josh Wu

>
> Thanks
> Guennadi
>
>>>>    static irqreturn_t atmel_isi_handle_streaming(struct atmel_isi *isi)
>>>>    {
>>>>    	if (isi->active) {
>>>> @@ -467,6 +474,8 @@ static int start_streaming(struct vb2_queue *vq,
>>>> unsigned int count)
>>>>    	struct atmel_isi *isi = ici->priv;
>>>>    	int ret;
>>>>    +	isi->enable_preview_path = is_output_rgb(icd->current_fmt->host_fmt);
>>>> +
>>>>    	pm_runtime_get_sync(ici->v4l2_dev.dev);
>>>>      	/* Reset ISI */
>>>> @@ -688,6 +697,14 @@ static const struct soc_mbus_pixelfmt
>>>> isi_camera_formats[] = {
>>>>    		.order			= SOC_MBUS_ORDER_LE,
>>>>    		.layout			= SOC_MBUS_LAYOUT_PACKED,
>>>>    	},
>>>> +	{
>>>> +		.fourcc			= V4L2_PIX_FMT_RGB565,
>>>> +		.name			= "RGB565",
>>>> +		.bits_per_sample	= 8,
>>>> +		.packing		= SOC_MBUS_PACKING_2X8_PADHI,
>>>> +		.order			= SOC_MBUS_ORDER_LE,
>>>> +		.layout			= SOC_MBUS_LAYOUT_PACKED,
>>>> +	},
>>>>    };
>>>>      /* This will be corrected as we get more formats */
>>>> @@ -744,7 +761,7 @@ static int isi_camera_get_formats(struct
>>>> soc_camera_device *icd,
>>>>    				  struct soc_camera_format_xlate *xlate)
>>>>    {
>>>>    	struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
>>>> -	int formats = 0, ret;
>>>> +	int formats = 0, ret, i, n;
>>>>    	/* sensor format */
>>>>    	struct v4l2_subdev_mbus_code_enum code = {
>>>>    		.which = V4L2_SUBDEV_FORMAT_ACTIVE,
>>>> @@ -778,13 +795,16 @@ static int isi_camera_get_formats(struct
>>>> soc_camera_device *icd,
>>>>    	case MEDIA_BUS_FMT_VYUY8_2X8:
>>>>    	case MEDIA_BUS_FMT_YUYV8_2X8:
>>>>    	case MEDIA_BUS_FMT_YVYU8_2X8:
>>>> -		formats++;
>>>> -		if (xlate) {
>>>> -			xlate->host_fmt	= &isi_camera_formats[0];
>>>> -			xlate->code	= code.code;
>>>> -			xlate++;
>>>> -			dev_dbg(icd->parent, "Providing format %s using code
>>>> %d\n",
>>>> -				isi_camera_formats[0].name, code.code);
>>>> +		n = ARRAY_SIZE(isi_camera_formats);
>>>> +		formats += n;
>>>> +		for (i = 0; i < n; i++) {
>>>> +			if (xlate) {
>>> I'd put if outside of the loop, or just do
>>>
>>> +		for (i = 0; xlate && i < n; i++) {
>> yes, that simpler one. I'll take it. Thanks.
>>
>> Best Regards,
>> Josh Wu
>>>
>>>> +				xlate->host_fmt	= &isi_camera_formats[i];
>>>> +				xlate->code	= code.code;
>>>> +				dev_dbg(icd->parent, "Providing format %s
>>>> using code %d\n",
>>>> +					isi_camera_formats[0].name,
>>>> code.code);
>>>> +				xlate++;
>>>> +			}
>>>>    		}
>>>>    		break;
>>>>    	default:
>>>> -- 
>>>> 1.9.1
>>>>

WARNING: multiple messages have this Message-ID (diff)
From: Josh Wu <josh.wu@atmel.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 5/5] media: atmel-isi: support RGB565 output when sensor output YUV formats
Date: Mon, 19 Oct 2015 10:50:44 +0800	[thread overview]
Message-ID: <56245A84.6070907@atmel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1510190357000.26684@axis700.grange>

Dear Guennadi,

On 10/19/2015 10:03 AM, Guennadi Liakhovetski wrote:
> Hi Josh,
>
> On Wed, 14 Oct 2015, Josh Wu wrote:
>
>> Dear Guennadi,
>>
>> Thanks for the review.
>>
>> On 10/5/2015 1:02 AM, Guennadi Liakhovetski wrote:
>>> On Tue, 22 Sep 2015, Josh Wu wrote:
>>>
>>>> This patch enable Atmel ISI preview path to convert the YUV to RGB format.
>>>>
>>>> Signed-off-by: Josh Wu <josh.wu@atmel.com>
>>>> ---
>>>>
>>>>    drivers/media/platform/soc_camera/atmel-isi.c | 38
>>>> ++++++++++++++++++++-------
>>>>    1 file changed, 29 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
>>>> b/drivers/media/platform/soc_camera/atmel-isi.c
>>>> index e87d354..e33a16a 100644
>>>> --- a/drivers/media/platform/soc_camera/atmel-isi.c
>>>> +++ b/drivers/media/platform/soc_camera/atmel-isi.c
>>>> @@ -201,13 +201,20 @@ static bool is_supported(struct soc_camera_device
>>>> *icd,
>>>>    	case V4L2_PIX_FMT_UYVY:
>>>>    	case V4L2_PIX_FMT_YVYU:
>>>>    	case V4L2_PIX_FMT_VYUY:
>>>> +	/* RGB */
>>>> +	case V4L2_PIX_FMT_RGB565:
>>>>    		return true;
>>>> -	/* RGB, TODO */
>>>>    	default:
>>>>    		return false;
>>>>    	}
>>>>    }
>>>>    +static bool is_output_rgb(const struct soc_mbus_pixelfmt *host_fmt)
>>>> +{
>>>> +	return host_fmt->fourcc == V4L2_PIX_FMT_RGB565 ||
>>>> +			host_fmt->fourcc == V4L2_PIX_FMT_RGB32;
>>>> +}
>>>> +
>>> Why not just pass fourcc to this function? Or maybe just embed it in
>>> start_streaming - it won't clutter it a lot.
>> I think pass fourcc to the function is good.
>> Since configure_geometry() is hardware related, and the enable_preview_path is
>> also hardware related, so I prefer initialize enable_preview_path in
>> configure_geometry().
> But you don't, you do it in start_streaming() below.

Right, then I'll move it to configure_geometry() in v2..

> But actually my
> comment was not about _where_ to do it, but whether this calculation is
> worth a separate function. I would just perform this calculation directly
> where you're calling it:
>
> static ... start_streaming(...)
> {
> 	...
> 	u32 fourcc = icd->current_fmt->host_fmt->fourcc;
>
> 	isi->enable_preview_path = fourcc == V4L2_PIX_FMT_RGB565 ||
> 				fourcc == V4L2_PIX_FMT_RGB32;

I thought this "function" might be called in other place, but actually 
no one call it.
So yes, I think there is no need to have such separated function. I'll 
fix it in v2. Thanks.

Best Regards,
Josh Wu

>
> Thanks
> Guennadi
>
>>>>    static irqreturn_t atmel_isi_handle_streaming(struct atmel_isi *isi)
>>>>    {
>>>>    	if (isi->active) {
>>>> @@ -467,6 +474,8 @@ static int start_streaming(struct vb2_queue *vq,
>>>> unsigned int count)
>>>>    	struct atmel_isi *isi = ici->priv;
>>>>    	int ret;
>>>>    +	isi->enable_preview_path = is_output_rgb(icd->current_fmt->host_fmt);
>>>> +
>>>>    	pm_runtime_get_sync(ici->v4l2_dev.dev);
>>>>      	/* Reset ISI */
>>>> @@ -688,6 +697,14 @@ static const struct soc_mbus_pixelfmt
>>>> isi_camera_formats[] = {
>>>>    		.order			= SOC_MBUS_ORDER_LE,
>>>>    		.layout			= SOC_MBUS_LAYOUT_PACKED,
>>>>    	},
>>>> +	{
>>>> +		.fourcc			= V4L2_PIX_FMT_RGB565,
>>>> +		.name			= "RGB565",
>>>> +		.bits_per_sample	= 8,
>>>> +		.packing		= SOC_MBUS_PACKING_2X8_PADHI,
>>>> +		.order			= SOC_MBUS_ORDER_LE,
>>>> +		.layout			= SOC_MBUS_LAYOUT_PACKED,
>>>> +	},
>>>>    };
>>>>      /* This will be corrected as we get more formats */
>>>> @@ -744,7 +761,7 @@ static int isi_camera_get_formats(struct
>>>> soc_camera_device *icd,
>>>>    				  struct soc_camera_format_xlate *xlate)
>>>>    {
>>>>    	struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
>>>> -	int formats = 0, ret;
>>>> +	int formats = 0, ret, i, n;
>>>>    	/* sensor format */
>>>>    	struct v4l2_subdev_mbus_code_enum code = {
>>>>    		.which = V4L2_SUBDEV_FORMAT_ACTIVE,
>>>> @@ -778,13 +795,16 @@ static int isi_camera_get_formats(struct
>>>> soc_camera_device *icd,
>>>>    	case MEDIA_BUS_FMT_VYUY8_2X8:
>>>>    	case MEDIA_BUS_FMT_YUYV8_2X8:
>>>>    	case MEDIA_BUS_FMT_YVYU8_2X8:
>>>> -		formats++;
>>>> -		if (xlate) {
>>>> -			xlate->host_fmt	= &isi_camera_formats[0];
>>>> -			xlate->code	= code.code;
>>>> -			xlate++;
>>>> -			dev_dbg(icd->parent, "Providing format %s using code
>>>> %d\n",
>>>> -				isi_camera_formats[0].name, code.code);
>>>> +		n = ARRAY_SIZE(isi_camera_formats);
>>>> +		formats += n;
>>>> +		for (i = 0; i < n; i++) {
>>>> +			if (xlate) {
>>> I'd put if outside of the loop, or just do
>>>
>>> +		for (i = 0; xlate && i < n; i++) {
>> yes, that simpler one. I'll take it. Thanks.
>>
>> Best Regards,
>> Josh Wu
>>>
>>>> +				xlate->host_fmt	= &isi_camera_formats[i];
>>>> +				xlate->code	= code.code;
>>>> +				dev_dbg(icd->parent, "Providing format %s
>>>> using code %d\n",
>>>> +					isi_camera_formats[0].name,
>>>> code.code);
>>>> +				xlate++;
>>>> +			}
>>>>    		}
>>>>    		break;
>>>>    	default:
>>>> -- 
>>>> 1.9.1
>>>>


  reply	other threads:[~2015-10-19  2:50 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22  5:14 [PATCH 0/5] media: atmel-isi: enable preview path to output RGB565 format Josh Wu
2015-09-22  5:14 ` Josh Wu
2015-09-22  5:14 ` [PATCH 1/5] media: atmel-isi: correct yuv swap according to different sensor outputs Josh Wu
2015-09-22  5:14   ` Josh Wu
2015-10-04 16:43   ` Guennadi Liakhovetski
2015-10-04 16:43     ` Guennadi Liakhovetski
2015-10-04 17:04     ` Guennadi Liakhovetski
2015-10-04 17:04       ` Guennadi Liakhovetski
2015-10-14  6:46       ` Josh Wu
2015-10-14  6:46         ` Josh Wu
2015-10-14  6:43     ` Josh Wu
2015-10-14  6:43       ` Josh Wu
2015-10-19  1:48       ` Guennadi Liakhovetski
2015-10-19  1:48         ` Guennadi Liakhovetski
2015-10-19  2:45         ` Josh Wu
2015-10-19  2:45           ` Josh Wu
2015-09-22  5:14 ` [PATCH 2/5] media: atmel-isi: prepare for the support of preview path Josh Wu
2015-09-22  5:14   ` Josh Wu
2015-09-22  5:14 ` [PATCH 3/5] media: atmel-isi: add code to setup correct resolution for " Josh Wu
2015-09-22  5:14   ` Josh Wu
2015-09-22  5:14 ` [PATCH 4/5] media: atmel-isi: setup YCC_SWAP correctly when using " Josh Wu
2015-09-22  5:14   ` Josh Wu
2015-10-04 16:50   ` Guennadi Liakhovetski
2015-10-04 16:50     ` Guennadi Liakhovetski
2015-10-14  6:44     ` Josh Wu
2015-10-14  6:44       ` Josh Wu
2015-09-22  5:14 ` [PATCH 5/5] media: atmel-isi: support RGB565 output when sensor output YUV formats Josh Wu
2015-09-22  5:14   ` Josh Wu
2015-10-04 17:02   ` Guennadi Liakhovetski
2015-10-04 17:02     ` Guennadi Liakhovetski
2015-10-14  6:57     ` Josh Wu
2015-10-14  6:57       ` Josh Wu
2015-10-19  2:03       ` Guennadi Liakhovetski
2015-10-19  2:03         ` Guennadi Liakhovetski
2015-10-19  2:50         ` Josh Wu [this message]
2015-10-19  2:50           ` Josh Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56245A84.6070907@atmel.com \
    --to=josh.wu@atmel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.