mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Vikash Garodia <quic_vgarodia@quicinc.com>,
	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 16:36:45 +0300	[thread overview]
Message-ID: <E98548DB-5085-4036-9F6C-DC22A604A0C2@linaro.org> (raw)
In-Reply-To: <9f5bce7e-2b8a-0b71-3a80-0b4f86d9f908@quicinc.com>

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

>
>> 
>>> +        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;
>> 


  reply	other threads:[~2023-03-29 13:36 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 [this message]
2023-03-29 17:15       ` Vikash Garodia
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=E98548DB-5085-4036-9F6C-DC22A604A0C2@linaro.org \
    --to=dmitry.baryshkov@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.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=quic_vgarodia@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®