From: Vikash Garodia <quic_vgarodia@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Andy Gross <agross@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
<linux-media@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <stanimir.k.varbanov@gmail.com>,
<andersson@kernel.org>, <konrad.dybcio@linaro.org>
Cc: <quic_dikshita@quicinc.com>, Viswanath Boma <quic_vboma@quicinc.com>
Subject: Re: [PATCH v4] venus: Enable sufficient sequence change support for sc7180 and fix for Decoder STOP command issue.
Date: Wed, 29 Mar 2023 22:45:56 +0530 [thread overview]
Message-ID: <b2e16887-bc35-c933-2107-6e8faa439770@quicinc.com> (raw)
In-Reply-To: <E98548DB-5085-4036-9F6C-DC22A604A0C2@linaro.org>
On 3/29/2023 7:06 PM, Dmitry Baryshkov wrote:
> 29 марта 2023 г. 10:48:23 GMT+03:00, Vikash Garodia <quic_vgarodia@quicinc.com> пишет:
>> On 3/29/2023 3:49 AM, Dmitry Baryshkov wrote:
>>> On 23/03/2023 15:01, Viswanath Boma wrote:
>>>> For VP9 bitstreams, there could be a change in resolution at interframe,
>>>> for driver to get notified of such resolution change,
>>>> enable the property in video firmware.
>>>> Also, EOS handling is now made same in video firmware across all V6 SOCs,
>>>> hence above a certain firmware version, the driver handling is
>>>> made generic for all V6s
>>> Having "Do abc. Also do defgh." is a clear sign that this patch should be split into two.
>> I agree, it could have split into patches. The patch introduces way to store venus firmware
>>
>> version and take some decision for various version. For ex. here STOP handling and enabling
>>
>> DRC event for specific firmware revision and onwards. Since both the handling was primarily
>>
>> dependent of firmware version, and since the handlings were smaller, it was combined as single
>>
>> patch. Let me know, if you have any further review comments, else, will raise a new version with
>>
>> 2 patches probably.
> Thanks!
>
>>>> Signed-off-by: Vikash Garodia <vgarodia@qti.qualcomm.com>
>>>> Signed-off-by: Viswanath Boma <quic_vboma@quicinc.com>
>>>> Tested-by: Nathan Hebert <nhebert@chromium.org>
>>>> ---
>>>> Since v3 : Addressed comments to rectify email address.
>>>>
>>>> drivers/media/platform/qcom/venus/core.h | 18 ++++++++++++++++++
>>>> drivers/media/platform/qcom/venus/hfi_cmds.c | 1 +
>>>> drivers/media/platform/qcom/venus/hfi_helper.h | 2 ++
>>>> drivers/media/platform/qcom/venus/hfi_msgs.c | 11 +++++++++--
>>>> drivers/media/platform/qcom/venus/vdec.c | 12 +++++++++++-
>>>> 5 files changed, 41 insertions(+), 3 deletions(-)
>>>>
> (Skipped)
>
>
>
>>>> @@ -671,6 +671,16 @@ static int vdec_set_properties(struct venus_inst *inst)
>>>> return ret;
>>>> }
>>>> + /* Enabling sufficient sequence change support for VP9 */
>>>> + if (of_device_is_compatible(inst->core->dev->of_node, "qcom,sc7180-venus")) {
>>> Let me repeat my question from v3:
>>>
>>> Is it really specific just to sc7180 or will it be applicable to any
>>> other platform using venus-5.4 firmware?
>> The HFI "HFI_PROPERTY_PARAM_VDEC_ENABLE_SUFFICIENT_SEQCHANGE_EVENT" is implemented
>>
>> only for sc7180. Calling this for any other venus-5.4 would error out the session with error as
>>
>> unsupported property from firmware.
>
> How can we be sure that other platforms do not end up using sc7180 firmware? Or that sc7180 didn't end up using some other firmware?
>
> I see generic qcom/venus-5.4/venus.mbn in Linux firmware. It's version is VIDEO.VE.5.4-00053-PROD-1. It can be used with any unfused device which uses firmware 5.4
Driver defines resources for every platforms and there it specifies the
firmware to be used for that platform. For ex, for sc7180, the firmware
is specified at [1].
The various firmware supported by different platforms are also available
in linux firmware.
[1]
https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/media/platform/qcom/venus/core.c#L765
>>>> + if (is_fw_rev_or_newer(inst->core, 5, 4, 51)) {
>>>> + ptype = HFI_PROPERTY_PARAM_VDEC_ENABLE_SUFFICIENT_SEQCHANGE_EVENT;
>>>> + ret = hfi_session_set_property(inst, ptype, &en);
>>>> + if (ret)
>>>> + return ret;
>>>> + }
>>>> + }
>>>> +
>>>> ptype = HFI_PROPERTY_PARAM_VDEC_CONCEAL_COLOR;
>>>> conceal = ctr->conceal_color & 0xffff;
>>>> conceal |= ((ctr->conceal_color >> 16) & 0xffff) << 10;
next prev parent reply other threads:[~2023-03-29 17:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-23 13:01 Viswanath Boma
2023-03-28 22:19 ` Dmitry Baryshkov
2023-03-29 7:48 ` Vikash Garodia
2023-03-29 13:36 ` Dmitry Baryshkov
2023-03-29 17:15 ` Vikash Garodia [this message]
2023-03-29 17:33 ` Dmitry Baryshkov
2023-03-30 4:34 ` Vikash Garodia
2023-03-28 22:20 ` Dmitry Baryshkov
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=b2e16887-bc35-c933-2107-6e8faa439770@quicinc.com \
--to=quic_vgarodia@quicinc.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=quic_dikshita@quicinc.com \
--cc=quic_vboma@quicinc.com \
--cc=stanimir.k.varbanov@gmail.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
all inboxes | Powered by JetHome®