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

Vikash Garodia <[email protected]> Fri, 31 Jul 2026 18:14:15 +0530
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/31/2026 5:27 PM, Dmitry Baryshkov wrote:
> On Tue, Jul 21, 2026 at 11:02:25PM +0530, Vikash Garodia wrote:
>> Document the iris video accelerator used on shikra platforms by adding
>> the qcom,shikra-iris compatible.
>>
>> Although QCM2290 and shikra share the same video hardware and overall
>> integration, their SMMU programming differs. QCM2290 exposes separate
>> stream IDs for the video hardware and the Xtensa path, requiring two
>> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
>> equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
>> and Xtensa isolation requirements, such SMR masking is not applicable on
>> QCM2290 platforms.
> 
> This means that there are still two different streams, one for pixel and
> one for non-pixel data. Stop using the mask and describe them
> separately. One will go to the pixel node, another will go to the
> non-pixel node. As you wrote, the hardware is the same as QCM2290, which
> has two separate streams.

AFAIU, SMR mask is an optimization to reduce the stream id configuration 
to SMMU hardware registers, separating out is _not_ recommended which 
again brings in additional register for programming the additional stream.

Regards,
Vikash>
>> Since shikra uses the same video hardware as QCM2290 and shares the same
>> programming model and capabilities, it is added as a fallback compatible
>> to qcom,qcm2290-venus, with conditional handling to allow either one or
>> two IOMMU entries.
>> Common schema is updated to accommodate the iova restriction of 600MB.
>> VPU restricts usage of 600MB for specific streams, which could otherwise
>> lead to device crash.
>>
>> Reviewed-by: Vishnu Reddy <[email protected]>
>> Signed-off-by: Vikash Garodia <[email protected]>
>