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

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

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