Kaanapali SOC brings in the new generation of video IP i.e iris4. When
compared to previous generation, iris3x, it has,
- separate power domains for stream and pixel processing hardware blocks
(bse and vpp).
- additional power domain for apv codec.
- power domains for individual pipes (VPPx).
- different clocks and reset lines.
This patch depends on
https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15
Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
.../bindings/media/qcom,kaanapali-iris.yaml | 254 +++++++++++++++++++++
include/dt-bindings/media/qcom,kaanapali-iris.h | 18 ++
2 files changed, 272 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..1f35472a2caea7acd2ef20b5cbdafadba882bd3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.yaml
@@ -0,0 +1,254 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,kaanapali-iris.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Kaanapali Iris video encoder and decoder
+
+maintainers:
+ - Vikash Garodia <vikash.garodia@oss.qualcomm.com>
+ - Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
+
+description:
+ The iris video processing unit is a video encode and decode accelerator
+ present on Qualcomm Kaanapali SoC.
+
+properties:
+ compatible:
+ const: qcom,kaanapali-iris
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 10
+
+ clock-names:
+ items:
+ - const: iface
+ - const: core
+ - const: vcodec0_core
+ - const: iface1
+ - const: core_freerun
+ - const: vcodec0_core_freerun
+ - const: vcodec_bse
+ - const: vcodec_vpp0
+ - const: vcodec_vpp1
+ - const: vcodec_apv
+
+ dma-coherent: true
+
+ firmware-name:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: cpu-cfg
+ - const: video-mem
+
+ interrupts:
+ maxItems: 1
+
+ iommu-map:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ - description: bitstream stream from vcodec
+ items:
+ - description: Function ID
+ - description: Phandle to IOMMU
+ - description: IOMMU stream ID base
+ - description: IOMMU stream ID mask
+ - description: Number of stream IDs
+ - description: non-pixel stream from vcodec
+ - description: non-pixel stream from tensilica
+ - description: pixel stream from vcodec
+ - description: secure bitstream stream from vcodec
+ - description: secure non-pixel stream from vcodec
+ - description: secure non-pixel stream from tensilica
+ - description: secure pixel stream from vcodec
+ # firmware might be handled by the TZ / hyp
+ - description: firmware stream from tensilica
+ minItems: 8
+
+ memory-region:
+ maxItems: 1
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+ power-domains:
+ maxItems: 7
+
+ power-domain-names:
+ items:
+ - const: venus
+ - const: vcodec0
+ - const: mxc
+ - const: mmcx
+ - const: vpp0
+ - const: vpp1
+ - const: apv
+
+ resets:
+ maxItems: 4
+
+ reset-names:
+ items:
+ - const: bus0
+ - const: bus1
+ - const: core
+ - const: vcodec0_core
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dma-coherent
+ - interconnects
+ - interconnect-names
+ - interrupts
+ - iommu-map
+ - memory-region
+ - power-domains
+ - power-domain-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/media/qcom,kaanapali-iris.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ video-codec@2000000 {
+ compatible = "qcom,kaanapali-iris";
+ reg = <0x02000000 0xf0000>;
+
+ clocks = <&gcc_video_axi0_clk>,
+ <&video_cc_mvs0c_clk>,
+ <&video_cc_mvs0_clk>,
+ <&gcc_video_axi1_clk>,
+ <&video_cc_mvs0c_freerun_clk>,
+ <&video_cc_mvs0_freerun_clk>,
+ <&video_cc_mvs0b_clk>,
+ <&video_cc_mvs0_vpp0_clk>,
+ <&video_cc_mvs0_vpp1_clk>,
+ <&video_cc_mvs0a_clk>;
+ clock-names = "iface",
+ "core",
+ "vcodec0_core",
+ "iface1",
+ "core_freerun",
+ "vcodec0_core_freerun",
+ "vcodec_bse",
+ "vcodec_vpp0",
+ "vcodec_vpp1",
+ "vcodec_apv";
+
+ dma-coherent;
+
+ interconnects = <&gem_noc_master_appss_proc &config_noc_slave_venus_cfg>,
+ <&mmss_noc_master_video_mvp &mc_virt_slave_ebi1>;
+ interconnect-names = "cpu-cfg",
+ "video-mem";
+
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommu-map = <IRIS_BITSTREAM &apps_smmu 0x1944 0x0 0x1>,
+ <IRIS_NON_PIXEL &apps_smmu 0x1940 0x0 0x1>,
+ <IRIS_NON_PIXEL &apps_smmu 0x1a20 0x0 0x1>,
+ <IRIS_PIXEL &apps_smmu 0x1943 0x0 0x1>,
+ <IRIS_SECURE_BITSTREAM &apps_smmu 0x1946 0x0 0x1>,
+ <IRIS_SECURE_NON_PIXEL &apps_smmu 0x1941 0x0 0x1>,
+ <IRIS_SECURE_NON_PIXEL &apps_smmu 0x1a21 0x0 0x1>,
+ <IRIS_SECURE_PIXEL &apps_smmu 0x1945 0x0 0x1>,
+ <IRIS_FIRMWARE &apps_smmu 0x1a22 0x0 0x1>;
+
+ memory-region = <&video_mem>;
+
+ operating-points-v2 = <&iris_opp_table>;
+
+ power-domains = <&video_cc_mvs0c_gdsc>,
+ <&video_cc_mvs0_gdsc>,
+ <&rpmhpd RPMHPD_MXC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&video_cc_mvs0_vpp0_gdsc>,
+ <&video_cc_mvs0_vpp1_gdsc>,
+ <&video_cc_mvs0a_gdsc>;
+ power-domain-names = "venus",
+ "vcodec0",
+ "mxc",
+ "mmcx",
+ "vpp0",
+ "vpp1",
+ "apv";
+
+ resets = <&gcc_video_axi0_clk_ares>,
+ <&gcc_video_axi1_clk_ares>,
+ <&video_cc_mvs0c_freerun_clk_ares>,
+ <&video_cc_mvs0_freerun_clk_ares>;
+ reset-names = "bus0",
+ "bus1",
+ "core",
+ "vcodec0_core";
+
+ iris_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000 240000000 240000000 360000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>,
+ <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-338000000 {
+ opp-hz = /bits/ 64 <338000000 338000000 338000000 507000000>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-420000000 {
+ opp-hz = /bits/ 64 <420000000 420000000 420000000 630000000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_svs>;
+ };
+
+ opp-444000000 {
+ opp-hz = /bits/ 64 <444000000 444000000 444000000 666000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>,
+ <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-533000000 {
+ opp-hz = /bits/ 64 <533000000 533000000 533000000 800000000>;
+ required-opps = <&rpmhpd_opp_nom>,
+ <&rpmhpd_opp_nom>;
+ };
+
+ opp-630000000 {
+ opp-hz = /bits/ 64 <630000000 630000000 630000000 1104000000>;
+ required-opps = <&rpmhpd_opp_turbo>,
+ <&rpmhpd_opp_turbo>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000 630000000 630000000 1260000000>;
+ required-opps = <&rpmhpd_opp_turbo_l0>,
+ <&rpmhpd_opp_turbo_l0>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000 630000000 850000000 1260000000>;
+ required-opps = <&rpmhpd_opp_turbo_l1>,
+ <&rpmhpd_opp_turbo_l1>;
+ };
+ };
+ };
diff --git a/include/dt-bindings/media/qcom,kaanapali-iris.h b/include/dt-bindings/media/qcom,kaanapali-iris.h
new file mode 100644
index 0000000000000000000000000000000000000000..757313799293d59b2122dd8d05b654f7a3a9876a
--- /dev/null
+++ b/include/dt-bindings/media/qcom,kaanapali-iris.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef _DT_BINDINGS_MEDIA_QCOM_KAANAPALI_IRIS_H_
+#define _DT_BINDINGS_MEDIA_QCOM_KAANAPALI_IRIS_H_
+
+/* Function identifiers for iommu-map to attach for the context bank devices */
+#define IRIS_BITSTREAM 0
+#define IRIS_NON_PIXEL 1
+#define IRIS_PIXEL 2
+#define IRIS_SECURE_BITSTREAM 3
+#define IRIS_SECURE_NON_PIXEL 4
+#define IRIS_SECURE_PIXEL 5
+#define IRIS_FIRMWARE 6
+
+#endif
--
2.34.1On 13/03/2026 14:19, Vikash Garodia wrote: > Kaanapali SOC brings in the new generation of video IP i.e iris4. When > compared to previous generation, iris3x, it has, > - separate power domains for stream and pixel processing hardware blocks > (bse and vpp). > - additional power domain for apv codec. > - power domains for individual pipes (VPPx). > - different clocks and reset lines. > > This patch depends on > https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15 > > Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> If you actually implement my feedback, then you don't need to keep that tag. The tag was given because you were pushing your solution regardless of received review. Best regards, Krzysztof
On 3/13/2026 9:13 PM, Krzysztof Kozlowski wrote: > On 13/03/2026 14:19, Vikash Garodia wrote: >> Kaanapali SOC brings in the new generation of video IP i.e iris4. When >> compared to previous generation, iris3x, it has, >> - separate power domains for stream and pixel processing hardware blocks >> (bse and vpp). >> - additional power domain for apv codec. >> - power domains for individual pipes (VPPx). >> - different clocks and reset lines. >> >> This patch depends on >> https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15 >> >> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> > > If you actually implement my feedback, then you don't need to keep that > tag. The tag was given because you were pushing your solution regardless > of received review. > Noted. Regards, Vikash
On Fri, 13 Mar 2026 18:49:35 +0530, Vikash Garodia wrote:
> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
> compared to previous generation, iris3x, it has,
> - separate power domains for stream and pixel processing hardware blocks
> (bse and vpp).
> - additional power domain for apv codec.
> - power domains for individual pipes (VPPx).
> - different clocks and reset lines.
>
> This patch depends on
> https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15
>
> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,kaanapali-iris.yaml | 254 +++++++++++++++++++++
> include/dt-bindings/media/qcom,kaanapali-iris.h | 18 ++
> 2 files changed, 272 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdm845.example.dtb: pcie@1c00000 (qcom,pcie-sdm845): iommu-map:0: [0, 4294967295, 7184, 1, 256, 4294967295, 7185, 1, 512, 4294967295, 7186, 1, 768, 4294967295, 7187, 1, 1024, 4294967295, 7188, 1, 1280, 4294967295, 7189, 1, 1536, 4294967295, 7190, 1, 1792, 4294967295, 7191, 1, 2048, 4294967295, 7192, 1, 2304, 4294967295, 7193, 1, 2560, 4294967295, 7194, 1, 2816, 4294967295, 7195, 1, 3072, 4294967295, 7196, 1, 3328, 4294967295, 7197, 1, 3584, 4294967295, 7198, 1, 3840, 4294967295, 7199, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdm845.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdm845.example.dtb: pcie@1c00000 (qcom,pcie-sdm845): Unevaluated properties are not allowed ('#address-cells', '#interrupt-cells', '#size-cells', 'bus-range', 'device_type', 'interrupt-map', 'interrupt-map-mask', 'iommu-map', 'linux,pci-domain', 'num-lanes', 'pcie@0', 'perst-gpios', 'phy-names', 'phys', 'power-domains', 'ranges', 'vddpe-3v3-supply', 'wake-gpios' were unexpected)
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdm845.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdm845.example.dtb: pcie@1c00000 (qcom,pcie-sdm845): iommu-map:0: [0, 4294967295, 7184, 1, 256, 4294967295, 7185, 1, 512, 4294967295, 7186, 1, 768, 4294967295, 7187, 1, 1024, 4294967295, 7188, 1, 1280, 4294967295, 7189, 1, 1536, 4294967295, 7190, 1, 1792, 4294967295, 7191, 1, 2048, 4294967295, 7192, 1, 2304, 4294967295, 7193, 1, 2560, 4294967295, 7194, 1, 2816, 4294967295, 7195, 1, 3072, 4294967295, 7196, 1, 3328, 4294967295, 7197, 1, 3584, 4294967295, 7198, 1, 3840, 4294967295, 7199, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:0: [0, 4294967295, 512, 1, 256] is too long
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdx55.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:1:0: 4294967295 is greater than the maximum of 65535
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdx55.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:1: [4294967295, 513, 1, 512, 4294967295] is too long
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdx55.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:2:3: 4294967295 is greater than the maximum of 65536
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdx55.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:2: [514, 1, 768, 4294967295, 515] is too long
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdx55.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:3: [1, 1024, 4294967295, 516, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdx55.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): Unevaluated properties are not allowed ('#address-cells', '#interrupt-cells', '#size-cells', 'bus-range', 'device_type', 'interrupt-map', 'interrupt-map-mask', 'iommu-map', 'linux,pci-domain', 'num-lanes', 'pcie@0', 'perst-gpios', 'phy-names', 'phys', 'power-domains', 'ranges', 'wake-gpios' were unexpected)
from schema $id: http://devicetree.org/schemas/pci/qcom,pcie-sdx55.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:0: [0, 4294967295, 512, 1, 256] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:1:0: 4294967295 is greater than the maximum of 65535
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:1: [4294967295, 513, 1, 512, 4294967295] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:2:3: 4294967295 is greater than the maximum of 65536
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:2: [514, 1, 768, 4294967295, 515] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/qcom,pcie-sdx55.example.dtb: pcie@1c00000 (qcom,pcie-sdx55): iommu-map:3: [1, 1024, 4294967295, 516, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:0: [0, 4294967295, 6468, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:1: [1, 4294967295, 6464, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:2: [1, 4294967295, 6688, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:3: [2, 4294967295, 6467, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:4: [3, 4294967295, 6470, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:5: [4, 4294967295, 6465, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:6: [4, 4294967295, 6689, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:7: [5, 4294967295, 6469, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:8: [6, 4294967295, 6690, 0, 1] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260313-kaanapali-iris-v3-1-9c0d1a67af4b@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
On Fri, Mar 13, 2026 at 06:49:35PM +0530, Vikash Garodia wrote:
> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
> compared to previous generation, iris3x, it has,
> - separate power domains for stream and pixel processing hardware blocks
> (bse and vpp).
> - additional power domain for apv codec.
> - power domains for individual pipes (VPPx).
> - different clocks and reset lines.
>
> This patch depends on
> https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15
>
> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,kaanapali-iris.yaml | 254 +++++++++++++++++++++
> include/dt-bindings/media/qcom,kaanapali-iris.h | 18 ++
> 2 files changed, 272 insertions(+)
> +
> + video-codec@2000000 {
> + compatible = "qcom,kaanapali-iris";
> + reg = <0x02000000 0xf0000>;
> +
> + clocks = <&gcc_video_axi0_clk>,
> + <&video_cc_mvs0c_clk>,
> + <&video_cc_mvs0_clk>,
> + <&gcc_video_axi1_clk>,
> + <&video_cc_mvs0c_freerun_clk>,
> + <&video_cc_mvs0_freerun_clk>,
> + <&video_cc_mvs0b_clk>,
> + <&video_cc_mvs0_vpp0_clk>,
> + <&video_cc_mvs0_vpp1_clk>,
> + <&video_cc_mvs0a_clk>;
> + clock-names = "iface",
> + "core",
> + "vcodec0_core",
> + "iface1",
> + "core_freerun",
> + "vcodec0_core_freerun",
> + "vcodec_bse",
> + "vcodec_vpp0",
> + "vcodec_vpp1",
> + "vcodec_apv";
> +
> + dma-coherent;
> +
> + interconnects = <&gem_noc_master_appss_proc &config_noc_slave_venus_cfg>,
> + <&mmss_noc_master_video_mvp &mc_virt_slave_ebi1>;
> + interconnect-names = "cpu-cfg",
> + "video-mem";
> +
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> +
> + iommu-map = <IRIS_BITSTREAM &apps_smmu 0x1944 0x0 0x1>,
> + <IRIS_NON_PIXEL &apps_smmu 0x1940 0x0 0x1>,
> + <IRIS_NON_PIXEL &apps_smmu 0x1a20 0x0 0x1>,
It think we still haven't settled on letting iommu-map to have several
entries for a single function.
> + <IRIS_PIXEL &apps_smmu 0x1943 0x0 0x1>,
> + <IRIS_SECURE_BITSTREAM &apps_smmu 0x1946 0x0 0x1>,
> + <IRIS_SECURE_NON_PIXEL &apps_smmu 0x1941 0x0 0x1>,
> + <IRIS_SECURE_NON_PIXEL &apps_smmu 0x1a21 0x0 0x1>,
> + <IRIS_SECURE_PIXEL &apps_smmu 0x1945 0x0 0x1>,
> + <IRIS_FIRMWARE &apps_smmu 0x1a22 0x0 0x1>;
> +
> + memory-region = <&video_mem>;
> +
> + operating-points-v2 = <&iris_opp_table>;
> +
> + power-domains = <&video_cc_mvs0c_gdsc>,
> + <&video_cc_mvs0_gdsc>,
> + <&rpmhpd RPMHPD_MXC>,
> + <&rpmhpd RPMHPD_MMCX>,
> + <&video_cc_mvs0_vpp0_gdsc>,
> + <&video_cc_mvs0_vpp1_gdsc>,
> + <&video_cc_mvs0a_gdsc>;
> + power-domain-names = "venus",
> + "vcodec0",
> + "mxc",
> + "mmcx",
> + "vpp0",
> + "vpp1",
> + "apv";
> +
> + resets = <&gcc_video_axi0_clk_ares>,
> + <&gcc_video_axi1_clk_ares>,
> + <&video_cc_mvs0c_freerun_clk_ares>,
> + <&video_cc_mvs0_freerun_clk_ares>;
> + reset-names = "bus0",
> + "bus1",
> + "core",
> + "vcodec0_core";
> +
> + iris_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-240000000 {
> + opp-hz = /bits/ 64 <240000000 240000000 240000000 360000000>;
> + required-opps = <&rpmhpd_opp_low_svs_d1>,
> + <&rpmhpd_opp_low_svs_d1>;
It's a DT and not the schema question, but please cross-check the OPP
points here. If I understand Taniya correctly, we should be using
corners from the PLL type rather than from the video_cc clock plan (they
differ for some reason). Downstream videocc driver also should have
correct rail corners for the PLLs.
> + };
> +
--
With best wishes
Dmitry
On 3/13/2026 8:32 PM, Dmitry Baryshkov wrote:
> On Fri, Mar 13, 2026 at 06:49:35PM +0530, Vikash Garodia wrote:
>> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
>> compared to previous generation, iris3x, it has,
>> - separate power domains for stream and pixel processing hardware blocks
>> (bse and vpp).
>> - additional power domain for apv codec.
>> - power domains for individual pipes (VPPx).
>> - different clocks and reset lines.
>>
>> This patch depends on
>> https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15
>>
>> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>> .../bindings/media/qcom,kaanapali-iris.yaml | 254 +++++++++++++++++++++
>> include/dt-bindings/media/qcom,kaanapali-iris.h | 18 ++
>> 2 files changed, 272 insertions(+)
>
>> +
>> + video-codec@2000000 {
>> + compatible = "qcom,kaanapali-iris";
>> + reg = <0x02000000 0xf0000>;
>> +
>> + clocks = <&gcc_video_axi0_clk>,
>> + <&video_cc_mvs0c_clk>,
>> + <&video_cc_mvs0_clk>,
>> + <&gcc_video_axi1_clk>,
>> + <&video_cc_mvs0c_freerun_clk>,
>> + <&video_cc_mvs0_freerun_clk>,
>> + <&video_cc_mvs0b_clk>,
>> + <&video_cc_mvs0_vpp0_clk>,
>> + <&video_cc_mvs0_vpp1_clk>,
>> + <&video_cc_mvs0a_clk>;
>> + clock-names = "iface",
>> + "core",
>> + "vcodec0_core",
>> + "iface1",
>> + "core_freerun",
>> + "vcodec0_core_freerun",
>> + "vcodec_bse",
>> + "vcodec_vpp0",
>> + "vcodec_vpp1",
>> + "vcodec_apv";
>> +
>> + dma-coherent;
>> +
>> + interconnects = <&gem_noc_master_appss_proc &config_noc_slave_venus_cfg>,
>> + <&mmss_noc_master_video_mvp &mc_virt_slave_ebi1>;
>> + interconnect-names = "cpu-cfg",
>> + "video-mem";
>> +
>> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> + iommu-map = <IRIS_BITSTREAM &apps_smmu 0x1944 0x0 0x1>,
>> + <IRIS_NON_PIXEL &apps_smmu 0x1940 0x0 0x1>,
>> + <IRIS_NON_PIXEL &apps_smmu 0x1a20 0x0 0x1>,
>
> It think we still haven't settled on letting iommu-map to have several
> entries for a single function.
I have described the hardware aspects in the discussion [1], if there is
any alternate way to handle this, we can discuss in the same discussion.
[1]
https://lore.kernel.org/all/21fda4d2-72e1-4e5b-aee0-a799886f53b7@oss.qualcomm.com/
>
>> + <IRIS_PIXEL &apps_smmu 0x1943 0x0 0x1>,
>> + <IRIS_SECURE_BITSTREAM &apps_smmu 0x1946 0x0 0x1>,
>> + <IRIS_SECURE_NON_PIXEL &apps_smmu 0x1941 0x0 0x1>,
>> + <IRIS_SECURE_NON_PIXEL &apps_smmu 0x1a21 0x0 0x1>,
>> + <IRIS_SECURE_PIXEL &apps_smmu 0x1945 0x0 0x1>,
>> + <IRIS_FIRMWARE &apps_smmu 0x1a22 0x0 0x1>;
>> +
>> + memory-region = <&video_mem>;
>> +
>> + operating-points-v2 = <&iris_opp_table>;
>> +
>> + power-domains = <&video_cc_mvs0c_gdsc>,
>> + <&video_cc_mvs0_gdsc>,
>> + <&rpmhpd RPMHPD_MXC>,
>> + <&rpmhpd RPMHPD_MMCX>,
>> + <&video_cc_mvs0_vpp0_gdsc>,
>> + <&video_cc_mvs0_vpp1_gdsc>,
>> + <&video_cc_mvs0a_gdsc>;
>> + power-domain-names = "venus",
>> + "vcodec0",
>> + "mxc",
>> + "mmcx",
>> + "vpp0",
>> + "vpp1",
>> + "apv";
>> +
>> + resets = <&gcc_video_axi0_clk_ares>,
>> + <&gcc_video_axi1_clk_ares>,
>> + <&video_cc_mvs0c_freerun_clk_ares>,
>> + <&video_cc_mvs0_freerun_clk_ares>;
>> + reset-names = "bus0",
>> + "bus1",
>> + "core",
>> + "vcodec0_core";
>> +
>> + iris_opp_table: opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-240000000 {
>> + opp-hz = /bits/ 64 <240000000 240000000 240000000 360000000>;
>> + required-opps = <&rpmhpd_opp_low_svs_d1>,
>> + <&rpmhpd_opp_low_svs_d1>;
>
> It's a DT and not the schema question, but please cross-check the OPP
> points here. If I understand Taniya correctly, we should be using
> corners from the PLL type rather than from the video_cc clock plan (they
> differ for some reason). Downstream videocc driver also should have
> correct rail corners for the PLLs.
>
>> + };
>> +
>
On Fri, Mar 13, 2026 at 08:46:52PM +0530, Vikash Garodia wrote:
>
> On 3/13/2026 8:32 PM, Dmitry Baryshkov wrote:
> > On Fri, Mar 13, 2026 at 06:49:35PM +0530, Vikash Garodia wrote:
> > > Kaanapali SOC brings in the new generation of video IP i.e iris4. When
> > > compared to previous generation, iris3x, it has,
> > > - separate power domains for stream and pixel processing hardware blocks
> > > (bse and vpp).
> > > - additional power domain for apv codec.
> > > - power domains for individual pipes (VPPx).
> > > - different clocks and reset lines.
> > >
> > > This patch depends on
> > > https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15
> > >
> > > Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > > ---
> > > .../bindings/media/qcom,kaanapali-iris.yaml | 254 +++++++++++++++++++++
> > > include/dt-bindings/media/qcom,kaanapali-iris.h | 18 ++
> > > 2 files changed, 272 insertions(+)
> >
> > > +
> > > + video-codec@2000000 {
> > > + compatible = "qcom,kaanapali-iris";
> > > + reg = <0x02000000 0xf0000>;
> > > +
> > > + clocks = <&gcc_video_axi0_clk>,
> > > + <&video_cc_mvs0c_clk>,
> > > + <&video_cc_mvs0_clk>,
> > > + <&gcc_video_axi1_clk>,
> > > + <&video_cc_mvs0c_freerun_clk>,
> > > + <&video_cc_mvs0_freerun_clk>,
> > > + <&video_cc_mvs0b_clk>,
> > > + <&video_cc_mvs0_vpp0_clk>,
> > > + <&video_cc_mvs0_vpp1_clk>,
> > > + <&video_cc_mvs0a_clk>;
> > > + clock-names = "iface",
> > > + "core",
> > > + "vcodec0_core",
> > > + "iface1",
> > > + "core_freerun",
> > > + "vcodec0_core_freerun",
> > > + "vcodec_bse",
> > > + "vcodec_vpp0",
> > > + "vcodec_vpp1",
> > > + "vcodec_apv";
> > > +
> > > + dma-coherent;
> > > +
> > > + interconnects = <&gem_noc_master_appss_proc &config_noc_slave_venus_cfg>,
> > > + <&mmss_noc_master_video_mvp &mc_virt_slave_ebi1>;
> > > + interconnect-names = "cpu-cfg",
> > > + "video-mem";
> > > +
> > > + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> > > +
> > > + iommu-map = <IRIS_BITSTREAM &apps_smmu 0x1944 0x0 0x1>,
> > > + <IRIS_NON_PIXEL &apps_smmu 0x1940 0x0 0x1>,
> > > + <IRIS_NON_PIXEL &apps_smmu 0x1a20 0x0 0x1>,
> >
> > It think we still haven't settled on letting iommu-map to have several
> > entries for a single function.
>
> I have described the hardware aspects in the discussion [1], if there is any
> alternate way to handle this, we can discuss in the same discussion.
Yes. But how do you plan to merge this? You've split away the patches,
they don't seem to be listed as dependencies, etc.
>
> [1] https://lore.kernel.org/all/21fda4d2-72e1-4e5b-aee0-a799886f53b7@oss.qualcomm.com/
--
With best wishes
Dmitry
On 3/13/2026 9:10 PM, Dmitry Baryshkov wrote:
> On Fri, Mar 13, 2026 at 08:46:52PM +0530, Vikash Garodia wrote:
>>
>> On 3/13/2026 8:32 PM, Dmitry Baryshkov wrote:
>>> On Fri, Mar 13, 2026 at 06:49:35PM +0530, Vikash Garodia wrote:
>>>> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
>>>> compared to previous generation, iris3x, it has,
>>>> - separate power domains for stream and pixel processing hardware blocks
>>>> (bse and vpp).
>>>> - additional power domain for apv codec.
>>>> - power domains for individual pipes (VPPx).
>>>> - different clocks and reset lines.
>>>>
>>>> This patch depends on
>>>> https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15
>>>>
>>>> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>> ---
>>>> .../bindings/media/qcom,kaanapali-iris.yaml | 254 +++++++++++++++++++++
>>>> include/dt-bindings/media/qcom,kaanapali-iris.h | 18 ++
>>>> 2 files changed, 272 insertions(+)
>>>
>>>> +
>>>> + video-codec@2000000 {
>>>> + compatible = "qcom,kaanapali-iris";
>>>> + reg = <0x02000000 0xf0000>;
>>>> +
>>>> + clocks = <&gcc_video_axi0_clk>,
>>>> + <&video_cc_mvs0c_clk>,
>>>> + <&video_cc_mvs0_clk>,
>>>> + <&gcc_video_axi1_clk>,
>>>> + <&video_cc_mvs0c_freerun_clk>,
>>>> + <&video_cc_mvs0_freerun_clk>,
>>>> + <&video_cc_mvs0b_clk>,
>>>> + <&video_cc_mvs0_vpp0_clk>,
>>>> + <&video_cc_mvs0_vpp1_clk>,
>>>> + <&video_cc_mvs0a_clk>;
>>>> + clock-names = "iface",
>>>> + "core",
>>>> + "vcodec0_core",
>>>> + "iface1",
>>>> + "core_freerun",
>>>> + "vcodec0_core_freerun",
>>>> + "vcodec_bse",
>>>> + "vcodec_vpp0",
>>>> + "vcodec_vpp1",
>>>> + "vcodec_apv";
>>>> +
>>>> + dma-coherent;
>>>> +
>>>> + interconnects = <&gem_noc_master_appss_proc &config_noc_slave_venus_cfg>,
>>>> + <&mmss_noc_master_video_mvp &mc_virt_slave_ebi1>;
>>>> + interconnect-names = "cpu-cfg",
>>>> + "video-mem";
>>>> +
>>>> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>>>> +
>>>> + iommu-map = <IRIS_BITSTREAM &apps_smmu 0x1944 0x0 0x1>,
>>>> + <IRIS_NON_PIXEL &apps_smmu 0x1940 0x0 0x1>,
>>>> + <IRIS_NON_PIXEL &apps_smmu 0x1a20 0x0 0x1>,
>>>
>>> It think we still haven't settled on letting iommu-map to have several
>>> entries for a single function.
>>
>> I have described the hardware aspects in the discussion [1], if there is any
>> alternate way to handle this, we can discuss in the same discussion.
>
> Yes. But how do you plan to merge this? You've split away the patches,
> they don't seem to be listed as dependencies, etc.
>
1:1 mapping of function ID with stream ID is closing on the reviews. I
will have to update this patch to represent it in 1:1 mapping.
Once done, this patch can be merged with the dependency marked in this
patch i.e
https://github.com/devicetree-org/dt-schema/pull/184/changes/d341298d62805bc972dfba691da6b3b62aa3ff15
>>
>> [1] https://lore.kernel.org/all/21fda4d2-72e1-4e5b-aee0-a799886f53b7@oss.qualcomm.com/
>
Regards,
Vikash
© 2016 - 2026 Red Hat, Inc.