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

[Bryan O'Donoghue]

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