Add DT entries for the qcm2290 Venus encoder/decoder.
Co-developed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qcm2290.dtsi | 55 +++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
index f49ac1c1f8a3..7cfacd189a10 100644
--- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
@@ -1628,6 +1628,61 @@ adreno_smmu: iommu@59a0000 {
#iommu-cells = <2>;
};
+ venus: video-codec@5a00000 {
+ compatible = "qcom,qcm2290-venus";
+ reg = <0 0x5a00000 0 0xf0000>;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
+
+ power-domains = <&gcc GCC_VENUS_GDSC>,
+ <&gcc GCC_VCODEC0_GDSC>,
+ <&rpmpd QCM2290_VDDCX>;
+ power-domain-names = "venus",
+ "vcodec0",
+ "cx";
+ operating-points-v2 = <&venus_opp_table>;
+
+ clocks = <&gcc GCC_VIDEO_VENUS_CTL_CLK>,
+ <&gcc GCC_VIDEO_AHB_CLK>,
+ <&gcc GCC_VENUS_CTL_AXI_CLK>,
+ <&gcc GCC_VIDEO_THROTTLE_CORE_CLK>,
+ <&gcc GCC_VIDEO_VCODEC0_SYS_CLK>,
+ <&gcc GCC_VCODEC0_AXI_CLK>;
+ clock-names = "core",
+ "iface",
+ "bus",
+ "throttle",
+ "vcodec0_core",
+ "vcodec0_bus";
+
+ memory-region = <&pil_video_mem>;
+ iommus = <&apps_smmu 0x860 0x0>,
+ <&apps_smmu 0x880 0x0>,
+ <&apps_smmu 0x861 0x04>,
+ <&apps_smmu 0x863 0x0>,
+ <&apps_smmu 0x804 0xe0>;
+
+ interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
+ &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
+ <&bimc MASTER_APPSS_PROC RPM_ACTIVE_TAG
+ &config_noc SLAVE_VENUS_CFG RPM_ACTIVE_TAG>;
+ interconnect-names = "video-mem",
+ "cpu-cfg";
+
+ venus_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-133333333 {
+ opp-hz = /bits/ 64 <133333333>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ };
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ required-opps = <&rpmpd_opp_svs>;
+ };
+ };
+ };
+
mdss: display-subsystem@5e00000 {
compatible = "qcom,qcm2290-mdss";
reg = <0x0 0x05e00000 0x0 0x1000>;
--
2.34.1
On 7/8/2025 11:35 PM, Jorge Ramirez-Ortiz wrote:
> Add DT entries for the qcm2290 Venus encoder/decoder.
>
> Co-developed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/qcm2290.dtsi | 55 +++++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
> index f49ac1c1f8a3..7cfacd189a10 100644
> --- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
> @@ -1628,6 +1628,61 @@ adreno_smmu: iommu@59a0000 {
> #iommu-cells = <2>;
> };
>
> + venus: video-codec@5a00000 {
> + compatible = "qcom,qcm2290-venus";
> + reg = <0 0x5a00000 0 0xf0000>;
> + interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
> +
> + power-domains = <&gcc GCC_VENUS_GDSC>,
> + <&gcc GCC_VCODEC0_GDSC>,
> + <&rpmpd QCM2290_VDDCX>;
> + power-domain-names = "venus",
> + "vcodec0",
> + "cx";
> + operating-points-v2 = <&venus_opp_table>;
> +
> + clocks = <&gcc GCC_VIDEO_VENUS_CTL_CLK>,
> + <&gcc GCC_VIDEO_AHB_CLK>,
> + <&gcc GCC_VENUS_CTL_AXI_CLK>,
> + <&gcc GCC_VIDEO_THROTTLE_CORE_CLK>,
> + <&gcc GCC_VIDEO_VCODEC0_SYS_CLK>,
> + <&gcc GCC_VCODEC0_AXI_CLK>;
> + clock-names = "core",
> + "iface",
> + "bus",
> + "throttle",
> + "vcodec0_core",
> + "vcodec0_bus";
> +
> + memory-region = <&pil_video_mem>;
> + iommus = <&apps_smmu 0x860 0x0>,
> + <&apps_smmu 0x880 0x0>,
> + <&apps_smmu 0x861 0x04>,
> + <&apps_smmu 0x863 0x0>,
> + <&apps_smmu 0x804 0xe0>;
What’s the rationale behind having five entries here?
could you share the use-cases that justify this configuration?
Thanks,
Dikshita
> +
> + interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
> + &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
> + <&bimc MASTER_APPSS_PROC RPM_ACTIVE_TAG
> + &config_noc SLAVE_VENUS_CFG RPM_ACTIVE_TAG>;
> + interconnect-names = "video-mem",
> + "cpu-cfg";
> +
> + venus_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-133333333 {
> + opp-hz = /bits/ 64 <133333333>;
> + required-opps = <&rpmpd_opp_low_svs>;
> + };
> +
> + opp-240000000 {
> + opp-hz = /bits/ 64 <240000000>;
> + required-opps = <&rpmpd_opp_svs>;
> + };
> + };
> + };
> +
> mdss: display-subsystem@5e00000 {
> compatible = "qcom,qcm2290-mdss";
> reg = <0x0 0x05e00000 0x0 0x1000>;
On 10/07/2025 09:57, Dikshita Agarwal wrote: >> + iommus = <&apps_smmu 0x860 0x0>, >> + <&apps_smmu 0x880 0x0>, >> + <&apps_smmu 0x861 0x04>, >> + <&apps_smmu 0x863 0x0>, >> + <&apps_smmu 0x804 0xe0>; > What’s the rationale behind having five entries here? > could you share the use-cases that justify this configuration? Already getting in trouble with non-pixel/secure # of iommus. Why not specify the maximum expected number hardware supports, specifically so we don't end up buried under incomplete schema again ? --- bod
On 7/10/2025 2:45 PM, Bryan O'Donoghue wrote: > On 10/07/2025 09:57, Dikshita Agarwal wrote: >>> + iommus = <&apps_smmu 0x860 0x0>, >>> + <&apps_smmu 0x880 0x0>, >>> + <&apps_smmu 0x861 0x04>, >>> + <&apps_smmu 0x863 0x0>, >>> + <&apps_smmu 0x804 0xe0>; >> What’s the rationale behind having five entries here? >> could you share the use-cases that justify this configuration? > > Already getting in trouble with non-pixel/secure # of iommus. > > Why not specify the maximum expected number hardware supports, specifically > so we don't end up buried under incomplete schema again ? Adding this in DT schema is fine, concern here is, adding it to the DT without a present use-case may be premature. Surprising to see it doesn't create any boot-up issues. Thanks, Dikshita > > --- > bod
© 2016 - 2025 Red Hat, Inc.