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

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

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@oss.qualcomm.com>
>>>>>> ---
>>>>>>     .../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
>>>>
>>>>>
>>>>>> +
>>>>>
>>>>
>>>
>>
>