Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
Vikash Garodia <[email protected]>
| Newsgroups | org.kernel.vger.linux-media,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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<[email protected]> >>>>> --- >>>> >>>> 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 <[email protected]> >>> >>> 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