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

[Vikash Garodia]

On 2/17/2026 9:45 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 17, 2026 at 09:04:52PM +0530, Vikash Garodia wrote:
> > On 2/17/2026 8:06 PM, Dmitry Baryshkov wrote:
> > > On Tue, Feb 17, 2026 at 07:13:39PM +0530, Vikash Garodia wrote:
> > > > On 1/27/2026 8:39 PM, Dmitry Baryshkov wrote:
> > > > > On Mon, Jan 26, 2026 at 05:55:44PM +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.
> > > > > >
> > > > > > iommu-map include all the different stream-ids which can be possibly
> > > > > > generated by vpu4 hardware.
> > > > >
> > > > > It's not how it can be defined.
> > > >
> > > > Do you mean to elaborate the different entries within iommu-map or to
> > > > elaborate the different stream ids and how they are grouped into different
> > > > functions ?
> > >
> > > The comment was sent three weeks ago.
> >
> > yeah, if you could still recollect, you can comment.
>
> I think it was more about 'stream IDs for pixel, secure, no-pixel,
> firmware, buffers, non-buffers and direct insight into the VPU memory'
> (pure example, as you can guess).
>
> > > > > > Signed-off-by: Vikash Garodia <vikash.garodia@xxxxxxxxxxxxxxxx>
> > > > > > ---
> > > > > >     .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
> > > > > >     1 file changed, 234 insertions(+)
> > > > > >
> > > > > > +
> > > > > > +  iommu-map: true
> > > > >
> > > > > This is totally underspecifified.
> > > >
> > > > oneof would be a better approach describing the possible stream-ids.
> > >
> > > oneOf of what? It is items with the definition of each item.
> >
> > something like below,
> >
> > properties:
> >    iommu-map:
> >      description: |
> >        List of IOMMU stream IDs corresponding to hardware function IDs.
> >        The number of entries depends on the SoC variant.
>
> Do we again have a story of variable number of entries for the single
> Kaanapali platform?

its for firmware stream-ID, which can be managed by kernel or Gunyah. 
Handling for it now would ensure we do not have to change the binding 
later when there is a need.

> >      type: array
> >      oneOf:
> >        - minItems: 8
> >          maxItems: 8
> >          items:
> >            type: integer
> >            description: IOMMU stream IDs
> >
> >        - minItems: 9
> >          maxItems: 9
> >          items:
> >            type: integer
> >            description: IOMMU stream IDs
> > > > > > +
> > > > > > +  memory-region:
> > > > > > +    maxItems: 1
> > > > > > +
> > > > >
> > > > > > +
> > > > > > +        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
> > > > > > +                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
> > > > > > +                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
> > > > > > +                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
> > > > > > +                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
> > > > > > +                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
> > > > > > +                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
> > > > > > +                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
> > > > > > +                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;
> > > > >
> > > > > #define the functions in the ABI, provide them in the bindings.
> > > >
> > > > Ack. will introduce a new header at [1] and define these functions
> > > >
> > > > [1] https://github.com/torvalds/linux/tree/master/include/dt-bindings/media
> > > >
> > > > Regards,
> > > > Vikash
> > > >
> > > > > > +