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

Dmitry Baryshkov
2025-09-25T20:33:28Z

On Fri, Sep 26, 2025 at 01:15:15AM +0530, Vikash Garodia wrote:
>
> On 9/26/2025 1:08 AM, Dmitry Baryshkov wrote:
> > On Fri, Sep 26, 2025 at 01:01:29AM +0530, Vikash Garodia wrote:
> >>
> >> On 9/26/2025 12:55 AM, Dmitry Baryshkov wrote:
> >>> On Thu, Sep 25, 2025 at 04:44:39AM +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.
> >>>>
> >>>> There are variants of this hardware, where only a single VPP pipe would
> >>>> be functional (VPP0), and APV may not be present. In such case, the
> >>>> hardware can be enabled without those 2 related power doamins, and
> >>>> corresponding clocks. This explains the min entries for power domains
> >>>> and clocks.
> >>>> Iommus include all the different stream-ids which can be possibly
> >>>> generated by vpu4 video hardware in both secure and non secure
> >>>> execution mode.
> >>>>
> >>>> This patch depends on following patches
> >>>> https://lore.kernel.org/all/20250924-knp-interconnect-v1-1-4c822a72141c@oss.qualcomm.com/
> >>>> https://lore.kernel.org/all/20250924-knp-clk-v1-3-29b02b818782@oss.qualcomm.com/
> >>>>
> >>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> >>>> ---
> >>>> .../bindings/media/qcom,kaanapali-iris.yaml | 236 +++++++++++++++++++++
> >>>> 1 file changed, 236 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..f3528d514fe29771227bee5f156962fedb1ea9cd
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.yaml
> >>>> @@ -0,0 +1,236 @@
> >>>> +# 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 encode and decode accelerators
> >>>> +
> >>>> +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 platforms.
> >>>> +
> >>>> +properties:
> >>>> + compatible:
> >>>> + const: qcom,kaanapali-iris
> >>>> +
> >>>> + reg:
> >>>> + maxItems: 1
> >>>> +
> >>>> + interrupts:
> >>>> + maxItems: 1
> >>>> +
> >>>> + power-domains:
> >>>> + minItems: 5
> >>>> + maxItems: 7
> >>>
> >>> You are sending bindings for a single device on a single platform. How
> >>> comes that it has min != max?
> >>
> >> I was planning to reuse this binding for the variant SOCs of kaanapali/vpu4. If
> >> we do not have min interface, then for those variants, we have to either have
> >> separate bindings or add if/else conditions(?). Introducing min now can make it
> >> easily usable for upcoming vpu4 variants.
> >
> > No, it makes it harder to follow the changes. This platform has
> > this-and-that requirements. Then you add another platform and it's clear
> > that the changes are for that platform. Now you have mixed two different
> > patches into a single one.
>
> you are suggesting to add new schema when the new variant comes in ?

No, I'm suggesting extending the schema when the new variant comes in
instead.

> there is
> also a possibility that this hardware(kaanapali) can be used without those
> optional power domains as well. Let say, someone does not want apv codec, in
> such case, that pd becomes optional.

That's totally a software construct - not enabling unused domains. Here
you are describing, you know, the hardware. And in the hardware the IP
core has a fixed number of connected clocks and power domains.

--
With best wishes
Dmitry