Re: [PATCH v3 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

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