Linux Media Controller development
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>,
	bingbu.cao@intel.com, tian.shu.qiu@intel.com
Cc: linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com,
	tfiga@google.com
Subject: Re: [PATCH] media: staging: ipu3-imgu: Initialise height_per_slice in the stripes
Date: Tue, 21 Sep 2021 14:07:05 +0300	[thread overview]
Message-ID: <YUm82RNBbu9VbQj9@paasikivi.fi.intel.com> (raw)
In-Reply-To: <20210916172504.677919-1-jeanmichel.hautbois@ideasonboard.com>

Hi Jean-Michel --- and Bingbu and Tianshu,

On Thu, Sep 16, 2021 at 07:25:04PM +0200, Jean-Michel Hautbois wrote:
> While playing with low resolutions for the grid, it appeared that
> height_per_slice is not initialised if we are not using both stripes for
> the calculations. This pattern occurs three times:
> - for the awb_fr processing block
> - for the af processing block
> - for the awb processing block
> 
> The idea of this small portion of code is to reduce complexity in
> loading the statistics, it could be done also when only one stripe is
> used. Fix it by getting this initialisation code outside of the else()
> test case.
> 
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
> ---
>  drivers/staging/media/ipu3/ipu3-css-params.c | 44 ++++++++++----------
>  1 file changed, 22 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/staging/media/ipu3/ipu3-css-params.c b/drivers/staging/media/ipu3/ipu3-css-params.c
> index e9d6bd9e9332..05da7dbdca78 100644
> --- a/drivers/staging/media/ipu3/ipu3-css-params.c
> +++ b/drivers/staging/media/ipu3/ipu3-css-params.c
> @@ -2428,16 +2428,16 @@ int imgu_css_cfg_acc(struct imgu_css *css, unsigned int pipe,
>  					acc->awb_fr.stripes[1].grid_cfg.width,
>  					b_w_log2);
>  		acc->awb_fr.stripes[1].grid_cfg.x_end = end;
> -
> -		/*
> -		 * To reduce complexity of debubbling and loading
> -		 * statistics fix grid_height_per_slice to 1 for both
> -		 * stripes.
> -		 */
> -		for (i = 0; i < stripes; i++)
> -			acc->awb_fr.stripes[i].grid_cfg.height_per_slice = 1;
>  	}
>  
> +	/*
> +	 * To reduce complexity of debubbling and loading
> +	 * statistics fix grid_height_per_slice to 1 for both
> +	 * stripes.
> +	 */
> +	for (i = 0; i < stripes; i++)
> +		acc->awb_fr.stripes[i].grid_cfg.height_per_slice = 1;
> +
>  	if (imgu_css_awb_fr_ops_calc(css, pipe, &acc->awb_fr))
>  		return -EINVAL;
>  
> @@ -2591,15 +2591,15 @@ int imgu_css_cfg_acc(struct imgu_css *css, unsigned int pipe,
>  			imgu_css_grid_end(acc->af.stripes[1].grid_cfg.x_start,
>  					  acc->af.stripes[1].grid_cfg.width,
>  					  b_w_log2);
> -
> -		/*
> -		 * To reduce complexity of debubbling and loading statistics
> -		 * fix grid_height_per_slice to 1 for both stripes
> -		 */
> -		for (i = 0; i < stripes; i++)
> -			acc->af.stripes[i].grid_cfg.height_per_slice = 1;
>  	}
>  
> +	/*
> +	 * To reduce complexity of debubbling and loading statistics
> +	 * fix grid_height_per_slice to 1 for both stripes
> +	 */
> +	for (i = 0; i < stripes; i++)
> +		acc->af.stripes[i].grid_cfg.height_per_slice = 1;
> +
>  	if (imgu_css_af_ops_calc(css, pipe, &acc->af))
>  		return -EINVAL;
>  
> @@ -2660,15 +2660,15 @@ int imgu_css_cfg_acc(struct imgu_css *css, unsigned int pipe,
>  			imgu_css_grid_end(acc->awb.stripes[1].grid.x_start,
>  					  acc->awb.stripes[1].grid.width,
>  					  b_w_log2);
> -
> -		/*
> -		 * To reduce complexity of debubbling and loading statistics
> -		 * fix grid_height_per_slice to 1 for both stripes
> -		 */
> -		for (i = 0; i < stripes; i++)
> -			acc->awb.stripes[i].grid.height_per_slice = 1;
>  	}
>  
> +	/*
> +	 * To reduce complexity of debubbling and loading statistics
> +	 * fix grid_height_per_slice to 1 for both stripes
> +	 */
> +	for (i = 0; i < stripes; i++)
> +		acc->awb.stripes[i].grid.height_per_slice = 1;
> +
>  	if (imgu_css_awb_ops_calc(css, pipe, &acc->awb))
>  		return -EINVAL;
>  

While it seems like a sensible idea to initialise arguments to firmware, does this have an
effect on the statistics format? If so, can the existing user space cope
with that?

Bingbu, Tianshu, any insights on this?

-- 
Kind regards,

Sakari Ailus

  parent reply	other threads:[~2021-09-21 11:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 17:25 [PATCH] media: staging: ipu3-imgu: Initialise height_per_slice in the stripes Jean-Michel Hautbois
2021-09-16 19:35 ` Laurent Pinchart
2021-09-21 11:07 ` Sakari Ailus [this message]
2021-09-21 13:04   ` Jean-Michel Hautbois
2021-09-21 14:33     ` Laurent Pinchart
2021-09-22  4:33       ` Cao, Bingbu
2021-09-22  5:54         ` Jean-Michel Hautbois
2021-09-23  9:06           ` Cao, Bingbu
2021-09-23  9:45             ` Laurent Pinchart
2021-09-23 10:29               ` Cao, Bingbu
2021-09-23 10:49                 ` Laurent Pinchart
2021-09-23 11:56                   ` Jean-Michel Hautbois
2021-09-28  1:21                     ` Cao, Bingbu
2021-09-28  5:41                       ` Jean-Michel Hautbois
2021-10-04 23:58                         ` Laurent Pinchart
2021-10-11  1:05                           ` Cao, Bingbu
2021-09-30  9:31                   ` Jean-Michel Hautbois
2021-10-11  2:42                     ` Cao, Bingbu
2021-10-14  6:57                       ` Jean-Michel Hautbois
2021-10-14  8:14                         ` Cao, Bingbu
2021-10-16  1:27                           ` Laurent Pinchart
2023-08-09  4:11                         ` Bingbu Cao
2023-08-14 13:28                           ` Laurent Pinchart
2023-08-15  2:48                             ` Bingbu Cao

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=YUm82RNBbu9VbQj9@paasikivi.fi.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=bingbu.cao@intel.com \
    --cc=jeanmichel.hautbois@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=tfiga@google.com \
    --cc=tian.shu.qiu@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox