[PATCH v2 0/2] media: qcom: Fix iova allocation from restrict region

Vishnu Reddy <[email protected]>
Newsgroups org.kernel.vger.linux-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-media,org.kernel.vger.stable
Message-ID <20260818-reserve_iova_in_driver-v2-0-5005a1154408@oss.qualcomm.com>
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/[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.

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.

Signed-off-by: Vishnu Reddy <[email protected]>
---
Changes in v2:
- Used the devm_kcalloc instead kcalloc (Bryan)
- Set bus_dma_limit instead of dma_coherent mask (Bryan)
- Added check for address and size once the IOVA is allocated (Bryan)
- Updated the commit description (Bryan)
- Link to v1: https://patch.msgid.link/20260812-reserve_iova_in_driver-v1-0-ed62f801275c@oss.qualcomm.com

To: Vikash Garodia <[email protected]>
To: Dikshita Agarwal <[email protected]>
To: Abhinav Kumar <[email protected]>
To: Bryan O'Donoghue <[email protected]>
To: Mauro Carvalho Chehab <[email protected]>
To: Stefan Schmidt <[email protected]>
To: Hans Verkuil <[email protected]>
To: Stanimir Varbanov <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]

---
Vishnu Reddy (2):
      media: iris: Fix iova allocation from restrict region
      media: venus: Fix iova allocation from restrict region

 drivers/media/platform/qcom/iris/iris_core.h  |  6 +++
 drivers/media/platform/qcom/iris/iris_probe.c | 62 ++++++++++++++++++++++++-
 drivers/media/platform/qcom/venus/core.c      | 66 +++++++++++++++++++++++++--
 drivers/media/platform/qcom/venus/core.h      |  5 ++
 4 files changed, 135 insertions(+), 4 deletions(-)
---
base-commit: e6664f2b33db9b6811eb4cec109f06cb2b4f458d
change-id: 20260812-reserve_iova_in_driver-855b388cbb29

Best regards,
--  
Vishnu Reddy <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.