Re: [PATCH v3 0/6] media: iris: prepare support for video codecs on Qcom vpu4 platform

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

On 11/11/2025 7:09 PM, Dmitry Baryshkov wrote:
> On Tue, 11 Nov 2025 at 14:43, Vikash Garodia
> <vikash.garodia@oss.qualcomm.com> wrote:
>>
>>
>> On 11/11/2025 4:08 PM, Dmitry Baryshkov wrote:
>>> On Fri, Nov 07, 2025 at 03:19:35PM +0530, Vikash Garodia wrote:
>>>> Upcoming Qualcomm kaanapali platform have a newer generation of video
>>>> IP, iris4 or vpu4. The hardware have evolved mostly w.r.t higher number
>>>> of power domains as well as multiple clock sources. It has support for
>>>> new codec(apv), when compared to prior generation.
>>>>
>>>>   From previous version of this series, the kaanapali binding patch(#1/8)
>>>> and the compatible patch(#8/8) have been dropped. The discussion for
>>>> this is captured here [1].
>>>> The series introducs buffer calculation and power sequence for vpu4. It
>>>> prepares for vpu4 when kaanapali is enabled after the binding discussion
>>>> is concluded.
>>>>
>>>>
>>>> gstreamer test:
>>>> Decoders validated with below commands, codec specific:
>>> Why not just run the fluster testsuite?
>>>
>>
>> yeah, fluster can also be executed. Individual codec commands were
>> explicitly called out incase someone wants to run standalone gst pipeline.
> 
> Please switch to fluster (in addition to Gst), ideally running all
> test cases for a codec. While enabling SC7280 support I found that
> there are enough corner cases which are being ignored by the driver.
> One additional bonus is that fluster runs several process in parallel
> by default, catching issues caused by several decode threads running
> in parallel.
> 

multi process issue is due to below [1] (tried it on lemans). Due to 
higher concurrency, we can see that the DMA buffer is mapped into 
un-addressable range (0-0x25800000) i.e 0x24b00000, and leading to 
global fault. This was the reason i was keeping 2 memory-region in 
kaanapali binding, to restrict certain ranges of IOVA.

Below solutions are being tried, again this is not limited to kaanapali 
and applies to existing enabled SOCs as well.

1. introduce dynamic device for output buffers which are big size 
comparatively, via iommu-map
2. introduce the restrictions to the addressable range.

[1]
157.511807:   SMMU_ERR_FATAL_NSEC_FAULT_NAME_REG : SMMU:>> 0x0x15000000 
NonSec Global Fault: NSGFSR=0x80000002, NSGFAR1=0x00000000, 
NSGFAR0=0x24b00000,  NSGFSYNR0=0x00000004,  NSGFSYNR1=0x08840884, 
NSGFSYNR2=0x00000000,  NSCR0=0x00280406

>>
>>>> gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
>>>> parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>>
>>>> gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
>>>> parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>>
>>>> gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
>>>> parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>>
>>>> Encoders validated with below commands:
>>>> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
>>>> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
>>>> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
>>>> location=<output_file.h264>
>>>>
>>>> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
>>>> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc
>>>> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
>>>> location=<output_file.hevc>
>>
>> Regards,
>> Vikash
> 
> 
>