linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanimir Varbanov <stanimir.varbanov@linaro.org>
To: Srinu Gorle <sgorle@codeaurora.org>,
	stanimir.varbanov@linaro.org, hverkuil@xs4all.nl,
	mchehab@kernel.org, linux-media@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Cc: acourbot@chromium.org, vgarodia@codeaurora.org
Subject: Re: [PATCH v1 3/5] media: venus: do not destroy video session during queue setup
Date: Fri, 9 Nov 2018 11:59:49 +0200	[thread overview]
Message-ID: <d8cb0c47-a3f7-314b-c65d-3c8eca724e6a@linaro.org> (raw)
In-Reply-To: <1538222432-25894-4-git-send-email-sgorle@codeaurora.org>

Hi Srinu,

On 9/29/18 3:00 PM, Srinu Gorle wrote:
> - open and close video sessions for plane properties is incorrect.

Could you rephrase this statement? I really don't understand what you mean.

> - add check to ensure, same instance persist from driver open to close.

This assumption is wrong. The v4l client can change the codec by SFMT
without close the device node, in that case we have to destroy and
create a new session with new codec.

> 
> Signed-off-by: Srinu Gorle <sgorle@codeaurora.org>
> ---
>  drivers/media/platform/qcom/venus/hfi.c  | 3 +++
>  drivers/media/platform/qcom/venus/vdec.c | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/media/platform/qcom/venus/hfi.c b/drivers/media/platform/qcom/venus/hfi.c
> index 36a4784..59c34ba 100644
> --- a/drivers/media/platform/qcom/venus/hfi.c
> +++ b/drivers/media/platform/qcom/venus/hfi.c
> @@ -207,6 +207,9 @@ int hfi_session_init(struct venus_inst *inst, u32 pixfmt)
>  	const struct hfi_ops *ops = core->ops;
>  	int ret;
>  
> +	if (inst->state >= INST_INIT && inst->state < INST_STOP)
> +		return 0;

In fact you want to be able to call session_init multiple times but
deinit the session only once? The hfi.c layer is designed to follow the
states as they are expected by the firmware side, if you want to call
session_init multiple times just make a wrapper in the vdec.c with
reference counting.

> +
>  	inst->hfi_codec = to_codec_type(pixfmt);
>  	reinit_completion(&inst->done);
>  
> diff --git a/drivers/media/platform/qcom/venus/vdec.c b/drivers/media/platform/qcom/venus/vdec.c
> index afe3b36..0035cf2 100644
> --- a/drivers/media/platform/qcom/venus/vdec.c
> +++ b/drivers/media/platform/qcom/venus/vdec.c
> @@ -700,6 +700,8 @@ static int vdec_num_buffers(struct venus_inst *inst, unsigned int *in_num,
>  
>  	*out_num = HFI_BUFREQ_COUNT_MIN(&bufreq, ver);
>  
> +	return 0;

OK in present implementation I decided that the codec is settled when
streamon on both queues is called (i.e. the final session_init is made
in streamon). IMO the correct one is to init the session in
reqbuf(output) and deinit session in reqbuf(output, count=0)?

The problem I see when you skip session_deinit is that the codec cannot
be changed without closing the video node.

> +
>  deinit:
>  	hfi_session_deinit(inst);
>  
> 

-- 
regards,
Stan

  reply	other threads:[~2018-11-09  9:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-29 12:00 [PATCH v1 0/5] Venus - Decode reconfig sequence Srinu Gorle
2018-09-29 12:00 ` [PATCH v1 1/5] media: venus: handle video decoder resolution change Srinu Gorle
2018-11-14 10:50   ` Tomasz Figa
2018-09-29 12:00 ` [PATCH v1 2/5] media: venus: dynamically configure codec type Srinu Gorle
2018-11-14 10:56   ` Tomasz Figa
2018-09-29 12:00 ` [PATCH v1 3/5] media: venus: do not destroy video session during queue setup Srinu Gorle
2018-11-09  9:59   ` Stanimir Varbanov [this message]
2018-11-14 11:02     ` Tomasz Figa
2018-09-29 12:00 ` [PATCH v1 4/5] media: venus: video decoder drop frames handling Srinu Gorle
2018-11-14 11:04   ` Tomasz Figa
2018-09-29 12:00 ` [PATCH v1 5/5] media: venus: update number of bytes used field properly for EOS frames Srinu Gorle
2018-11-08 10:16   ` Stanimir Varbanov
2018-11-12  8:12     ` Alexandre Courbot
2018-11-12 12:20       ` Stanimir Varbanov
2018-11-13  9:31         ` Alexandre Courbot

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=d8cb0c47-a3f7-314b-c65d-3c8eca724e6a@linaro.org \
    --to=stanimir.varbanov@linaro.org \
    --cc=acourbot@chromium.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sgorle@codeaurora.org \
    --cc=vgarodia@codeaurora.org \
    /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;
as well as URLs for NNTP newsgroup(s).