[PATCH v6 0/8] media: qcom: venus: add MSM8939 support

[PATCH v6 0/8] media: qcom: venus: add MSM8939 support

[Erikas Bitovtas]

This patch series adds support for Venus on MSM8939. It is mostly
similar to MSM8916 Venus, except it needs two additional cores to be
powered on before it can start decoding.

As per Dmitry's request, I am attaching Fluster results and
v4l2-compliance output. Fluster results were very inconsistent and
caused power collapse fails.
H.264: https://pastebin.com/C15qeq5W
H.265 (HEVC): https://pastebin.com/WDsnxvuk
VP8: https://pastebin.com/egAgEm15
v4l2-compliance: https://pastebin.com/VpBhEFc1
Power collapse fail log: https://pastebin.com/rTivMcpK

Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
Changes in v6:
- Added a more generic mechanism on blacklisting codecs.
- Reworded a commit for setting Venus core GDSCs to hardware controlled.
- Reworded a commit for adding HEVC decoding to MSM8939.
- Link to v5: https://patch.msgid.link/20260507-msm8939-venus-rfc-v5-0-d7b5ea2ce591@gmail.com

Changes in v5:
- Undid the merge of vcodec_clks, they are split back to
  vcodec{0,1}_clks now.
- Extracted a dev_pm_domain_attach_list() call into a function of its
  own to reduce nesting.
- Added missing "power-domain-names" required property to device tree
  binding.
- Renamed vcodec clocks and power domains to match other Venus bindings.
- Reordered commits and grouped them by subsystems. Now first come DTB
  patches, then clock, then media.
- Removed "status = "disabled"" in the device tree example.
- Link to v4: https://patch.msgid.link/20260506-msm8939-venus-rfc-v4-0-994f5eb22acb@gmail.com

Changes in v4:
- Removed vcodec{0,1}_pmdomains and merged vcodec{0,1}_clks into
  vcodec_clks instead for MSM8939.
- Inlined video decoder and encoder device tree nodes in the driver and
  removed them from the binding.
- Kept vdec and venc methods for HFI v3 separate from HFI v1.
- {vdec,venc}_get() are now called as early as before, since it is no
  longer needed for us to attach power domains to dev_dec and dev_enc.
- Link to v3: https://patch.msgid.link/20260427-msm8939-venus-rfc-v3-0-288195bb7917@gmail.com

Changes in v3:
- Added missing vcodec1_clks to resource struct.
- Removed enc_nodename from resource struct since we include
  video-decoder now.
- Link to v2: https://patch.msgid.link/20260425-msm8939-venus-rfc-v2-0-f69e52b36207@gmail.com

Changes in v2:
- Enabled GDSCs during encoding as well.
- Merged vcodec{0,1}_pmdomains_num into vcodec_pmdomains_num.
- Reworded commit for marking GDSCs as hardware controlled. Same
  situation as in cdc59600bccf ("clk: qcom: gcc-msm8953: fix stuck venus0_core0 clock")
- Clarified the reason for missing firmware-name property in device
  tree.
- Clarified the reason for moving vdec_get and venc_get for later.
- Link to v1: https://patch.msgid.link/20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com

To: Bryan O'Donoghue <bod@kernel.org>
To: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
To: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: André Apitzsch <git@apitzsch.eu>
To: Erikas Bitovtas <xerikasxx@gmail.com>
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
To: Michael Turquette <mturquette@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>
To: Brian Masney <bmasney@redhat.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-clk@vger.kernel.org

---
André Apitzsch (4):
      media: dt-bindings: venus: Add qcom,msm8939 schema
      arm64: dts: qcom: msm8939: Add venus node
      arm64: dts: qcom: msm8939-longcheer-l9100: Enable venus node
      media: qcom: venus: Add msm8939 resource struct

Erikas Bitovtas (4):
      arm64: dts: qcom: msm8939-asus-z00t: add Venus
      clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled
      media: qcom: venus: add power domain enable logic for Venus cores
      media: qcom: venus: add codec blacklist mechanism

 .../bindings/media/qcom,msm8939-venus.yaml         |  79 +++++++++++
 arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts     |   8 ++
 .../boot/dts/qcom/msm8939-longcheer-l9100.dts      |   8 ++
 arch/arm64/boot/dts/qcom/msm8939.dtsi              |  23 ++++
 drivers/clk/qcom/gcc-msm8939.c                     |   4 +
 drivers/media/platform/qcom/venus/core.c           |  47 +++++++
 drivers/media/platform/qcom/venus/core.h           |   2 +
 drivers/media/platform/qcom/venus/hfi_parser.c     |  10 +-
 drivers/media/platform/qcom/venus/pm_helpers.c     | 149 ++++++++++++++++++++-
 9 files changed, 321 insertions(+), 9 deletions(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260416-msm8939-venus-rfc-c025c4c74fae

Best regards,
--  
Erikas Bitovtas <xerikasxx@gmail.com>

[PATCH v6 1/8] media: dt-bindings: venus: Add qcom,msm8939 schema

[Erikas Bitovtas]

From: André Apitzsch <git@apitzsch.eu>

Add a schema description for the Venus video decoder/encoder IP in
MSM8939.

Signed-off-by: André Apitzsch <git@apitzsch.eu>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
 .../bindings/media/qcom,msm8939-venus.yaml         | 79 ++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,msm8939-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8939-venus.yaml
new file mode 100644
index 000000000000..10a50a410748
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,msm8939-venus.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,msm8939-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8939 Venus video encode and decode accelerators
+
+maintainers:
+  - André Apitzsch <git@apitzsch.eu>
+  - Erikas Bitovtas <xerikasxx@gmail.com>
+
+description:
+  The Venus IP is a video encode and decode accelerator present
+  on Qualcomm platforms
+
+allOf:
+  - $ref: qcom,venus-common.yaml#
+
+properties:
+  compatible:
+    const: qcom,msm8939-venus
+
+  power-domains:
+    maxItems: 3
+
+  power-domain-names:
+    items:
+      - const: venus
+      - const: vcodec0
+      - const: vcodec1
+
+  clocks:
+    maxItems: 5
+
+  clock-names:
+    items:
+      - const: core
+      - const: iface
+      - const: bus
+      - const: vcodec0_core
+      - const: vcodec1_core
+
+  iommus:
+    maxItems: 1
+
+required:
+  - compatible
+  - iommus
+  - power-domain-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/qcom,gcc-msm8939.h>
+
+    video-codec@1d00000 {
+      compatible = "qcom,msm8939-venus";
+      reg = <0x01d00000 0xff000>;
+      interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+      clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
+               <&gcc GCC_VENUS0_AHB_CLK>,
+               <&gcc GCC_VENUS0_AXI_CLK>,
+               <&gcc GCC_VENUS0_CORE0_VCODEC0_CLK>,
+               <&gcc GCC_VENUS0_CORE1_VCODEC0_CLK>;
+      clock-names = "core",
+                    "iface",
+                    "bus",
+                    "vcodec0_core",
+                    "vcodec1_core";
+      power-domains = <&gcc VENUS_GDSC>,
+                      <&gcc VENUS_CORE0_GDSC>,
+                      <&gcc VENUS_CORE1_GDSC>;
+      power-domain-names = "venus", "vcodec0", "vcodec1";
+      iommus = <&apps_iommu 5>;
+      memory-region = <&venus_mem>;
+    };

-- 
2.54.0

[PATCH v6 2/8] arm64: dts: qcom: msm8939: Add venus node

[Erikas Bitovtas]

From: André Apitzsch <git@apitzsch.eu>

Add DT entries for the msm8939 venus encoder/decoder.

Signed-off-by: André Apitzsch <git@apitzsch.eu>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
 arch/arm64/boot/dts/qcom/msm8939.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index d4d7b0c9206c..71e22584a46b 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -1627,6 +1627,29 @@ opp-19200000 {
 			};
 		};
 
+		venus: video-codec@1d00000 {
+			compatible = "qcom,msm8939-venus";
+			reg = <0x01d00000 0xff000>;
+			interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
+				 <&gcc GCC_VENUS0_AHB_CLK>,
+				 <&gcc GCC_VENUS0_AXI_CLK>,
+				 <&gcc GCC_VENUS0_CORE0_VCODEC0_CLK>,
+				 <&gcc GCC_VENUS0_CORE1_VCODEC0_CLK>;
+			clock-names = "core",
+				      "iface",
+				      "bus",
+				      "vcodec0_core",
+				      "vcodec1_core";
+			power-domains = <&gcc VENUS_GDSC>,
+					<&gcc VENUS_CORE0_GDSC>,
+					<&gcc VENUS_CORE1_GDSC>;
+			power-domain-names = "venus", "vcodec0", "vcodec1";
+			iommus = <&apps_iommu 5>;
+			memory-region = <&venus_mem>;
+			status = "disabled";
+		};
+
 		apps_iommu: iommu@1ef0000 {
 			compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
 			reg = <0x01ef0000 0x3000>;

-- 
2.54.0

[PATCH v6 3/8] arm64: dts: qcom: msm8939-longcheer-l9100: Enable venus node

[Erikas Bitovtas]

From: André Apitzsch <git@apitzsch.eu>

Enable the venus node so that the video encoder/decoder will start
working.

Default paths for firmware work on BQ Aquaris M5, which means
firmware-name property can be left out.

Signed-off-by: André Apitzsch <git@apitzsch.eu>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
---
 arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts b/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
index 13422a19c26a..48514c3df718 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
+++ b/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
@@ -314,6 +314,14 @@ &usb_hs_phy {
 	extcon = <&usb_id>;
 };
 
+&venus {
+	status = "okay";
+};
+
+&venus_mem {
+	status = "okay";
+};
+
 &wcnss {
 	status = "okay";
 };

-- 
2.54.0

[PATCH v6 4/8] arm64: dts: qcom: msm8939-asus-z00t: add Venus

[Erikas Bitovtas]

Enable Venus video encoder/decoder for Asus ZenFone 2 Laser/Selfie.

Default firmware paths work on Asus ZenFone 2 Laser/Selfie, which
means firmware-name property can be left out.

Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
 arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
index 90e966242720..231a3e9c1929 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
+++ b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
@@ -267,6 +267,14 @@ &usb_hs_phy {
 	extcon = <&usb_id>;
 };
 
+&venus {
+	status = "okay";
+};
+
+&venus_mem {
+	status = "okay";
+};
+
 &wcnss {
 	status = "okay";
 };

-- 
2.54.0

[PATCH v6 5/8] clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled

[Erikas Bitovtas]

Since in downstream kernel VENUS_CORE0_GDSC and VENUS_CORE1_GDSC have a
device tree property "qcom,supports-hw-trigger", add a HW_CTRL flag
to these GDSCs to pass their control to hardware.

Venus core clock cannot be enabled if Venus core GDSCs are switched off.
But since they are set to be hardware controlled, they can be switched
off at any moment. Vote for the Venus core clock to enable it later when
GDSCs get turned on.

Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
 drivers/clk/qcom/gcc-msm8939.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/qcom/gcc-msm8939.c b/drivers/clk/qcom/gcc-msm8939.c
index 45193b3d714b..420997b00ae0 100644
--- a/drivers/clk/qcom/gcc-msm8939.c
+++ b/drivers/clk/qcom/gcc-msm8939.c
@@ -3664,6 +3664,7 @@ static struct clk_branch gcc_venus0_vcodec0_clk = {
 
 static struct clk_branch gcc_venus0_core0_vcodec0_clk = {
 	.halt_reg = 0x4c02c,
+	.halt_check = BRANCH_HALT_SKIP,
 	.clkr = {
 		.enable_reg = 0x4c02c,
 		.enable_mask = BIT(0),
@@ -3681,6 +3682,7 @@ static struct clk_branch gcc_venus0_core0_vcodec0_clk = {
 
 static struct clk_branch gcc_venus0_core1_vcodec0_clk = {
 	.halt_reg = 0x4c034,
+	.halt_check = BRANCH_HALT_SKIP,
 	.clkr = {
 		.enable_reg = 0x4c034,
 		.enable_mask = BIT(0),
@@ -3753,6 +3755,7 @@ static struct gdsc venus_core0_gdsc = {
 	.pd = {
 		.name = "venus_core0",
 	},
+	.flags = HW_CTRL,
 	.pwrsts = PWRSTS_OFF_ON,
 };
 
@@ -3761,6 +3764,7 @@ static struct gdsc venus_core1_gdsc = {
 	.pd = {
 		.name = "venus_core1",
 	},
+	.flags = HW_CTRL,
 	.pwrsts = PWRSTS_OFF_ON,
 };
 

-- 
2.54.0

Re: [PATCH v6 5/8] clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled

[Konrad Dybcio]

On 5/10/26 11:47 AM, Erikas Bitovtas wrote:
> Since in downstream kernel VENUS_CORE0_GDSC and VENUS_CORE1_GDSC have a
> device tree property "qcom,supports-hw-trigger", add a HW_CTRL flag
> to these GDSCs to pass their control to hardware.
> 
> Venus core clock cannot be enabled if Venus core GDSCs are switched off.

The downstream device tree suggests the reverse - the venus_coreN GDSCs
refer to venus0_coreN_vcodec0_clk (and venus_gdsc lists
clk_gcc_venus0_axi_clk and clk_gcc_venus0_vcodec0_clk)

> But since they are set to be hardware controlled, they can be switched
> off at any moment. Vote for the Venus core clock to enable it later when
> GDSCs get turned on.

I understand these words but I can't see how they reflect the change

> 
> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
> ---
>  drivers/clk/qcom/gcc-msm8939.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/clk/qcom/gcc-msm8939.c b/drivers/clk/qcom/gcc-msm8939.c
> index 45193b3d714b..420997b00ae0 100644
> --- a/drivers/clk/qcom/gcc-msm8939.c
> +++ b/drivers/clk/qcom/gcc-msm8939.c
> @@ -3664,6 +3664,7 @@ static struct clk_branch gcc_venus0_vcodec0_clk = {
>  
>  static struct clk_branch gcc_venus0_core0_vcodec0_clk = {
>  	.halt_reg = 0x4c02c,
> +	.halt_check = BRANCH_HALT_SKIP,
>  	.clkr = {
>  		.enable_reg = 0x4c02c,
>  		.enable_mask = BIT(0),
> @@ -3681,6 +3682,7 @@ static struct clk_branch gcc_venus0_core0_vcodec0_clk = {
>  
>  static struct clk_branch gcc_venus0_core1_vcodec0_clk = {
>  	.halt_reg = 0x4c034,
> +	.halt_check = BRANCH_HALT_SKIP,
>  	.clkr = {
>  		.enable_reg = 0x4c034,
>  		.enable_mask = BIT(0),
> @@ -3753,6 +3755,7 @@ static struct gdsc venus_core0_gdsc = {
>  	.pd = {
>  		.name = "venus_core0",
>  	},
> +	.flags = HW_CTRL,
>  	.pwrsts = PWRSTS_OFF_ON,
>  };
>  
> @@ -3761,6 +3764,7 @@ static struct gdsc venus_core1_gdsc = {
>  	.pd = {
>  		.name = "venus_core1",
>  	},
> +	.flags = HW_CTRL,

This should be HW_CTRL_TRIGGER, paired with a change to call
dev_pm_genpd_set_hwmode() in the driver - this currently only happens
in vcodec_control_v4().

Konrad

[PATCH v6 6/8] media: qcom: venus: add power domain enable logic for Venus cores

[Erikas Bitovtas]

Attach power domains for vdec and venc cores and power them up if a vdec
or venc session is started.

Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
 drivers/media/platform/qcom/venus/pm_helpers.c | 149 ++++++++++++++++++++++++-
 1 file changed, 145 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
index f0269524ac70..5ed7cbef8149 100644
--- a/drivers/media/platform/qcom/venus/pm_helpers.c
+++ b/drivers/media/platform/qcom/venus/pm_helpers.c
@@ -297,10 +297,31 @@ static int load_scale_v1(struct venus_inst *inst)
 	return ret;
 }
 
+static int vcodec_domains_get_v1(struct venus_core *core)
+{
+	struct device *dev = core->dev;
+	const struct venus_resources *res = core->res;
+	const struct dev_pm_domain_attach_data vcodec_data = {
+		.pd_names = res->vcodec_pmdomains,
+		.num_pd_names = res->vcodec_pmdomains_num,
+		.pd_flags = PD_FLAG_NO_DEV_LINK,
+	};
+
+	if (!res->vcodec_pmdomains)
+		return 0;
+
+	return dev_pm_domain_attach_list(dev, &vcodec_data,
+					 &core->pmdomains);
+}
+
 static int core_get_v1(struct venus_core *core)
 {
 	int ret;
 
+	ret = vcodec_domains_get_v1(core);
+	if (ret < 0)
+		return ret;
+
 	ret = core_clks_get(core);
 	if (ret)
 		return ret;
@@ -319,12 +340,128 @@ static void core_put_v1(struct venus_core *core)
 static int core_power_v1(struct venus_core *core, int on)
 {
 	int ret = 0;
+	struct device *pd_dev = core->res->vcodec_pmdomains ?
+		core->pmdomains->pd_devs[0] : NULL;
 
-	if (on == POWER_ON)
+	if (on == POWER_ON) {
+		if (pd_dev) {
+			ret = pm_runtime_resume_and_get(pd_dev);
+			if (ret)
+				return ret;
+		}
 		ret = core_clks_enable(core);
-	else
+		if (ret) {
+			pm_runtime_put_sync(pd_dev);
+			return ret;
+		}
+	} else {
+		if (pd_dev)
+			pm_runtime_put_sync(pd_dev);
 		core_clks_disable(core);
+	}
+
+	return 0;
+}
+
+static int vcodec_domains_enable(struct venus_core *core)
+{
+	const struct venus_resources *res = core->res;
+	struct device *pd_dev;
+	int i = 1, ret;
+
+	if (!res->vcodec_pmdomains)
+		return 0;
+
+	for (; i < res->vcodec_pmdomains_num; i++) {
+		pd_dev = core->pmdomains->pd_devs[i];
+		ret = pm_runtime_resume_and_get(pd_dev);
+		if (ret)
+			goto err;
+	}
+
+	return 0;
+err:
+	while (i-- > 1)
+		pm_runtime_put_sync(core->pmdomains->pd_devs[i]);
+	return ret;
+}
+
+static void vcodec_domains_disable(struct venus_core *core)
+{
+	const struct venus_resources *res = core->res;
+	struct device *pd_dev;
+	int i = 1;
+
+	if (!res->vcodec_pmdomains)
+		return;
+
+	for (; i < res->vcodec_pmdomains_num; i++) {
+		pd_dev = core->pmdomains->pd_devs[i];
+		pm_runtime_put_sync(pd_dev);
+	}
+}
+
+static int vdec_get_v1(struct device *dev)
+{
+	struct venus_core *core = dev_get_drvdata(dev);
+
+	return vcodec_clks_get(core, core->dev, core->vcodec0_clks,
+			       core->res->vcodec0_clks);
+}
+
+static int vdec_power_v1(struct device *dev, int on)
+{
+	struct venus_core *core = dev_get_drvdata(dev);
+	int ret;
+
+	if (on == POWER_ON) {
+		ret = vcodec_domains_enable(core);
+		if (ret)
+			return ret;
+
+		ret = vcodec_clks_enable(core, core->vcodec0_clks);
+		if (ret)
+			goto err;
+	} else {
+		vcodec_domains_disable(core);
+		vcodec_clks_disable(core, core->vcodec0_clks);
+	}
+
+	return 0;
+err:
+	vcodec_domains_disable(core);
+	return ret;
+}
 
+static int venc_get_v1(struct device *dev)
+{
+	struct venus_core *core = dev_get_drvdata(dev);
+
+	return vcodec_clks_get(core, core->dev, core->vcodec1_clks,
+			       core->res->vcodec1_clks);
+}
+
+static int venc_power_v1(struct device *dev, int on)
+{
+	struct venus_core *core = dev_get_drvdata(dev);
+	int ret;
+
+	if (on == POWER_ON) {
+		ret = vcodec_domains_enable(core);
+		if (ret)
+			return ret;
+
+		ret = vcodec_clks_enable(core, core->vcodec1_clks);
+		if (ret)
+			goto err;
+	} else {
+		vcodec_domains_disable(core);
+		vcodec_clks_disable(core, core->vcodec1_clks);
+	}
+
+	return 0;
+err:
+	vcodec_domains_disable(core);
 	return ret;
 }
 
@@ -332,6 +469,10 @@ static const struct venus_pm_ops pm_ops_v1 = {
 	.core_get = core_get_v1,
 	.core_put = core_put_v1,
 	.core_power = core_power_v1,
+	.vdec_get = vdec_get_v1,
+	.vdec_power = vdec_power_v1,
+	.venc_get = venc_get_v1,
+	.venc_power = venc_power_v1,
 	.load_scale = load_scale_v1,
 };
 
@@ -875,7 +1016,7 @@ static int venc_power_v4(struct device *dev, int on)
 	return ret;
 }
 
-static int vcodec_domains_get(struct venus_core *core)
+static int vcodec_domains_get_v4(struct venus_core *core)
 {
 	int ret;
 	struct device *dev = core->dev;
@@ -993,7 +1134,7 @@ static int core_get_v4(struct venus_core *core)
 	if (ret)
 		return ret;
 
-	ret = vcodec_domains_get(core);
+	ret = vcodec_domains_get_v4(core);
 	if (ret)
 		return ret;
 

-- 
2.54.0

Re: [PATCH v6 6/8] media: qcom: venus: add power domain enable logic for Venus cores

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Missing NULL pointer check in the error path of core_power_v1() causes a kernel panic.
- [High] Unchecked dereference of core->pmdomains causes kernel panic when PM domains are disabled or not configured.
- [High] Hardware teardown order inversion risks bus hangs and synchronous external aborts.
- [High] Unmanaged PM domain attachment leads to permanent resource and memory leaks.
- [Medium] Devres allocations in vcodec_clks_get() are improperly tied to the parent device, causing memory leaks on child unbind.
--

commit 82e8b597268e31404de211144b4b0ac33778da1d
Author: Erikas Bitovtas <xerikasxx@gmail.com>
Date:   Sun May 10 09:47:44 2026 +0000

    media: qcom: venus: add power domain enable logic for Venus cores
    
    Attach power domains for vdec and venc cores and power them up if a vdec
    or venc session is started.

> diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
> index f0269524ac70e..5ed7cbef8149c 100644
> --- a/drivers/media/platform/qcom/venus/pm_helpers.c
> +++ b/drivers/media/platform/qcom/venus/pm_helpers.c

[ ... ]

> @@ -297,10 +297,31 @@ static int load_scale_v1(struct venus_inst *inst)
>  	return ret;
>  }
>  
> +static int vcodec_domains_get_v1(struct venus_core *core)
> +{
> +	struct device *dev = core->dev;
> +	const struct venus_resources *res = core->res;
> +	const struct dev_pm_domain_attach_data vcodec_data = {
> +		.pd_names = res->vcodec_pmdomains,
> +		.num_pd_names = res->vcodec_pmdomains_num,
> +		.pd_flags = PD_FLAG_NO_DEV_LINK,
> +	};
> +
> +	if (!res->vcodec_pmdomains)
> +		return 0;
> +
> +	return dev_pm_domain_attach_list(dev, &vcodec_data,
> +					 &core->pmdomains);

Does this leak the power domains if the driver unbinds or initialization fails?
There doesn't appear to be a corresponding dev_pm_domain_detach_list() call in
the error path or in core_put_v1().

Perhaps we should either manually detach them during cleanup, or use the
managed devm_pm_domain_attach_list() API instead?

> +}

[ ... ]

> @@ -319,12 +340,128 @@ static void core_put_v1(struct venus_core *core)
>  static int core_power_v1(struct venus_core *core, int on)
>  {
>  	int ret = 0;
> +	struct device *pd_dev = core->res->vcodec_pmdomains ?
> +		core->pmdomains->pd_devs[0] : NULL;

If CONFIG_PM is disabled or no generic domains are found,
dev_pm_domain_attach_list() can safely return 0 without allocating
core->pmdomains.

Would this lead to a NULL pointer dereference here when trying to access
core->pmdomains->pd_devs[0]? Should we check if core->pmdomains is valid
before dereferencing it, rather than relying on res->vcodec_pmdomains?

> -	if (on == POWER_ON)
> +	if (on == POWER_ON) {
> +		if (pd_dev) {
> +			ret = pm_runtime_resume_and_get(pd_dev);
> +			if (ret)
> +				return ret;
> +		}
>  		ret = core_clks_enable(core);
> -	else
> +		if (ret) {
> +			pm_runtime_put_sync(pd_dev);

Could this cause a NULL pointer dereference in the error path if the platform
does not define PM domains and pd_dev is NULL? 

The successful resume path checks if (pd_dev) before calling
pm_runtime_resume_and_get(), but the error handling here unconditionally passes
pd_dev to pm_runtime_put_sync().

> +			return ret;
> +		}
> +	} else {
> +		if (pd_dev)
> +			pm_runtime_put_sync(pd_dev);
>  		core_clks_disable(core);
> +	}

In standard power management, teardown operations usually strictly reverse the
initialization order to avoid faults. Here, the POWER_OFF path disables the PM
domain before disabling the core clocks, while the POWER_ON path enables the
PM domain before the clocks.

Could powering off the domain while its clocks are actively running lead to
unclocked register access faults or bus hangs?

> +
> +	return 0;
> +}
> +
> +static int vcodec_domains_enable(struct venus_core *core)
> +{
> +	const struct venus_resources *res = core->res;
> +	struct device *pd_dev;
> +	int i = 1, ret;
> +
> +	if (!res->vcodec_pmdomains)
> +		return 0;
> +
> +	for (; i < res->vcodec_pmdomains_num; i++) {
> +		pd_dev = core->pmdomains->pd_devs[i];

Similar to core_power_v1(), could this dereference a NULL core->pmdomains
if dev_pm_domain_attach_list() succeeded but returned 0?

> +		ret = pm_runtime_resume_and_get(pd_dev);
> +		if (ret)
> +			goto err;
> +	}

[ ... ]

> +static int vdec_get_v1(struct device *dev)
> +{
> +	struct venus_core *core = dev_get_drvdata(dev);
> +
> +	return vcodec_clks_get(core, core->dev, core->vcodec0_clks,

Is it intended to pass the parent device (core->dev) instead of the child
vdec device (dev) here?

Looking at vcodec_clks_get(), it uses devm_clk_get() which ties the resource
allocations to the devres list of the provided device. If core->dev is used,
the allocations belong to the parent device. 

If the child vdec device goes through unbind/rebind cycles, wouldn't this
cause clock references and devres memory to leak on the parent device?

> +			       core->res->vcodec0_clks);
> +}
> +
> +static int vdec_power_v1(struct device *dev, int on)
> +{
> +	struct venus_core *core = dev_get_drvdata(dev);
> +	int ret;
> +
> +	if (on == POWER_ON) {
> +		ret = vcodec_domains_enable(core);
> +		if (ret)
> +			return ret;
> +
> +		ret = vcodec_clks_enable(core, core->vcodec0_clks);
> +		if (ret)
> +			goto err;
> +	} else {
> +		vcodec_domains_disable(core);
> +		vcodec_clks_disable(core, core->vcodec0_clks);

Does this sequence have the same teardown order issue mentioned in
core_power_v1()? The domains are disabled before the clocks are shut down,
which might cause hardware lockups or aborts.

> +	}
> +
> +	return 0;
> +err:

[ ... ]

> +static int venc_get_v1(struct device *dev)
> +{
> +	struct venus_core *core = dev_get_drvdata(dev);
> +
> +	return vcodec_clks_get(core, core->dev, core->vcodec1_clks,

This shares the same question as vdec_get_v1(): should this use the child
device (dev) instead of the parent device (core->dev) to avoid devres leaks
during child unbinds?

> +			       core->res->vcodec1_clks);
> +}
> +
> +static int venc_power_v1(struct device *dev, int on)
> +{
> +	struct venus_core *core = dev_get_drvdata(dev);
> +	int ret;
> +
> +	if (on == POWER_ON) {
> +		ret = vcodec_domains_enable(core);
> +		if (ret)
> +			return ret;
> +
> +		ret = vcodec_clks_enable(core, core->vcodec1_clks);
> +		if (ret)
> +			goto err;
> +	} else {
> +		vcodec_domains_disable(core);
> +		vcodec_clks_disable(core, core->vcodec1_clks);

As with the other POWER_OFF paths, would disabling domains before clocks here
cause hardware issues?

> +	}
> +
> +	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260510-msm8939-venus-rfc-v6-0-e69465375900@gmail.com?part=6

[PATCH v6 7/8] media: qcom: venus: Add msm8939 resource struct

[Erikas Bitovtas]

From: André Apitzsch <git@apitzsch.eu>

Add msm8939 configuration data and related compatible.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: André Apitzsch <git@apitzsch.eu>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
 drivers/media/platform/qcom/venus/core.c | 41 ++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index 7e639760c41d..6ad20d58dda2 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -688,6 +688,46 @@ static const struct venus_resources msm8916_res = {
 	.enc_nodename = "video-encoder",
 };
 
+static const struct freq_tbl msm8939_freq_table[] = {
+	{ 489600, 266670000 },	/* 1080p @ 60 */
+	{ 244800, 133330000 },	/* 1080p @ 30 */
+	{ 244800, 200000000 },	/* 1080p @ 30 */
+	{ 220800, 133330000 },	/* 720p @ 60 */
+	{ 108000, 133330000 },	/* 720p @ 30 */
+	{ 108000, 200000000 },	/* 720p @ 30 */
+	{ 72000, 133330000 },	/* VGA @ 60 */
+	{ 36000, 133330000 },	/* VGA @ 30 */
+};
+
+static const struct reg_val msm8939_reg_preset[] = {
+	{ 0xe0020, 0x0aaaaaaa },
+	{ 0xe0024, 0x0aaaaaaa },
+	{ 0x80124, 0x00000003 },
+};
+
+static const struct venus_resources msm8939_res = {
+	.freq_tbl = msm8939_freq_table,
+	.freq_tbl_size = ARRAY_SIZE(msm8939_freq_table),
+	.reg_tbl = msm8939_reg_preset,
+	.reg_tbl_size = ARRAY_SIZE(msm8939_reg_preset),
+	.clks = { "core", "iface", "bus", },
+	.clks_num = 3,
+	.vcodec0_clks = { "vcodec0_core", "vcodec1_core" },
+	.vcodec1_clks = { "vcodec0_core", "vcodec1_core" },
+	.vcodec_clks_num = 2,
+	.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0", "vcodec1" },
+	.vcodec_pmdomains_num = 3,
+	.max_load = 489600, /* 1080p@30 + 1080p@30 */
+	.hfi_version = HFI_VERSION_1XX,
+	.vmem_id = VIDC_RESOURCE_NONE,
+	.vmem_size = 0,
+	.vmem_addr = 0,
+	.dma_mask = 0xddc00000 - 1,
+	.fwname = "qcom/venus-1.8/venus.mbn",
+	.dec_nodename = "video-decoder",
+	.enc_nodename = "video-encoder",
+};
+
 static const struct freq_tbl msm8996_freq_table[] = {
 	{ 1944000, 520000000 },	/* 4k UHD @ 60 (decode only) */
 	{  972000, 520000000 },	/* 4k UHD @ 30 */
@@ -1121,6 +1161,7 @@ static const struct venus_resources qcm2290_res = {
 
 static const struct of_device_id venus_dt_match[] = {
 	{ .compatible = "qcom,msm8916-venus", .data = &msm8916_res, },
+	{ .compatible = "qcom,msm8939-venus", .data = &msm8939_res, },
 	{ .compatible = "qcom,msm8996-venus", .data = &msm8996_res, },
 	{ .compatible = "qcom,msm8998-venus", .data = &msm8998_res, },
 	{ .compatible = "qcom,qcm2290-venus", .data = &qcm2290_res, },

-- 
2.54.0

Re: [PATCH v6 7/8] media: qcom: venus: Add msm8939 resource struct

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Non-monotonic frequency table causes scaling inversions and dead code.
- [High] Clock rate array aliasing leaves `vcodec1_core` unscaled.
- [High] Missing PM domain detachment causes a resource leak on probe failure/unbind.
--

commit 568a6ece0caefd3f300b18b1d182b85169c54db9
Author: André Apitzsch <git@apitzsch.eu>

media: qcom: venus: Add msm8939 resource struct

This commit adds configuration data and the related compatible string to
support the msm8939 platform in the venus media driver.

> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -688,6 +688,46 @@ static const struct venus_resources msm8916_res = {
>  	.enc_nodename = "video-encoder",
>  };
>  
> +static const struct freq_tbl msm8939_freq_table[] = {
> +	{ 489600, 266670000 },	/* 1080p @ 60 */
> +	{ 244800, 133330000 },	/* 1080p @ 30 */
> +	{ 244800, 200000000 },	/* 1080p @ 30 */
> +	{ 220800, 133330000 },	/* 720p @ 60 */
> +	{ 108000, 133330000 },	/* 720p @ 30 */
> +	{ 108000, 200000000 },	/* 720p @ 30 */

The freq_tbl algorithm in load_scale_v1() iterates sequentially over this
table and stops when mbs_per_sec > table[i].load.

Since there are duplicate load thresholds here (e.g., 244800 and 108000),
does this ordering cause scaling inversions and leave the 133.33MHz entries
as dead code?

For a load of 108001, the loop breaks at the first 108000 entry, falling
back to the previous frequency (133.33MHz). However, for a lower load of
exactly 108000, it continues past the first entry and breaks at 72000,
acquiring the higher 200MHz frequency.

> +	{ 72000, 133330000 },	/* VGA @ 60 */
> +	{ 36000, 133330000 },	/* VGA @ 30 */
> +};

[ ... ]

> +static const struct venus_resources msm8939_res = {
> +	.freq_tbl = msm8939_freq_table,
> +	.freq_tbl_size = ARRAY_SIZE(msm8939_freq_table),
> +	.reg_tbl = msm8939_reg_preset,
> +	.reg_tbl_size = ARRAY_SIZE(msm8939_reg_preset),
> +	.clks = { "core", "iface", "bus", },
> +	.clks_num = 3,
> +	.vcodec0_clks = { "vcodec0_core", "vcodec1_core" },
> +	.vcodec1_clks = { "vcodec0_core", "vcodec1_core" },

Are both clock arrays intended to have "vcodec0_core" at index 0?

The dynamic frequency scaling logic in core_clks_set_rate() applies the
required frequency explicitly to index 0 of both arrays:

    clk_set_rate(core->vcodec0_clks[0], freq);
    clk_set_rate(core->vcodec1_clks[0], freq);

Because "vcodec0_core" is at index 0 for both arrays, this sets
vcodec0_core twice and leaves vcodec1_core unscaled.

> +	.vcodec_clks_num = 2,
> +	.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0", "vcodec1" },

Because previous V1 resources did not define vcodec_pmdomains, the domain
attachment in vcodec_domains_get_v1() would return early.

Now that this patch populates the array, will this cause a PM domain
resource leak on probe failure or driver unbind?

The corresponding teardown function core_put_v1() is currently empty and
lacks a call to dev_pm_domain_detach_list() to clean up the domains
attached by vcodec_domains_get_v1().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260510-msm8939-venus-rfc-v6-0-e69465375900@gmail.com?part=7

[PATCH v6 8/8] media: qcom: venus: add codec blacklist mechanism

[Erikas Bitovtas]

Add decode and encode blacklist properties to allow disabling different
codecs per Venus device, instead of doing it per HFI version.

Despite using HFI version 1, MSM8939 supports HEVC decoding, therefore
it is not blacklisted. Add HEVC to the type converter function so it can
be recognized.

Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
 drivers/media/platform/qcom/venus/core.c       |  6 ++++++
 drivers/media/platform/qcom/venus/core.h       |  2 ++
 drivers/media/platform/qcom/venus/hfi_parser.c | 10 +++++-----
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index 6ad20d58dda2..75cf63b452dd 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -178,6 +178,8 @@ static void venus_sys_error_handler(struct work_struct *work)
 static u32 to_v4l2_codec_type(u32 codec)
 {
 	switch (codec) {
+	case HFI_VIDEO_CODEC_HEVC:
+		return V4L2_PIX_FMT_HEVC;
 	case HFI_VIDEO_CODEC_H264:
 		return V4L2_PIX_FMT_H264;
 	case HFI_VIDEO_CODEC_H263:
@@ -684,6 +686,8 @@ static const struct venus_resources msm8916_res = {
 	.vmem_addr = 0,
 	.dma_mask = 0xddc00000 - 1,
 	.fwname = "qcom/venus-1.8/venus.mbn",
+	.dec_codec_blacklist = HFI_VIDEO_CODEC_HEVC | HFI_VIDEO_CODEC_SPARK,
+	.enc_codec_blacklist = HFI_VIDEO_CODEC_HEVC,
 	.dec_nodename = "video-decoder",
 	.enc_nodename = "video-encoder",
 };
@@ -724,6 +728,8 @@ static const struct venus_resources msm8939_res = {
 	.vmem_addr = 0,
 	.dma_mask = 0xddc00000 - 1,
 	.fwname = "qcom/venus-1.8/venus.mbn",
+	.dec_codec_blacklist = HFI_VIDEO_CODEC_SPARK,
+	.enc_codec_blacklist = HFI_VIDEO_CODEC_HEVC,
 	.dec_nodename = "video-decoder",
 	.enc_nodename = "video-encoder",
 };
diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
index 7506f5d0f609..514dfb99449c 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -84,6 +84,8 @@ struct venus_resources {
 	unsigned int vcodec_pmdomains_num;
 	const char **opp_pmdomain;
 	unsigned int vcodec_num;
+	const u32 dec_codec_blacklist;
+	const u32 enc_codec_blacklist;
 	const char * const resets[VIDC_RESETS_NUM_MAX];
 	unsigned int resets_num;
 	enum hfi_version hfi_version;
diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c b/drivers/media/platform/qcom/venus/hfi_parser.c
index 92765f9c8873..8e762cf77968 100644
--- a/drivers/media/platform/qcom/venus/hfi_parser.c
+++ b/drivers/media/platform/qcom/venus/hfi_parser.c
@@ -206,11 +206,11 @@ static int parse_codecs(struct venus_core *core, void *data)
 	core->dec_codecs = codecs->dec_codecs;
 	core->enc_codecs = codecs->enc_codecs;
 
-	if (IS_V1(core)) {
-		core->dec_codecs &= ~HFI_VIDEO_CODEC_HEVC;
-		core->dec_codecs &= ~HFI_VIDEO_CODEC_SPARK;
-		core->enc_codecs &= ~HFI_VIDEO_CODEC_HEVC;
-	}
+	if (core->res->dec_codec_blacklist)
+		core->dec_codecs &= ~core->res->dec_codec_blacklist;
+
+	if (core->res->enc_codec_blacklist)
+		core->enc_codecs &= ~core->res->enc_codec_blacklist;
 
 	return sizeof(*codecs);
 }

-- 
2.54.0

Re: [PATCH v6 0/8] media: qcom: venus: add MSM8939 support

[Bryan O'Donoghue]

On 10/05/2026 10:47, Erikas Bitovtas wrote:
> This patch series adds support for Venus on MSM8939. It is mostly
> similar to MSM8916 Venus, except it needs two additional cores to be
> powered on before it can start decoding.
> 
> As per Dmitry's request, I am attaching Fluster results and
> v4l2-compliance output. Fluster results were very inconsistent and
> caused power collapse fails.
> H.264: https://pastebin.com/C15qeq5W
> H.265 (HEVC): https://pastebin.com/WDsnxvuk
> VP8: https://pastebin.com/egAgEm15
> v4l2-compliance: https://pastebin.com/VpBhEFc1
> Power collapse fail log: https://pastebin.com/rTivMcpK
> 
> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
> ---
> Changes in v6:
> - Added a more generic mechanism on blacklisting codecs.
> - Reworded a commit for setting Venus core GDSCs to hardware controlled.
> - Reworded a commit for adding HEVC decoding to MSM8939.
> - Link to v5: https://patch.msgid.link/20260507-msm8939-venus-rfc-v5-0-d7b5ea2ce591@gmail.com

Since you've indicated you are doing a v7 here's some more feedback on v6.

- A clear description of what has been tested and verified as working on
   each core. I think we got lost in the weeds of discussing the GDSC
   change, when what I was trying to understand was the bitmap
   of working encoder/decoder, what is particular to each core.

- HEVC decoder only works on 8939 afaict so there's no sense in
   trying to make it do encoder

- Ideally we have one node that works as an encoder and one as a
   decoder - which is pretty standard and normal on this genration
   of hardware.

- If that is not possible then decoder/decoder is also acceptable
   with the caveat that the declared list of decoder formats should
   be true from the perspective of user-space.

   We discussed blacklisting/whitelist particular codes, that's up
   to you to decide in your submission.

   For my part I think a list is better than a strcmp() as you never
   know how complex the logic might end up getting.
> 
> Changes in v5:
> - Undid the merge of vcodec_clks, they are split back to
>    vcodec{0,1}_clks now.
> - Extracted a dev_pm_domain_attach_list() call into a function of its
>    own to reduce nesting.
> - Added missing "power-domain-names" required property to device tree
>    binding.
> - Renamed vcodec clocks and power domains to match other Venus bindings.
> - Reordered commits and grouped them by subsystems. Now first come DTB
>    patches, then clock, then media.
> - Removed "status = "disabled"" in the device tree example.
> - Link to v4: https://patch.msgid.link/20260506-msm8939-venus-rfc-v4-0-994f5eb22acb@gmail.com
> 
> Changes in v4:
> - Removed vcodec{0,1}_pmdomains and merged vcodec{0,1}_clks into
>    vcodec_clks instead for MSM8939.
> - Inlined video decoder and encoder device tree nodes in the driver and
>    removed them from the binding.
> - Kept vdec and venc methods for HFI v3 separate from HFI v1.
> - {vdec,venc}_get() are now called as early as before, since it is no
>    longer needed for us to attach power domains to dev_dec and dev_enc.
> - Link to v3: https://patch.msgid.link/20260427-msm8939-venus-rfc-v3-0-288195bb7917@gmail.com
> 
> Changes in v3:
> - Added missing vcodec1_clks to resource struct.
> - Removed enc_nodename from resource struct since we include
>    video-decoder now.
> - Link to v2: https://patch.msgid.link/20260425-msm8939-venus-rfc-v2-0-f69e52b36207@gmail.com
> 
> Changes in v2:
> - Enabled GDSCs during encoding as well.
> - Merged vcodec{0,1}_pmdomains_num into vcodec_pmdomains_num.
> - Reworded commit for marking GDSCs as hardware controlled. Same
>    situation as in cdc59600bccf ("clk: qcom: gcc-msm8953: fix stuck venus0_core0 clock")
> - Clarified the reason for missing firmware-name property in device
>    tree.
> - Clarified the reason for moving vdec_get and venc_get for later.
> - Link to v1: https://patch.msgid.link/20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com
> 
> To: Bryan O'Donoghue <bod@kernel.org>
> To: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> To: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> To: Mauro Carvalho Chehab <mchehab@kernel.org>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> To: André Apitzsch <git@apitzsch.eu>
> To: Erikas Bitovtas <xerikasxx@gmail.com>
> To: Bjorn Andersson <andersson@kernel.org>
> To: Konrad Dybcio <konradybcio@kernel.org>
> To: Michael Turquette <mturquette@baylibre.com>
> To: Stephen Boyd <sboyd@kernel.org>
> To: Brian Masney <bmasney@redhat.com>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> 
> ---
> André Apitzsch (4):
>        media: dt-bindings: venus: Add qcom,msm8939 schema
>        arm64: dts: qcom: msm8939: Add venus node
>        arm64: dts: qcom: msm8939-longcheer-l9100: Enable venus node
>        media: qcom: venus: Add msm8939 resource struct
> 
> Erikas Bitovtas (4):
>        arm64: dts: qcom: msm8939-asus-z00t: add Venus
>        clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled
>        media: qcom: venus: add power domain enable logic for Venus cores
>        media: qcom: venus: add codec blacklist mechanism
> 
>   .../bindings/media/qcom,msm8939-venus.yaml         |  79 +++++++++++
>   arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts     |   8 ++
>   .../boot/dts/qcom/msm8939-longcheer-l9100.dts      |   8 ++
>   arch/arm64/boot/dts/qcom/msm8939.dtsi              |  23 ++++
>   drivers/clk/qcom/gcc-msm8939.c                     |   4 +
>   drivers/media/platform/qcom/venus/core.c           |  47 +++++++
>   drivers/media/platform/qcom/venus/core.h           |   2 +
>   drivers/media/platform/qcom/venus/hfi_parser.c     |  10 +-
>   drivers/media/platform/qcom/venus/pm_helpers.c     | 149 ++++++++++++++++++++-
>   9 files changed, 321 insertions(+), 9 deletions(-)
> ---
> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> change-id: 20260416-msm8939-venus-rfc-c025c4c74fae
> 
> Best regards,
> --
> Erikas Bitovtas <xerikasxx@gmail.com>
>