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

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 11:39:53PM +0530, Vikash Garodia wrote:
> 
> 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.

In my humble opionion the firmware stream-ID should be there, but let
the driver detect whether to use it or not.

Another approach might be:

iommu-map:
  items:
    - foo
    - bar
    - baz
    - ....
    - firmware
  # firmware might be handled by the TZ / hyp
  minItems: 8


> 
> > 
> > >      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
> > > > > 
> > > > > > 
> > > > > > > +
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

-- 
With best wishes
Dmitry