mbox series

[v2,00/18] Venus QoL / maintainability fixes

Message ID 20230228-topic-venus-v2-0-d95d14949c79@linaro.org
Headers show
Series Venus QoL / maintainability fixes | expand

Message

Konrad Dybcio May 4, 2023, 8 a.m. UTC 
v1 -> v2:
- Move "Write to VIDC_CTRL_INIT after unmasking interrupts" up and add
  a Fixes tag & Cc stable
- Reword the comment in "Correct IS_V6() checks"
- Move up "media: venus: Remap bufreq fields on HFI6XX", add Fixes and
  Cc stable
- Use better English in "Use newly-introduced hfi_buffer_requirements
  accessors" commit message
- Mention "Restrict writing SCIACMDARG3 to Venus V1/V2" doesn't seem to
  regress SM8250 in the commit message
- Pick up tags (note: I capitalized the R in Dikshita's 'reviewed-by'
  and removed one occurrence of random '**' to make sure review tools
  like b4 don't go crazy)
- Handle AR50_LITE in "Assign registers based on VPU version"
- Drop /* VPUn */ comments, they're invalid as explained by Vikash
- Take a different approach to the sys_idle problem in patch 1

v1: https://lore.kernel.org/r/20230228-topic-venus-v1-0-58c2c88384e9@linaro.org

Currently upstream assumes all (well, almost all - see 7280 or CrOS
specific checks) Venus implementations using the same version of the
Hardware Firmware Interface can be treated the same way. This is
however not the case.

This series tries to introduce the groundwork to start differentiating
them based on the VPU (Video Processing Unit) hardware type, fixes a
couple of issues that were an effect of that generalized assumption
and lays the foundation for supporting 8150 (IRIS1) and SM6115/QCM2290
(AR50 Lite), which will hopefully come soon.

Tested on 8250, but pretty please test it on your boards too!

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Konrad Dybcio (18):
      media: venus: hfi_venus: Only consider sys_idle_indicator on V1
      media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts
      media: venus: Remap bufreq fields on HFI6XX
      media: venus: Introduce VPU version distinction
      media: venus: Add vpu_version to most SoCs
      media: venus: firmware: Leave a clue for homegrown porters
      media: venus: hfi_venus: Sanitize venus_boot_core() per-VPU-version
      media: venus: core: Assign registers based on VPU version
      media: venus: hfi_venus: Fix version checks in venus_halt_axi()
      media: venus: hfi_venus: Fix version checks in venus_isr()
      media: venus: hfi_venus: Fix version check in venus_cpu_and_video_core_idle()
      media: venus: hfi_venus: Fix version check in venus_cpu_idle_and_pc_ready()
      media: venus: firmware: Correct IS_V6() checks
      media: venus: hfi_platform: Check vpu_version instead of device compatible
      media: venus: vdec: Fix version check in vdec_set_work_route()
      media: venus: Introduce accessors for remapped hfi_buffer_reqs members
      media: venus: Use newly-introduced hfi_buffer_requirements accessors
      media: venus: hfi_venus: Restrict writing SCIACMDARG3 to Venus V1/V2

 drivers/media/platform/qcom/venus/core.c           | 11 ++--
 drivers/media/platform/qcom/venus/core.h           | 15 ++++++
 drivers/media/platform/qcom/venus/firmware.c       | 19 +++++--
 drivers/media/platform/qcom/venus/helpers.c        |  7 +--
 drivers/media/platform/qcom/venus/hfi_helper.h     | 61 +++++++++++++++++++---
 drivers/media/platform/qcom/venus/hfi_msgs.c       |  2 +-
 .../media/platform/qcom/venus/hfi_plat_bufs_v6.c   | 22 ++++----
 drivers/media/platform/qcom/venus/hfi_platform.c   |  2 +-
 drivers/media/platform/qcom/venus/hfi_venus.c      | 45 ++++++++--------
 drivers/media/platform/qcom/venus/vdec.c           | 10 ++--
 drivers/media/platform/qcom/venus/vdec_ctrls.c     |  2 +-
 drivers/media/platform/qcom/venus/venc.c           |  4 +-
 drivers/media/platform/qcom/venus/venc_ctrls.c     |  2 +-
 13 files changed, 138 insertions(+), 64 deletions(-)
---
base-commit: 92e815cf07ed24ee1c51b122f24ffcf2964b4b13
change-id: 20230228-topic-venus-70ea3bc76688

Best regards,

Comments

Vikash Garodia May 5, 2023, 12:28 p.m. UTC | #1 
On 5/4/2023 1:30 PM, Konrad Dybcio wrote:
> As per information from Qualcomm [1], this property is not really
> supported beyond msm8916 (HFI V1) and some newer HFI versions really
> dislike receiving it, going as far as crashing the device.
>
> Only consider toggling it (via the module option) on HFIV1.
> While at it, get rid of the global static variable (which defaulted
> to zero) which was never explicitly assigned to for V1.
>
> Note: [1] is a reply to the actual message in question, as lore did not
> properly receive some of the emails..
>
> [1] https://lore.kernel.org/lkml/955cd520-3881-0c22-d818-13fe9a47e124@linaro.org/
> Fixes: 7ed9e0b3393c ("media: venus: hfi, vdec: v6 Add IS_V6() to existing IS_V4() if locations")
> Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
>   drivers/media/platform/qcom/venus/hfi_venus.c | 18 ++++++------------
>   1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
> index 2ad40b3945b0..bff435abd59b 100644
> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> @@ -131,7 +131,6 @@ struct venus_hfi_device {
>   
>   static bool venus_pkt_debug;
>   int venus_fw_debug = HFI_DEBUG_MSG_ERROR | HFI_DEBUG_MSG_FATAL;
> -static bool venus_sys_idle_indicator;
>   static bool venus_fw_low_power_mode = true;
>   static int venus_hw_rsp_timeout = 1000;
>   static bool venus_fw_coverage;
> @@ -947,17 +946,12 @@ static int venus_sys_set_default_properties(struct venus_hfi_device *hdev)
>   	if (ret)
>   		dev_warn(dev, "setting fw debug msg ON failed (%d)\n", ret);
>   
> -	/*
> -	 * Idle indicator is disabled by default on some 4xx firmware versions,
> -	 * enable it explicitly in order to make suspend functional by checking
> -	 * WFI (wait-for-interrupt) bit.
> -	 */
> -	if (IS_V4(hdev->core) || IS_V6(hdev->core))
> -		venus_sys_idle_indicator = true;
> -
> -	ret = venus_sys_set_idle_message(hdev, venus_sys_idle_indicator);
> -	if (ret)
> -		dev_warn(dev, "setting idle response ON failed (%d)\n", ret);
> +	/* HFI_PROPERTY_SYS_IDLE_INDICATOR is not supported beyond 8916 (HFI V1) */
> +	if (IS_V1(hdev->core)) {
> +		ret = venus_sys_set_idle_message(hdev, false);
> +		if (ret)
> +			dev_warn(dev, "setting idle response ON failed (%d)\n", ret);
> +	}

This property was enabled in video firmware for SDM845 by default from 
version #7. Need to confirm if patch[1]

was added before the default enablement in firmware. This patch need to 
be verified on SDM845 for suspend

functionality, before removing it for V4 to avoid power regression.

[1] 17cd3d1d2e52: media: venus: hfi_venus: add suspend functionality for 
Venus 4xx

-Vikash

>   
>   	ret = venus_sys_set_power_control(hdev, venus_fw_low_power_mode);
>   	if (ret)
>
Vikash Garodia May 5, 2023, 12:49 p.m. UTC | #2 
On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
> The Video Processing Unit hardware version is the differentiator,
> based on which we should decide which code paths to take in hw
we -> video driver
> init. Up until now, we've relied on HFI versions, but that was

not just hw init, aspects like power sequence, buffer calculations, etc 
would

rely on hardware version.

Once the above comments are addressed, you can put

Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>

> just a happy accident between recent SoCs. Add a field in the
> res struct and add correlated definitions that will be used to
> account for the aforementioned differences.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
>   drivers/media/platform/qcom/venus/core.h | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
> index 4f81669986ba..62c310b7dee6 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -48,6 +48,14 @@ struct bw_tbl {
>   	u32 peak_10bit;
>   };
>   
> +enum vpu_version {
> +	VPU_VERSION_AR50,
> +	VPU_VERSION_AR50_LITE,
> +	VPU_VERSION_IRIS1,
> +	VPU_VERSION_IRIS2,
> +	VPU_VERSION_IRIS2_1,
> +};
> +
>   struct venus_resources {
>   	u64 dma_mask;
>   	const struct freq_tbl *freq_tbl;
> @@ -71,6 +79,7 @@ struct venus_resources {
>   	const char * const resets[VIDC_RESETS_NUM_MAX];
>   	unsigned int resets_num;
>   	enum hfi_version hfi_version;
> +	enum vpu_version vpu_version;
>   	u8 num_vpp_pipes;
>   	u32 max_load;
>   	unsigned int vmem_id;
> @@ -481,6 +490,12 @@ struct venus_inst {
>   #define IS_V4(core)	((core)->res->hfi_version == HFI_VERSION_4XX)
>   #define IS_V6(core)	((core)->res->hfi_version == HFI_VERSION_6XX)
>   
> +#define IS_AR50(core)		((core)->res->vpu_version == VPU_VERSION_AR50)
> +#define IS_AR50_LITE(core)	((core)->res->vpu_version == VPU_VERSION_AR50_LITE)
> +#define IS_IRIS1(core)		((core)->res->vpu_version == VPU_VERSION_IRIS1)
> +#define IS_IRIS2(core)		((core)->res->vpu_version == VPU_VERSION_IRIS2)
> +#define IS_IRIS2_1(core)	((core)->res->vpu_version == VPU_VERSION_IRIS2_1)
> +
>   #define ctrl_to_inst(ctrl)	\
>   	container_of((ctrl)->handler, struct venus_inst, ctrl_handler)
>   
>
Vikash Garodia May 5, 2023, 12:52 p.m. UTC | #3 
On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
> Add vpu_version where I was able to retrieve the information to
> allow for more precise hardware-specific code path matching.
>
> Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> ---
>   drivers/media/platform/qcom/venus/core.c | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
> index 2ae867cb4c48..01671dd23888 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -684,6 +684,7 @@ static const struct venus_resources sdm845_res = {
>   	.vcodec_clks_num = 2,
>   	.max_load = 3110400,	/* 4096x2160@90 */
>   	.hfi_version = HFI_VERSION_4XX,
> +	.vpu_version = VPU_VERSION_AR50,
>   	.vmem_id = VIDC_RESOURCE_NONE,
>   	.vmem_size = 0,
>   	.vmem_addr = 0,
> @@ -709,6 +710,7 @@ static const struct venus_resources sdm845_res_v2 = {
>   	.vcodec_num = 2,
>   	.max_load = 3110400,	/* 4096x2160@90 */
>   	.hfi_version = HFI_VERSION_4XX,
> +	.vpu_version = VPU_VERSION_AR50,
>   	.vmem_id = VIDC_RESOURCE_NONE,
>   	.vmem_size = 0,
>   	.vmem_addr = 0,
> @@ -756,6 +758,7 @@ static const struct venus_resources sc7180_res = {
>   	.opp_pmdomain = (const char *[]) { "cx", NULL },
>   	.vcodec_num = 1,
>   	.hfi_version = HFI_VERSION_4XX,
> +	.vpu_version = VPU_VERSION_AR50,
>   	.vmem_id = VIDC_RESOURCE_NONE,
>   	.vmem_size = 0,
>   	.vmem_addr = 0,
> @@ -809,6 +812,7 @@ static const struct venus_resources sm8250_res = {
>   	.vcodec_num = 1,
>   	.max_load = 7833600,
>   	.hfi_version = HFI_VERSION_6XX,
> +	.vpu_version = VPU_VERSION_IRIS2,
>   	.num_vpp_pipes = 4,
>   	.vmem_id = VIDC_RESOURCE_NONE,
>   	.vmem_size = 0,
> @@ -866,6 +870,7 @@ static const struct venus_resources sc7280_res = {
>   	.opp_pmdomain = (const char *[]) { "cx", NULL },
>   	.vcodec_num = 1,
>   	.hfi_version = HFI_VERSION_6XX,
> +	.vpu_version = VPU_VERSION_IRIS2_1,
>   	.num_vpp_pipes = 1,
>   	.vmem_id = VIDC_RESOURCE_NONE,
>   	.vmem_size = 0,
>
Vikash Garodia May 5, 2023, 1:21 p.m. UTC | #4 
On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
> Only IRIS2(_1) should enter the until-now-IS_V6() path and the
> condition for skipping part of it should be IS_IRIS2_1 and not the
> number of VPP pipes. Fix that.

Do not see any issue with existing code. IRIS2 with single pipe is 
IRIS2_1. This does not

quality as a fix to earlier implementation. Since this series introduces 
VPU versions,

IRIS2 with 1 pipe is being replaced with IRIS2_1.

-Vikash

>
> Fixes: 4b0b6e147dc9 ("media: venus: hfi: Add 6xx AXI halt logic")
> Fixes: 78d434ba8659 ("media: venus: hfi: Skip AON register programming for V6 1pipe")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
>   drivers/media/platform/qcom/venus/hfi_venus.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
> index 9b840440a115..ca56b1a8eb71 100644
> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> @@ -549,10 +549,10 @@ static int venus_halt_axi(struct venus_hfi_device *hdev)
>   	u32 mask_val;
>   	int ret;
>   
> -	if (IS_V6(hdev->core)) {
> +	if (IS_IRIS2(hdev->core) || IS_IRIS2_1(hdev->core)) {
>   		writel(0x3, cpu_cs_base + CPU_CS_X2RPMH_V6);
>   
> -		if (hdev->core->res->num_vpp_pipes == 1)
> +		if (IS_IRIS2_1(hdev->core))
>   			goto skip_aon_mvp_noc;
>   
>   		writel(0x1, aon_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
>
Vikash Garodia May 5, 2023, 1:36 p.m. UTC | #5 
On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
> IS_V6() should have instead checked for specific VPU versions. Fix it.

This is again not a fix. The patch just adds a video hardware AR50_LITE, 
which is

not supported on existing driver yet. With existing code, IS_V6 covers 
the video

hardwares which are enabled by the driver.

-Vikash

>
> Fixes: e396e75fc254 ("media: venus: hfi: Read WRAPPER_TZ_CPU_STATUS_V6 on 6xx")
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
>   drivers/media/platform/qcom/venus/hfi_venus.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
> index 6d5906fab800..82aa7deeafa1 100644
> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> @@ -1537,7 +1537,7 @@ static bool venus_cpu_and_video_core_idle(struct venus_hfi_device *hdev)
>   	void __iomem *cpu_cs_base = hdev->core->cpu_cs_base;
>   	u32 ctrl_status, cpu_status;
>   
> -	if (IS_V6(hdev->core))
> +	if (IS_AR50_LITE(hdev->core) || IS_IRIS2(hdev->core) || IS_IRIS2_1(hdev->core))
>   		cpu_status = readl(wrapper_tz_base + WRAPPER_TZ_CPU_STATUS_V6);
>   	else
>   		cpu_status = readl(wrapper_base + WRAPPER_CPU_STATUS);
>
Vikash Garodia May 5, 2023, 1:47 p.m. UTC | #6 
On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
> This is not a matter of the host SoC, but the VPU chip in Venus. Fix it.
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> ---
>   drivers/media/platform/qcom/venus/hfi_platform.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_platform.c b/drivers/media/platform/qcom/venus/hfi_platform.c
> index f07f554bc5fe..d163d5b0e6b7 100644
> --- a/drivers/media/platform/qcom/venus/hfi_platform.c
> +++ b/drivers/media/platform/qcom/venus/hfi_platform.c
> @@ -80,7 +80,7 @@ hfi_platform_get_codecs(struct venus_core *core, u32 *enc_codecs, u32 *dec_codec
>   	if (plat->codecs)
>   		plat->codecs(enc_codecs, dec_codecs, count);
>   
> -	if (of_device_is_compatible(core->dev->of_node, "qcom,sc7280-venus")) {
> +	if (IS_IRIS2_1(core)) {
>   		*enc_codecs &= ~HFI_VIDEO_CODEC_VP8;
>   		*dec_codecs &= ~HFI_VIDEO_CODEC_VP8;
>   	}
>
Vikash Garodia May 5, 2023, 2:02 p.m. UTC | #7 
On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
> This is not so much V6-dependent as it's IRIS(1|2|2_1). Fix it.
Again, why is it marked as fix ?
>
> Fixes: 6483a8cbea54 ("media: venus: vdec: set work route to fw")
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
>   drivers/media/platform/qcom/venus/vdec.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
> index 51a53bf82bd3..33e3f7208b1a 100644
> --- a/drivers/media/platform/qcom/venus/vdec.c
> +++ b/drivers/media/platform/qcom/venus/vdec.c
> @@ -701,7 +701,7 @@ static int vdec_set_work_route(struct venus_inst *inst)
>   	u32 ptype = HFI_PROPERTY_PARAM_WORK_ROUTE;
>   	struct hfi_video_work_route wr;
>   
> -	if (!IS_V6(inst->core))
> +	if (!(IS_IRIS1(inst->core) || IS_IRIS2(inst->core) || IS_IRIS2_1(inst->core)))

Not a good idea to add IRIS1 just for deciding work route and not at 
other places in driver. Add IRIS1 relevant

code in other aspects as well, if the patch needs to handle anything 
w.r.t IRIS1.

>   		return 0;
>   
>   	wr.video_work_route = inst->core->res->num_vpp_pipes;
>
Dmitry Baryshkov May 5, 2023, 2:43 p.m. UTC | #8 
On Fri, 5 May 2023 at 16:22, Vikash Garodia <quic_vgarodia@quicinc.com> wrote:
>
>
> On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
> > Only IRIS2(_1) should enter the until-now-IS_V6() path and the
> > condition for skipping part of it should be IS_IRIS2_1 and not the
> > number of VPP pipes. Fix that.
>
> Do not see any issue with existing code. IRIS2 with single pipe is
> IRIS2_1. This does not
>
> quality as a fix to earlier implementation. Since this series introduces
> VPU versions,
>
> IRIS2 with 1 pipe is being replaced with IRIS2_1.

Could you please fix the line wrapping of your emails. It becomes hard
to read them otherwise.
Vikash Garodia May 5, 2023, 3:28 p.m. UTC | #9 
On 5/5/2023 8:13 PM, Dmitry Baryshkov wrote:
> On Fri, 5 May 2023 at 16:22, Vikash Garodia <quic_vgarodia@quicinc.com> wrote:
>>
>> On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
>>> Only IRIS2(_1) should enter the until-now-IS_V6() path and the
>>> condition for skipping part of it should be IS_IRIS2_1 and not the
>>> number of VPP pipes. Fix that.
>> Do not see any issue with existing code. IRIS2 with single pipe is
>> IRIS2_1. This does not
>>
>> quality as a fix to earlier implementation. Since this series introduces
>> VPU versions,
>>
>> IRIS2 with 1 pipe is being replaced with IRIS2_1.
> Could you please fix the line wrapping of your emails. It becomes hard
> to read them otherwise.

My apologies for the inconvenience. Tried to set the email wrap config, but it 
does not take

an effect on my email client. Will try playing around a bit with it and fix it.

Meanwhile go through the comments and if you can align them with minimal effort, we

can continue to discuss on the same.

-Vikash

>
>
Konrad Dybcio May 5, 2023, 7:12 p.m. UTC | #10 
On 5.05.2023 15:21, Vikash Garodia wrote:
> 
> On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
>> Only IRIS2(_1) should enter the until-now-IS_V6() path and the
>> condition for skipping part of it should be IS_IRIS2_1 and not the
>> number of VPP pipes. Fix that.
> 
> Do not see any issue with existing code. IRIS2 with single pipe is IRIS2_1. This does not
> 
> quality as a fix to earlier implementation. Since this series introduces VPU versions,
> 
> IRIS2 with 1 pipe is being replaced with IRIS2_1.
> 
> -Vikash
Right, I'll drop the fixes tags.

Also, your email client seems to be inserting 2 newlines instead of 1.
If you're using thunderbird, you may want to edit:

mail.identity.(default or your mail identity idx).default.compose_html

to `false`

or you can use shift+enter as a half-measure

Konrad
> 
>>
>> Fixes: 4b0b6e147dc9 ("media: venus: hfi: Add 6xx AXI halt logic")
>> Fixes: 78d434ba8659 ("media: venus: hfi: Skip AON register programming for V6 1pipe")
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
>>   drivers/media/platform/qcom/venus/hfi_venus.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
>> index 9b840440a115..ca56b1a8eb71 100644
>> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
>> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
>> @@ -549,10 +549,10 @@ static int venus_halt_axi(struct venus_hfi_device *hdev)
>>       u32 mask_val;
>>       int ret;
>>   -    if (IS_V6(hdev->core)) {
>> +    if (IS_IRIS2(hdev->core) || IS_IRIS2_1(hdev->core)) {
>>           writel(0x3, cpu_cs_base + CPU_CS_X2RPMH_V6);
>>   -        if (hdev->core->res->num_vpp_pipes == 1)
>> +        if (IS_IRIS2_1(hdev->core))
>>               goto skip_aon_mvp_noc;
>>             writel(0x1, aon_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
>>
Konrad Dybcio May 5, 2023, 7:14 p.m. UTC | #11 
On 5.05.2023 15:36, Vikash Garodia wrote:
> 
> On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
>> IS_V6() should have instead checked for specific VPU versions. Fix it.
> 
> This is again not a fix. The patch just adds a video hardware AR50_LITE, which is
> 
> not supported on existing driver yet. With existing code, IS_V6 covers the video
> 
> hardwares which are enabled by the driver.
ack

Konrad
> 
> -Vikash
> 
>>
>> Fixes: e396e75fc254 ("media: venus: hfi: Read WRAPPER_TZ_CPU_STATUS_V6 on 6xx")
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
>>   drivers/media/platform/qcom/venus/hfi_venus.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
>> index 6d5906fab800..82aa7deeafa1 100644
>> --- a/drivers/media/platform/qcom/venus/hfi_venus.c
>> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
>> @@ -1537,7 +1537,7 @@ static bool venus_cpu_and_video_core_idle(struct venus_hfi_device *hdev)
>>       void __iomem *cpu_cs_base = hdev->core->cpu_cs_base;
>>       u32 ctrl_status, cpu_status;
>>   -    if (IS_V6(hdev->core))
>> +    if (IS_AR50_LITE(hdev->core) || IS_IRIS2(hdev->core) || IS_IRIS2_1(hdev->core))
>>           cpu_status = readl(wrapper_tz_base + WRAPPER_TZ_CPU_STATUS_V6);
>>       else
>>           cpu_status = readl(wrapper_base + WRAPPER_CPU_STATUS);
>>
Konrad Dybcio May 5, 2023, 7:15 p.m. UTC | #12 
On 5.05.2023 16:02, Vikash Garodia wrote:
> 
> On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
>> This is not so much V6-dependent as it's IRIS(1|2|2_1). Fix it.
> Again, why is it marked as fix ?
It corrects the logic but does not manifest on currently
supported hardware. I'll reword it and drop the fixes tag.

>>
>> Fixes: 6483a8cbea54 ("media: venus: vdec: set work route to fw")
>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> ---
>>   drivers/media/platform/qcom/venus/vdec.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
>> index 51a53bf82bd3..33e3f7208b1a 100644
>> --- a/drivers/media/platform/qcom/venus/vdec.c
>> +++ b/drivers/media/platform/qcom/venus/vdec.c
>> @@ -701,7 +701,7 @@ static int vdec_set_work_route(struct venus_inst *inst)
>>       u32 ptype = HFI_PROPERTY_PARAM_WORK_ROUTE;
>>       struct hfi_video_work_route wr;
>>   -    if (!IS_V6(inst->core))
>> +    if (!(IS_IRIS1(inst->core) || IS_IRIS2(inst->core) || IS_IRIS2_1(inst->core)))
> 
> Not a good idea to add IRIS1 just for deciding work route and not at other places in driver. Add IRIS1 relevant
> 
> code in other aspects as well, if the patch needs to handle anything w.r.t IRIS1.
I'd say that correcting this condition is fair regardless. I can
however delay this patch until IRIS1 enablement if you'd prefer
that.

Konrad
> 
>>           return 0;
>>         wr.video_work_route = inst->core->res->num_vpp_pipes;
>>
Vikash Garodia May 9, 2023, 12:12 p.m. UTC | #13 
On 5/6/2023 12:45 AM, Konrad Dybcio wrote:
> 
> 
> On 5.05.2023 16:02, Vikash Garodia wrote:
>>
>> On 5/4/2023 1:31 PM, Konrad Dybcio wrote:
>>> This is not so much V6-dependent as it's IRIS(1|2|2_1). Fix it.
>> Again, why is it marked as fix ?
> It corrects the logic but does not manifest on currently
> supported hardware. I'll reword it and drop the fixes tag.
> 
>>>
>>> Fixes: 6483a8cbea54 ("media: venus: vdec: set work route to fw")
>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>> ---
>>>   drivers/media/platform/qcom/venus/vdec.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
>>> index 51a53bf82bd3..33e3f7208b1a 100644
>>> --- a/drivers/media/platform/qcom/venus/vdec.c
>>> +++ b/drivers/media/platform/qcom/venus/vdec.c
>>> @@ -701,7 +701,7 @@ static int vdec_set_work_route(struct venus_inst *inst)
>>>       u32 ptype = HFI_PROPERTY_PARAM_WORK_ROUTE;
>>>       struct hfi_video_work_route wr;
>>>   -    if (!IS_V6(inst->core))
>>> +    if (!(IS_IRIS1(inst->core) || IS_IRIS2(inst->core) || IS_IRIS2_1(inst->core)))
>>
>> Not a good idea to add IRIS1 just for deciding work route and not at other places in driver. Add IRIS1 relevant
>>
>> code in other aspects as well, if the patch needs to handle anything w.r.t IRIS1.
> I'd say that correcting this condition is fair regardless. I can
> however delay this patch until IRIS1 enablement if you'd prefer
> that.

Lets add IRIS1 along with other IRIS1 changes.

> Konrad
>>
>>>           return 0;
>>>         wr.video_work_route = inst->core->res->num_vpp_pipes;
>>>
Bryan O'Donoghue May 12, 2023, 3:01 a.m. UTC | #14 
On 04/05/2023 09:00, Konrad Dybcio wrote:
> Tested on 8250, but pretty please test it on your boards too!

What's the definition of test here ?

I ran this

ffplay -codec:video h264_v4l2m2m FantasticFour-ROTSS.mp4

and this

ffplay -codec:video vp8_v4l2m2m /mnt/big-buck-bunny_trailer.webm

on db410c with no errors. Then again I applied and disapplied the 8x8 
264 fix to that branch and saw no discernable difference so I'm not very 
confident we have good coverage.

@Stan @Vikash could you give some suggested tests for coverage here ?

@Konrad - get a db410c !

My superficial first-pass on this series looks good but, before giving a 
Tested-by here, I think we should define a set of coverage tests, run 
them - the upper end on sm8250 and lower end msm8916 "makes sense to me"

20? different gstreamer tests at different formats and different sizes 
on our selected platforms db410c, rb5, rb3 I have - also an 820 I 
haven't booted and an enforce sdm660.

Which tests will we use to validate this series and subsequent series to 
ensure we don't have more regressions ?

---
bod
Vikash Garodia May 16, 2023, 12:57 p.m. UTC | #15 
On 5/12/2023 8:31 AM, Bryan O'Donoghue wrote:
> On 04/05/2023 09:00, Konrad Dybcio wrote:
>> Tested on 8250, but pretty please test it on your boards too!
> 
> What's the definition of test here ?
> 
> I ran this
> 
> ffplay -codec:video h264_v4l2m2m FantasticFour-ROTSS.mp4
> 
> and this
> 
> ffplay -codec:video vp8_v4l2m2m /mnt/big-buck-bunny_trailer.webm
> 
> on db410c with no errors. Then again I applied and disapplied the 8x8 264 fix to
> that branch and saw no discernable difference so I'm not very confident we have
> good coverage.
> 
> @Stan @Vikash could you give some suggested tests for coverage here ?

I could think of below test aspects for this series
1. Suspend Resume
2. Concurrency test
3. Module load -> video usecase -> module unload -> module load -> video
usecase. This would ensure video firmware is reloaded and functional.
4. Video playback and encode for all supported resolution and codecs.
5. In general, video playback with more test content.

I would be testing the series with stability test suite on CrOS. That would be
either on sc7180 or sc7280 setup.

Konrad, you can post the new version as one patch needs to be dropped. Test can
be done on the new version. There are few patches in the series pending review,
which can be done in parallel.

-Vikash

> 
> @Konrad - get a db410c !
> 
> My superficial first-pass on this series looks good but, before giving a
> Tested-by here, I think we should define a set of coverage tests, run them - the
> upper end on sm8250 and lower end msm8916 "makes sense to me"
> 
> 20? different gstreamer tests at different formats and different sizes on our
> selected platforms db410c, rb5, rb3 I have - also an 820 I haven't booted and an
> enforce sdm660.
> 
> Which tests will we use to validate this series and subsequent series to ensure
> we don't have more regressions ?
> 
> ---
> bod
Konrad Dybcio May 17, 2023, 8:25 p.m. UTC | #16 
On 12.05.2023 05:01, Bryan O'Donoghue wrote:
> On 04/05/2023 09:00, Konrad Dybcio wrote:
>> Tested on 8250, but pretty please test it on your boards too!
> 
> What's the definition of test here ?
> 
> I ran this
> 
> ffplay -codec:video h264_v4l2m2m FantasticFour-ROTSS.mp4
> 
> and this
> 
> ffplay -codec:video vp8_v4l2m2m /mnt/big-buck-bunny_trailer.webm
> 
> on db410c with no errors. Then again I applied and disapplied the 8x8 264 fix to that branch and saw no discernable difference so I'm not very confident we have good coverage.
I don't think we have any coverage at all, especially considering
there were 1 or 2 patches fixing vdec not working at all in the past
few months.. Maybe CrOS has some internal pipelines for this.

> 
> @Stan @Vikash could you give some suggested tests for coverage here ?
> 
> @Konrad - get a db410c !
Don't think they're even made anymore!

> 
> My superficial first-pass on this series looks good but, before giving a Tested-by here, I think we should define a set of coverage tests, run them - the upper end on sm8250 and lower end msm8916 "makes sense to me"
> 
> 20? different gstreamer tests at different formats and different sizes on our selected platforms db410c, rb5, rb3 I have - also an 820 I haven't booted and an enforce sdm660.
> 
> Which tests will we use to validate this series and subsequent series to ensure we don't have more regressions ?
Personally I've done:

- boot and check if venus still probes and doesn't shout in dmesg
- decode and re-encode a H264 file

which is far from perfect..

Konrad
> 
> ---
> bod