Re: [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible

[Bryan O'Donoghue <bod@kernel.org>]

On 31/07/2026 14:39, Bryan O'Donoghue wrote:
> On 21/07/2026 18:32, Vikash Garodia wrote:
>> diff --git a/Documentation/devicetree/bindings/media/qcom,venus- 
>> common.yaml b/Documentation/devicetree/bindings/media/qcom,venus- 
>> common.yaml
>> index 
>> 59a3fde846d2196ab1e4588eb396012ba6860712..0be2f9119e78233928d23af86836ac294aa769ee 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> @@ -37,7 +37,10 @@ properties:
>>       maxItems: 20
>>
>>     memory-region:
>> -    maxItems: 1
>> +    minItems: 1
>> +    items:
>> +      - description: Firmware-loaded codec carveout
>> +      - description: IOMMU IOVA reservation region
> 
> So we discussed separately the pixel and non-pixel sub-nodes as well as 
> this basically alternate means of memory delination.
> 
> What I'd like is a clear statement
> 
> - Committing to this scheme for existing platforms
> - Adding the pixel and sub-pixel to the shared
> - Backporting at least one method to -stable
> 
> For that reason this extension should at a minimum be its own commit 
> with a well articulated commit log.
> 
> Since this is minItems: 1 it is conceviable to land both this and the 
> sub-node into the same file.
> 
> But my continued feedback and objection is not being clear about what's 
> being done and having two separate methods without a clear roadmap.
> 
> You have your sub-node RFC and this change - I won't say sneaking in 
> here but, its a surreptitious change as given as-is.
> 
> - Which method
> - Both ? Then what goes to -stable
> 
> We also discussed offline the fact that right-now the lack of a means of 
> addressing this in upstream means we are in effect leaving a known 
> critical bug open to the vagaries of IOVA allocation @ runtime across 
> every single venus and iris there is.
> 
> So to me minItems: 1 for -stable _in_this_kernel_cycle_ is warranted.
> 
> ---
> bod

Just thinking about our conversation on this topic..

Truth be told, I don't think any new features should be merged to venus 
or iris until this gets a resolution applicable to -stable. Its just not 
kosher to pretend everything is fine and keep merging new features with 
a known critical error festering unaddressed. Fixes: yes, other stuff no.

Bug fixes > New features many times over.

This absolutely has to go to the top of the queue, its going on for 
months unresolved - what use is a new video codec to a user on a system 
where we can mess up the IOVA/SID mappings and trigger a hard reset ? 
Its not just that its a bug, its that its a system resetting bug.

I'm going to have to insist.

---
bod