[PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
Nas Chung
nas.chung at chipsnmedia.com
Tue Jun 30 22:39:52 PDT 2026
Hi, Krzysztof.
>-----Original Message-----
>From: Krzysztof Kozlowski <krzk at kernel.org>
>Sent: Thursday, June 25, 2026 3:29 PM
>
>On Thu, Jun 25, 2026 at 01:43:33AM +0000, Nas Chung wrote:
>> >> + sram:
>> >> + $ref: /schemas/types.yaml#/definitions/phandle
>> >> + description:
>> >> + phandle to the SRAM node used to store reference data, reducing
>DMA
>> >> + memory bandwidth.
>> >> +
>> >> + iommus:
>> >> + maxItems: 1
>> >> +
>> >> + "#cooling-cells":
>> >> + const: 2
>> >> +
>> >> + "#address-cells":
>> >> + const: 2
>> >> +
>> >> + "#size-cells":
>> >> + const: 2
>> >> +
>> >> + ranges: true
>> >> +
>> >> +patternProperties:
>> >> + "^interface@[0-9a-f]+$":
>> >
>> >I have to wonder if this interface business is required at all.
>> >Why can this not go into the parent, with each region fetchable via
>> >reg-names, interrupt-names and iommu-names?
>>
>> Thanks for your feedback.
>>
>> I did try the flat model, but the blocker is the IOMMU.
>>
>> The control region and four interface regions are independent DMA
>requesters
>> with distinct stream IDs, and each interface can be assigned to a
>different VM,
>> driving the video core with its own isolated memory.
>>
>> If all stream IDs are listed under the parent's iommus, they bind to a
>> single device and share one domain, so the isolation is lost.
>> This is the main reason I added the interface nodes.
>
>Feels similar to issue Qualcomm has. I rejected such subnodes and
>Qualcomm came with a solution in DMA IOMMU code, but that solution was
>rejected by DMA folks:
>https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-
>5d08f5cd2ca1 at kernel.org/
>
>I don't have proper arguments to convince DMA folks, thus I agree for
>Qualcomm for the subnodes. It should be fine here as well, in such case.
Thanks for sharing this.
I'll keep the subnodes and note this rationale in the v7 cover letter.
Thanks.
Nas.
>
>Best regards,
>Krzysztof
More information about the linux-arm-kernel
mailing list