Re: [PATCH 2/2] media: venus: Fix iova allocation from restrict region
Vikash Garodia <[email protected]>
| Newsgroups | org.kernel.vger.linux-media,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On 8/12/2026 4:25 PM, Vishnu Reddy 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 > > A series to reserve the 0-600MB IOVA range via "iommu-addresses" was > already posted here: > https://lore.kernel.org/all/20260807-iris_iova_600mb_fix- > [email protected] > > Those changes involve DT binding and DT node changes, and discussion is > still ongoing on how to handle those for stable and for the upcoming > sub-node design, with no conclusion reached yet. Thereby a critical reset > issue is still open. > > This is an alternate solution to fix the unhandled SMMU page fault > by restricting the IOVA range in the video driver, which also makes it > easier and faster to land on mainline and stable kernels. At the same > time the patch only reserves in the IOVA space without allocating > any physical memory. > > Currently sub-nodes are not yet present, and only a single device is > available, so the restriction is applied to both non-pixel and pixel > stream IDs. This makes the solution unoptimal while fixing the issue > considering all scenarios. > Once sub-nodes for non-pixel, pixel, and secure streams become available, > the restriction can be made stream specific. > > Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") > Cc:[email protected] > Signed-off-by: Vishnu Reddy<[email protected]> > --- > drivers/media/platform/qcom/venus/core.c | 71 +++++++++++++++++++++++++++++++- > drivers/media/platform/qcom/venus/core.h | 5 +++ > 2 files changed, 74 insertions(+), 2 deletions(-) Reviewed-by: Vikash Garodia <[email protected]>