All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
To: "Heiko Stübner" <heiko@sntech.de>,
	helen.koike@collabora.com, linux-media@vger.kernel.org,
	mchehab@kernel.org, Laurent.pinchart@ideasonboard.com,
	hverkuil@xs4all.nl
Cc: linux-rockchip@lists.infradead.org, ezequiel@collabora.com,
	christoph.muellner@theobroma-systems.com, tfiga@chromium.org
Subject: Re: [PATCH v4 3/3] media: rockchip: rkisp1: extend uapi array sizes
Date: Sat, 16 Jan 2021 14:34:43 +0100	[thread overview]
Message-ID: <1635e481-364a-f99b-8a0c-3d3e33440ed1@collabora.com> (raw)
In-Reply-To: <2554499.uZKlY2gecq@diego>



Am 16.01.21 um 12:57 schrieb Heiko Stübner:
> Hi Dafna,
> 
> Am Samstag, 16. Januar 2021, 10:05:39 CET schrieb Dafna Hirschfeld:
>> Am 16.01.21 um 00:52 schrieb Heiko Stübner:
>>> Am Freitag, 15. Januar 2021, 18:41:06 CET schrieb Dafna Hirschfeld:
>>>> Am 15.01.21 um 17:38 schrieb Heiko Stuebner:
>>>>> From: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
>>>>>
>>>>> Later variants of the rkisp1 block use more entries in some arrays:
>>>>>
>>>>> RKISP1_CIF_ISP_AE_MEAN_MAX                 25 -> 81
>>>>> RKISP1_CIF_ISP_HIST_BIN_N_MAX              16 -> 32
>>>>> RKISP1_CIF_ISP_GAMMA_OUT_MAX_SAMPLES       17 -> 34
>>>>> RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE 28 -> 81
>>>>
>>>> I see you didn't change the value for that define.
>>>
>>> In the below patch I find
>>>
>>> @@ -103,7 +111,9 @@
>>> * Histogram calculation
>>> */
>>> /* Last 3 values unused. */
>>> -#define RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE 28
>>> +#define RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE_V10 28
>>> +#define RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE_V12 81
>>> +#define RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE     RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE_V12
>>>
>>> so I'm not sure I understand what you mean except this.
>>
>> Opps, I somehow missed that.
>> But now since we have 81 entries, it makes no sense to
>> define it to 28 for V10 and documenting "Last 3 values unused" (see just above the definition).
>> We can set it just to 25, we have 56 (81-25) unused values anyway.
> 
> The rkisp1_hst_config() function iterates over its regs-array and accesses
> 4 weight values in each step and writing them to the register:
> 
> static const u32 hist_weight_regs[] = {
> 	RKISP1_CIF_ISP_HIST_WEIGHT_00TO30_V10, ... weight0-3
> 	RKISP1_CIF_ISP_HIST_WEIGHT_40TO21_V10, ... weight4-7
> 	RKISP1_CIF_ISP_HIST_WEIGHT_31TO12_V10, ... weight8-11
> 	RKISP1_CIF_ISP_HIST_WEIGHT_22TO03_V10, ... weight12-15
> 	RKISP1_CIF_ISP_HIST_WEIGHT_13TO43_V10, ... weight16-19
> 	RKISP1_CIF_ISP_HIST_WEIGHT_04TO34_V10, ... weight20-23
> 	RKISP1_CIF_ISP_HIST_WEIGHT_44_V10, ... weight24-27
> };
> 
> and yes the last step only uses 1 value to write to the register.
> But I guess if we really want to reduce the max value, we should move
> that last part into a separate write, so that we don't access parts we claim
> to not access ;-)
> 
>>>> The usage of it is a bit more complicated.
>>>> It is used in function rkisp1_hst_config.
>>>
>>> Yeah, though the for-loop iterates over 4*7 entry values, so stays
>>> below the RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE_V10 in all cases.
>>>
>>>
>>>> Actually the real number of weight values are 25 (5x5) for rk3399,
>>>> the last 3 are not used. I think that in order to support both
>>>> 5x5 and 9x9 the code in rkisp1-params.c should change. I'll
>>>> send a patch fixing it.
>>>
>>> If you look at my V12-patch [0] the weight handling is done different there
>>> and from the registers, it looks like they exchanges that part of the isp.
>>>
>>> [0] https://lore.kernel.org/linux-media/20210108193311.3423236-11-heiko@sntech.de/
>>> void rkisp1_hst_config_v12() as a search term
>>>
>>> [...]
>>
>> Right, there is no need to change the relevant code in rkisp1-param.c when setting the
>> RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE to 25.
> 
> ok, should we add a 4th patch fixing that and moving the last write out of the loop?

I think changing the related code in the rkisp1-params.c can be done later in a separate patch.
I think you can change it to 25 in the same patch that adds V12 support and write in the commit message
that because the array size is now 81, there is no point defining the grid size for V10 to 28
and in addition documenting that the last 3 values are not used.

Thanks,
Dafna

> 
> 
> Heiko
> 
>>>>> @@ -862,8 +898,16 @@ struct rkisp1_cif_isp_af_stat {
>>>>>      *
>>>>>      * @hist_bins: measured bin counters
>>>>>      *
>>>>> - * Measurement window divided into 16 sub-windows, set
>>>>> - * with ISP_HIST_XXX
>>>>> + * Measurement window divided into 16 sub-windows for V10/V10
>>>>> + * and 32 sub-windows for V12/V13, set with ISP_HIST_XXX
>>>>
>>>> It is actually not windows but histogram bins. Could you change it to:
>>>> "The histogram values divided into 16 bins for V10/V11 and 32 bins
>>>> for V12/V13. It is configured within the struct rkisp1_cif_isp_hst_config.
>>>
>>> I've changed this like your suggestions and will give a bit of time for
>>> the stuff above. But I guess I can send a v5 some time tomorrow?
>>>
>>>
>>> Thanks for your input
>>> Heiko
>>>
>>>
>>
> 
> 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
To: "Heiko Stübner" <heiko@sntech.de>,
	helen.koike@collabora.com, linux-media@vger.kernel.org,
	mchehab@kernel.org, Laurent.pinchart@ideasonboard.com,
	hverkuil@xs4all.nl
Cc: linux-rockchip@lists.infradead.org, tfiga@chromium.org,
	ezequiel@collabora.com, christoph.muellner@theobroma-systems.com
Subject: Re: [PATCH v4 3/3] media: rockchip: rkisp1: extend uapi array sizes
Date: Sat, 16 Jan 2021 14:34:43 +0100	[thread overview]
Message-ID: <1635e481-364a-f99b-8a0c-3d3e33440ed1@collabora.com> (raw)
In-Reply-To: <2554499.uZKlY2gecq@diego>



Am 16.01.21 um 12:57 schrieb Heiko Stübner:
> Hi Dafna,
> 
> Am Samstag, 16. Januar 2021, 10:05:39 CET schrieb Dafna Hirschfeld:
>> Am 16.01.21 um 00:52 schrieb Heiko Stübner:
>>> Am Freitag, 15. Januar 2021, 18:41:06 CET schrieb Dafna Hirschfeld:
>>>> Am 15.01.21 um 17:38 schrieb Heiko Stuebner:
>>>>> From: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
>>>>>
>>>>> Later variants of the rkisp1 block use more entries in some arrays:
>>>>>
>>>>> RKISP1_CIF_ISP_AE_MEAN_MAX                 25 -> 81
>>>>> RKISP1_CIF_ISP_HIST_BIN_N_MAX              16 -> 32
>>>>> RKISP1_CIF_ISP_GAMMA_OUT_MAX_SAMPLES       17 -> 34
>>>>> RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE 28 -> 81
>>>>
>>>> I see you didn't change the value for that define.
>>>
>>> In the below patch I find
>>>
>>> @@ -103,7 +111,9 @@
>>> * Histogram calculation
>>> */
>>> /* Last 3 values unused. */
>>> -#define RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE 28
>>> +#define RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE_V10 28
>>> +#define RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE_V12 81
>>> +#define RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE     RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE_V12
>>>
>>> so I'm not sure I understand what you mean except this.
>>
>> Opps, I somehow missed that.
>> But now since we have 81 entries, it makes no sense to
>> define it to 28 for V10 and documenting "Last 3 values unused" (see just above the definition).
>> We can set it just to 25, we have 56 (81-25) unused values anyway.
> 
> The rkisp1_hst_config() function iterates over its regs-array and accesses
> 4 weight values in each step and writing them to the register:
> 
> static const u32 hist_weight_regs[] = {
> 	RKISP1_CIF_ISP_HIST_WEIGHT_00TO30_V10, ... weight0-3
> 	RKISP1_CIF_ISP_HIST_WEIGHT_40TO21_V10, ... weight4-7
> 	RKISP1_CIF_ISP_HIST_WEIGHT_31TO12_V10, ... weight8-11
> 	RKISP1_CIF_ISP_HIST_WEIGHT_22TO03_V10, ... weight12-15
> 	RKISP1_CIF_ISP_HIST_WEIGHT_13TO43_V10, ... weight16-19
> 	RKISP1_CIF_ISP_HIST_WEIGHT_04TO34_V10, ... weight20-23
> 	RKISP1_CIF_ISP_HIST_WEIGHT_44_V10, ... weight24-27
> };
> 
> and yes the last step only uses 1 value to write to the register.
> But I guess if we really want to reduce the max value, we should move
> that last part into a separate write, so that we don't access parts we claim
> to not access ;-)
> 
>>>> The usage of it is a bit more complicated.
>>>> It is used in function rkisp1_hst_config.
>>>
>>> Yeah, though the for-loop iterates over 4*7 entry values, so stays
>>> below the RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE_V10 in all cases.
>>>
>>>
>>>> Actually the real number of weight values are 25 (5x5) for rk3399,
>>>> the last 3 are not used. I think that in order to support both
>>>> 5x5 and 9x9 the code in rkisp1-params.c should change. I'll
>>>> send a patch fixing it.
>>>
>>> If you look at my V12-patch [0] the weight handling is done different there
>>> and from the registers, it looks like they exchanges that part of the isp.
>>>
>>> [0] https://lore.kernel.org/linux-media/20210108193311.3423236-11-heiko@sntech.de/
>>> void rkisp1_hst_config_v12() as a search term
>>>
>>> [...]
>>
>> Right, there is no need to change the relevant code in rkisp1-param.c when setting the
>> RKISP1_CIF_ISP_HISTOGRAM_WEIGHT_GRIDS_SIZE to 25.
> 
> ok, should we add a 4th patch fixing that and moving the last write out of the loop?

I think changing the related code in the rkisp1-params.c can be done later in a separate patch.
I think you can change it to 25 in the same patch that adds V12 support and write in the commit message
that because the array size is now 81, there is no point defining the grid size for V10 to 28
and in addition documenting that the last 3 values are not used.

Thanks,
Dafna

> 
> 
> Heiko
> 
>>>>> @@ -862,8 +898,16 @@ struct rkisp1_cif_isp_af_stat {
>>>>>      *
>>>>>      * @hist_bins: measured bin counters
>>>>>      *
>>>>> - * Measurement window divided into 16 sub-windows, set
>>>>> - * with ISP_HIST_XXX
>>>>> + * Measurement window divided into 16 sub-windows for V10/V10
>>>>> + * and 32 sub-windows for V12/V13, set with ISP_HIST_XXX
>>>>
>>>> It is actually not windows but histogram bins. Could you change it to:
>>>> "The histogram values divided into 16 bins for V10/V11 and 32 bins
>>>> for V12/V13. It is configured within the struct rkisp1_cif_isp_hst_config.
>>>
>>> I've changed this like your suggestions and will give a bit of time for
>>> the stuff above. But I guess I can send a v5 some time tomorrow?
>>>
>>>
>>> Thanks for your input
>>> Heiko
>>>
>>>
>>
> 
> 
> 
> 

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2021-01-16 17:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 16:38 [PATCH v4 0/3] Fix the rkisp1 userspace API for later IP versions Heiko Stuebner
2021-01-15 16:38 ` Heiko Stuebner
2021-01-15 16:38 ` [PATCH v4 1/3] media: rockchip: rkisp1: fix comment about number of histogram sub-windows Heiko Stuebner
2021-01-15 16:38   ` Heiko Stuebner
2021-01-15 16:38 ` [PATCH v4 2/3] media: rockchip: rkisp1: carry ip version information Heiko Stuebner
2021-01-15 16:38   ` Heiko Stuebner
2021-01-15 19:42   ` Laurent Pinchart
2021-01-15 19:42     ` Laurent Pinchart
2021-01-15 20:29     ` Heiko Stübner
2021-01-15 20:29       ` Heiko Stübner
2021-01-18  9:19       ` Dafna Hirschfeld
2021-01-18  9:19         ` Dafna Hirschfeld
2021-01-18  9:21         ` Heiko Stübner
2021-01-18  9:21           ` Heiko Stübner
2021-01-18  9:27           ` Laurent Pinchart
2021-01-18  9:27             ` Laurent Pinchart
2021-01-15 16:38 ` [PATCH v4 3/3] media: rockchip: rkisp1: extend uapi array sizes Heiko Stuebner
2021-01-15 16:38   ` Heiko Stuebner
2021-01-15 17:41   ` Dafna Hirschfeld
2021-01-15 17:41     ` Dafna Hirschfeld
2021-01-15 23:52     ` Heiko Stübner
2021-01-15 23:52       ` Heiko Stübner
2021-01-16  9:05       ` Dafna Hirschfeld
2021-01-16  9:05         ` Dafna Hirschfeld
2021-01-16 11:57         ` Heiko Stübner
2021-01-16 11:57           ` Heiko Stübner
2021-01-16 13:34           ` Dafna Hirschfeld [this message]
2021-01-16 13:34             ` Dafna Hirschfeld

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=1635e481-364a-f99b-8a0c-3d3e33440ed1@collabora.com \
    --to=dafna.hirschfeld@collabora.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=christoph.muellner@theobroma-systems.com \
    --cc=ezequiel@collabora.com \
    --cc=heiko@sntech.de \
    --cc=helen.koike@collabora.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mchehab@kernel.org \
    --cc=tfiga@chromium.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.