Re: [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video node

Vikash Garodia
2025-10-09T02:53:05Z

On 10/9/2025 6:34 AM, Krzysztof Kozlowski wrote:
> On 09/10/2025 09:55, Bryan O'Donoghue wrote:
>> On 09/10/2025 01:47, Krzysztof Kozlowski wrote:
>>>> Maybe it would be possible to also use an inferred FUNCTION_ID somehow
>>>> though TBH I think that's a work-around.
>>> Three months ago I gave you the answer for that - it is inferred by
>>> index on the list.
>>
>> But at least as I understand it, you can have multiple SID entries that
>> need to map to a FUNCTION_ID which means you need to encode that
>> inferred indexing in your driver.
>
> Yes.
>
>>
>> So you can't have the iommu code just know what to do.. it has to be
>> driver specific.
>
> Yes.
>
>>
>> The iommu description for this platform basically lacks the data that
>> _should_ be there -> FUNCTION_ID.
>
> No. The index tells that already.

Hardware1 can have 2 iommus entries for FUNCTION_ID_1, while Hardware2 can have
3 iommus entry. It would be good to keep this info in devicetree, as it is still
hardware specific (function_id is the hardware identifier).
Defaulting the index would imply, the common device driver would need to book
keep the iommus and hardware id in driver for every SOC. Any mismatch in order
in DT and driver table would result in error too.

More importantly, this need to be agreed by IOMMU maintainer to extend the
iommus property.

Regards,
Vikash
>
>>
>> The rule is that the DT should really describe the hardware right ?
>
> It already does. Same as I wrote on IRC, DT already has all the
> information. Entry 0 has function ID-foo. Entry 1 has function ID-bar.
> Entry 2 has function ID-bar or whatever.
>
> Best regards,
> Krzysztof