Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

On 8/7/2026 6:48 PM, Bryan O'Donoghue wrote:
> On 07/08/2026 11:22, Vikash Garodia wrote:
>>>>> I don't like the idea of this series, because it_again_ doesn't 
>>>>> tell us
>>>>> the truth about the hardware. This typicall ends up with bigger 
>>>>> problems
>>>> honestly...thats all the info i have about the vpu hardware that it
>>>> restricts non pixel to DMA from the 0-600MB range. The same i have been
>>>> trying for a year now
>>> You are not honest here. You also know that there are secure streams,
>>> which have to use their own IOMMU SIDs. And some of them, as far as I
>>> remember, also have memory range restrictions.
>> please read the commit description again, the answer is there.
> 
> So I don't necessarily get all of the detail out of the commit log myself.
> 
> Could you give some detail to address Dmitry's point.
> 
> The question as I read it is - are all of the other potential SIDs 
> covered by this change ?
> 

I get the query as "secure streams also have their dedicated reserve 
regions, so how does this approach helps" - This patch does not reserve 
any IOVA for secure streams, only the forward looking subnode can assign 
specific reserve for specific streams.
The patch enforces a common IOVA across all streams, and is good enough 
to fix the problem we have w.r.t device reset.

>>> So, if we land these patches, how do extend it later to account for all
>>> of that?
>>>
>> forward looking design would be subnode, which we can land ontop of this
>> series.
> 
> Yes it should be possible to branch to make subnodes work on-top of this 
> - accepting that once this lands it becomes ABI and support for this 
> method must be sustained, even after sub-nodes land.
> 

Thats the plan. This goes as ABI with subnode to land on top of it.

> ---
> bod