Re: [PATCH v3 5/6] media: qcom: iris: vdec: update find_format to handle 8bit and 10bit formats

[Neil Armstrong <neil.armstrong@linaro.org>]

On 5/20/26 17:47, Vikash Garodia wrote:
> 
> On 5/20/2026 9:09 PM, Neil Armstrong wrote:
>> On 5/20/26 17:30, Vikash Garodia wrote:
>>>
>>> On 5/18/2026 1:06 PM, Neil Armstrong wrote:
>>>> On 5/13/26 21:27, Vikash Garodia wrote:
>>>>>
>>>>>
>>>>> On 5/11/2026 2:50 PM, Neil Armstrong wrote:
>>>>>> The 10bit pixel format can be only used when the decoder identifies the
>>>>>> stream as decoding into 10bit pixel format buffers, so update the
>>>>>> find_format helper to filter the formats and only allow the proper
>>>>>> formats when setting or trying a capture format.
>>>>>>
>>>>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>>>>>> ---
>>>>>>   drivers/media/platform/qcom/iris/iris_platform_common.h |  1 +
>>>>>>   drivers/media/platform/qcom/iris/iris_vdec.c            | 10 ++++ ++ ++++
>>>>>>   2 files changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/media/platform/qcom/iris/ iris_platform_common.h b/drivers/media/platform/qcom/iris/ iris_platform_common.h
>>>>>> index 5a489917580e..cd3509da4b75 100644
>>>>>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>>>>>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>>>>>> @@ -18,6 +18,7 @@ struct iris_inst;
>>>>>>   #define REGISTER_BIT_DEPTH(luma, chroma)    ((luma) << 16 | (chroma))
>>>>>>   #define BIT_DEPTH_8                REGISTER_BIT_DEPTH(8, 8)
>>>>>> +#define BIT_DEPTH_10                REGISTER_BIT_DEPTH(10, 10)
>>>>>>   #define CODED_FRAMES_PROGRESSIVE        0x0
>>>>>>   #define DEFAULT_MAX_HOST_BUF_COUNT        64
>>>>>>   #define DEFAULT_MAX_HOST_BURST_BUF_COUNT    256
>>>>>> diff --git a/drivers/media/platform/qcom/iris/iris_vdec.c b/ drivers/ media/platform/qcom/iris/iris_vdec.c
>>>>>> index eea69f937147..f4d9951ed04c 100644
>>>>>> --- a/drivers/media/platform/qcom/iris/iris_vdec.c
>>>>>> +++ b/drivers/media/platform/qcom/iris/iris_vdec.c
>>>>>> @@ -99,6 +99,16 @@ find_format(struct iris_inst *inst, u32 pixfmt, u32 type)
>>>>>>       if (i == size || fmt[i].type != type)
>>>>>>           return NULL;
>>>>>> +    if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
>>>>>> +        if (iris_fmt_is_8bit(fmt[i].pixfmt) &&
>>>>>> +            inst->fw_caps[BIT_DEPTH].value == BIT_DEPTH_10)
>>>>>> +            return NULL;
>>>>>> +
>>>>>> +        if (iris_fmt_is_10bit(fmt[i].pixfmt) &&
>>>>>> +            inst->fw_caps[BIT_DEPTH].value != BIT_DEPTH_10)
>>>>>> +            return NULL;
>>>>>> +    }
>>>>>
>>>>> similar logic would be now needed while enumerating fmt.
>>>>>
>>>>> VIDIOC_ENUM_FMT will now enumerate all capture formats (NV12, QC08C, QC10C..) regardless of the stream's bit depth, while VIDIOC_S_FMT will reject the wrong-depth formats.
>>>>>
>>>>> userspace will see formats via ENUM_FMT that it cannot successfully set with S_FMT.
>>>>
>>>> So initially I did that, but I reverted since it broke decoding with gstreamer when trying
>>>> to use QC10C since it requires negociating the src/sink before sending the fist buffer
>>>> and then get the source format change to switch to 10bit.
>>>
>>> Does that mean that src is still producing the data in Q10c, while sink is configured to NV12 (8bit) ?
>>
>> No, it's early src/sink negociation capabilities with the special DRM DMABUF format to handle the QC10c, way before playback starts and starts the v4l2 dance.
>>
> 
> How will it know its Q10c, even before the playback starts ?

So in the way upstream gstreamer wants to support QC8C/QC10C, the format must be specified like:
gst-launch-1.0 -v -m filesrc location=Big_Buck_Bunny_1080_10s_30MB.h265 ! h265parse !  v4l2h265dec ! "video/x-raw(memory:DMABuf), format=DMA_DRM, drm-format=NV12:0x0500000000000001" ! kmssink
or
gst-launch-1.0 -v -m filesrc location=Big_Buck_Bunny_1080_10s_30MB_main10.h265 ! h265parse !  v4l2h265dec ! "video/x-raw(memory:DMABuf), format=DMA_DRM, drm-format=P010:0x0500000000000001" ! kmssink

so this means the QC8C/QC10C format must be listed in the VIDIOC_ENUM_FMT so the v4l2h265dec element can enums them as supported (and translated as drm-format=NV12:0x0500000000000001/drm-format=P010:0x0500000000000001)

Neil

> 
>>>
>>>>
>>>> I checked and none of the other v4l2 drivers supporting 10bit does that, so it seems right
>>>> to allow enumerating all possibly supported formats and only accept the session supported
>>>> one with S_FMT.
>>>
>>> I was reading the documentation on this aspects, and it says to keep all the supported ones, instead of changing runtime and limit it to 10bit ones, in this case.
>>
>> Hmm, so my change is correct ?
> 
> Yes, to me.
> 
>>
>>>
>>> +ing Nico and Hans incase they would like to comment on this.
>>>
>>>>
>>>>>
>>>>>> +
>>>>>>       return &fmt[i];
>>>>>>   }
>>>>>>
>>>>>
>>>>> Regards,
>>>>> Vikash
>>>>>
>>>>
>>>
>>
>