Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
From: Vikash Garodia
Date: Thu Jul 30 2026 - 04:56:24 EST
On 7/29/2026 5:51 PM, Konrad Dybcio wrote:
On 7/23/26 12:44 PM, Vikash Garodia wrote:
On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
On 22/07/2026 14:41, Vikash Garodia wrote:
Update the memory-region property to support two regions:
1. Firmware-loaded codec carveout (existing)
2. IOMMU IOVA reservation region (new)
The IOMMU IOVA reservation region is required to restrict usage of
specific IOVA memory range. For example, VPU restricts usage of 600MB
for specific streams, which could otherwise lead to device crash. This
change allows platforms to define separate memory regions for codec
carveout and IOVA restrictions.
This schema update supports existing DTS having single memory-region,
thereby allowing gradual migration of DTS to support two memory region.
Signed-off-by: Vikash Garodia<vikash.garodia@xxxxxxxxxxxxxxxx>
---
I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
Doesn't this cause the same limitation that the initial patch
by Daniel (all HW contexts can't access 0-600MiB anymore)?
Yes, it does, but for cases, like Shikra, which have single streams (with SMRs), there is no additional benefit in going with sub nodes in such case.
Please note that somewhere, I was under the impression all venus
impls suffer from that
Yes, all of venus/iris, including Shikra, have this limitation. I was trying to convey that for single stream case, like that of Shikra, we can specify the restrictive IOVA range in the parent iris node itself instead of introducing a sub node and put the same restriction there.
Regards,
Vikash
Konrad