From: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
To: "Vikash Garodia" <quic_vgarodia@quicinc.com>,
"Martin Dørum" <dorum@noisolation.com>
Cc: linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH] media: venus: only set H264_TRANSFORM_8X8 on supported hfi versions
Date: Fri, 26 May 2023 01:03:43 +0300 [thread overview]
Message-ID: <bd5a5b80-6849-bd98-0815-cc94badbec13@gmail.com> (raw)
In-Reply-To: <24c92a72-3d32-d6ce-172b-b127d54c3c75@quicinc.com>
Hi Martin,
On 3.05.23 г. 9:47 ч., Vikash Garodia wrote:
>
> On 5/3/2023 11:23 AM, Stanimir Varbanov wrote:
>> Hi,
>>
>> On 3.05.23 г. 7:25 ч., Vikash Garodia wrote:
>>> On 5/3/2023 2:22 AM, Stanimir Varbanov wrote:
>>>>
>>>>
>>>> On 14.04.23 г. 13:12 ч., Martin Dørum wrote:
>>>>> Setting the H264_TRANSFORM_8X8 property only works on HFI versions
>>>>>> =4xx. The code used to unconditionally set the property in
>>>>> venc_set_properties, which meant that initializing the encoder would
>>>>> always fail unless the hfi_version was >=4xx.
>>>>>
>>>>> This patch changes venc_set_properties to only set the
>>>>> H264_TRANSFORM_8X8 property if the hfi version is >=4xx.
>>>>>
>>>>> Signed-off-by: Martin Dørum <dorum@noisolation.com>
>>>>>
>>>>> ---
>>>>>
>>>>> I have an APQ8016-based board. Before this patch, the Venus driver
>>>>> would simply fail with EINVAL when trying to request buffers
>>>>> (VIDIOC_REQBUFS). With this patch, encoding works
>>>>> (tested using gstreamer's v4l2h264enc).
>>>>>
>>>>> drivers/media/platform/qcom/venus/venc.c | 21 +++++++++++----------
>>>>> 1 file changed, 11 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/media/platform/qcom/venus/venc.c
>>>>> b/drivers/media/platform/qcom/venus/venc.c
>>>>> index cdb12546c4fa..b3df805a8c9c 100644
>>>>> --- a/drivers/media/platform/qcom/venus/venc.c
>>>>> +++ b/drivers/media/platform/qcom/venus/venc.c
>>>>> @@ -672,16 +672,17 @@ static int venc_set_properties(struct
>>>>> venus_inst *inst)
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> - ptype = HFI_PROPERTY_PARAM_VENC_H264_TRANSFORM_8X8;
>>>>> - h264_transform.enable_type = 0;
>>>>> - if (ctr->profile.h264 == V4L2_MPEG_VIDEO_H264_PROFILE_HIGH ||
>>>>> - ctr->profile.h264 ==
>>>>> V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_HIGH)
>>>>> - h264_transform.enable_type = ctr->h264_8x8_transform;
>>>>> -
>>>>> - ret = hfi_session_set_property(inst, ptype, &h264_transform);
>>>>> - if (ret)
>>>>> - return ret;
>>>>> -
>>>>> + if (!IS_V1(inst->core) && !IS_V3(inst->core)) {
>>>>
>>>> Instead of doing these checks here you could do:
>>>>
>>>> diff --git a/drivers/media/platform/qcom/venus/hfi_cmds.c
>>>> b/drivers/media/platform/qcom/venus/hfi_cmds.c
>>>> index bc3f8ff05840..2453e5c3d244 100644
>>>> --- a/drivers/media/platform/qcom/venus/hfi_cmds.c
>>>> +++ b/drivers/media/platform/qcom/venus/hfi_cmds.c
>>>> @@ -1064,6 +1064,7 @@ static int pkt_session_set_property_1x(struct
>>>> hfi_session_set_property_pkt *pkt,
>>>> break;
>>>> }
>>>> case HFI_PROPERTY_PARAM_VENC_HDR10_PQ_SEI:
>>>> + case HFI_PROPERTY_PARAM_VENC_H264_TRANSFORM_8X8:
>>>> return -ENOTSUPP;
>>>>
>>> This may still deinit the session from [1] based on failure return
>>> value.
>>>
>>> [1]
>>> https://elixir.bootlin.com/linux/v6.3/source/drivers/media/platform/qcom/venus/venc.c#L963
>>
>> No, it will not fail because of:
>>
>> https://elixir.bootlin.com/linux/v6.3/source/drivers/media/platform/qcom/venus/hfi_venus.c#L1426
>
> Thats correct, I missed to notice the explicit handling for -ENOTSUPP.
> Above suggestion is better than keeping verison checks and
>
> would also avoid deinit.
>
Could you send v2 with suggested change?
--
regards,
Stan
prev parent reply other threads:[~2023-05-25 22:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-14 10:12 [PATCH] media: venus: only set H264_TRANSFORM_8X8 on supported hfi versions Martin Dørum
2023-04-27 14:43 ` Javier Martinez Canillas
2023-05-02 12:49 ` Vikash Garodia
2023-05-02 16:37 ` Bryan O'Donoghue
2023-05-12 10:32 ` Bryan O'Donoghue
2023-05-16 12:33 ` Vikash Garodia
2023-05-02 20:52 ` Stanimir Varbanov
2023-05-03 4:25 ` Vikash Garodia
2023-05-03 5:53 ` Stanimir Varbanov
2023-05-03 6:47 ` Vikash Garodia
2023-05-25 22:03 ` Stanimir Varbanov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd5a5b80-6849-bd98-0815-cc94badbec13@gmail.com \
--to=stanimir.k.varbanov@gmail.com \
--cc=dorum@noisolation.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=quic_vgarodia@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox