Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
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,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On 8/12/2026 10:49 AM, Bryan O'Donoghue wrote: > On 11/08/2026 01:17, Dmitry Baryshkov wrote: >>> You are well aware of them, but still asking the same. Reasons, >>> 1. We have been attempting the subnodes for almost a year with multiple >>> pushbacks from multiple maintainers. We are closer and working on it >>> to post >>> for iris, followed by venus, once review is acceptable for iris. >> I think that we should have concentrated on it. From my point of view, >> the subnodes solution is ready and the last obstacle was the >> under-informing commit message. As you can see, Rob has (had?) questions >> about this solution too. > > Its taking too long. > > I just suggested restricting concurrency but, that can't be right. The > issue is IOVA - concurrency merely makes the bug more _likely_ to show > up so in fact that won't work. > > -rc1 hits soon, if sub-nodes isn't ready to go by that point there is no > choice but to implement BROKEN or minItems, 100% up to qcom to decide > which. > minItems is the way which could easily fix and patch all the kernels exposed with the known bug. At the same time, we have identified a way to even reserve this in driver now (venus/iris) with [1] and the results are good with this as well. If not minItems, would prefer [1] in -rc1 to avoid further delays or to keep the crash exposed. Please review. https://lore.kernel.org/linux-media/20260812-reserve_iova_in_driver-v1-0-ed62f801275c@oss.qualcomm.com/ Regards, Vikash > --- > bod