[PATCH v8 0/3] media: venus: enable venus on qcs615

[PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

QCS615 uses the same video core as SC7180, so reuse the same resource
data of SC7180 for QCS615 to enable video functionality.

There are no resources for the video-decoder and video-encoder nodes
in the device tree, so remove these two nodes from the device tree. In
addition, to ensure that the video codec functions properly, use [3]
to add encoder and decoder node entries in the venus driver.

Validated this series on QCS615 and SC7180.

Note:
This series consist of DT patches and a venus driver patch. The patch
1/3, which is venus driver patch, can be picked independently without
having any functional dependency. But patch 2/3 & patch 3/3, which are
DT patches, still depend on [1].

[1] https://lore.kernel.org/all/20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com

Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
---
Changes in v8:
- 1. Add missing tags.
- 2. Fix the dependency to point to videoCC series alone.
- 3. Fix review comments from Konrad.
- Link to v7: https://lore.kernel.org/r/20250527-add-venus-for-qcs615-v7-0-cca26e2768e3@quicinc.com

Changes in v7:
- 1. Update devicetree patch to fix the cherry-pick patch conflict issue.
- 2. Remove dt-bindings patch from this patch series due to it has been
picked.
- Link to v6: https://lore.kernel.org/r/20241219-add-venus-for-qcs615-v6-0-e9a74d3b003d@quicinc.com

Changes in v6:
- 1. Remove video-decoder and video-encoder nodes from the device tree
- 2. Add a new dependency.
- 3. Fix missing tag.
- 4. Update commit message.
- Link to v5: https://lore.kernel.org/r/20241217-add-venus-for-qcs615-v5-0-747395d9e630@quicinc.com

Changes in v5:
- 1. Remove extra blank lines in yaml files.
- 2. Add new variables in the driver while keeping the order of the
original variables. And remove unnecessary variable initialization.
- 3. Update commit message.
- 4. Update the order of nodes in the device tree.
- Link to v4: https://lore.kernel.org/r/20241213-add-venus-for-qcs615-v4-0-7e2c9a72d309@quicinc.com

Changes in v4:
- 1. Remove qcom,qcs615-venus.yaml and use qcom,sc7180-venus.yaml for
qcs615 dt-bindings.
- 2. Add "qcom,qcs615-venus" compatible into qcom,sc7180-venus.yaml.
- 3. Remove qcs615 resource from the driver and use sc7180 resource for
the qcs615.
- 4. Use the frequency in the opp-table in devicetree for the driver.
For compatibility, if getting data from the opp table fails, the data
in the frequency table will be used.
- 5. Keep the reverse Christmas tree order coding style.
- 6. Add "qcom,sc7180-venus" compatible in devicetree.
- 7. Update cover letter message.
- Link to v3: https://lore.kernel.org/r/20241125-add-venus-for-qcs615-v3-0-5a376b97a68e@quicinc.com

Changes in v3:
- 1. Remove the ‘|’ after 'description' in the qcom,qcs615-venus.yaml.
- 2. Add a blank line before 'opp-table' in the qcom,qcs615-venus.yaml.
- 3. Put ‘additionalProperties’ before ‘properties’ in the
qcom,qcs615-venus.yaml.
- 4. Update the subject of qcom,qcs615-venus.yaml patch.
- Link to v2: https://lore.kernel.org/r/20241112-add-venus-for-qcs615-v2-0-e67947f957af@quicinc.com

Changes in v2:
- 1. The change-id of DT and driver are removed.
- 2. Add qcom,qcs615-venus.yaml files to explain DT.
- 3. The order of driver's commit and DT's commit is adjusted. Place the
driver's commit before the DT's commit.
- 4. Extends driver's commit message.
- 5. Split DT's commit into two commits. Add the venus node to the
qcs615.dtsi file. Then in the qcs615-ride.dts file enable the venus node.
- 6. Modify alignment, sort, upper and lower case letters issue.
- 7. Update cover letter message description.
- Link to v1: https://lore.kernel.org/r/20241008-add_qcs615_video-v1-0-436ce07bfc63@quicinc.com

---
Renjiang Han (3):
      media: venus: pm_helpers: use opp-table for the frequency
      arm64: dts: qcom: qcs615: add venus node to devicetree
      arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec

 arch/arm64/boot/dts/qcom/qcs615-ride.dts       |  4 ++
 arch/arm64/boot/dts/qcom/qcs615.dtsi           | 78 ++++++++++++++++++++++++++
 drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++-----
 3 files changed, 121 insertions(+), 14 deletions(-)
---
base-commit: 176e917e010cb7dcc605f11d2bc33f304292482b
change-id: 20250526-add-venus-for-qcs615-a547540656d1
prerequisite-message-id: <20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com>
prerequisite-patch-id: afd2dce9e6066b1f6ce0b41ceafe0dd47ad97c40
prerequisite-patch-id: f8d64c8cf6cd883dc7bbb2a4ed6d5a4db85c536d

Best regards,
-- 
Renjiang Han <quic_renjiang@quicinc.com>

[PATCH v8 1/3] media: venus: pm_helpers: use opp-table for the frequency

[Renjiang Han]

The frequency value in the opp-table in the device tree and the freq_tbl
in the driver are the same.

Therefore, update pm_helpers.c to use the opp-table for frequency values
for the v4 core.
If getting data from the opp table fails, fall back to using the frequency
table.

Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
---
 drivers/media/platform/qcom/venus/pm_helpers.c | 53 +++++++++++++++++++-------
 1 file changed, 39 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
index 409aa9bd0b5d099c993eedb03177ec5ed918b4a0..434dd66076e8faf7f3feac6c29152789f8d2f81b 100644
--- a/drivers/media/platform/qcom/venus/pm_helpers.c
+++ b/drivers/media/platform/qcom/venus/pm_helpers.c
@@ -43,14 +43,20 @@ static int core_clks_enable(struct venus_core *core)
 	const struct venus_resources *res = core->res;
 	const struct freq_tbl *freq_tbl = core->res->freq_tbl;
 	unsigned int freq_tbl_size = core->res->freq_tbl_size;
+	struct device *dev = core->dev;
+	struct dev_pm_opp *opp;
 	unsigned long freq;
 	unsigned int i;
 	int ret;
 
-	if (!freq_tbl)
-		return -EINVAL;
-
-	freq = freq_tbl[freq_tbl_size - 1].freq;
+	opp = dev_pm_opp_find_freq_ceil(dev, &freq);
+	if (IS_ERR(opp)) {
+		if (!freq_tbl)
+			return -EINVAL;
+		freq = freq_tbl[freq_tbl_size - 1].freq;
+	} else {
+		dev_pm_opp_put(opp);
+	}
 
 	for (i = 0; i < res->clks_num; i++) {
 		if (IS_V6(core)) {
@@ -631,12 +637,15 @@ min_loaded_core(struct venus_inst *inst, u32 *min_coreid, u32 *min_load, bool lo
 
 static int decide_core(struct venus_inst *inst)
 {
+	const struct freq_tbl *freq_tbl = inst->core->res->freq_tbl;
 	const u32 ptype = HFI_PROPERTY_CONFIG_VIDEOCORES_USAGE;
 	struct venus_core *core = inst->core;
 	u32 min_coreid, min_load, cur_inst_load;
 	u32 min_lp_coreid, min_lp_load, cur_inst_lp_load;
 	struct hfi_videocores_usage_type cu;
-	unsigned long max_freq;
+	unsigned long max_freq = ULONG_MAX;
+	struct device *dev = core->dev;
+	struct dev_pm_opp *opp;
 	int ret = 0;
 
 	if (legacy_binding) {
@@ -659,7 +668,11 @@ static int decide_core(struct venus_inst *inst)
 	cur_inst_lp_load *= inst->clk_data.low_power_freq;
 	/*TODO : divide this inst->load by work_route */
 
-	max_freq = core->res->freq_tbl[0].freq;
+	opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
+	if (IS_ERR(opp))
+		max_freq = freq_tbl[0].freq;
+	else
+		dev_pm_opp_put(opp);
 
 	min_loaded_core(inst, &min_coreid, &min_load, false);
 	min_loaded_core(inst, &min_lp_coreid, &min_lp_load, true);
@@ -1082,7 +1095,9 @@ static int load_scale_v4(struct venus_inst *inst)
 	unsigned int num_rows = core->res->freq_tbl_size;
 	struct device *dev = core->dev;
 	unsigned long freq = 0, freq_core1 = 0, freq_core2 = 0;
+	unsigned long max_freq = ULONG_MAX;
 	unsigned long filled_len = 0;
+	struct dev_pm_opp *opp;
 	int i, ret = 0;
 
 	for (i = 0; i < inst->num_input_bufs; i++)
@@ -1108,19 +1123,29 @@ static int load_scale_v4(struct venus_inst *inst)
 
 	freq = max(freq_core1, freq_core2);
 
-	if (freq > table[0].freq) {
-		dev_dbg(dev, VDBGL "requested clock rate: %lu scaling clock rate : %lu\n",
-			freq, table[0].freq);
+	opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
+	if (IS_ERR(opp))
+		max_freq = table[0].freq;
+	else
+		dev_pm_opp_put(opp);
 
-		freq = table[0].freq;
+	if (freq > max_freq) {
+		dev_dbg(dev, VDBGL "requested clock rate: %lu scaling clock rate : %lu\n",
+			freq, max_freq);
+		freq = max_freq;
 		goto set_freq;
 	}
 
-	for (i = num_rows - 1 ; i >= 0; i--) {
-		if (freq <= table[i].freq) {
-			freq = table[i].freq;
-			break;
+	opp = dev_pm_opp_find_freq_ceil(dev, &freq);
+	if (IS_ERR(opp)) {
+		for (i = num_rows - 1 ; i >= 0; i--) {
+			if (freq <= table[i].freq) {
+				freq = table[i].freq;
+				break;
+			}
 		}
+	} else {
+		dev_pm_opp_put(opp);
 	}
 
 set_freq:

-- 
2.34.1

[PATCH v8 2/3] arm64: dts: qcom: qcs615: add venus node to devicetree

[Renjiang Han]

Add the venus node to the devicetree for the qcs615 platform to enable
video functionality. The qcs615 platform currently lacks video
functionality due to the absence of the venus node. Fallback to sc7180 due
to the same video core.

Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs615.dtsi | 78 ++++++++++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi
index 9befd9a40113245137779d96ac4e822cb9a142c5..7d1497dab9f3266a0837a4ec0b76120dc839575f 100644
--- a/arch/arm64/boot/dts/qcom/qcs615.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi
@@ -449,6 +449,11 @@ smem_region: smem@86000000 {
 			no-map;
 			hwlocks = <&tcsr_mutex 3>;
 		};
+
+		pil_video_mem: pil-video@93400000 {
+			reg = <0x0 0x93400000 0x0 0x500000>;
+			no-map;
+		};
 	};
 
 	soc: soc@0 {
@@ -3253,6 +3258,79 @@ gem_noc: interconnect@9680000 {
 			qcom,bcm-voters = <&apps_bcm_voter>;
 		};
 
+		venus: video-codec@aa00000 {
+			compatible = "qcom,qcs615-venus", "qcom,sc7180-venus";
+			reg = <0x0 0x0aa00000 0x0 0x100000>;
+			interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+
+			clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
+				 <&videocc VIDEO_CC_VENUS_AHB_CLK>,
+				 <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
+				 <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
+				 <&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
+			clock-names = "core",
+				      "iface",
+				      "bus",
+				      "vcodec0_core",
+				      "vcodec0_bus";
+
+			power-domains = <&videocc VENUS_GDSC>,
+					<&videocc VCODEC0_GDSC>,
+					<&rpmhpd RPMHPD_CX>;
+			power-domain-names = "venus",
+					     "vcodec0",
+					     "cx";
+
+			operating-points-v2 = <&venus_opp_table>;
+
+			interconnects = <&mmss_noc MASTER_VIDEO_P0 QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+					<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+			interconnect-names = "video-mem",
+					     "cpu-cfg";
+
+			iommus = <&apps_smmu 0xe60 0x20>;
+
+			memory-region = <&pil_video_mem>;
+
+			status = "disabled";
+
+			venus_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				opp-133330000 {
+					opp-hz = /bits/ 64 <133330000>;
+					required-opps = <&rpmhpd_opp_low_svs>;
+				};
+
+				opp-240000000 {
+					opp-hz = /bits/ 64 <240000000>;
+					required-opps = <&rpmhpd_opp_svs>;
+				};
+
+				opp-300000000 {
+					opp-hz = /bits/ 64 <300000000>;
+					required-opps = <&rpmhpd_opp_svs_l1>;
+				};
+
+				opp-380000000 {
+					opp-hz = /bits/ 64 <380000000>;
+					required-opps = <&rpmhpd_opp_nom>;
+				};
+
+				opp-410000000 {
+					opp-hz = /bits/ 64 <410000000>;
+					required-opps = <&rpmhpd_opp_nom_l1>;
+				};
+
+				opp-460000000 {
+					opp-hz = /bits/ 64 <460000000>;
+					required-opps = <&rpmhpd_opp_turbo>;
+				};
+			};
+		};
+
 		videocc: clock-controller@ab00000 {
 			compatible = "qcom,qcs615-videocc";
 			reg = <0 0x0ab00000 0 0x10000>;

-- 
2.34.1

[PATCH v8 3/3] arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec

[Renjiang Han]

Enable the venus node to allow the video codec to start working properly
by setting its status to "okay".

Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
index 2b5aa3c66867676bda59ff82b902b6e4974126f8..0686f5c10bdaf7ba3f522e16acd2107d25742dd9 100644
--- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
@@ -338,6 +338,10 @@ &ufs_mem_phy {
 	status = "okay";
 };
 
+&venus {
+	status = "okay";
+};
+
 &watchdog {
 	clocks = <&sleep_clk>;
 };

-- 
2.34.1

Re: [PATCH v8 2/3] arm64: dts: qcom: qcs615: add venus node to devicetree

[Konrad Dybcio]

On 5/30/25 6:02 AM, Renjiang Han wrote:
> Add the venus node to the devicetree for the qcs615 platform to enable
> video functionality. The qcs615 platform currently lacks video
> functionality due to the absence of the venus node. Fallback to sc7180 due
> to the same video core.
> 
> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Rob Herring (Arm)]

On Fri, 30 May 2025 09:32:12 +0530, Renjiang Han wrote:
> QCS615 uses the same video core as SC7180, so reuse the same resource
> data of SC7180 for QCS615 to enable video functionality.
> 
> There are no resources for the video-decoder and video-encoder nodes
> in the device tree, so remove these two nodes from the device tree. In
> addition, to ensure that the video codec functions properly, use [3]
> to add encoder and decoder node entries in the venus driver.
> 
> Validated this series on QCS615 and SC7180.
> 
> Note:
> This series consist of DT patches and a venus driver patch. The patch
> 1/3, which is venus driver patch, can be picked independently without
> having any functional dependency. But patch 2/3 & patch 3/3, which are
> DT patches, still depend on [1].
> 
> [1] https://lore.kernel.org/all/20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com
> 
> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
> ---
> Changes in v8:
> - 1. Add missing tags.
> - 2. Fix the dependency to point to videoCC series alone.
> - 3. Fix review comments from Konrad.
> - Link to v7: https://lore.kernel.org/r/20250527-add-venus-for-qcs615-v7-0-cca26e2768e3@quicinc.com
> 
> Changes in v7:
> - 1. Update devicetree patch to fix the cherry-pick patch conflict issue.
> - 2. Remove dt-bindings patch from this patch series due to it has been
> picked.
> - Link to v6: https://lore.kernel.org/r/20241219-add-venus-for-qcs615-v6-0-e9a74d3b003d@quicinc.com
> 
> Changes in v6:
> - 1. Remove video-decoder and video-encoder nodes from the device tree
> - 2. Add a new dependency.
> - 3. Fix missing tag.
> - 4. Update commit message.
> - Link to v5: https://lore.kernel.org/r/20241217-add-venus-for-qcs615-v5-0-747395d9e630@quicinc.com
> 
> Changes in v5:
> - 1. Remove extra blank lines in yaml files.
> - 2. Add new variables in the driver while keeping the order of the
> original variables. And remove unnecessary variable initialization.
> - 3. Update commit message.
> - 4. Update the order of nodes in the device tree.
> - Link to v4: https://lore.kernel.org/r/20241213-add-venus-for-qcs615-v4-0-7e2c9a72d309@quicinc.com
> 
> Changes in v4:
> - 1. Remove qcom,qcs615-venus.yaml and use qcom,sc7180-venus.yaml for
> qcs615 dt-bindings.
> - 2. Add "qcom,qcs615-venus" compatible into qcom,sc7180-venus.yaml.
> - 3. Remove qcs615 resource from the driver and use sc7180 resource for
> the qcs615.
> - 4. Use the frequency in the opp-table in devicetree for the driver.
> For compatibility, if getting data from the opp table fails, the data
> in the frequency table will be used.
> - 5. Keep the reverse Christmas tree order coding style.
> - 6. Add "qcom,sc7180-venus" compatible in devicetree.
> - 7. Update cover letter message.
> - Link to v3: https://lore.kernel.org/r/20241125-add-venus-for-qcs615-v3-0-5a376b97a68e@quicinc.com
> 
> Changes in v3:
> - 1. Remove the ‘|’ after 'description' in the qcom,qcs615-venus.yaml.
> - 2. Add a blank line before 'opp-table' in the qcom,qcs615-venus.yaml.
> - 3. Put ‘additionalProperties’ before ‘properties’ in the
> qcom,qcs615-venus.yaml.
> - 4. Update the subject of qcom,qcs615-venus.yaml patch.
> - Link to v2: https://lore.kernel.org/r/20241112-add-venus-for-qcs615-v2-0-e67947f957af@quicinc.com
> 
> Changes in v2:
> - 1. The change-id of DT and driver are removed.
> - 2. Add qcom,qcs615-venus.yaml files to explain DT.
> - 3. The order of driver's commit and DT's commit is adjusted. Place the
> driver's commit before the DT's commit.
> - 4. Extends driver's commit message.
> - 5. Split DT's commit into two commits. Add the venus node to the
> qcs615.dtsi file. Then in the qcs615-ride.dts file enable the venus node.
> - 6. Modify alignment, sort, upper and lower case letters issue.
> - 7. Update cover letter message description.
> - Link to v1: https://lore.kernel.org/r/20241008-add_qcs615_video-v1-0-436ce07bfc63@quicinc.com
> 
> ---
> Renjiang Han (3):
>       media: venus: pm_helpers: use opp-table for the frequency
>       arm64: dts: qcom: qcs615: add venus node to devicetree
>       arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec
> 
>  arch/arm64/boot/dts/qcom/qcs615-ride.dts       |  4 ++
>  arch/arm64/boot/dts/qcom/qcs615.dtsi           | 78 ++++++++++++++++++++++++++
>  drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++-----
>  3 files changed, 121 insertions(+), 14 deletions(-)
> ---
> base-commit: 176e917e010cb7dcc605f11d2bc33f304292482b
> change-id: 20250526-add-venus-for-qcs615-a547540656d1
> prerequisite-message-id: <20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com>
> prerequisite-patch-id: afd2dce9e6066b1f6ce0b41ceafe0dd47ad97c40
> prerequisite-patch-id: f8d64c8cf6cd883dc7bbb2a4ed6d5a4db85c536d
> 
> Best regards,
> --
> Renjiang Han <quic_renjiang@quicinc.com>
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit 176e917e010cb7dcc605f11d2bc33f304292482b
 Deps: looking for dependencies matching 2 patch-ids
 Deps: Applying prerequisite patch: [PATCH v2 1/2] arm64: dts: qcom: qcs615: Add clock nodes for multimedia clock
 Deps: Applying prerequisite patch: [PATCH v2 2/2] arm64: dts: qcom: qcs615: Add CPU scaling clock node

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20250530-add-venus-for-qcs615-v8-0-c0092ac616d0@quicinc.com:

In file included from arch/arm64/boot/dts/qcom/qcs615-ride.dts:10:
arch/arm64/boot/dts/qcom/qcs615.dtsi:6:10: fatal error: dt-bindings/clock/qcom,qcs615-camcc.h: No such file or directory
    6 | #include <dt-bindings/clock/qcom,qcs615-camcc.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [scripts/Makefile.dtbs:131: arch/arm64/boot/dts/qcom/qcs615-ride.dtb] Error 1
make[2]: *** [scripts/Makefile.build:470: arch/arm64/boot/dts/qcom] Error 2
make[2]: Target 'arch/arm64/boot/dts/qcom/qcs615-ride.dtb' not remade because of errors.
make[1]: *** [/home/rob/proj/linux-dt-testing/Makefile:1477: qcom/qcs615-ride.dtb] Error 2
make: *** [Makefile:248: __sub-make] Error 2
make: Target 'qcom/apq8096-ifc6640.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-j3ltetw.dtb' not remade because of errors.
make: Target 'qcom/msm8998-fxtec-pro1.dtb' not remade because of errors.
make: Target 'qcom/sm7325-nothing-spacewar.dtb' not remade because of errors.
make: Target 'qcom/sm7125-xiaomi-curtana.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-dell-xps13-9345.dtb' not remade because of errors.
make: Target 'qcom/msm8998-mtp.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-a5u-eur.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-lenovo-thinkpad-x13s.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r3-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-crd-pro.dtb' not remade because of errors.
make: Target 'qcom/sm6115p-lenovo-j606f.dtb' not remade because of errors.
make: Target 'qcom/msm8998-sony-xperia-yoshino-maple.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp454.dtb' not remade because of errors.
make: Target 'qcom/qcs6490-rb3gen2.dtb' not remade because of errors.
make: Target 'qcom/msm8992-xiaomi-libra.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-r4.dtb' not remade because of errors.
make: Target 'qcom/sdm450-motorola-ali.dtb' not remade because of errors.
make: Target 'qcom/x1e78100-lenovo-thinkpad-t14s-oled.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-quackingstick-r0.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel360-wifi.dtb' not remade because of errors.
make: Target 'qcom/sdm630-sony-xperia-ganges-kirin.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-coachz-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/sdm845-lg-judyp.dtb' not remade because of errors.
make: Target 'qcom/sdm845-cheza-r3.dtb' not remade because of errors.
make: Target 'qcom/msm8939-wingtech-wt82918.dtb' not remade because of errors.
make: Target 'qcom/qrb2210-rb1.dtb' not remade because of errors.
make: Target 'qcom/msm8996-mtp.dtb' not remade because of errors.
make: Target 'qcom/sm8750-mtp.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-zombie.dtb' not remade because of errors.
make: Target 'qcom/msm8992-lg-bullhead-rev-10.dtb' not remade because of errors.
make: Target 'qcom/qrb5165-rb5.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-lenovo-yoga-slim7x.dtb' not remade because of errors.
make: Target 'qcom/sm8550-qrd.dtb' not remade because of errors.
make: Target 'qcom/sdm630-sony-xperia-nile-discovery.dtb' not remade because of errors.
make: Target 'qcom/sm8550-sony-xperia-yodo-pdx234.dtb' not remade because of errors.
make: Target 'qcom/msm8939-huawei-kiwi.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-wormdingler-rev1-inx.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-microsoft-arcata.dtb' not remade because of errors.
make: Target 'qcom/sdm845-oneplus-fajita.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-nots-r4.dtb' not remade because of errors.
make: Target 'qcom/sdm660-xiaomi-lavender.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-coachz-r1.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r10.dtb' not remade because of errors.
make: Target 'qcom/msm8939-wingtech-wt82918hd.dtb' not remade because of errors.
make: Target 'qcom/ipq6018-cp01-c1.dtb' not remade because of errors.
make: Target 'qcom/msm8916-motorola-surnia.dtb' not remade because of errors.
make: Target 'qcom/sm8350-microsoft-surface-duo2.dtb' not remade because of errors.
make: Target 'qcom/qcm6490-idp.dtb' not remade because of errors.
make: Target 'qcom/sm8550-mtp.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-a3u-eur.dtb' not remade because of errors.
make: Target 'qcom/sdm845-sony-xperia-tama-akari.dtb' not remade because of errors.
make: Target 'qcom/x1p42100-crd.dtb' not remade because of errors.
make: Target 'qcom/sm8250-mtp.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-nots-r9.dtb' not remade because of errors.
make: Target 'qcom/sm8250-xiaomi-elish-csot.dtb' not remade because of errors.
make: Target 'qcom/msm8916-wingtech-wt88047.dtb' not remade because of errors.
make: Target 'qcom/msm8916-thwc-ufi001c.dtb' not remade because of errors.
make: Target 'qcom/msm8998-xiaomi-sagit.dtb' not remade because of errors.
make: Target 'qcom/qcs8550-aim300-aiot.dtb' not remade because of errors.
make: Target 'qcom/sdm450-lenovo-tbx605f.dtb' not remade because of errors.
make: Target 'qcom/sm8250-xiaomi-elish-boe.dtb' not remade because of errors.
make: Target 'qcom/qcs404-evb-4000.dtb' not remade because of errors.
make: Target 'qcom/qcs9100-ride.dtb' not remade because of errors.
make: Target 'qcom/msm8996-sony-xperia-tone-kagura.dtb' not remade because of errors.
make: Target 'qcom/sm8150-sony-xperia-kumano-griffin.dtb' not remade because of errors.
make: Target 'qcom/sdm670-google-sargo.dtb' not remade because of errors.
make: Target 'qcom/x1e001de-devkit.dtb' not remade because of errors.
make: Target 'qcom/sa8775p-ride.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-crd.dtb' not remade because of errors.
make: Target 'qcom/ipq5424-rdp466.dtb' not remade because of errors.
make: Target 'qcom/sc8180x-lenovo-flex-5g.dtb' not remade because of errors.
make: Target 'qcom/sdm845-lg-judyln.dtb' not remade because of errors.
make: Target 'qcom/sm6125-xiaomi-ginkgo.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r3-kb.dtb' not remade because of errors.
make: Target 'qcom/msm8916-motorola-osprey.dtb' not remade because of errors.
make: Target 'qcom/sm8250-xiaomi-pipa.dtb' not remade because of errors.
make: Target 'qcom/sdm845-oneplus-enchilada.dtb' not remade because of errors.
make: Target 'qcom/msm8956-sony-xperia-loire-suzu.dtb' not remade because of errors.
make: Target 'qcom/sc7280-idp.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-evoker-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-homestar-r4.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-rossa.dtb' not remade because of errors.
make: Target 'qcom/apq8039-t2.dtb' not remade because of errors.
make: Target 'qcom/msm8916-motorola-harpia.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-e5.dtb' not remade because of errors.
make: Target 'qcom/sc7280-idp2.dtb' not remade because of errors.
make: Target 'qcom/apq8016-sbc-d3-camera-mezzanine.dtb' not remade because of errors.
make: Target 'qcom/msm8939-sony-xperia-kanuti-tulip.dtb' not remade because of errors.
make: Target 'qcom/ipq8074-hk01.dtb' not remade because of errors.
make: Target 'qcom/sm8150-mtp.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp433.dtb' not remade because of errors.
make: Target 'qcom/sdm845-sony-xperia-tama-apollo.dtb' not remade because of errors.
make: Target 'qcom/msm8998-lenovo-miix-630.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-karin.dtb' not remade because of errors.
make: Target 'qcom/sdm630-sony-xperia-nile-pioneer.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-grandmax.dtb' not remade because of errors.
make: Target 'qcom/msm8916-alcatel-idol347.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp453.dtb' not remade because of errors.
make: Target 'qcom/sc7180-acer-aspire1.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-r1.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-e7.dtb' not remade because of errors.
make: Target 'qcom/ipq5018-rdp432-c2.dtb' not remade because of errors.
make: Target 'qcom/apq8016-schneider-hmibsc.dtb' not remade because of errors.
make: Target 'qcom/qrb4210-rb2.dtb' not remade because of errors.
make: Target 'qcom/ipq5018-tplink-archer-ax55-v1.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-evoker.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-kingoftown.dtb' not remade because of errors.
make: Target 'qcom/sm4450-qrd.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-j5.dtb' not remade because of errors.
make: Target 'qcom/msm8998-asus-novago-tp370ql.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r2-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8992-lg-h815.dtb' not remade because of errors.
make: Target 'qcom/sdx75-idp.dtb' not remade because of errors.
make: Target 'qcom/sm8350-sony-xperia-sagami-pdx215.dtb' not remade because of errors.
make: Target 'qcom/apq8096-db820c.dtb' not remade because of errors.
make: Target 'qcom/msm8996-sony-xperia-tone-keyaki.dtb' not remade because of errors.
make: Target 'qcom/msm8916-longcheer-l8150.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-suzuran.dtb' not remade because of errors.
make: Target 'qcom/sdm845-mtp.dtb' not remade because of errors.
make: Target 'qcom/sm6375-sony-xperia-murray-pdx225.dtb' not remade because of errors.
make: Target 'qcom/msm8916-yiming-uz801v3.dtb' not remade because of errors.
make: Target 'qcom/qcs9100-ride-r3.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-hp-omnibook-x14.dtb' not remade because of errors.
make: Target 'qcom/msm8953-xiaomi-vince.dtb' not remade because of errors.
make: Target 'qcom/sdm845-cheza-r2.dtb' not remade because of errors.
make: Target 'qcom/ipq5332-rdp441.dtb' not remade because of errors.
make: Target 'qcom/msm8992-lg-bullhead-rev-101.dtb' not remade because of errors.
make: Target 'qcom/msm8917-xiaomi-riva.dtb' not remade because of errors.
make: Target 'qcom/msm8996-xiaomi-gemini.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-r9.dtb' not remade because of errors.
make: Target 'qcom/msm8998-sony-xperia-yoshino-lilac.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-gprimeltecan.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel360-lte.dtb' not remade because of errors.
make: Target 'qcom/sdm845-shift-axolotl.dtb' not remade because of errors.
make: Target 'qcom/msm8996-oneplus3t.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-zombie-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r3.dtb' not remade because of errors.
make: Target 'qcom/sar2130p-qar2130p.dtb' not remade because of errors.
make: Target 'qcom/sm8650-hdk.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-herobrine-r1.dtb' not remade because of errors.
make: Target 'qcom/msm8916-longcheer-l8910.dtb' not remade because of errors.
make: Target 'qcom/sdm630-sony-xperia-nile-voyager.dtb' not remade because of errors.
make: Target 'qcom/sm8450-hdk.dtb' not remade because of errors.
make: Target 'qcom/msm8929-wingtech-wt82918hd.dtb' not remade because of errors.
make: Target 'qcom/sm8250-sony-xperia-edo-pdx203.dtb' not remade because of errors.
make: Target 'qcom/sm8350-hdk.dtb' not remade because of errors.
make: Target 'qcom/ipq8074-hk10-c1.dtb' not remade because of errors.
make: Target 'qcom/sm8450-qrd.dtb' not remade because of errors.
make: Target 'qcom/msm8916-lg-c50.dtb' not remade because of errors.
make: Target 'qcom/sm8250-sony-xperia-edo-pdx206.dtb' not remade because of errors.
make: Target 'qcom/sm7225-fairphone-fp4.dtb' not remade because of errors.
make: Target 'qcom/sa8155p-adp.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-qcp.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r1-kb.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-grandprimelte.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-zombie-nvme-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-homestar-r3.dtb' not remade because of errors.
make: Target 'qcom/ipq5332-rdp474.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-asus-vivobook-s15.dtb' not remade because of errors.
make: Target 'qcom/sm8150-microsoft-surface-duo.dtb' not remade because of errors.
make: Target 'qcom/msm8996pro-xiaomi-scorpio.dtb' not remade because of errors.
make: Target 'qcom/x1e78100-lenovo-thinkpad-t14s.dtb' not remade because of errors.
make: Target 'qcom/sm8150-hdk.dtb' not remade because of errors.
make: Target 'qcom/sc8180x-primus.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r10-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-j5x.dtb' not remade because of errors.
make: Target 'qcom/sc7180-idp.dtb' not remade because of errors.
make: Target 'qcom/msm8916-mtp.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-hp-elitebook-ultra-g1q.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-r10.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-zombie-nvme.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-microsoft-romulus15.dtb' not remade because of errors.
make: Target 'qcom/qru1000-idp.dtb' not remade because of errors.
make: Target 'qcom/msm8998-hp-envy-x2.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-wormdingler-rev1-boe-rt5682s.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel-parade.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r9-kb.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-wormdingler-rev1-boe.dtb' not remade because of errors.
make: Target 'qcom/qcs615-ride.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-coachz-r3-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7280-crd-r3.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-gt58.dtb' not remade because of errors.
make: Target 'qcom/sa8775p-ride-r3.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-villager-r1.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel-ti.dtb' not remade because of errors.
make: Target 'qcom/qcm6490-shift-otter.dtb' not remade because of errors.
make: Target 'qcom/qcs8300-ride.dtb' not remade because of errors.
make: Target 'qcom/apq8016-sbc.dtb' not remade because of errors.
make: Target 'qcom/msm8996pro-xiaomi-natrium.dtb' not remade because of errors.
make: Target 'qcom/sdm845-samsung-starqltechn.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8953-xiaomi-tissot.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r9.dtb' not remade because of errors.
make: Target 'qcom/sm6125-xiaomi-laurel-sprout.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-sumire.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-serranove.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-coachz-r3.dtb' not remade because of errors.
make: Target 'qcom/sdm845-sony-xperia-tama-akatsuki.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp449.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8916-lg-m216.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-crd.dtb' not remade because of errors.
make: Target 'qcom/apq8094-sony-xperia-kitakami-karin_windy.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r9-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel-lte-ti.dtb' not remade because of errors.
make: Target 'qcom/msm8996-sony-xperia-tone-dora.dtb' not remade because of errors.
make: Target 'qcom/sa8295p-adp.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-ivy.dtb' not remade because of errors.
make: Target 'qcom/sdm845-xiaomi-beryllium-ebbg.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r3.dtb' not remade because of errors.
make: Target 'qcom/msm8998-oneplus-dumpling.dtb' not remade because of errors.
make: Target 'qcom/sm8650-mtp.dtb' not remade because of errors.
make: Target 'qcom/msm8996-oneplus3.dtb' not remade because of errors.
make: Target 'qcom/sm8550-hdk.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-microsoft-romulus13.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8939-samsung-a7.dtb' not remade because of errors.
make: Target 'qcom/qcm6490-fairphone-fp5.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-huawei-gaokun3.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-wormdingler-rev1-inx-rt5682s.dtb' not remade because of errors.
make: Target 'qcom/msm8953-xiaomi-mido.dtb' not remade because of errors.
make: Target 'qcom/msm8916-asus-z00l.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r2.dtb' not remade because of errors.
make: Target 'qcom/sm6350-sony-xperia-lena-pdx213.dtb' not remade because of errors.
make: Target 'qcom/sdm632-fairphone-fp3.dtb' not remade because of errors.
make: Target 'qcom/msm8953-motorola-potter.dtb' not remade because of errors.
make: Target 'qcom/sda660-inforce-ifc6560.dtb' not remade because of errors.
make: Target 'qcom/sm8150-sony-xperia-kumano-bahamut.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel-lte-parade.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-homestar-r2.dtb' not remade because of errors.
make: Target 'qcom/sm8250-hdk.dtb' not remade because of errors.
make: Target 'qcom/sm8650-qrd.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-microsoft-blackrock.dtb' not remade because of errors.
make: Target 'qcom/ipq8074-hk10-c2.dtb' not remade because of errors.
make: Target 'qcom/msm8953-xiaomi-daisy.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-crd.dtb' not remade because of errors.
make: Target 'qcom/sdm850-samsung-w737.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-nots-r5.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-gt510.dtb' not remade because of errors.
make: Target 'qcom/sdm850-lenovo-yoga-c630.dtb' not remade because of errors.
make: Target 'qcom/msm8916-thwc-uf896.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r10-kb.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-satsuki.dtb' not remade because of errors.
make: Target 'qcom/sdm632-motorola-ocean.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-villager-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/sm6115-fxtec-pro1x.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r3-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8998-sony-xperia-yoshino-poplar.dtb' not remade because of errors.
make: Target 'qcom/msm8916-huawei-g7.dtb' not remade because of errors.
make: Target 'qcom/msm8916-wingtech-wt86518.dtb' not remade because of errors.
make: Target 'qcom/sm8350-sony-xperia-sagami-pdx214.dtb' not remade because of errors.
make: Target 'qcom/msm8916-wingtech-wt86528.dtb' not remade because of errors.
make: Target 'qcom/sdm845-db845c.dtb' not remade because of errors.
make: Target 'qcom/sa8540p-ride.dtb' not remade because of errors.
make: Target 'qcom/msm8939-longcheer-l9100.dtb' not remade because of errors.
make: Target 'qcom/qdu1000-idp.dtb' not remade because of errors.
make: Target 'qcom/sm8550-samsung-q5q.dtb' not remade because of errors.
make: Target 'qcom/msm8992-msft-lumia-octagon-talkman.dtb' not remade because of errors.
make: Target 'qcom/msm8916-gplus-fl8005a.dtb' not remade because of errors.
make: Target 'qcom/sm8350-mtp.dtb' not remade because of errors.
make: Target 'qcom/msm8956-sony-xperia-loire-kugo.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r1.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r1.dtb' not remade because of errors.
make: Target 'qcom/msm8998-oneplus-cheeseburger.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-villager-r0.dtb' not remade because of errors.
make: Target 'qcom/sm8750-qrd.dtb' not remade because of errors.
make: Target 'qcom/sm4250-oneplus-billie2.dtb' not remade because of errors.
make: Target 'qcom/sdm636-sony-xperia-ganges-mermaid.dtb' not remade because of errors.
make: Target 'qcom/qcs404-evb-1000.dtb' not remade because of errors.
make: Target 'qcom/ipq5332-rdp442.dtb' not remade because of errors.
make: Target 'qcom/sdm845-cheza-r1.dtb' not remade because of errors.
make: Target 'qcom/msm8994-msft-lumia-octagon-cityman.dtb' not remade because of errors.
make: Target 'qcom/msm8916-acer-a1-724.dtb' not remade because of errors.
make: Target 'qcom/sdm845-xiaomi-beryllium-tianma.dtb' not remade because of errors.
make: Target 'qcom/sm6125-sony-xperia-seine-pdx201.dtb' not remade because of errors.
make: Target 'qcom/sdm845-xiaomi-polaris.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp418.dtb' not remade because of errors.
make: Target 'qcom/msm8216-samsung-fortuna3g.dtb' not remade because of errors.
make: Target 'qcom/sm8450-sony-xperia-nagara-pdx223.dtb' not remade because of errors.
make: Target 'qcom/sm8450-sony-xperia-nagara-pdx224.dtb' not remade because of errors.
make: Target 'qcom/sm7125-xiaomi-joyeuse.dtb' not remade because of errors.
make: Target 'qcom/msm8994-huawei-angler-rev-101.dtb' not remade because of errors.
make: Target 'qcom/ipq5332-rdp468.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-nots-r10.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-quackingstick-r0-lte.dtb' not remade because of errors.

Re: [PATCH v8 1/3] media: venus: pm_helpers: use opp-table for the frequency

[Dmitry Baryshkov]

On Fri, May 30, 2025 at 09:32:13AM +0530, Renjiang Han wrote:
> The frequency value in the opp-table in the device tree and the freq_tbl
> in the driver are the same.
> 
> Therefore, update pm_helpers.c to use the opp-table for frequency values
> for the v4 core.

You are kind of missing the linking between the first two sentences. "The
tables are the same, so use the second one." You need to explain that
some of the platforms (provide examples) use the same core, but
different frequency tables. Using OPP tables allows us to abstract core
description from the frequency data and use fallback compatibles.

> If getting data from the opp table fails, fall back to using the frequency
> table.
> 
> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
> ---
>  drivers/media/platform/qcom/venus/pm_helpers.c | 53 +++++++++++++++++++-------
>  1 file changed, 39 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
> index 409aa9bd0b5d099c993eedb03177ec5ed918b4a0..434dd66076e8faf7f3feac6c29152789f8d2f81b 100644
> --- a/drivers/media/platform/qcom/venus/pm_helpers.c
> +++ b/drivers/media/platform/qcom/venus/pm_helpers.c
> @@ -43,14 +43,20 @@ static int core_clks_enable(struct venus_core *core)
>  	const struct venus_resources *res = core->res;
>  	const struct freq_tbl *freq_tbl = core->res->freq_tbl;
>  	unsigned int freq_tbl_size = core->res->freq_tbl_size;
> +	struct device *dev = core->dev;
> +	struct dev_pm_opp *opp;
>  	unsigned long freq;
>  	unsigned int i;
>  	int ret;
>  
> -	if (!freq_tbl)
> -		return -EINVAL;
> -
> -	freq = freq_tbl[freq_tbl_size - 1].freq;
> +	opp = dev_pm_opp_find_freq_ceil(dev, &freq);
> +	if (IS_ERR(opp)) {
> +		if (!freq_tbl)
> +			return -EINVAL;
> +		freq = freq_tbl[freq_tbl_size - 1].freq;
> +	} else {
> +		dev_pm_opp_put(opp);
> +	}
>  
>  	for (i = 0; i < res->clks_num; i++) {
>  		if (IS_V6(core)) {
> @@ -631,12 +637,15 @@ min_loaded_core(struct venus_inst *inst, u32 *min_coreid, u32 *min_load, bool lo
>  
>  static int decide_core(struct venus_inst *inst)
>  {
> +	const struct freq_tbl *freq_tbl = inst->core->res->freq_tbl;
>  	const u32 ptype = HFI_PROPERTY_CONFIG_VIDEOCORES_USAGE;
>  	struct venus_core *core = inst->core;
>  	u32 min_coreid, min_load, cur_inst_load;
>  	u32 min_lp_coreid, min_lp_load, cur_inst_lp_load;
>  	struct hfi_videocores_usage_type cu;
> -	unsigned long max_freq;
> +	unsigned long max_freq = ULONG_MAX;
> +	struct device *dev = core->dev;
> +	struct dev_pm_opp *opp;
>  	int ret = 0;
>  
>  	if (legacy_binding) {
> @@ -659,7 +668,11 @@ static int decide_core(struct venus_inst *inst)
>  	cur_inst_lp_load *= inst->clk_data.low_power_freq;
>  	/*TODO : divide this inst->load by work_route */
>  
> -	max_freq = core->res->freq_tbl[0].freq;
> +	opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
> +	if (IS_ERR(opp))
> +		max_freq = freq_tbl[0].freq;
> +	else
> +		dev_pm_opp_put(opp);
>  
>  	min_loaded_core(inst, &min_coreid, &min_load, false);
>  	min_loaded_core(inst, &min_lp_coreid, &min_lp_load, true);
> @@ -1082,7 +1095,9 @@ static int load_scale_v4(struct venus_inst *inst)
>  	unsigned int num_rows = core->res->freq_tbl_size;
>  	struct device *dev = core->dev;
>  	unsigned long freq = 0, freq_core1 = 0, freq_core2 = 0;
> +	unsigned long max_freq = ULONG_MAX;
>  	unsigned long filled_len = 0;
> +	struct dev_pm_opp *opp;
>  	int i, ret = 0;
>  
>  	for (i = 0; i < inst->num_input_bufs; i++)
> @@ -1108,19 +1123,29 @@ static int load_scale_v4(struct venus_inst *inst)
>  
>  	freq = max(freq_core1, freq_core2);
>  
> -	if (freq > table[0].freq) {
> -		dev_dbg(dev, VDBGL "requested clock rate: %lu scaling clock rate : %lu\n",
> -			freq, table[0].freq);
> +	opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
> +	if (IS_ERR(opp))
> +		max_freq = table[0].freq;
> +	else
> +		dev_pm_opp_put(opp);
>  
> -		freq = table[0].freq;
> +	if (freq > max_freq) {
> +		dev_dbg(dev, VDBGL "requested clock rate: %lu scaling clock rate : %lu\n",
> +			freq, max_freq);
> +		freq = max_freq;
>  		goto set_freq;
>  	}
>  
> -	for (i = num_rows - 1 ; i >= 0; i--) {
> -		if (freq <= table[i].freq) {
> -			freq = table[i].freq;
> -			break;
> +	opp = dev_pm_opp_find_freq_ceil(dev, &freq);
> +	if (IS_ERR(opp)) {
> +		for (i = num_rows - 1 ; i >= 0; i--) {
> +			if (freq <= table[i].freq) {
> +				freq = table[i].freq;
> +				break;
> +			}
>  		}
> +	} else {
> +		dev_pm_opp_put(opp);
>  	}
>  
>  set_freq:
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
> QCS615 uses the same video core as SC7180, so reuse the same resource
> data of SC7180 for QCS615 to enable video functionality.
> 
> There are no resources for the video-decoder and video-encoder nodes
> in the device tree, so remove these two nodes from the device tree. In
> addition, to ensure that the video codec functions properly, use [3]
> to add encoder and decoder node entries in the venus driver.
> 
> Validated this series on QCS615 and SC7180.
> 
> Note:
> This series consist of DT patches and a venus driver patch. The patch
> 1/3, which is venus driver patch, can be picked independently without
> having any functional dependency. But patch 2/3 & patch 3/3, which are
> DT patches, still depend on [1].

I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
on QCS615 over(?)clocked.

> 
> [1] https://lore.kernel.org/all/20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com
> 
> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
> ---
> Changes in v8:
> - 1. Add missing tags.
> - 2. Fix the dependency to point to videoCC series alone.
> - 3. Fix review comments from Konrad.
> - Link to v7: https://lore.kernel.org/r/20250527-add-venus-for-qcs615-v7-0-cca26e2768e3@quicinc.com
> 
> Changes in v7:
> - 1. Update devicetree patch to fix the cherry-pick patch conflict issue.
> - 2. Remove dt-bindings patch from this patch series due to it has been
> picked.
> - Link to v6: https://lore.kernel.org/r/20241219-add-venus-for-qcs615-v6-0-e9a74d3b003d@quicinc.com
> 
> Changes in v6:
> - 1. Remove video-decoder and video-encoder nodes from the device tree
> - 2. Add a new dependency.
> - 3. Fix missing tag.
> - 4. Update commit message.
> - Link to v5: https://lore.kernel.org/r/20241217-add-venus-for-qcs615-v5-0-747395d9e630@quicinc.com
> 
> Changes in v5:
> - 1. Remove extra blank lines in yaml files.
> - 2. Add new variables in the driver while keeping the order of the
> original variables. And remove unnecessary variable initialization.
> - 3. Update commit message.
> - 4. Update the order of nodes in the device tree.
> - Link to v4: https://lore.kernel.org/r/20241213-add-venus-for-qcs615-v4-0-7e2c9a72d309@quicinc.com
> 
> Changes in v4:
> - 1. Remove qcom,qcs615-venus.yaml and use qcom,sc7180-venus.yaml for
> qcs615 dt-bindings.
> - 2. Add "qcom,qcs615-venus" compatible into qcom,sc7180-venus.yaml.
> - 3. Remove qcs615 resource from the driver and use sc7180 resource for
> the qcs615.
> - 4. Use the frequency in the opp-table in devicetree for the driver.
> For compatibility, if getting data from the opp table fails, the data
> in the frequency table will be used.
> - 5. Keep the reverse Christmas tree order coding style.
> - 6. Add "qcom,sc7180-venus" compatible in devicetree.
> - 7. Update cover letter message.
> - Link to v3: https://lore.kernel.org/r/20241125-add-venus-for-qcs615-v3-0-5a376b97a68e@quicinc.com
> 
> Changes in v3:
> - 1. Remove the ‘|’ after 'description' in the qcom,qcs615-venus.yaml.
> - 2. Add a blank line before 'opp-table' in the qcom,qcs615-venus.yaml.
> - 3. Put ‘additionalProperties’ before ‘properties’ in the
> qcom,qcs615-venus.yaml.
> - 4. Update the subject of qcom,qcs615-venus.yaml patch.
> - Link to v2: https://lore.kernel.org/r/20241112-add-venus-for-qcs615-v2-0-e67947f957af@quicinc.com
> 
> Changes in v2:
> - 1. The change-id of DT and driver are removed.
> - 2. Add qcom,qcs615-venus.yaml files to explain DT.
> - 3. The order of driver's commit and DT's commit is adjusted. Place the
> driver's commit before the DT's commit.
> - 4. Extends driver's commit message.
> - 5. Split DT's commit into two commits. Add the venus node to the
> qcs615.dtsi file. Then in the qcs615-ride.dts file enable the venus node.
> - 6. Modify alignment, sort, upper and lower case letters issue.
> - 7. Update cover letter message description.
> - Link to v1: https://lore.kernel.org/r/20241008-add_qcs615_video-v1-0-436ce07bfc63@quicinc.com
> 
> ---
> Renjiang Han (3):
>       media: venus: pm_helpers: use opp-table for the frequency
>       arm64: dts: qcom: qcs615: add venus node to devicetree
>       arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec
> 
>  arch/arm64/boot/dts/qcom/qcs615-ride.dts       |  4 ++
>  arch/arm64/boot/dts/qcom/qcs615.dtsi           | 78 ++++++++++++++++++++++++++
>  drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++-----
>  3 files changed, 121 insertions(+), 14 deletions(-)
> ---
> base-commit: 176e917e010cb7dcc605f11d2bc33f304292482b
> change-id: 20250526-add-venus-for-qcs615-a547540656d1
> prerequisite-message-id: <20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com>
> prerequisite-patch-id: afd2dce9e6066b1f6ce0b41ceafe0dd47ad97c40
> prerequisite-patch-id: f8d64c8cf6cd883dc7bbb2a4ed6d5a4db85c536d
> 
> Best regards,
> -- 
> Renjiang Han <quic_renjiang@quicinc.com>
> 

-- 
With best wishes
Dmitry

Re: [PATCH v8 3/3] arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec

[Dmitry Baryshkov]

On Fri, May 30, 2025 at 09:32:15AM +0530, Renjiang Han wrote:
> Enable the venus node to allow the video codec to start working properly
> by setting its status to "okay".
> 
> Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> index 2b5aa3c66867676bda59ff82b902b6e4974126f8..0686f5c10bdaf7ba3f522e16acd2107d25742dd9 100644
> --- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> @@ -338,6 +338,10 @@ &ufs_mem_phy {
>  	status = "okay";
>  };
>  
> +&venus {
> +	status = "okay";

Does QCS615 work with existing qcom/venus-5.4/venus.mbn or does it need
another VPU firmware?

> +};
> +
>  &watchdog {
>  	clocks = <&sleep_clk>;
>  };
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
>> QCS615 uses the same video core as SC7180, so reuse the same resource
>> data of SC7180 for QCS615 to enable video functionality.
>>
>> There are no resources for the video-decoder and video-encoder nodes
>> in the device tree, so remove these two nodes from the device tree. In
>> addition, to ensure that the video codec functions properly, use [3]
>> to add encoder and decoder node entries in the venus driver.
>>
>> Validated this series on QCS615 and SC7180.
>>
>> Note:
>> This series consist of DT patches and a venus driver patch. The patch
>> 1/3, which is venus driver patch, can be picked independently without
>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>> DT patches, still depend on [1].
> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
> on QCS615 over(?)clocked.
Agree, so we need to make sure that the driver patch is not picked after 
the DT patch.
>
>> [1] https://lore.kernel.org/all/20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com
>>
>> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
>> ---
>> Changes in v8:
>> - 1. Add missing tags.
>> - 2. Fix the dependency to point to videoCC series alone.
>> - 3. Fix review comments from Konrad.
>> - Link to v7: https://lore.kernel.org/r/20250527-add-venus-for-qcs615-v7-0-cca26e2768e3@quicinc.com
>>
>> Changes in v7:
>> - 1. Update devicetree patch to fix the cherry-pick patch conflict issue.
>> - 2. Remove dt-bindings patch from this patch series due to it has been
>> picked.
>> - Link to v6: https://lore.kernel.org/r/20241219-add-venus-for-qcs615-v6-0-e9a74d3b003d@quicinc.com
>>
>> Changes in v6:
>> - 1. Remove video-decoder and video-encoder nodes from the device tree
>> - 2. Add a new dependency.
>> - 3. Fix missing tag.
>> - 4. Update commit message.
>> - Link to v5: https://lore.kernel.org/r/20241217-add-venus-for-qcs615-v5-0-747395d9e630@quicinc.com
>>
>> Changes in v5:
>> - 1. Remove extra blank lines in yaml files.
>> - 2. Add new variables in the driver while keeping the order of the
>> original variables. And remove unnecessary variable initialization.
>> - 3. Update commit message.
>> - 4. Update the order of nodes in the device tree.
>> - Link to v4: https://lore.kernel.org/r/20241213-add-venus-for-qcs615-v4-0-7e2c9a72d309@quicinc.com
>>
>> Changes in v4:
>> - 1. Remove qcom,qcs615-venus.yaml and use qcom,sc7180-venus.yaml for
>> qcs615 dt-bindings.
>> - 2. Add "qcom,qcs615-venus" compatible into qcom,sc7180-venus.yaml.
>> - 3. Remove qcs615 resource from the driver and use sc7180 resource for
>> the qcs615.
>> - 4. Use the frequency in the opp-table in devicetree for the driver.
>> For compatibility, if getting data from the opp table fails, the data
>> in the frequency table will be used.
>> - 5. Keep the reverse Christmas tree order coding style.
>> - 6. Add "qcom,sc7180-venus" compatible in devicetree.
>> - 7. Update cover letter message.
>> - Link to v3: https://lore.kernel.org/r/20241125-add-venus-for-qcs615-v3-0-5a376b97a68e@quicinc.com
>>
>> Changes in v3:
>> - 1. Remove the ‘|’ after 'description' in the qcom,qcs615-venus.yaml.
>> - 2. Add a blank line before 'opp-table' in the qcom,qcs615-venus.yaml.
>> - 3. Put ‘additionalProperties’ before ‘properties’ in the
>> qcom,qcs615-venus.yaml.
>> - 4. Update the subject of qcom,qcs615-venus.yaml patch.
>> - Link to v2: https://lore.kernel.org/r/20241112-add-venus-for-qcs615-v2-0-e67947f957af@quicinc.com
>>
>> Changes in v2:
>> - 1. The change-id of DT and driver are removed.
>> - 2. Add qcom,qcs615-venus.yaml files to explain DT.
>> - 3. The order of driver's commit and DT's commit is adjusted. Place the
>> driver's commit before the DT's commit.
>> - 4. Extends driver's commit message.
>> - 5. Split DT's commit into two commits. Add the venus node to the
>> qcs615.dtsi file. Then in the qcs615-ride.dts file enable the venus node.
>> - 6. Modify alignment, sort, upper and lower case letters issue.
>> - 7. Update cover letter message description.
>> - Link to v1: https://lore.kernel.org/r/20241008-add_qcs615_video-v1-0-436ce07bfc63@quicinc.com
>>
>> ---
>> Renjiang Han (3):
>>        media: venus: pm_helpers: use opp-table for the frequency
>>        arm64: dts: qcom: qcs615: add venus node to devicetree
>>        arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec
>>
>>   arch/arm64/boot/dts/qcom/qcs615-ride.dts       |  4 ++
>>   arch/arm64/boot/dts/qcom/qcs615.dtsi           | 78 ++++++++++++++++++++++++++
>>   drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++-----
>>   3 files changed, 121 insertions(+), 14 deletions(-)
>> ---
>> base-commit: 176e917e010cb7dcc605f11d2bc33f304292482b
>> change-id: 20250526-add-venus-for-qcs615-a547540656d1
>> prerequisite-message-id: <20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com>
>> prerequisite-patch-id: afd2dce9e6066b1f6ce0b41ceafe0dd47ad97c40
>> prerequisite-patch-id: f8d64c8cf6cd883dc7bbb2a4ed6d5a4db85c536d
>>
>> Best regards,
>> -- 
>> Renjiang Han <quic_renjiang@quicinc.com>
>>
-- 
Best Regards,
Renjiang

Re: [PATCH v8 3/3] arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec

[Renjiang Han]

On 5/31/2025 4:31 AM, Dmitry Baryshkov wrote:
> On Fri, May 30, 2025 at 09:32:15AM +0530, Renjiang Han wrote:
>> Enable the venus node to allow the video codec to start working properly
>> by setting its status to "okay".
>>
>> Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
>> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
>> ---
>>   arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
>> index 2b5aa3c66867676bda59ff82b902b6e4974126f8..0686f5c10bdaf7ba3f522e16acd2107d25742dd9 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
>> @@ -338,6 +338,10 @@ &ufs_mem_phy {
>>   	status = "okay";
>>   };
>>   
>> +&venus {
>> +	status = "okay";
> Does QCS615 work with existing qcom/venus-5.4/venus.mbn or does it need
> another VPU firmware?
yes, QCS615 works with existing qcom/venus-5.4/venus.mbn.
>
>> +};
>> +
>>   &watchdog {
>>   	clocks = <&sleep_clk>;
>>   };
>>
>> -- 
>> 2.34.1
>>
-- 
Best Regards,
Renjiang

Re: [PATCH v8 1/3] media: venus: pm_helpers: use opp-table for the frequency

[Konrad Dybcio]

On 5/30/25 6:02 AM, Renjiang Han wrote:
> The frequency value in the opp-table in the device tree and the freq_tbl
> in the driver are the same.
> 
> Therefore, update pm_helpers.c to use the opp-table for frequency values
> for the v4 core.
> If getting data from the opp table fails, fall back to using the frequency
> table.
> 
> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
> ---

You can save yourself some error-checking pain in this patch if you
do something like 

ret = devm_pm_opp_of_add_table(dev);
if (ret == -ENODEV) {
	for (i = 0; i < freq_tbl_len; i++)
		dev_pm_opp_add(dev, freq_tbl[i], 0);
}

to programmatically migrate everyone to OPP..

But - tangent - I'd say efforts to preserve compatibility with DTs that
don't even contain frequency data for a given target are rather futile.. 
Such descriptions where we only know the frequency (be it the tables that
we currently have, or the constructed OPP tables that only contain frequency
data and no voltage corners) are incomplete, and if the system manages to
not crash if the driver requests a TURBO/max freq, it's all because we got
lucky, as this consumer is not voting on (MM)CX.

That said, it's probably to keep the breakage to minimum, especially
given this is an old driver for old hardware.. I'll add the missing
OPPs across platforms with an intention to drop the hardcoding somewhere
in the future

Konrad

Re: [PATCH v8 3/3] arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec

[Dmitry Baryshkov]

On Sat, May 31, 2025 at 08:07:06AM +0800, Renjiang Han wrote:
> 
> On 5/31/2025 4:31 AM, Dmitry Baryshkov wrote:
> > On Fri, May 30, 2025 at 09:32:15AM +0530, Renjiang Han wrote:
> > > Enable the venus node to allow the video codec to start working properly
> > > by setting its status to "okay".
> > > 
> > > Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > > Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
> > > ---
> > >   arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++++
> > >   1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> > > index 2b5aa3c66867676bda59ff82b902b6e4974126f8..0686f5c10bdaf7ba3f522e16acd2107d25742dd9 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> > > @@ -338,6 +338,10 @@ &ufs_mem_phy {
> > >   	status = "okay";
> > >   };
> > > +&venus {
> > > +	status = "okay";
> > Does QCS615 work with existing qcom/venus-5.4/venus.mbn or does it need
> > another VPU firmware?
> yes, QCS615 works with existing qcom/venus-5.4/venus.mbn.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


> > 
> > > +};
> > > +
> > >   &watchdog {
> > >   	clocks = <&sleep_clk>;
> > >   };
> > > 
> > > -- 
> > > 2.34.1
> > > 
> -- 
> Best Regards,
> Renjiang
> 

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
> 
> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
> > On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
> > > QCS615 uses the same video core as SC7180, so reuse the same resource
> > > data of SC7180 for QCS615 to enable video functionality.
> > > 
> > > There are no resources for the video-decoder and video-encoder nodes
> > > in the device tree, so remove these two nodes from the device tree. In
> > > addition, to ensure that the video codec functions properly, use [3]
> > > to add encoder and decoder node entries in the venus driver.
> > > 
> > > Validated this series on QCS615 and SC7180.
> > > 
> > > Note:
> > > This series consist of DT patches and a venus driver patch. The patch
> > > 1/3, which is venus driver patch, can be picked independently without
> > > having any functional dependency. But patch 2/3 & patch 3/3, which are
> > > DT patches, still depend on [1].
> > I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
> > on QCS615 over(?)clocked.
> Agree, so we need to make sure that the driver patch is not picked after the
> DT patch.

Worse: we need to make sure that the driver patch is present in the
branch which picks up DT patches. Otherwise building & testing that
branch (which is not unfrequent when doing git bisect) will fail.

The easiest way to ensure that is to merge driver changes in v6.N and
then DT changes in v6.N+1.

-- 
With best wishes
Dmitry

Re: [PATCH v8 1/3] media: venus: pm_helpers: use opp-table for the frequency

[Renjiang Han]

On 5/31/2025 4:26 AM, Dmitry Baryshkov wrote:
> On Fri, May 30, 2025 at 09:32:13AM +0530, Renjiang Han wrote:
>> The frequency value in the opp-table in the device tree and the freq_tbl
>> in the driver are the same.
>>
>> Therefore, update pm_helpers.c to use the opp-table for frequency values
>> for the v4 core.
> You are kind of missing the linking between the first two sentences. "The
> tables are the same, so use the second one." You need to explain that
> some of the platforms (provide examples) use the same core, but
> different frequency tables. Using OPP tables allows us to abstract core
> description from the frequency data and use fallback compatibles.
OK. Thanks for your comment. I'll update this message in next version.
>
>> If getting data from the opp table fails, fall back to using the frequency
>> table.
>>
>> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
>> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
>> ---
>>   drivers/media/platform/qcom/venus/pm_helpers.c | 53 +++++++++++++++++++-------
>>   1 file changed, 39 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
>> index 409aa9bd0b5d099c993eedb03177ec5ed918b4a0..434dd66076e8faf7f3feac6c29152789f8d2f81b 100644
>> --- a/drivers/media/platform/qcom/venus/pm_helpers.c
>> +++ b/drivers/media/platform/qcom/venus/pm_helpers.c
>> @@ -43,14 +43,20 @@ static int core_clks_enable(struct venus_core *core)
>>   	const struct venus_resources *res = core->res;
>>   	const struct freq_tbl *freq_tbl = core->res->freq_tbl;
>>   	unsigned int freq_tbl_size = core->res->freq_tbl_size;
>> +	struct device *dev = core->dev;
>> +	struct dev_pm_opp *opp;
>>   	unsigned long freq;
>>   	unsigned int i;
>>   	int ret;
>>   
>> -	if (!freq_tbl)
>> -		return -EINVAL;
>> -
>> -	freq = freq_tbl[freq_tbl_size - 1].freq;
>> +	opp = dev_pm_opp_find_freq_ceil(dev, &freq);
>> +	if (IS_ERR(opp)) {
>> +		if (!freq_tbl)
>> +			return -EINVAL;
>> +		freq = freq_tbl[freq_tbl_size - 1].freq;
>> +	} else {
>> +		dev_pm_opp_put(opp);
>> +	}
>>   
>>   	for (i = 0; i < res->clks_num; i++) {
>>   		if (IS_V6(core)) {
>> @@ -631,12 +637,15 @@ min_loaded_core(struct venus_inst *inst, u32 *min_coreid, u32 *min_load, bool lo
>>   
>>   static int decide_core(struct venus_inst *inst)
>>   {
>> +	const struct freq_tbl *freq_tbl = inst->core->res->freq_tbl;
>>   	const u32 ptype = HFI_PROPERTY_CONFIG_VIDEOCORES_USAGE;
>>   	struct venus_core *core = inst->core;
>>   	u32 min_coreid, min_load, cur_inst_load;
>>   	u32 min_lp_coreid, min_lp_load, cur_inst_lp_load;
>>   	struct hfi_videocores_usage_type cu;
>> -	unsigned long max_freq;
>> +	unsigned long max_freq = ULONG_MAX;
>> +	struct device *dev = core->dev;
>> +	struct dev_pm_opp *opp;
>>   	int ret = 0;
>>   
>>   	if (legacy_binding) {
>> @@ -659,7 +668,11 @@ static int decide_core(struct venus_inst *inst)
>>   	cur_inst_lp_load *= inst->clk_data.low_power_freq;
>>   	/*TODO : divide this inst->load by work_route */
>>   
>> -	max_freq = core->res->freq_tbl[0].freq;
>> +	opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
>> +	if (IS_ERR(opp))
>> +		max_freq = freq_tbl[0].freq;
>> +	else
>> +		dev_pm_opp_put(opp);
>>   
>>   	min_loaded_core(inst, &min_coreid, &min_load, false);
>>   	min_loaded_core(inst, &min_lp_coreid, &min_lp_load, true);
>> @@ -1082,7 +1095,9 @@ static int load_scale_v4(struct venus_inst *inst)
>>   	unsigned int num_rows = core->res->freq_tbl_size;
>>   	struct device *dev = core->dev;
>>   	unsigned long freq = 0, freq_core1 = 0, freq_core2 = 0;
>> +	unsigned long max_freq = ULONG_MAX;
>>   	unsigned long filled_len = 0;
>> +	struct dev_pm_opp *opp;
>>   	int i, ret = 0;
>>   
>>   	for (i = 0; i < inst->num_input_bufs; i++)
>> @@ -1108,19 +1123,29 @@ static int load_scale_v4(struct venus_inst *inst)
>>   
>>   	freq = max(freq_core1, freq_core2);
>>   
>> -	if (freq > table[0].freq) {
>> -		dev_dbg(dev, VDBGL "requested clock rate: %lu scaling clock rate : %lu\n",
>> -			freq, table[0].freq);
>> +	opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
>> +	if (IS_ERR(opp))
>> +		max_freq = table[0].freq;
>> +	else
>> +		dev_pm_opp_put(opp);
>>   
>> -		freq = table[0].freq;
>> +	if (freq > max_freq) {
>> +		dev_dbg(dev, VDBGL "requested clock rate: %lu scaling clock rate : %lu\n",
>> +			freq, max_freq);
>> +		freq = max_freq;
>>   		goto set_freq;
>>   	}
>>   
>> -	for (i = num_rows - 1 ; i >= 0; i--) {
>> -		if (freq <= table[i].freq) {
>> -			freq = table[i].freq;
>> -			break;
>> +	opp = dev_pm_opp_find_freq_ceil(dev, &freq);
>> +	if (IS_ERR(opp)) {
>> +		for (i = num_rows - 1 ; i >= 0; i--) {
>> +			if (freq <= table[i].freq) {
>> +				freq = table[i].freq;
>> +				break;
>> +			}
>>   		}
>> +	} else {
>> +		dev_pm_opp_put(opp);
>>   	}
>>   
>>   set_freq:
>>
>> -- 
>> 2.34.1
>>
-- 
Best Regards,
Renjiang

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

On 6/2/2025 2:16 PM, Dmitry Baryshkov wrote:
> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
>>>> QCS615 uses the same video core as SC7180, so reuse the same resource
>>>> data of SC7180 for QCS615 to enable video functionality.
>>>>
>>>> There are no resources for the video-decoder and video-encoder nodes
>>>> in the device tree, so remove these two nodes from the device tree. In
>>>> addition, to ensure that the video codec functions properly, use [3]
>>>> to add encoder and decoder node entries in the venus driver.
>>>>
>>>> Validated this series on QCS615 and SC7180.
>>>>
>>>> Note:
>>>> This series consist of DT patches and a venus driver patch. The patch
>>>> 1/3, which is venus driver patch, can be picked independently without
>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>> DT patches, still depend on [1].
>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
>>> on QCS615 over(?)clocked.
>> Agree, so we need to make sure that the driver patch is not picked after the
>> DT patch.
> Worse: we need to make sure that the driver patch is present in the
> branch which picks up DT patches. Otherwise building & testing that
> branch (which is not unfrequent when doing git bisect) will fail.
>
> The easiest way to ensure that is to merge driver changes in v6.N and
> then DT changes in v6.N+1.
Yes, now DT patches are pending videocc DT patch. I think the
venus driver patch will likely be picked no later than the DT patches.

-- 
Best Regards,
Renjiang

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On Thu, Jun 05, 2025 at 07:24:55PM +0800, Renjiang Han wrote:
> 
> On 6/2/2025 2:16 PM, Dmitry Baryshkov wrote:
> > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
> > > On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
> > > > On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
> > > > > QCS615 uses the same video core as SC7180, so reuse the same resource
> > > > > data of SC7180 for QCS615 to enable video functionality.
> > > > > 
> > > > > There are no resources for the video-decoder and video-encoder nodes
> > > > > in the device tree, so remove these two nodes from the device tree. In
> > > > > addition, to ensure that the video codec functions properly, use [3]
> > > > > to add encoder and decoder node entries in the venus driver.
> > > > > 
> > > > > Validated this series on QCS615 and SC7180.
> > > > > 
> > > > > Note:
> > > > > This series consist of DT patches and a venus driver patch. The patch
> > > > > 1/3, which is venus driver patch, can be picked independently without
> > > > > having any functional dependency. But patch 2/3 & patch 3/3, which are
> > > > > DT patches, still depend on [1].
> > > > I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
> > > > on QCS615 over(?)clocked.
> > > Agree, so we need to make sure that the driver patch is not picked after the
> > > DT patch.
> > Worse: we need to make sure that the driver patch is present in the
> > branch which picks up DT patches. Otherwise building & testing that
> > branch (which is not unfrequent when doing git bisect) will fail.
> > 
> > The easiest way to ensure that is to merge driver changes in v6.N and
> > then DT changes in v6.N+1.
> Yes, now DT patches are pending videocc DT patch. I think the
> venus driver patch will likely be picked no later than the DT patches.

Please read carefully: it's a question of the patch being present in the
_same_ branch before DT patches are picked up.

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Krzysztof Kozlowski]

On 02/06/2025 08:16, Dmitry Baryshkov wrote:
> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
>>
>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
>>>> QCS615 uses the same video core as SC7180, so reuse the same resource
>>>> data of SC7180 for QCS615 to enable video functionality.
>>>>
>>>> There are no resources for the video-decoder and video-encoder nodes
>>>> in the device tree, so remove these two nodes from the device tree. In
>>>> addition, to ensure that the video codec functions properly, use [3]
>>>> to add encoder and decoder node entries in the venus driver.
>>>>
>>>> Validated this series on QCS615 and SC7180.
>>>>
>>>> Note:
>>>> This series consist of DT patches and a venus driver patch. The patch
>>>> 1/3, which is venus driver patch, can be picked independently without
>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>> DT patches, still depend on [1].
>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
>>> on QCS615 over(?)clocked.
>> Agree, so we need to make sure that the driver patch is not picked after the
>> DT patch.
> 
> Worse: we need to make sure that the driver patch is present in the
> branch which picks up DT patches. Otherwise building & testing that


Well, that's a NAK then (although depends what you mean by DT).

Best regards,
Krzysztof

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 02/06/2025 08:16, Dmitry Baryshkov wrote:
> > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
> >>
> >> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
> >>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
> >>>> QCS615 uses the same video core as SC7180, so reuse the same resource
> >>>> data of SC7180 for QCS615 to enable video functionality.
> >>>>
> >>>> There are no resources for the video-decoder and video-encoder nodes
> >>>> in the device tree, so remove these two nodes from the device tree. In
> >>>> addition, to ensure that the video codec functions properly, use [3]
> >>>> to add encoder and decoder node entries in the venus driver.
> >>>>
> >>>> Validated this series on QCS615 and SC7180.
> >>>>
> >>>> Note:
> >>>> This series consist of DT patches and a venus driver patch. The patch
> >>>> 1/3, which is venus driver patch, can be picked independently without
> >>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
> >>>> DT patches, still depend on [1].
> >>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
> >>> on QCS615 over(?)clocked.
> >> Agree, so we need to make sure that the driver patch is not picked after the
> >> DT patch.
> >
> > Worse: we need to make sure that the driver patch is present in the
> > branch which picks up DT patches. Otherwise building & testing that
>
>
> Well, that's a NAK then (although depends what you mean by DT).

I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
patch. Or just merging the patches in two consequent releases.

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Krzysztof Kozlowski]

On 05/06/2025 14:30, Dmitry Baryshkov wrote:
> On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 02/06/2025 08:16, Dmitry Baryshkov wrote:
>>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
>>>>
>>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
>>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
>>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource
>>>>>> data of SC7180 for QCS615 to enable video functionality.
>>>>>>
>>>>>> There are no resources for the video-decoder and video-encoder nodes
>>>>>> in the device tree, so remove these two nodes from the device tree. In
>>>>>> addition, to ensure that the video codec functions properly, use [3]
>>>>>> to add encoder and decoder node entries in the venus driver.
>>>>>>
>>>>>> Validated this series on QCS615 and SC7180.
>>>>>>
>>>>>> Note:
>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>> DT patches, still depend on [1].
>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
>>>>> on QCS615 over(?)clocked.
>>>> Agree, so we need to make sure that the driver patch is not picked after the
>>>> DT patch.
>>>
>>> Worse: we need to make sure that the driver patch is present in the
>>> branch which picks up DT patches. Otherwise building & testing that
>>
>>
>> Well, that's a NAK then (although depends what you mean by DT).
> 
> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver

Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
one branch.

> patch. Or just merging the patches in two consequent releases.

That's a new device nodes, new hardware so it should not be blocked by
any driver patch. This is just totally broken process / patchset / work.

Best regards,
Krzysztof

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Bryan O'Donoghue]

On 31/05/2025 01:05, Renjiang Han wrote:
>>>
>>> Note:
>>> This series consist of DT patches and a venus driver patch. The patch
>>> 1/3, which is venus driver patch, can be picked independently without
>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>> DT patches, still depend on [1].
>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
>> on QCS615 over(?)clocked.
> Agree, so we need to make sure that the driver patch is not picked after 
> the DT patch.

This statement is confusing.

1/3 states that there will be a fallback if there is no OPP table present.

Giving the code a glance, I believe that is so, freq_table should be 
used if there is no OPP specified in the DT.

I think we are having a hard time here understanding what you are saying.

My understanding:

- venus modification is standalone 1/3
   Qcs615 will fallback if no OPP is present

- dt modification 2/3 3/3 is therefore also independent of driver

---
bod

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Bryan O'Donoghue]

On 05/06/2025 13:33, Krzysztof Kozlowski wrote:
> On 05/06/2025 14:30, Dmitry Baryshkov wrote:
>> On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>
>>> On 02/06/2025 08:16, Dmitry Baryshkov wrote:
>>>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
>>>>>
>>>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
>>>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
>>>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource
>>>>>>> data of SC7180 for QCS615 to enable video functionality.
>>>>>>>
>>>>>>> There are no resources for the video-decoder and video-encoder nodes
>>>>>>> in the device tree, so remove these two nodes from the device tree. In
>>>>>>> addition, to ensure that the video codec functions properly, use [3]
>>>>>>> to add encoder and decoder node entries in the venus driver.
>>>>>>>
>>>>>>> Validated this series on QCS615 and SC7180.
>>>>>>>
>>>>>>> Note:
>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>> DT patches, still depend on [1].
>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
>>>>>> on QCS615 over(?)clocked.
>>>>> Agree, so we need to make sure that the driver patch is not picked after the
>>>>> DT patch.
>>>>
>>>> Worse: we need to make sure that the driver patch is present in the
>>>> branch which picks up DT patches. Otherwise building & testing that
>>>
>>>
>>> Well, that's a NAK then (although depends what you mean by DT).
>>
>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
> 
> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
> one branch.
> 
>> patch. Or just merging the patches in two consequent releases.
> 
> That's a new device nodes, new hardware so it should not be blocked by
> any driver patch. This is just totally broken process / patchset / work.
> 
> Best regards,
> Krzysztof

Reading this thread, I don't think that is the case.

I don't see how patches 2/3 or 3/3 depend on 1/3.

The frequency table is a fallback in the driver and the DT changes are 
completely straight forward.

TBH, I think we are hitting an email comms/social barrier here, not a 
technical one.

@Renjiang can you please confirm that freq_table is a fallback, qcs615 
will work without OPP table and the DTS stuff doesn't depend on the driver.

TBH, I don't see how the DTS can or should but...

---
bod

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On Thu, Jun 05, 2025 at 01:40:03PM +0100, Bryan O'Donoghue wrote:
> On 05/06/2025 13:33, Krzysztof Kozlowski wrote:
> > On 05/06/2025 14:30, Dmitry Baryshkov wrote:
> > > On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > 
> > > > On 02/06/2025 08:16, Dmitry Baryshkov wrote:
> > > > > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
> > > > > > 
> > > > > > On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
> > > > > > > On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
> > > > > > > > QCS615 uses the same video core as SC7180, so reuse the same resource
> > > > > > > > data of SC7180 for QCS615 to enable video functionality.
> > > > > > > > 
> > > > > > > > There are no resources for the video-decoder and video-encoder nodes
> > > > > > > > in the device tree, so remove these two nodes from the device tree. In
> > > > > > > > addition, to ensure that the video codec functions properly, use [3]
> > > > > > > > to add encoder and decoder node entries in the venus driver.
> > > > > > > > 
> > > > > > > > Validated this series on QCS615 and SC7180.
> > > > > > > > 
> > > > > > > > Note:
> > > > > > > > This series consist of DT patches and a venus driver patch. The patch
> > > > > > > > 1/3, which is venus driver patch, can be picked independently without
> > > > > > > > having any functional dependency. But patch 2/3 & patch 3/3, which are
> > > > > > > > DT patches, still depend on [1].
> > > > > > > I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
> > > > > > > on QCS615 over(?)clocked.
> > > > > > Agree, so we need to make sure that the driver patch is not picked after the
> > > > > > DT patch.
> > > > > 
> > > > > Worse: we need to make sure that the driver patch is present in the
> > > > > branch which picks up DT patches. Otherwise building & testing that
> > > > 
> > > > 
> > > > Well, that's a NAK then (although depends what you mean by DT).
> > > 
> > > I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
> > 
> > Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
> > one branch.

Surely it can... Like any other cross-subsystem dependency.

> > 
> > > patch. Or just merging the patches in two consequent releases.
> > 
> > That's a new device nodes, new hardware so it should not be blocked by
> > any driver patch. This is just totally broken process / patchset / work.
> > 
> > Best regards,
> > Krzysztof
> 
> Reading this thread, I don't think that is the case.
> 
> I don't see how patches 2/3 or 3/3 depend on 1/3.

Please correct me if I'm wrong. Without driver changes from patch 1, the
driver will always use frequency table from the driver itself. In this
case it will be the frequency table (and corners) for SC7180, which
would make venus driver overclock the hardware on QCS615.

> 
> The frequency table is a fallback in the driver and the DT changes are
> completely straight forward.
> 
> TBH, I think we are hitting an email comms/social barrier here, not a
> technical one.

I assume so.

> 
> @Renjiang can you please confirm that freq_table is a fallback, qcs615 will
> work without OPP table and the DTS stuff doesn't depend on the driver.
> 
> TBH, I don't see how the DTS can or should but...
> 
> ---
> bod
> 

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Bryan O'Donoghue]

On 05/06/2025 17:02, Dmitry Baryshkov wrote:
> Please correct me if I'm wrong. Without driver changes from patch 1, the
> driver will always use frequency table from the driver itself. In this
> case it will be the frequency table (and corners) for SC7180, which
> would make venus driver overclock the hardware on QCS615.

True.

Yes, let's apply 1/3 and then re-submit 2 and 3 once it hits -next.

---
bod

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On 05/06/2025 17:39, Bryan O'Donoghue wrote:
> On 05/06/2025 17:02, Dmitry Baryshkov wrote:
>> Please correct me if I'm wrong. Without driver changes from patch 1, the
>> driver will always use frequency table from the driver itself. In this
>> case it will be the frequency table (and corners) for SC7180, which
>> would make venus driver overclock the hardware on QCS615.
> 
> True.
> 
> Yes, let's apply 1/3 and then re-submit 2 and 3 once it hits -next.

Not enough. 1/3 should hit Bjorn's tree, see Arnd's rejection for 6.15 
patchset.

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Krzysztof Kozlowski]

On 05/06/2025 18:02, Dmitry Baryshkov wrote:
> On Thu, Jun 05, 2025 at 01:40:03PM +0100, Bryan O'Donoghue wrote:
>> On 05/06/2025 13:33, Krzysztof Kozlowski wrote:
>>> On 05/06/2025 14:30, Dmitry Baryshkov wrote:
>>>> On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>>
>>>>> On 02/06/2025 08:16, Dmitry Baryshkov wrote:
>>>>>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
>>>>>>>
>>>>>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
>>>>>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
>>>>>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource
>>>>>>>>> data of SC7180 for QCS615 to enable video functionality.
>>>>>>>>>
>>>>>>>>> There are no resources for the video-decoder and video-encoder nodes
>>>>>>>>> in the device tree, so remove these two nodes from the device tree. In
>>>>>>>>> addition, to ensure that the video codec functions properly, use [3]
>>>>>>>>> to add encoder and decoder node entries in the venus driver.
>>>>>>>>>
>>>>>>>>> Validated this series on QCS615 and SC7180.
>>>>>>>>>
>>>>>>>>> Note:
>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>>>> DT patches, still depend on [1].
>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
>>>>>>>> on QCS615 over(?)clocked.
>>>>>>> Agree, so we need to make sure that the driver patch is not picked after the
>>>>>>> DT patch.
>>>>>>
>>>>>> Worse: we need to make sure that the driver patch is present in the
>>>>>> branch which picks up DT patches. Otherwise building & testing that
>>>>>
>>>>>
>>>>> Well, that's a NAK then (although depends what you mean by DT).
>>>>
>>>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
>>>
>>> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
>>> one branch.
> 
> Surely it can... Like any other cross-subsystem dependency.

Sure it cannot, because this breaks the basic rule of not mixing drivers
into DTS. Arm soc maintainers are not merging drivers back to DTS and
the DTS must not go via drivers tree. These are basic assumptions around
DTS, see subsystem profile for more explanations.


Best regards,
Krzysztof

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On 05/06/2025 18:12, Krzysztof Kozlowski wrote:
> On 05/06/2025 18:02, Dmitry Baryshkov wrote:
>> On Thu, Jun 05, 2025 at 01:40:03PM +0100, Bryan O'Donoghue wrote:
>>> On 05/06/2025 13:33, Krzysztof Kozlowski wrote:
>>>> On 05/06/2025 14:30, Dmitry Baryshkov wrote:
>>>>> On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>>>
>>>>>> On 02/06/2025 08:16, Dmitry Baryshkov wrote:
>>>>>>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote:
>>>>>>>>
>>>>>>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote:
>>>>>>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote:
>>>>>>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource
>>>>>>>>>> data of SC7180 for QCS615 to enable video functionality.
>>>>>>>>>>
>>>>>>>>>> There are no resources for the video-decoder and video-encoder nodes
>>>>>>>>>> in the device tree, so remove these two nodes from the device tree. In
>>>>>>>>>> addition, to ensure that the video codec functions properly, use [3]
>>>>>>>>>> to add encoder and decoder node entries in the venus driver.
>>>>>>>>>>
>>>>>>>>>> Validated this series on QCS615 and SC7180.
>>>>>>>>>>
>>>>>>>>>> Note:
>>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>>>>> DT patches, still depend on [1].
>>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core
>>>>>>>>> on QCS615 over(?)clocked.
>>>>>>>> Agree, so we need to make sure that the driver patch is not picked after the
>>>>>>>> DT patch.
>>>>>>>
>>>>>>> Worse: we need to make sure that the driver patch is present in the
>>>>>>> branch which picks up DT patches. Otherwise building & testing that
>>>>>>
>>>>>>
>>>>>> Well, that's a NAK then (although depends what you mean by DT).
>>>>>
>>>>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
>>>>
>>>> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
>>>> one branch.
>>
>> Surely it can... Like any other cross-subsystem dependency.
> 
> Sure it cannot, because this breaks the basic rule of not mixing drivers
> into DTS. Arm soc maintainers are not merging drivers back to DTS and
> the DTS must not go via drivers tree. These are basic assumptions around
> DTS, see subsystem profile for more explanations.

Ack, so v6.N+1, which is also fine.

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

On 6/5/2025 8:40 PM, Bryan O'Donoghue wrote:
>>>> Well, that's a NAK then (although depends what you mean by DT).
>>>
>>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
>>
>> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
>> one branch.
>>
>>> patch. Or just merging the patches in two consequent releases.
>>
>> That's a new device nodes, new hardware so it should not be blocked by
>> any driver patch. This is just totally broken process / patchset / work.
>>
>> Best regards,
>> Krzysztof
>
> Reading this thread, I don't think that is the case.
>
> I don't see how patches 2/3 or 3/3 depend on 1/3.
>
> The frequency table is a fallback in the driver and the DT changes are 
> completely straight forward.
>
> TBH, I think we are hitting an email comms/social barrier here, not a 
> technical one.
>
> @Renjiang can you please confirm that freq_table is a fallback, qcs615 
> will work without OPP table and the DTS stuff doesn't depend on the 
> driver.
yes, freq_table is a fallback. driver will use freq_table without OPP 
table. the DTS doesn't depend on the driver.
>
> TBH, I don't see how the DTS can or should but...
>
> ---
> bod 

-- 
Best Regards,
Renjiang

Re: [PATCH v8 1/3] media: venus: pm_helpers: use opp-table for the frequency

[Renjiang Han]

On 5/31/2025 7:11 PM, Konrad Dybcio wrote:
> On 5/30/25 6:02 AM, Renjiang Han wrote:
>> The frequency value in the opp-table in the device tree and the freq_tbl
>> in the driver are the same.
>>
>> Therefore, update pm_helpers.c to use the opp-table for frequency values
>> for the v4 core.
>> If getting data from the opp table fails, fall back to using the frequency
>> table.
>>
>> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
>> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
>> ---
> You can save yourself some error-checking pain in this patch if you
> do something like
>
> ret = devm_pm_opp_of_add_table(dev);
> if (ret == -ENODEV) {
> 	for (i = 0; i < freq_tbl_len; i++)
> 		dev_pm_opp_add(dev, freq_tbl[i], 0);
> }
>
> to programmatically migrate everyone to OPP..
>
> But - tangent - I'd say efforts to preserve compatibility with DTs that
> don't even contain frequency data for a given target are rather futile..
> Such descriptions where we only know the frequency (be it the tables that
> we currently have, or the constructed OPP tables that only contain frequency
> data and no voltage corners) are incomplete, and if the system manages to
> not crash if the driver requests a TURBO/max freq, it's all because we got
> lucky, as this consumer is not voting on (MM)CX.
>
> That said, it's probably to keep the breakage to minimum, especially
> given this is an old driver for old hardware.. I'll add the missing
> OPPs across platforms with an intention to drop the hardcoding somewhere
> in the future
>
> Konrad
Thanks for your comments. This is a good way. I'll update in next version.

-- 
Best Regards,
Renjiang

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

On 6/6/2025 11:52 AM, Renjiang Han wrote:
>
> On 6/5/2025 8:40 PM, Bryan O'Donoghue wrote:
>>>>> Well, that's a NAK then (although depends what you mean by DT).
>>>>
>>>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver
>>>
>>> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into
>>> one branch.
>>>
>>>> patch. Or just merging the patches in two consequent releases.
>>>
>>> That's a new device nodes, new hardware so it should not be blocked by
>>> any driver patch. This is just totally broken process / patchset / 
>>> work.
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Reading this thread, I don't think that is the case.
>>
>> I don't see how patches 2/3 or 3/3 depend on 1/3.
>>
>> The frequency table is a fallback in the driver and the DT changes 
>> are completely straight forward.
>>
>> TBH, I think we are hitting an email comms/social barrier here, not a 
>> technical one.
>>
>> @Renjiang can you please confirm that freq_table is a fallback, 
>> qcs615 will work without OPP table and the DTS stuff doesn't depend 
>> on the driver.
> yes, freq_table is a fallback. driver will use freq_table without OPP 
> table. the DTS doesn't depend on the driver.
To correct my previous response:
For this project, the driver patch needs to be merged first. Since it
falls back to SC7180, but their frequencies are different which is
reflected in the OPP table defined in the DTS.

The DTS patch is intended to enable video function on the QCS615 platform.

The driver patch is to switch from using the driver freq_table to the
OPP table from the DTS. Without it, the driver will continue to use the
internal freq_table as before.

Therefore, if the DTS patch is applied without the driver patch, the video
function will be enabled on the QCS615 platform, but the driver will use
the SC7180 frequency table, which can lead to an overclocking issue.
>>
>> TBH, I don't see how the DTS can or should but...
>>
>> ---
>> bod 
>
-- 
Best Regards,
Renjiang

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Krzysztof Kozlowski]

On 06/06/2025 09:51, Renjiang Han wrote:
>>>
>>> Reading this thread, I don't think that is the case.
>>>
>>> I don't see how patches 2/3 or 3/3 depend on 1/3.
>>>
>>> The frequency table is a fallback in the driver and the DT changes 
>>> are completely straight forward.
>>>
>>> TBH, I think we are hitting an email comms/social barrier here, not a 
>>> technical one.
>>>
>>> @Renjiang can you please confirm that freq_table is a fallback, 
>>> qcs615 will work without OPP table and the DTS stuff doesn't depend 
>>> on the driver.
>> yes, freq_table is a fallback. driver will use freq_table without OPP 
>> table. the DTS doesn't depend on the driver.
> To correct my previous response:
> For this project, the driver patch needs to be merged first. Since it
> falls back to SC7180, but their frequencies are different which is
> reflected in the OPP table defined in the DTS.
> 
> The DTS patch is intended to enable video function on the QCS615 platform.
> 
> The driver patch is to switch from using the driver freq_table to the
> OPP table from the DTS. Without it, the driver will continue to use the
> internal freq_table as before.
> 
> Therefore, if the DTS patch is applied without the driver patch, the video
> function will be enabled on the QCS615 platform, but the driver will use
> the SC7180 frequency table, which can lead to an overclocking issue.

This means devices are not really compatible and DTS is not correct.

Best regards,
Krzysztof

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>
>>>> Note:
>>>> This series consist of DT patches and a venus driver patch. The patch
>>>> 1/3, which is venus driver patch, can be picked independently without
>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>> DT patches, still depend on [1].
>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video 
>>> core
>>> on QCS615 over(?)clocked.
>> Agree, so we need to make sure that the driver patch is not picked 
>> after the DT patch.
>
> This statement is confusing.
>
> 1/3 states that there will be a fallback if there is no OPP table 
> present.
>
> Giving the code a glance, I believe that is so, freq_table should be 
> used if there is no OPP specified in the DT.
>
> I think we are having a hard time here understanding what you are saying.
>
> My understanding:
>
> - venus modification is standalone 1/3
>   Qcs615 will fallback if no OPP is present
>
> - dt modification 2/3 3/3 is therefore also independent of driver
>
> ---
> bod
yes, let me re-spin this with driver patch alone. Once that gets in, 
will bring in the DT patches.

-- 
Best Regards,
Renjiang

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Krzysztof Kozlowski]

On 06/06/2025 14:37, Renjiang Han wrote:
> 
> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>
>>>>> Note:
>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>> DT patches, still depend on [1].
>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video 
>>>> core
>>>> on QCS615 over(?)clocked.
>>> Agree, so we need to make sure that the driver patch is not picked 
>>> after the DT patch.
>>
>> This statement is confusing.
>>
>> 1/3 states that there will be a fallback if there is no OPP table 
>> present.
>>
>> Giving the code a glance, I believe that is so, freq_table should be 
>> used if there is no OPP specified in the DT.
>>
>> I think we are having a hard time here understanding what you are saying.
>>
>> My understanding:
>>
>> - venus modification is standalone 1/3
>>   Qcs615 will fallback if no OPP is present
>>
>> - dt modification 2/3 3/3 is therefore also independent of driver
>>
>> ---
>> bod
> yes, let me re-spin this with driver patch alone. Once that gets in, 
> will bring in the DT patches.
Did you read my feedback? There is no "once that gets in". DTS is an
independent hardware description and your patchset claiming there is
dependency is just broken.

I am repeating this since few emails, so shall I NAK it that you will
address the main issue you have?

Best regards,
Krzysztof

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
> On 06/06/2025 14:37, Renjiang Han wrote:
>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>> Note:
>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>> DT patches, still depend on [1].
>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video
>>>>> core
>>>>> on QCS615 over(?)clocked.
>>>> Agree, so we need to make sure that the driver patch is not picked
>>>> after the DT patch.
>>> This statement is confusing.
>>>
>>> 1/3 states that there will be a fallback if there is no OPP table
>>> present.
>>>
>>> Giving the code a glance, I believe that is so, freq_table should be
>>> used if there is no OPP specified in the DT.
>>>
>>> I think we are having a hard time here understanding what you are saying.
>>>
>>> My understanding:
>>>
>>> - venus modification is standalone 1/3
>>>    Qcs615 will fallback if no OPP is present
>>>
>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>
>>> ---
>>> bod
>> yes, let me re-spin this with driver patch alone. Once that gets in,
>> will bring in the DT patches.
> Did you read my feedback? There is no "once that gets in". DTS is an
> independent hardware description and your patchset claiming there is
> dependency is just broken.
>
> I am repeating this since few emails, so shall I NAK it that you will
> address the main issue you have?
>
> Best regards,
> Krzysztof

Hi Krzysztof

SC7180 and QCS615 use the same video core. Only difference lies in the
freq_table for the video. Freq_table is generally determined at SOC level.
The Venus driver does not currently handle freq_table compatibility well
across platforms. This patch enables the driver to use the OPP-table from
the DT, addressing the frequency compatibility issue.

-- 
Best Regards,
Renjiang

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Krzysztof Kozlowski]

On 06/06/2025 14:51, Renjiang Han wrote:
> 
> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
>> On 06/06/2025 14:37, Renjiang Han wrote:
>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>>> Note:
>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>> DT patches, still depend on [1].
>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video
>>>>>> core
>>>>>> on QCS615 over(?)clocked.
>>>>> Agree, so we need to make sure that the driver patch is not picked
>>>>> after the DT patch.
>>>> This statement is confusing.
>>>>
>>>> 1/3 states that there will be a fallback if there is no OPP table
>>>> present.
>>>>
>>>> Giving the code a glance, I believe that is so, freq_table should be
>>>> used if there is no OPP specified in the DT.
>>>>
>>>> I think we are having a hard time here understanding what you are saying.
>>>>
>>>> My understanding:
>>>>
>>>> - venus modification is standalone 1/3
>>>>    Qcs615 will fallback if no OPP is present
>>>>
>>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>>
>>>> ---
>>>> bod
>>> yes, let me re-spin this with driver patch alone. Once that gets in,
>>> will bring in the DT patches.
>> Did you read my feedback? There is no "once that gets in". DTS is an
>> independent hardware description and your patchset claiming there is
>> dependency is just broken.
>>
>> I am repeating this since few emails, so shall I NAK it that you will
>> address the main issue you have?
>>
>> Best regards,
>> Krzysztof
> 
> Hi Krzysztof
> 
> SC7180 and QCS615 use the same video core. Only difference lies in the
> freq_table for the video. Freq_table is generally determined at SOC level.
> The Venus driver does not currently handle freq_table compatibility well
> across platforms. This patch enables the driver to use the OPP-table from
> the DT, addressing the frequency compatibility issue.
This does not resolve the main problem at all. If SW cannot use the
fallback alone, your fallback has no meaning and is not only confusing
but actually incorrect. And based on previous statements like
"overclocking" it is not only incorrect, but even harmful.

Best regards,
Krzysztof

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote:
> On 06/06/2025 14:51, Renjiang Han wrote:
>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
>>> On 06/06/2025 14:37, Renjiang Han wrote:
>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>>>> Note:
>>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>>> DT patches, still depend on [1].
>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video
>>>>>>> core
>>>>>>> on QCS615 over(?)clocked.
>>>>>> Agree, so we need to make sure that the driver patch is not picked
>>>>>> after the DT patch.
>>>>> This statement is confusing.
>>>>>
>>>>> 1/3 states that there will be a fallback if there is no OPP table
>>>>> present.
>>>>>
>>>>> Giving the code a glance, I believe that is so, freq_table should be
>>>>> used if there is no OPP specified in the DT.
>>>>>
>>>>> I think we are having a hard time here understanding what you are saying.
>>>>>
>>>>> My understanding:
>>>>>
>>>>> - venus modification is standalone 1/3
>>>>>     Qcs615 will fallback if no OPP is present
>>>>>
>>>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>>>
>>>>> ---
>>>>> bod
>>>> yes, let me re-spin this with driver patch alone. Once that gets in,
>>>> will bring in the DT patches.
>>> Did you read my feedback? There is no "once that gets in". DTS is an
>>> independent hardware description and your patchset claiming there is
>>> dependency is just broken.
>>>
>>> I am repeating this since few emails, so shall I NAK it that you will
>>> address the main issue you have?
>>>
>>> Best regards,
>>> Krzysztof
>> Hi Krzysztof
>>
>> SC7180 and QCS615 use the same video core. Only difference lies in the
>> freq_table for the video. Freq_table is generally determined at SOC level.
>> The Venus driver does not currently handle freq_table compatibility well
>> across platforms. This patch enables the driver to use the OPP-table from
>> the DT, addressing the frequency compatibility issue.
> This does not resolve the main problem at all. If SW cannot use the
> fallback alone, your fallback has no meaning and is not only confusing
> but actually incorrect. And based on previous statements like
> "overclocking" it is not only incorrect, but even harmful.
>
> Best regards,
> Krzysztof
The fallback is only triggered when there is no OPP table in the DT.
Since the QCS615 DT will include an OPP table, the fallback logic will
not be used.

Also, if the freq from the freq_table and the OPP table are the same,
would it be acceptable to drop the freq_table from the driver?

-- 
Best Regards,
Renjiang

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Bryan O'Donoghue]

On 06/06/2025 14:32, Renjiang Han wrote:
> 
> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote:
>> On 06/06/2025 14:51, Renjiang Han wrote:
>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
>>>> On 06/06/2025 14:37, Renjiang Han wrote:
>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>>>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>>>>> Note:
>>>>>>>>> This series consist of DT patches and a venus driver patch. The 
>>>>>>>>> patch
>>>>>>>>> 1/3, which is venus driver patch, can be picked independently 
>>>>>>>>> without
>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, 
>>>>>>>>> which are
>>>>>>>>> DT patches, still depend on [1].
>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video
>>>>>>>> core
>>>>>>>> on QCS615 over(?)clocked.
>>>>>>> Agree, so we need to make sure that the driver patch is not picked
>>>>>>> after the DT patch.
>>>>>> This statement is confusing.
>>>>>>
>>>>>> 1/3 states that there will be a fallback if there is no OPP table
>>>>>> present.
>>>>>>
>>>>>> Giving the code a glance, I believe that is so, freq_table should be
>>>>>> used if there is no OPP specified in the DT.
>>>>>>
>>>>>> I think we are having a hard time here understanding what you are 
>>>>>> saying.
>>>>>>
>>>>>> My understanding:
>>>>>>
>>>>>> - venus modification is standalone 1/3
>>>>>>     Qcs615 will fallback if no OPP is present
>>>>>>
>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>>>>
>>>>>> ---
>>>>>> bod
>>>>> yes, let me re-spin this with driver patch alone. Once that gets in,
>>>>> will bring in the DT patches.
>>>> Did you read my feedback? There is no "once that gets in". DTS is an
>>>> independent hardware description and your patchset claiming there is
>>>> dependency is just broken.
>>>>
>>>> I am repeating this since few emails, so shall I NAK it that you will
>>>> address the main issue you have?
>>>>
>>>> Best regards,
>>>> Krzysztof
>>> Hi Krzysztof
>>>
>>> SC7180 and QCS615 use the same video core. Only difference lies in the
>>> freq_table for the video. Freq_table is generally determined at SOC 
>>> level.
>>> The Venus driver does not currently handle freq_table compatibility well
>>> across platforms. This patch enables the driver to use the OPP-table 
>>> from
>>> the DT, addressing the frequency compatibility issue.
>> This does not resolve the main problem at all. If SW cannot use the
>> fallback alone, your fallback has no meaning and is not only confusing
>> but actually incorrect. And based on previous statements like
>> "overclocking" it is not only incorrect, but even harmful.
>>
>> Best regards,
>> Krzysztof
> The fallback is only triggered when there is no OPP table in the DT.
> Since the QCS615 DT will include an OPP table, the fallback logic will
> not be used.
> 
> Also, if the freq from the freq_table and the OPP table are the same,
> would it be acceptable to drop the freq_table from the driver?

If you drop the freq_table, you will need to apply OPPs for the sc7180 
to DTS first before venus or you'll break sc7180.

I think TBH you should add a freq_tbl for QCS615 and make it so the 
order of patch application doesn't matter wrt adding OPP support.

- Add QCS freq_tbl
- Add OPP support

Then do whatever in DTS, nothing can break in this case.

As we've established the fallback isn't a fallback because it falls back 
to wrong data, so lets fix that.

---
bod

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Vikash Garodia]

On 6/6/2025 8:23 PM, Bryan O'Donoghue wrote:
> On 06/06/2025 14:32, Renjiang Han wrote:
>>
>> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote:
>>> On 06/06/2025 14:51, Renjiang Han wrote:
>>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
>>>>> On 06/06/2025 14:37, Renjiang Han wrote:
>>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>>>>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>>>>>> Note:
>>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>>>>> DT patches, still depend on [1].
>>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video
>>>>>>>>> core
>>>>>>>>> on QCS615 over(?)clocked.
>>>>>>>> Agree, so we need to make sure that the driver patch is not picked
>>>>>>>> after the DT patch.
>>>>>>> This statement is confusing.
>>>>>>>
>>>>>>> 1/3 states that there will be a fallback if there is no OPP table
>>>>>>> present.
>>>>>>>
>>>>>>> Giving the code a glance, I believe that is so, freq_table should be
>>>>>>> used if there is no OPP specified in the DT.
>>>>>>>
>>>>>>> I think we are having a hard time here understanding what you are saying.
>>>>>>>
>>>>>>> My understanding:
>>>>>>>
>>>>>>> - venus modification is standalone 1/3
>>>>>>>     Qcs615 will fallback if no OPP is present
>>>>>>>
>>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>>>>>
>>>>>>> ---
>>>>>>> bod
>>>>>> yes, let me re-spin this with driver patch alone. Once that gets in,
>>>>>> will bring in the DT patches.
>>>>> Did you read my feedback? There is no "once that gets in". DTS is an
>>>>> independent hardware description and your patchset claiming there is
>>>>> dependency is just broken.
>>>>>
>>>>> I am repeating this since few emails, so shall I NAK it that you will
>>>>> address the main issue you have?
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>> Hi Krzysztof
>>>>
>>>> SC7180 and QCS615 use the same video core. Only difference lies in the
>>>> freq_table for the video. Freq_table is generally determined at SOC level.
>>>> The Venus driver does not currently handle freq_table compatibility well
>>>> across platforms. This patch enables the driver to use the OPP-table from
>>>> the DT, addressing the frequency compatibility issue.
>>> This does not resolve the main problem at all. If SW cannot use the
>>> fallback alone, your fallback has no meaning and is not only confusing
>>> but actually incorrect. And based on previous statements like
>>> "overclocking" it is not only incorrect, but even harmful.
>>>
>>> Best regards,
>>> Krzysztof
>> The fallback is only triggered when there is no OPP table in the DT.
>> Since the QCS615 DT will include an OPP table, the fallback logic will
>> not be used.
>>
>> Also, if the freq from the freq_table and the OPP table are the same,
>> would it be acceptable to drop the freq_table from the driver?
> 
> If you drop the freq_table, you will need to apply OPPs for the sc7180 to DTS
> first before venus or you'll break sc7180.
> 
> I think TBH you should add a freq_tbl for QCS615 and make it so the order of
> patch application doesn't matter wrt adding OPP support.
That would my proposal too here. Add the proper table in driver resources for
QCS615, so that either of OPP or fallback would not matter and would be carrying
right values either way(no over clocking).

Regards,
Vikash
> 
> - Add QCS freq_tbl
> - Add OPP support
> 
> Then do whatever in DTS, nothing can break in this case.
> 
> As we've established the fallback isn't a fallback because it falls back to
> wrong data, so lets fix that.
> 
> ---
> bod

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On 06/06/2025 08:54, Krzysztof Kozlowski wrote:
> On 06/06/2025 09:51, Renjiang Han wrote:
>>>>
>>>> Reading this thread, I don't think that is the case.
>>>>
>>>> I don't see how patches 2/3 or 3/3 depend on 1/3.
>>>>
>>>> The frequency table is a fallback in the driver and the DT changes
>>>> are completely straight forward.
>>>>
>>>> TBH, I think we are hitting an email comms/social barrier here, not a
>>>> technical one.
>>>>
>>>> @Renjiang can you please confirm that freq_table is a fallback,
>>>> qcs615 will work without OPP table and the DTS stuff doesn't depend
>>>> on the driver.
>>> yes, freq_table is a fallback. driver will use freq_table without OPP
>>> table. the DTS doesn't depend on the driver.
>> To correct my previous response:
>> For this project, the driver patch needs to be merged first. Since it
>> falls back to SC7180, but their frequencies are different which is
>> reflected in the OPP table defined in the DTS.
>>
>> The DTS patch is intended to enable video function on the QCS615 platform.
>>
>> The driver patch is to switch from using the driver freq_table to the
>> OPP table from the DTS. Without it, the driver will continue to use the
>> internal freq_table as before.
>>
>> Therefore, if the DTS patch is applied without the driver patch, the video
>> function will be enabled on the QCS615 platform, but the driver will use
>> the SC7180 frequency table, which can lead to an overclocking issue.
> 
> This means devices are not really compatible and DTS is not correct.

The devices are compatible: all programming interface is the same. 
Having the freq table in the driver is an error.


-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On 06/06/2025 15:53, Bryan O'Donoghue wrote:
> On 06/06/2025 14:32, Renjiang Han wrote:
>>
>> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote:
>>> On 06/06/2025 14:51, Renjiang Han wrote:
>>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
>>>>> On 06/06/2025 14:37, Renjiang Han wrote:
>>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>>>>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>>>>>> Note:
>>>>>>>>>> This series consist of DT patches and a venus driver patch. 
>>>>>>>>>> The patch
>>>>>>>>>> 1/3, which is venus driver patch, can be picked independently 
>>>>>>>>>> without
>>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, 
>>>>>>>>>> which are
>>>>>>>>>> DT patches, still depend on [1].
>>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get 
>>>>>>>>> video
>>>>>>>>> core
>>>>>>>>> on QCS615 over(?)clocked.
>>>>>>>> Agree, so we need to make sure that the driver patch is not picked
>>>>>>>> after the DT patch.
>>>>>>> This statement is confusing.
>>>>>>>
>>>>>>> 1/3 states that there will be a fallback if there is no OPP table
>>>>>>> present.
>>>>>>>
>>>>>>> Giving the code a glance, I believe that is so, freq_table should be
>>>>>>> used if there is no OPP specified in the DT.
>>>>>>>
>>>>>>> I think we are having a hard time here understanding what you are 
>>>>>>> saying.
>>>>>>>
>>>>>>> My understanding:
>>>>>>>
>>>>>>> - venus modification is standalone 1/3
>>>>>>>     Qcs615 will fallback if no OPP is present
>>>>>>>
>>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>>>>>
>>>>>>> ---
>>>>>>> bod
>>>>>> yes, let me re-spin this with driver patch alone. Once that gets in,
>>>>>> will bring in the DT patches.
>>>>> Did you read my feedback? There is no "once that gets in". DTS is an
>>>>> independent hardware description and your patchset claiming there is
>>>>> dependency is just broken.
>>>>>
>>>>> I am repeating this since few emails, so shall I NAK it that you will
>>>>> address the main issue you have?
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>> Hi Krzysztof
>>>>
>>>> SC7180 and QCS615 use the same video core. Only difference lies in the
>>>> freq_table for the video. Freq_table is generally determined at SOC 
>>>> level.
>>>> The Venus driver does not currently handle freq_table compatibility 
>>>> well
>>>> across platforms. This patch enables the driver to use the OPP-table 
>>>> from
>>>> the DT, addressing the frequency compatibility issue.
>>> This does not resolve the main problem at all. If SW cannot use the
>>> fallback alone, your fallback has no meaning and is not only confusing
>>> but actually incorrect. And based on previous statements like
>>> "overclocking" it is not only incorrect, but even harmful.
>>>
>>> Best regards,
>>> Krzysztof
>> The fallback is only triggered when there is no OPP table in the DT.
>> Since the QCS615 DT will include an OPP table, the fallback logic will
>> not be used.
>>
>> Also, if the freq from the freq_table and the OPP table are the same,
>> would it be acceptable to drop the freq_table from the driver?

No, it's not acceptable, because then you'll break support for old DTs, 
which is a no-go.

> 
> If you drop the freq_table, you will need to apply OPPs for the sc7180 
> to DTS first before venus or you'll break sc7180.
> 
> I think TBH you should add a freq_tbl for QCS615 and make it so the 
> order of patch application doesn't matter wrt adding OPP support.

That would require adding board data for QCS615, which definitely 
doesn't look like a good solution. It is _exactly_ the same as SC7180. 
I'm against duplicating it just for the sake of having freq_tbl.

> 
> - Add QCS freq_tbl
> - Add OPP support
> 
> Then do whatever in DTS, nothing can break in this case.
> 
> As we've established the fallback isn't a fallback because it falls back 
> to wrong data, so lets fix that.

Why isn't it a fallback? With the driver changes in place, the fallback 
is totally correct.

-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Renjiang Han]

On 6/7/2025 10:13 AM, Dmitry Baryshkov wrote:
> On 06/06/2025 15:53, Bryan O'Donoghue wrote:
>> On 06/06/2025 14:32, Renjiang Han wrote:
>>>
>>> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote:
>>>> On 06/06/2025 14:51, Renjiang Han wrote:
>>>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
>>>>>> On 06/06/2025 14:37, Renjiang Han wrote:
>>>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>>>>>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>>>>>>> Note:
>>>>>>>>>>> This series consist of DT patches and a venus driver patch. 
>>>>>>>>>>> The patch
>>>>>>>>>>> 1/3, which is venus driver patch, can be picked 
>>>>>>>>>>> independently without
>>>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, 
>>>>>>>>>>> which are
>>>>>>>>>>> DT patches, still depend on [1].
>>>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get 
>>>>>>>>>> video
>>>>>>>>>> core
>>>>>>>>>> on QCS615 over(?)clocked.
>>>>>>>>> Agree, so we need to make sure that the driver patch is not 
>>>>>>>>> picked
>>>>>>>>> after the DT patch.
>>>>>>>> This statement is confusing.
>>>>>>>>
>>>>>>>> 1/3 states that there will be a fallback if there is no OPP table
>>>>>>>> present.
>>>>>>>>
>>>>>>>> Giving the code a glance, I believe that is so, freq_table 
>>>>>>>> should be
>>>>>>>> used if there is no OPP specified in the DT.
>>>>>>>>
>>>>>>>> I think we are having a hard time here understanding what you 
>>>>>>>> are saying.
>>>>>>>>
>>>>>>>> My understanding:
>>>>>>>>
>>>>>>>> - venus modification is standalone 1/3
>>>>>>>>     Qcs615 will fallback if no OPP is present
>>>>>>>>
>>>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>>>>>>
>>>>>>>> ---
>>>>>>>> bod
>>>>>>> yes, let me re-spin this with driver patch alone. Once that gets 
>>>>>>> in,
>>>>>>> will bring in the DT patches.
>>>>>> Did you read my feedback? There is no "once that gets in". DTS is an
>>>>>> independent hardware description and your patchset claiming there is
>>>>>> dependency is just broken.
>>>>>>
>>>>>> I am repeating this since few emails, so shall I NAK it that you 
>>>>>> will
>>>>>> address the main issue you have?
>>>>>>
>>>>>> Best regards,
>>>>>> Krzysztof
>>>>> Hi Krzysztof
>>>>>
>>>>> SC7180 and QCS615 use the same video core. Only difference lies in 
>>>>> the
>>>>> freq_table for the video. Freq_table is generally determined at 
>>>>> SOC level.
>>>>> The Venus driver does not currently handle freq_table 
>>>>> compatibility well
>>>>> across platforms. This patch enables the driver to use the 
>>>>> OPP-table from
>>>>> the DT, addressing the frequency compatibility issue.
>>>> This does not resolve the main problem at all. If SW cannot use the
>>>> fallback alone, your fallback has no meaning and is not only confusing
>>>> but actually incorrect. And based on previous statements like
>>>> "overclocking" it is not only incorrect, but even harmful.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>> The fallback is only triggered when there is no OPP table in the DT.
>>> Since the QCS615 DT will include an OPP table, the fallback logic will
>>> not be used.
>>>
>>> Also, if the freq from the freq_table and the OPP table are the same,
>>> would it be acceptable to drop the freq_table from the driver?
>
> No, it's not acceptable, because then you'll break support for old 
> DTs, which is a no-go.
>
>>
>> If you drop the freq_table, you will need to apply OPPs for the 
>> sc7180 to DTS first before venus or you'll break sc7180.
>>
>> I think TBH you should add a freq_tbl for QCS615 and make it so the 
>> order of patch application doesn't matter wrt adding OPP support.
>
> That would require adding board data for QCS615, which definitely 
> doesn't look like a good solution. It is _exactly_ the same as SC7180. 
> I'm against duplicating it just for the sake of having freq_tbl.
>
>>
>> - Add QCS freq_tbl
>> - Add OPP support
>>
>> Then do whatever in DTS, nothing can break in this case.
>>
>> As we've established the fallback isn't a fallback because it falls 
>> back to wrong data, so lets fix that.
>
> Why isn't it a fallback? With the driver changes in place, the 
> fallback is totally correct.
Agree.
Also, currently, both the freq_table and the opp-table are present
in the driver and DT code, and their frequency values are identical.
This driver patch is simply switching the frequency source from freq_table
to opp-table.
Therefore, I think this patch is an enhancement to the driver's
functionality and can be submitted independently, as it is not part of any
specific project.

-- 
Best Regards,
Renjiang

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Bryan O'Donoghue]

On 07/06/2025 03:13, Dmitry Baryshkov wrote:
>>
>> As we've established the fallback isn't a fallback because it falls 
>> back to wrong data, so lets fix that.
> 
> Why isn't it a fallback? With the driver changes in place, the fallback 
> is totally correct.

Its not a fallback _as_is_

I'm fine either way

- Apply 1/3 and then re-submit 2/3 3/3

or

- Enumerate a QCS615 table
- Apply 1/3 here

---
bod

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Krzysztof Kozlowski]

On 06/06/2025 15:32, Renjiang Han wrote:
> 
> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote:
>> On 06/06/2025 14:51, Renjiang Han wrote:
>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
>>>> On 06/06/2025 14:37, Renjiang Han wrote:
>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>>>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>>>>> Note:
>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>>>> DT patches, still depend on [1].
>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video
>>>>>>>> core
>>>>>>>> on QCS615 over(?)clocked.
>>>>>>> Agree, so we need to make sure that the driver patch is not picked
>>>>>>> after the DT patch.
>>>>>> This statement is confusing.
>>>>>>
>>>>>> 1/3 states that there will be a fallback if there is no OPP table
>>>>>> present.
>>>>>>
>>>>>> Giving the code a glance, I believe that is so, freq_table should be
>>>>>> used if there is no OPP specified in the DT.
>>>>>>
>>>>>> I think we are having a hard time here understanding what you are saying.
>>>>>>
>>>>>> My understanding:
>>>>>>
>>>>>> - venus modification is standalone 1/3
>>>>>>     Qcs615 will fallback if no OPP is present
>>>>>>
>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>>>>
>>>>>> ---
>>>>>> bod
>>>>> yes, let me re-spin this with driver patch alone. Once that gets in,
>>>>> will bring in the DT patches.
>>>> Did you read my feedback? There is no "once that gets in". DTS is an
>>>> independent hardware description and your patchset claiming there is
>>>> dependency is just broken.
>>>>
>>>> I am repeating this since few emails, so shall I NAK it that you will
>>>> address the main issue you have?
>>>>
>>>> Best regards,
>>>> Krzysztof
>>> Hi Krzysztof
>>>
>>> SC7180 and QCS615 use the same video core. Only difference lies in the
>>> freq_table for the video. Freq_table is generally determined at SOC level.
>>> The Venus driver does not currently handle freq_table compatibility well
>>> across platforms. This patch enables the driver to use the OPP-table from
>>> the DT, addressing the frequency compatibility issue.
>> This does not resolve the main problem at all. If SW cannot use the
>> fallback alone, your fallback has no meaning and is not only confusing
>> but actually incorrect. And based on previous statements like
>> "overclocking" it is not only incorrect, but even harmful.
>>
>> Best regards,
>> Krzysztof
> The fallback is only triggered when there is no OPP table in the DT.

No. I don't think you understand how fallback works. Fallback will be
applied on any QCS615 DTS without front compatible.


Best regards,
Krzysztof

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Dmitry Baryshkov]

On 07/06/2025 10:16, Bryan O'Donoghue wrote:
> On 07/06/2025 03:13, Dmitry Baryshkov wrote:
>>>
>>> As we've established the fallback isn't a fallback because it falls 
>>> back to wrong data, so lets fix that.
>>
>> Why isn't it a fallback? With the driver changes in place, the 
>> fallback is totally correct.
> 
> Its not a fallback _as_is_
> 
> I'm fine either way
> 
> - Apply 1/3 and then re-submit 2/3 3/3

Let's settle on this option. I think it is the cleanest option.

> 
> or
> 
> - Enumerate a QCS615 table
> - Apply 1/3 here
> 
> ---
> bod


-- 
With best wishes
Dmitry

Re: [PATCH v8 0/3] media: venus: enable venus on qcs615

[Konrad Dybcio]

On 6/7/25 11:46 AM, Krzysztof Kozlowski wrote:
> On 06/06/2025 15:32, Renjiang Han wrote:
>>
>> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote:
>>> On 06/06/2025 14:51, Renjiang Han wrote:
>>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote:
>>>>> On 06/06/2025 14:37, Renjiang Han wrote:
>>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote:
>>>>>>> On 31/05/2025 01:05, Renjiang Han wrote:
>>>>>>>>>> Note:
>>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch
>>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without
>>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are
>>>>>>>>>> DT patches, still depend on [1].
>>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video
>>>>>>>>> core
>>>>>>>>> on QCS615 over(?)clocked.
>>>>>>>> Agree, so we need to make sure that the driver patch is not picked
>>>>>>>> after the DT patch.
>>>>>>> This statement is confusing.
>>>>>>>
>>>>>>> 1/3 states that there will be a fallback if there is no OPP table
>>>>>>> present.
>>>>>>>
>>>>>>> Giving the code a glance, I believe that is so, freq_table should be
>>>>>>> used if there is no OPP specified in the DT.
>>>>>>>
>>>>>>> I think we are having a hard time here understanding what you are saying.
>>>>>>>
>>>>>>> My understanding:
>>>>>>>
>>>>>>> - venus modification is standalone 1/3
>>>>>>>     Qcs615 will fallback if no OPP is present
>>>>>>>
>>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver
>>>>>>>
>>>>>>> ---
>>>>>>> bod
>>>>>> yes, let me re-spin this with driver patch alone. Once that gets in,
>>>>>> will bring in the DT patches.
>>>>> Did you read my feedback? There is no "once that gets in". DTS is an
>>>>> independent hardware description and your patchset claiming there is
>>>>> dependency is just broken.
>>>>>
>>>>> I am repeating this since few emails, so shall I NAK it that you will
>>>>> address the main issue you have?
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>> Hi Krzysztof
>>>>
>>>> SC7180 and QCS615 use the same video core. Only difference lies in the
>>>> freq_table for the video. Freq_table is generally determined at SOC level.
>>>> The Venus driver does not currently handle freq_table compatibility well
>>>> across platforms. This patch enables the driver to use the OPP-table from
>>>> the DT, addressing the frequency compatibility issue.
>>> This does not resolve the main problem at all. If SW cannot use the
>>> fallback alone, your fallback has no meaning and is not only confusing
>>> but actually incorrect. And based on previous statements like
>>> "overclocking" it is not only incorrect, but even harmful.
>>>
>>> Best regards,
>>> Krzysztof
>> The fallback is only triggered when there is no OPP table in the DT.
> 
> No. I don't think you understand how fallback works. Fallback will be
> applied on any QCS615 DTS without front compatible.

Please read each other's messages..

Krzysztof refers to the fallback compatible mechanism, which means
the proposed QCS615 node will match against the driver containing the
sc7180 compatible.

BOD refers to the driver falling back to using the hardcoded sc7180
freq_table when the OPP table is absent (which will not be the case
for QCS615 since the node will be introduced with an OPP table on
day 0).

This patchset is okay to merge in proposed order (dt patches a cycle
after the venus patch)

Konrad