From: Dikshita Agarwal <quic_dikshita@quicinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
<quic_vgarodia@quicinc.com>, <quic_abhinavk@quicinc.com>,
<mchehab@kernel.org>
Cc: <hverkuil@xs4all.nl>, <linux-media@vger.kernel.org>,
<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 08/12] media: iris: Avoid updating frame size to firmware during reconfig
Date: Thu, 6 Mar 2025 18:02:47 +0530 [thread overview]
Message-ID: <3d93b47b-4d68-8626-2b32-4840ea9925db@quicinc.com> (raw)
In-Reply-To: <39f566fc-9cc9-44be-9b14-7ced0607464f@linaro.org>
On 3/6/2025 6:56 AM, Bryan O'Donoghue wrote:
> On 05/03/2025 10:43, Dikshita Agarwal wrote:
>> During the reconfig, firmware sends the resolution aligned by 8 byte,
>> if driver set the same resoluton to firmware, it will be aligned to 16
>> byte causing another sequence change which would be incorrect.
>
> During reconfig the firmware sends the resolution aligned to 8 bytes. If
> the driver sends the same resolution back to the firmware the resolution
> will be aligned to 16 bytes not 8.
>
> The alignment mismatch would then subsequently cause the firmware to send
> another redundant sequence change.
>
>> Fix this by not setting the updated resolution to firmware during
>> reconfig.
>
> Fix this by not setting the resolution property during reconfig.
Ack.
>>
>> Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
>> ---
>> .../platform/qcom/iris/iris_hfi_gen1_command.c | 15 ++++++++-------
>> .../platform/qcom/iris/iris_hfi_gen1_response.c | 1 +
>> drivers/media/platform/qcom/iris/iris_instance.h | 2 ++
>> drivers/media/platform/qcom/iris/iris_vdec.c | 4 ++++
>> 4 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
>> b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
>> index a160ae915886..d5e81049d37e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
>> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
>> @@ -562,14 +562,15 @@ static int iris_hfi_gen1_set_resolution(struct
>> iris_inst *inst)
>> struct hfi_framesize fs;
>> int ret;
>> - fs.buffer_type = HFI_BUFFER_INPUT;
>> - fs.width = inst->fmt_src->fmt.pix_mp.width;
>> - fs.height = inst->fmt_src->fmt.pix_mp.height;
>> -
>> - ret = hfi_gen1_set_property(inst, ptype, &fs, sizeof(fs));
>> - if (ret)
>> - return ret;
>> + if (!inst->in_reconfig) {
>> + fs.buffer_type = HFI_BUFFER_INPUT;
>> + fs.width = inst->fmt_src->fmt.pix_mp.width;
>> + fs.height = inst->fmt_src->fmt.pix_mp.height;
>> + ret = hfi_gen1_set_property(inst, ptype, &fs, sizeof(fs));
>> + if (ret)
>> + return ret;
>> + }
>> fs.buffer_type = HFI_BUFFER_OUTPUT2;
>> fs.width = inst->fmt_dst->fmt.pix_mp.width;
>> fs.height = inst->fmt_dst->fmt.pix_mp.height;
>> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
>> b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
>> index 91d95eed68aa..6576496fdbdf 100644
>> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
>> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
>> @@ -155,6 +155,7 @@ static void iris_hfi_gen1_read_changed_params(struct
>> iris_inst *inst,
>> inst->crop.height = event.height;
>> }
>> + inst->in_reconfig = true;
>
> This flag can be changed by iris_hfi_isr_handler() down the chain.
>
>
>> @@ -453,6 +453,8 @@ static int iris_vdec_process_streamon_input(struct
>> iris_inst *inst)
>> if (ret)
>> return ret;
>> + inst->in_reconfig = false;
>> +
>> return iris_inst_change_sub_state(inst, 0, set_sub_state);
>> }
>> @@ -544,6 +546,8 @@ static int iris_vdec_process_streamon_output(struct
>> iris_inst *inst)
>> if (ret)
>> return ret;
>> + inst->in_reconfig = false;
>> +
>
> Are these usages of the in_reconfig flag then thread-safe ?
>
> i.e. are both iris_vdec_process_streamon_input() and
> iris_vdec_process_streamon_output() guaranteed not to run @ the same time ?
>
> I don't see any obvious locking here.
>
Since reconfig handling is only relevant to capture port, the usage of
in_reconfig flag in output port is unnecessary. I'll remove the redundant
flag from output stream_on to simplify the code.
Thanks,
Dikshita
> ---
> bod
next prev parent reply other threads:[~2025-03-06 12:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 10:43 [RFC PATCH 00/12] Add support for HEVC and VP9 codecs in decoder Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 01/12] media: iris: Add HEVC and VP9 formats for decoder Dikshita Agarwal
2025-03-06 0:17 ` Bryan O'Donoghue
2025-03-06 11:55 ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 02/12] media: iris: Add platform capabilities for HEVC and VP9 decoders Dikshita Agarwal
2025-03-06 0:28 ` Bryan O'Donoghue
2025-03-06 12:07 ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 03/12] media: iris: Set mandatory properties " Dikshita Agarwal
2025-03-05 14:00 ` neil.armstrong
2025-03-06 12:10 ` Dikshita Agarwal
2025-03-06 0:52 ` Bryan O'Donoghue
2025-03-06 12:16 ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 04/12] media: iris: Add internal buffer calculation " Dikshita Agarwal
2025-03-06 1:05 ` Bryan O'Donoghue
2025-03-06 12:26 ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 05/12] media: iris: Skip destroying internal buffer if not dequeued Dikshita Agarwal
2025-03-05 20:44 ` Dmitry Baryshkov
2025-03-06 12:26 ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 06/12] media: iris: Update CAPTURE format info based on OUTPUT format Dikshita Agarwal
2025-03-05 20:45 ` Dmitry Baryshkov
2025-03-06 12:27 ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 07/12] media: iris: Add handling for corrupt and drop frames Dikshita Agarwal
2025-03-06 1:12 ` Bryan O'Donoghue
2025-03-05 10:43 ` [RFC PATCH 08/12] media: iris: Avoid updating frame size to firmware during reconfig Dikshita Agarwal
2025-03-06 1:26 ` Bryan O'Donoghue
2025-03-06 12:32 ` Dikshita Agarwal [this message]
2025-03-05 10:43 ` [RFC PATCH 09/12] media: iris: Avoid sending LAST flag multiple times Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 10/12] media: iris: Send V4L2_BUF_FLAG_ERROR for buffers with 0 filled length Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 11/12] media: iris: Fix handling of eos buffer during drain Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 12/12] media: iris: Add handling for no show frames Dikshita Agarwal
2025-03-05 14:22 ` [RFC PATCH 00/12] Add support for HEVC and VP9 codecs in decoder neil.armstrong
2025-03-06 12:34 ` Dikshita Agarwal
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=3d93b47b-4d68-8626-2b32-4840ea9925db@quicinc.com \
--to=quic_dikshita@quicinc.com \
--cc=bryan.odonoghue@linaro.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=quic_abhinavk@quicinc.com \
--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