From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Vikash Garodia <quic_vgarodia@quicinc.com>,
Fritz Koenig <frkoenig@chromium.org>,
Stanimir Varbanov <stanimir.varbanov@linaro.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sasha Levin <sashal@kernel.org>,
agross@kernel.org, bjorn.andersson@linaro.org,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: [PATCH AUTOSEL 5.18 051/159] media: venus: do not queue internal buffers from previous sequence
Date: Mon, 30 May 2022 09:22:36 -0400 [thread overview]
Message-ID: <20220530132425.1929512-51-sashal@kernel.org> (raw)
In-Reply-To: <20220530132425.1929512-1-sashal@kernel.org>
From: Vikash Garodia <quic_vgarodia@quicinc.com>
[ Upstream commit 73664f107c0fafb59cd91e576b81c986adb74610 ]
During reconfig (DRC) event from firmware, it is not guaranteed that
all the DPB(internal) buffers would be released by the firmware. Some
buffers might be released gradually while processing frames from the
new sequence. These buffers now stay idle in the dpblist.
In subsequent call to queue the DPBs to firmware, these idle buffers
should not be queued. The fix identifies those buffers and free them.
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Tested-by: Fritz Koenig <frkoenig@chromium.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/media/platform/qcom/venus/helpers.c | 34 +++++++++++++++------
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c b/drivers/media/platform/qcom/venus/helpers.c
index 0bca95d01650..fa01edd54c03 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -90,12 +90,28 @@ bool venus_helper_check_codec(struct venus_inst *inst, u32 v4l2_pixfmt)
}
EXPORT_SYMBOL_GPL(venus_helper_check_codec);
+static void free_dpb_buf(struct venus_inst *inst, struct intbuf *buf)
+{
+ ida_free(&inst->dpb_ids, buf->dpb_out_tag);
+
+ list_del_init(&buf->list);
+ dma_free_attrs(inst->core->dev, buf->size, buf->va, buf->da,
+ buf->attrs);
+ kfree(buf);
+}
+
int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
{
- struct intbuf *buf;
+ struct intbuf *buf, *next;
+ unsigned int dpb_size = 0;
int ret = 0;
- list_for_each_entry(buf, &inst->dpbbufs, list) {
+ if (inst->dpb_buftype == HFI_BUFFER_OUTPUT)
+ dpb_size = inst->output_buf_size;
+ else if (inst->dpb_buftype == HFI_BUFFER_OUTPUT2)
+ dpb_size = inst->output2_buf_size;
+
+ list_for_each_entry_safe(buf, next, &inst->dpbbufs, list) {
struct hfi_frame_data fdata;
memset(&fdata, 0, sizeof(fdata));
@@ -106,6 +122,12 @@ int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
if (buf->owned_by == FIRMWARE)
continue;
+ /* free buffer from previous sequence which was released later */
+ if (dpb_size > buf->size) {
+ free_dpb_buf(inst, buf);
+ continue;
+ }
+
fdata.clnt_data = buf->dpb_out_tag;
ret = hfi_session_process_buf(inst, &fdata);
@@ -127,13 +149,7 @@ int venus_helper_free_dpb_bufs(struct venus_inst *inst)
list_for_each_entry_safe(buf, n, &inst->dpbbufs, list) {
if (buf->owned_by == FIRMWARE)
continue;
-
- ida_free(&inst->dpb_ids, buf->dpb_out_tag);
-
- list_del_init(&buf->list);
- dma_free_attrs(inst->core->dev, buf->size, buf->va, buf->da,
- buf->attrs);
- kfree(buf);
+ free_dpb_buf(inst, buf);
}
if (list_empty(&inst->dpbbufs))
--
2.35.1
next prev parent reply other threads:[~2022-05-30 13:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220530132425.1929512-1-sashal@kernel.org>
2022-05-30 13:22 ` [PATCH AUTOSEL 5.18 050/159] media: venus: hfi: avoid null dereference in deinit Sasha Levin
2022-05-30 13:22 ` Sasha Levin [this message]
2022-05-30 13:22 ` [PATCH AUTOSEL 5.18 070/159] drm: msm: fix error check return value of irq_of_parse_and_map() Sasha Levin
2022-05-30 13:22 ` [PATCH AUTOSEL 5.18 071/159] drm/msm/dpu: Clean up CRC debug logs Sasha Levin
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=20220530132425.1929512-51-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=frkoenig@chromium.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_vgarodia@quicinc.com \
--cc=stable@vger.kernel.org \
--cc=stanimir.varbanov@linaro.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