Re: [PATCH v3 01/13] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema

[Vikash Garodia]

On 9/10/2026 12:29 PM, Krzysztof Kozlowski wrote:
> On Wed, Sep 09, 2026 at 08:27:08PM +0530, Vikash Garodia wrote:
> > The VPU issues DMA through several SMMU streams, and the hardware does
> > not give every stream the same addressable range. The non-pixel stream
> > cannot address the low 600MB of IOVA space, while the pixel stream can
> > address the full range:
> >      +-----------------------------------------------------------+
> >      | non-pixel stream addressable range (600 MB - 3.5 GB)      |
> >      | 0x25800000 - 0xe0000000                                   |
> >      +-----------------------------------------------------------+
> >      | pixel stream addressable range (0 - 3.5 GB)               |
> >      | 0x00000000 - 0xe0000000                                   |
> >      +-----------------------------------------------------------+
> > A single "iommus" property on the video-codec node puts every stream in
> > one IOMMU domain sharing one IOVA allocator, so nothing restricts a
> > non-pixel buffer to avoid 0 to 600MB. Once an allocation lands below
> > that boundary the hardware faults, which shows up as unhandled SMMU page
> > faults and spontaneous reboots:
> > https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> >
> > Given that the address range restriction is for specific VPU stream, it
> > should be ideally be moved to that stream. To achieve the same, a subset
> > of streams is now represented as subnodes, so that each can be
> > associated with its respective addressable range. The design was
> > discussed and agreed by mainatiners here
> > https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@xxxxxxxxxx
> >
> > In the past, this limitation was addressed with an iommu-map approach,
> > with the iris driver dynamically creating the devices. That approach was
> > later concluded to be a hack to avoid having subnodes, and was NAKed by
> > the iommu maintainers. It was discussed in detail here:
> > https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@xxxxxxxxxx/
> >
> > "iommu-ranges" on the subnode describes the *allowed* IOVA range that
> > stream is allowed to use, so the IOVA is allocated from the specified
> > range only. Define all the possible subnodes so as to describe all the
> > VPU hardware iommu interfaces, both secure as well as non secure.
> >
> > address-cells, size-cells and dma-ranges declares the 1:1 DMA
> > translation into the parent.
> >
> > The parent "iommus" is kept as an alternative via "oneOf", so platforms
> > that have not been converted to subnodes still validate. New platforms
> > should use the subnode form.
> >
> > This patch depends-on:
> > https://github.com/devicetree-org/dt-schema/pull/207
>
> Please drop, not suitable for commit, keep it in the changelog

Sure, will add this to changelog.

> >   Tested-by: Daniel J Blueman <daniel@xxxxxxxxx>
>
> Plese drop, not true here

ok, got picked in b4 trailers, will drop.

> > Signed-off-by: Vikash Garodia <vikash.garodia@xxxxxxxxxxxxxxxx>
> > ---
> >   .../bindings/media/qcom,sc7180-venus.yaml          | 15 ----
> >   .../bindings/media/qcom,venus-common.yaml          | 97 ++++++++++++++++++++++
> >   2 files changed, 97 insertions(+), 15 deletions(-)
>
> I see this causes DT checks failures but I don't see the report, so
> probably it was because of schema dependency.
>
> Best regards,
> Krzysztof