* [PATCH 0/4] Improvement around mtk_vcodec_mem_free() logging and usage
@ 2023-11-13 12:26 Fei Shao
2023-11-13 12:26 ` [PATCH 1/4] media: mediatek: vcodec: Replace dev_name in error string Fei Shao
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: Fei Shao @ 2023-11-13 12:26 UTC (permalink / raw)
To: Hans Verkuil, AngeloGioacchino Del Regno
Cc: Fei Shao, Andrew-CT Chen, Dan Carpenter, Irui Wang,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, Xiaoyong Lu,
Yunfei Dong, linux-arm-kernel, linux-kernel, linux-media,
linux-mediatek
This series includes some improvements around mtk_vcodec_mem_free() in
mtk_vcodec_util.c.
I noticed that mtk_vcodec_mem_free() generates a spurious error if the
target DMA buffer has been freed previously:
mtk_vcodec_mem_free(),69: [MTK_V4L2][ERROR] 18000000.video-codec
dma_free size=0 failed!
It's actually harmless, but it brings some confusion to our developers
and testing infra so I'd like to fix it. Then I found some checks around
mtk_vcodec_mem_free() usages in the driver that can optimized together,
so I wrapped both into this series.
The first two patches are for aesthetic and style improvements, the
third suppresses the error mentioned above, and the last removes the
redundant code for optimization.
Regards,
Fei
Fei Shao (4):
media: mediatek: vcodec: Replace dev_name in error string
media: mediatek: vcodec: Drop unnecessary variable
media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria
media: mediatek: vcodec: Drop VA check against mtk_vcodec_mem_free()
.../mediatek/vcodec/common/mtk_vcodec_util.c | 23 +++++++--------
.../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 18 ++++--------
.../vcodec/decoder/vdec/vdec_h264_if.c | 9 ++----
.../vcodec/decoder/vdec/vdec_h264_req_if.c | 9 ++----
.../decoder/vdec/vdec_h264_req_multi_if.c | 6 ++--
.../decoder/vdec/vdec_hevc_req_multi_if.c | 9 ++----
.../vcodec/decoder/vdec/vdec_vp8_if.c | 4 +--
.../vcodec/decoder/vdec/vdec_vp8_req_if.c | 12 +++-----
.../vcodec/decoder/vdec/vdec_vp9_if.c | 15 ++++------
.../vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 29 +++++++------------
.../mediatek/vcodec/decoder/vdec_msg_queue.c | 15 ++++------
11 files changed, 54 insertions(+), 95 deletions(-)
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/4] media: mediatek: vcodec: Replace dev_name in error string
2023-11-13 12:26 [PATCH 0/4] Improvement around mtk_vcodec_mem_free() logging and usage Fei Shao
@ 2023-11-13 12:26 ` Fei Shao
2023-12-06 10:19 ` AngeloGioacchino Del Regno
2023-11-13 12:26 ` [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable Fei Shao
` (2 subsequent siblings)
3 siblings, 1 reply; 13+ messages in thread
From: Fei Shao @ 2023-11-13 12:26 UTC (permalink / raw)
To: Hans Verkuil, AngeloGioacchino Del Regno
Cc: Fei Shao, Andrew-CT Chen, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, Yunfei Dong,
linux-arm-kernel, linux-kernel, linux-media, linux-mediatek
mtk_v4l2_err() already uses dev_err(), so don't print the device name
again. Print function name instead.
Signed-off-by: Fei Shao <fshao@chromium.org>
---
.../media/platform/mediatek/vcodec/common/mtk_vcodec_util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index 9ce34a3b5ee6..ea8c35c0e667 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -67,7 +67,7 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
mem->va = dma_alloc_coherent(&plat_dev->dev, size, &mem->dma_addr, GFP_KERNEL);
if (!mem->va) {
mtk_v4l2_err(plat_dev, "%s dma_alloc size=%ld failed!",
- dev_name(&plat_dev->dev), size);
+ __func__, size);
return -ENOMEM;
}
@@ -99,7 +99,7 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
if (!mem->va) {
mtk_v4l2_err(plat_dev, "%s dma_free size=%ld failed!",
- dev_name(&plat_dev->dev), size);
+ __func__, size);
return;
}
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable
2023-11-13 12:26 [PATCH 0/4] Improvement around mtk_vcodec_mem_free() logging and usage Fei Shao
2023-11-13 12:26 ` [PATCH 1/4] media: mediatek: vcodec: Replace dev_name in error string Fei Shao
@ 2023-11-13 12:26 ` Fei Shao
2023-12-06 10:19 ` AngeloGioacchino Del Regno
2023-11-13 12:26 ` [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria Fei Shao
2023-11-13 12:26 ` [PATCH 4/4] media: mediatek: vcodec: Drop VA check against mtk_vcodec_mem_free() Fei Shao
3 siblings, 1 reply; 13+ messages in thread
From: Fei Shao @ 2023-11-13 12:26 UTC (permalink / raw)
To: Hans Verkuil, AngeloGioacchino Del Regno
Cc: Fei Shao, Andrew-CT Chen, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, Yunfei Dong,
linux-arm-kernel, linux-kernel, linux-media, linux-mediatek
It's unclear why only mem->size has local copies without particular
usage in mtk_vcodec_mem_alloc() and mtk_vcodec_mem_free(), and they
seem removable.
Drop them to make the code visually consistent, and update printk format
identifier accordingly.
Signed-off-by: Fei Shao <fshao@chromium.org>
---
.../mediatek/vcodec/common/mtk_vcodec_util.c | 22 +++++++++----------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index ea8c35c0e667..23bea2702c9a 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -49,7 +49,6 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
{
enum mtk_instance_type inst_type = *((unsigned int *)priv);
struct platform_device *plat_dev;
- unsigned long size = mem->size;
int id;
if (inst_type == MTK_INST_ENCODER) {
@@ -64,15 +63,15 @@ int mtk_vcodec_mem_alloc(void *priv, struct mtk_vcodec_mem *mem)
id = dec_ctx->id;
}
- mem->va = dma_alloc_coherent(&plat_dev->dev, size, &mem->dma_addr, GFP_KERNEL);
+ mem->va = dma_alloc_coherent(&plat_dev->dev, mem->size, &mem->dma_addr, GFP_KERNEL);
if (!mem->va) {
- mtk_v4l2_err(plat_dev, "%s dma_alloc size=%ld failed!",
- __func__, size);
+ mtk_v4l2_err(plat_dev, "%s dma_alloc size=0x%zx failed!",
+ __func__, mem->size);
return -ENOMEM;
}
- mtk_v4l2_debug(plat_dev, 3, "[%d] - va = %p dma = 0x%lx size = 0x%lx", id, mem->va,
- (unsigned long)mem->dma_addr, size);
+ mtk_v4l2_debug(plat_dev, 3, "[%d] - va = %p dma = 0x%lx size = 0x%zx", id, mem->va,
+ (unsigned long)mem->dma_addr, mem->size);
return 0;
}
@@ -82,7 +81,6 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
{
enum mtk_instance_type inst_type = *((unsigned int *)priv);
struct platform_device *plat_dev;
- unsigned long size = mem->size;
int id;
if (inst_type == MTK_INST_ENCODER) {
@@ -98,15 +96,15 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
}
if (!mem->va) {
- mtk_v4l2_err(plat_dev, "%s dma_free size=%ld failed!",
- __func__, size);
+ mtk_v4l2_err(plat_dev, "%s dma_free size=0x%zx failed!",
+ __func__, mem->size);
return;
}
- mtk_v4l2_debug(plat_dev, 3, "[%d] - va = %p dma = 0x%lx size = 0x%lx", id, mem->va,
- (unsigned long)mem->dma_addr, size);
+ mtk_v4l2_debug(plat_dev, 3, "[%d] - va = %p dma = 0x%lx size = 0x%zx", id, mem->va,
+ (unsigned long)mem->dma_addr, mem->size);
- dma_free_coherent(&plat_dev->dev, size, mem->va, mem->dma_addr);
+ dma_free_coherent(&plat_dev->dev, mem->size, mem->va, mem->dma_addr);
mem->va = NULL;
mem->dma_addr = 0;
mem->size = 0;
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria
2023-11-13 12:26 [PATCH 0/4] Improvement around mtk_vcodec_mem_free() logging and usage Fei Shao
2023-11-13 12:26 ` [PATCH 1/4] media: mediatek: vcodec: Replace dev_name in error string Fei Shao
2023-11-13 12:26 ` [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable Fei Shao
@ 2023-11-13 12:26 ` Fei Shao
2023-12-06 10:19 ` AngeloGioacchino Del Regno
2023-11-13 12:26 ` [PATCH 4/4] media: mediatek: vcodec: Drop VA check against mtk_vcodec_mem_free() Fei Shao
3 siblings, 1 reply; 13+ messages in thread
From: Fei Shao @ 2023-11-13 12:26 UTC (permalink / raw)
To: Hans Verkuil, AngeloGioacchino Del Regno
Cc: Fei Shao, Andrew-CT Chen, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, Yunfei Dong,
linux-arm-kernel, linux-kernel, linux-media, linux-mediatek
mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
never been allocated or was freed properly in the previous call. That
makes log confusing.
Update the error path to print log only when the caller attempts to free
nonzero-size buffer with VA being NULL, which indicates something indeed
went wrong.
This brings another benefit that the callers no more need to check
mem->va explicitly to avoid the error, which can make the code more
compact and neat.
Signed-off-by: Fei Shao <fshao@chromium.org>
---
.../media/platform/mediatek/vcodec/common/mtk_vcodec_util.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
index 23bea2702c9a..5eb267decfb6 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_util.c
@@ -96,8 +96,9 @@ void mtk_vcodec_mem_free(void *priv, struct mtk_vcodec_mem *mem)
}
if (!mem->va) {
- mtk_v4l2_err(plat_dev, "%s dma_free size=0x%zx failed!",
- __func__, mem->size);
+ if (mem->size)
+ mtk_v4l2_err(plat_dev, "%s VA is NULL but size = 0x%zx",
+ __func__, mem->size);
return;
}
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 4/4] media: mediatek: vcodec: Drop VA check against mtk_vcodec_mem_free()
2023-11-13 12:26 [PATCH 0/4] Improvement around mtk_vcodec_mem_free() logging and usage Fei Shao
` (2 preceding siblings ...)
2023-11-13 12:26 ` [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria Fei Shao
@ 2023-11-13 12:26 ` Fei Shao
2023-12-06 10:19 ` AngeloGioacchino Del Regno
3 siblings, 1 reply; 13+ messages in thread
From: Fei Shao @ 2023-11-13 12:26 UTC (permalink / raw)
To: Hans Verkuil, AngeloGioacchino Del Regno
Cc: Fei Shao, Andrew-CT Chen, Dan Carpenter, Irui Wang,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, Xiaoyong Lu,
Yunfei Dong, linux-arm-kernel, linux-kernel, linux-media,
linux-mediatek
Now mtk_vcodec_mem_free() handles the VA-is-NULL case without generating
excess error log, so we don't need to check that every time before using
it in the driver.
Remove all the unnecessary if branches against mtk_vcodec_mem_free().
Signed-off-by: Fei Shao <fshao@chromium.org>
---
.../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 18 ++++--------
.../vcodec/decoder/vdec/vdec_h264_if.c | 9 ++----
.../vcodec/decoder/vdec/vdec_h264_req_if.c | 9 ++----
.../decoder/vdec/vdec_h264_req_multi_if.c | 6 ++--
.../decoder/vdec/vdec_hevc_req_multi_if.c | 9 ++----
.../vcodec/decoder/vdec/vdec_vp8_if.c | 4 +--
.../vcodec/decoder/vdec/vdec_vp8_req_if.c | 12 +++-----
.../vcodec/decoder/vdec/vdec_vp9_if.c | 15 ++++------
.../vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 29 +++++++------------
.../mediatek/vcodec/decoder/vdec_msg_queue.c | 15 ++++------
10 files changed, 43 insertions(+), 83 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
index 2b6a5adbc419..cd3a85cd4a98 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
@@ -783,8 +783,7 @@ static int vdec_av1_slice_init_cdf_table(struct vdec_av1_slice_instance *instanc
mtk_vdec_debug(ctx, "map cdf table to 0x%p\n", remote_cdf_table);
- if (instance->cdf_table.va)
- mtk_vcodec_mem_free(ctx, &instance->cdf_table);
+ mtk_vcodec_mem_free(ctx, &instance->cdf_table);
instance->cdf_table.size = vsi->cdf_table_size;
ret = mtk_vcodec_mem_alloc(ctx, &instance->cdf_table);
@@ -814,8 +813,7 @@ static int vdec_av1_slice_init_iq_table(struct vdec_av1_slice_instance *instance
mtk_vdec_debug(ctx, "map iq table to 0x%p\n", remote_iq_table);
- if (instance->iq_table.va)
- mtk_vcodec_mem_free(ctx, &instance->iq_table);
+ mtk_vcodec_mem_free(ctx, &instance->iq_table);
instance->iq_table.size = vsi->iq_table_size;
ret = mtk_vcodec_mem_alloc(ctx, &instance->iq_table);
@@ -970,22 +968,19 @@ static int vdec_av1_slice_alloc_working_buffer(struct vdec_av1_slice_instance *i
max_sb_h = DIV_ROUND_UP(max_h, 128);
for (i = 0; i < AV1_MAX_FRAME_BUF_COUNT; i++) {
- if (instance->mv[i].va)
- mtk_vcodec_mem_free(ctx, &instance->mv[i]);
+ mtk_vcodec_mem_free(ctx, &instance->mv[i]);
instance->mv[i].size = max_sb_w * max_sb_h * SZ_1K;
ret = mtk_vcodec_mem_alloc(ctx, &instance->mv[i]);
if (ret)
goto err;
- if (instance->seg[i].va)
- mtk_vcodec_mem_free(ctx, &instance->seg[i]);
+ mtk_vcodec_mem_free(ctx, &instance->seg[i]);
instance->seg[i].size = max_sb_w * max_sb_h * 512;
ret = mtk_vcodec_mem_alloc(ctx, &instance->seg[i]);
if (ret)
goto err;
- if (instance->cdf[i].va)
- mtk_vcodec_mem_free(ctx, &instance->cdf[i]);
+ mtk_vcodec_mem_free(ctx, &instance->cdf[i]);
instance->cdf[i].size = AV1_CDF_TABLE_BUFFER_SIZE;
ret = mtk_vcodec_mem_alloc(ctx, &instance->cdf[i]);
if (ret)
@@ -1001,8 +996,7 @@ static int vdec_av1_slice_alloc_working_buffer(struct vdec_av1_slice_instance *i
vsi->cdf_tmp.size = instance->cdf_temp.size;
}
- if (instance->tile.va)
- mtk_vcodec_mem_free(ctx, &instance->tile);
+ mtk_vcodec_mem_free(ctx, &instance->tile);
instance->tile.size = AV1_TILE_BUF_SIZE * V4L2_AV1_MAX_TILE_COUNT;
ret = mtk_vcodec_mem_alloc(ctx, &instance->tile);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_if.c
index bf7dffe60d07..16f8fd407e09 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_if.c
@@ -157,8 +157,7 @@ static void free_predication_buf(struct vdec_h264_inst *inst)
inst->vsi->pred_buf_dma = 0;
mem = &inst->pred_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
}
static int alloc_mv_buf(struct vdec_h264_inst *inst, struct vdec_pic_info *pic)
@@ -170,8 +169,7 @@ static int alloc_mv_buf(struct vdec_h264_inst *inst, struct vdec_pic_info *pic)
for (i = 0; i < H264_MAX_FB_NUM; i++) {
mem = &inst->mv_buf[i];
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
mem->size = buf_sz;
err = mtk_vcodec_mem_alloc(inst->ctx, mem);
if (err) {
@@ -192,8 +190,7 @@ static void free_mv_buf(struct vdec_h264_inst *inst)
for (i = 0; i < H264_MAX_FB_NUM; i++) {
inst->vsi->mv_buf_dma[i] = 0;
mem = &inst->mv_buf[i];
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
}
}
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_if.c
index 5600f1df653d..6793fcc0fcc8 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_if.c
@@ -174,8 +174,7 @@ static void free_predication_buf(struct vdec_h264_slice_inst *inst)
struct mtk_vcodec_mem *mem = &inst->pred_buf;
inst->vsi_ctx.pred_buf_dma = 0;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
}
static int alloc_mv_buf(struct vdec_h264_slice_inst *inst,
@@ -189,8 +188,7 @@ static int alloc_mv_buf(struct vdec_h264_slice_inst *inst,
mtk_v4l2_vdec_dbg(3, inst->ctx, "size = 0x%x", buf_sz);
for (i = 0; i < H264_MAX_MV_NUM; i++) {
mem = &inst->mv_buf[i];
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
mem->size = buf_sz;
err = mtk_vcodec_mem_alloc(inst->ctx, mem);
if (err) {
@@ -211,8 +209,7 @@ static void free_mv_buf(struct vdec_h264_slice_inst *inst)
for (i = 0; i < H264_MAX_MV_NUM; i++) {
inst->vsi_ctx.mv_buf_dma[i] = 0;
mem = &inst->mv_buf[i];
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
}
}
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
index 0e741e0dc8ba..81d21ddf5ced 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_multi_if.c
@@ -316,8 +316,7 @@ static int vdec_h264_slice_alloc_mv_buf(struct vdec_h264_slice_inst *inst,
mtk_v4l2_vdec_dbg(3, inst->ctx, "size = 0x%x", buf_sz);
for (i = 0; i < H264_MAX_MV_NUM; i++) {
mem = &inst->mv_buf[i];
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
mem->size = buf_sz;
err = mtk_vcodec_mem_alloc(inst->ctx, mem);
if (err) {
@@ -336,8 +335,7 @@ static void vdec_h264_slice_free_mv_buf(struct vdec_h264_slice_inst *inst)
for (i = 0; i < H264_MAX_MV_NUM; i++) {
mem = &inst->mv_buf[i];
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
}
}
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_hevc_req_multi_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_hevc_req_multi_if.c
index 06ed47df693b..17c07feedb56 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_hevc_req_multi_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_hevc_req_multi_if.c
@@ -651,8 +651,7 @@ static int vdec_hevc_slice_alloc_mv_buf(struct vdec_hevc_slice_inst *inst,
mtk_v4l2_vdec_dbg(3, inst->ctx, "allocate mv buffer size = 0x%x", buf_sz);
for (i = 0; i < HEVC_MAX_MV_NUM; i++) {
mem = &inst->mv_buf[i];
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
mem->size = buf_sz;
err = mtk_vcodec_mem_alloc(inst->ctx, mem);
if (err) {
@@ -671,8 +670,7 @@ static void vdec_hevc_slice_free_mv_buf(struct vdec_hevc_slice_inst *inst)
for (i = 0; i < HEVC_MAX_MV_NUM; i++) {
mem = &inst->mv_buf[i];
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
}
}
@@ -913,8 +911,7 @@ static void vdec_hevc_slice_deinit(void *h_vdec)
vdec_hevc_slice_free_mv_buf(inst);
mem = &inst->wrap_addr;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
vdec_msg_queue_deinit(&inst->ctx->msg_queue, inst->ctx);
kfree(inst);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
index 19407f9bc773..7bcc3566371c 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
@@ -379,9 +379,7 @@ static void free_working_buf(struct vdec_vp8_inst *inst)
{
struct mtk_vcodec_mem *mem = &inst->working_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
-
+ mtk_vcodec_mem_free(inst->ctx, mem);
inst->vsi->dec.working_buf_dma = 0;
}
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_req_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_req_if.c
index f64b21c07169..9a2710104a16 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_req_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_req_if.c
@@ -192,23 +192,19 @@ static void vdec_vp8_slice_free_working_buf(struct vdec_vp8_slice_inst *inst)
struct mtk_vcodec_mem *mem;
mem = &inst->seg_id_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
inst->vsi->dec.seg_id_buf_dma = 0;
mem = &inst->wrap_y_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
inst->vsi->dec.wrap_y_dma = 0;
mem = &inst->wrap_c_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
inst->vsi->dec.wrap_c_dma = 0;
mem = &inst->vld_wrapper_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
inst->vsi->dec.vld_wrapper_dma = 0;
}
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_if.c
index 55355fa70090..5def2d228fa3 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_if.c
@@ -387,8 +387,7 @@ static bool vp9_alloc_work_buf(struct vdec_vp9_inst *inst)
vsi->pic_h, vsi->buf_w, vsi->buf_h);
mem = &inst->mv_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
mem->size = ((vsi->buf_w / 64) *
(vsi->buf_h / 64) + 2) * 36 * 16;
@@ -405,8 +404,7 @@ static bool vp9_alloc_work_buf(struct vdec_vp9_inst *inst)
mem = &inst->seg_id_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
mem->size = VP9_SEG_ID_SZ;
result = mtk_vcodec_mem_alloc(inst->ctx, mem);
@@ -567,8 +565,7 @@ static void vp9_free_inst(struct vdec_vp9_inst *inst)
struct mtk_vcodec_mem mem;
mem = inst->mem;
- if (mem.va)
- mtk_vcodec_mem_free(inst->ctx, &mem);
+ mtk_vcodec_mem_free(inst->ctx, &mem);
}
static bool vp9_decode_end_proc(struct vdec_vp9_inst *inst)
@@ -761,12 +758,10 @@ static void vdec_vp9_deinit(void *h_vdec)
mtk_vdec_err(inst->ctx, "vpu_dec_deinit failed");
mem = &inst->mv_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
mem = &inst->seg_id_buf;
- if (mem->va)
- mtk_vcodec_mem_free(inst->ctx, mem);
+ mtk_vcodec_mem_free(inst->ctx, mem);
vp9_free_all_sf_ref_fb(inst);
vp9_free_inst(inst);
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
index e393e3e668f8..b885730826fb 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
@@ -590,8 +590,7 @@ static int vdec_vp9_slice_alloc_working_buffer(struct vdec_vp9_slice_instance *i
size = (max_sb_w * max_sb_h + 2) * 576;
for (i = 0; i < 2; i++) {
- if (instance->mv[i].va)
- mtk_vcodec_mem_free(ctx, &instance->mv[i]);
+ mtk_vcodec_mem_free(ctx, &instance->mv[i]);
instance->mv[i].size = size;
if (mtk_vcodec_mem_alloc(ctx, &instance->mv[i]))
goto err;
@@ -599,8 +598,7 @@ static int vdec_vp9_slice_alloc_working_buffer(struct vdec_vp9_slice_instance *i
size = (max_sb_w * max_sb_h * 32) + 256;
for (i = 0; i < 2; i++) {
- if (instance->seg[i].va)
- mtk_vcodec_mem_free(ctx, &instance->seg[i]);
+ mtk_vcodec_mem_free(ctx, &instance->seg[i]);
instance->seg[i].size = size;
if (mtk_vcodec_mem_alloc(ctx, &instance->seg[i]))
goto err;
@@ -637,20 +635,15 @@ static void vdec_vp9_slice_free_working_buffer(struct vdec_vp9_slice_instance *i
struct mtk_vcodec_dec_ctx *ctx = instance->ctx;
int i;
- for (i = 0; i < ARRAY_SIZE(instance->mv); i++) {
- if (instance->mv[i].va)
- mtk_vcodec_mem_free(ctx, &instance->mv[i]);
- }
- for (i = 0; i < ARRAY_SIZE(instance->seg); i++) {
- if (instance->seg[i].va)
- mtk_vcodec_mem_free(ctx, &instance->seg[i]);
- }
- if (instance->tile.va)
- mtk_vcodec_mem_free(ctx, &instance->tile);
- if (instance->prob.va)
- mtk_vcodec_mem_free(ctx, &instance->prob);
- if (instance->counts.va)
- mtk_vcodec_mem_free(ctx, &instance->counts);
+ for (i = 0; i < ARRAY_SIZE(instance->mv); i++)
+ mtk_vcodec_mem_free(ctx, &instance->mv[i]);
+
+ for (i = 0; i < ARRAY_SIZE(instance->seg); i++)
+ mtk_vcodec_mem_free(ctx, &instance->seg[i]);
+
+ mtk_vcodec_mem_free(ctx, &instance->tile);
+ mtk_vcodec_mem_free(ctx, &instance->prob);
+ mtk_vcodec_mem_free(ctx, &instance->counts);
instance->level = VP9_RES_NONE;
}
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
index f283c4703dc6..7b426bb8b1de 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
@@ -206,26 +206,21 @@ void vdec_msg_queue_deinit(struct vdec_msg_queue *msg_queue,
int i;
mem = &msg_queue->wdma_addr;
- if (mem->va)
- mtk_vcodec_mem_free(ctx, mem);
+ mtk_vcodec_mem_free(ctx, mem);
for (i = 0; i < NUM_BUFFER_COUNT; i++) {
lat_buf = &msg_queue->lat_buf[i];
mem = &lat_buf->wdma_err_addr;
- if (mem->va)
- mtk_vcodec_mem_free(ctx, mem);
+ mtk_vcodec_mem_free(ctx, mem);
mem = &lat_buf->slice_bc_addr;
- if (mem->va)
- mtk_vcodec_mem_free(ctx, mem);
+ mtk_vcodec_mem_free(ctx, mem);
mem = &lat_buf->rd_mv_addr;
- if (mem->va)
- mtk_vcodec_mem_free(ctx, mem);
+ mtk_vcodec_mem_free(ctx, mem);
mem = &lat_buf->tile_addr;
- if (mem->va)
- mtk_vcodec_mem_free(ctx, mem);
+ mtk_vcodec_mem_free(ctx, mem);
kfree(lat_buf->private_data);
lat_buf->private_data = NULL;
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 4/4] media: mediatek: vcodec: Drop VA check against mtk_vcodec_mem_free()
2023-11-13 12:26 ` [PATCH 4/4] media: mediatek: vcodec: Drop VA check against mtk_vcodec_mem_free() Fei Shao
@ 2023-12-06 10:19 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 13+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-12-06 10:19 UTC (permalink / raw)
To: Fei Shao, Hans Verkuil
Cc: Andrew-CT Chen, Dan Carpenter, Irui Wang, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, Xiaoyong Lu,
Yunfei Dong, linux-arm-kernel, linux-kernel, linux-media,
linux-mediatek
Il 13/11/23 13:26, Fei Shao ha scritto:
> Now mtk_vcodec_mem_free() handles the VA-is-NULL case without generating
> excess error log, so we don't need to check that every time before using
> it in the driver.
>
> Remove all the unnecessary if branches against mtk_vcodec_mem_free().
>
> Signed-off-by: Fei Shao <fshao@chromium.org>
For the reasons explained in patch [3/4], I'd prefer to keep those checks.
Cheers,
Angelo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria
2023-11-13 12:26 ` [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria Fei Shao
@ 2023-12-06 10:19 ` AngeloGioacchino Del Regno
2023-12-07 11:17 ` Fei Shao
0 siblings, 1 reply; 13+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-12-06 10:19 UTC (permalink / raw)
To: Fei Shao, Hans Verkuil
Cc: Andrew-CT Chen, Matthias Brugger, Mauro Carvalho Chehab,
Nicolas Dufresne, Nícolas F. R. A. Prado, Tiffany Lin,
Yunfei Dong, linux-arm-kernel, linux-kernel, linux-media,
linux-mediatek
Il 13/11/23 13:26, Fei Shao ha scritto:
> mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
> never been allocated or was freed properly in the previous call. That
> makes log confusing.
>
> Update the error path to print log only when the caller attempts to free
> nonzero-size buffer with VA being NULL, which indicates something indeed
> went wrong.
>
> This brings another benefit that the callers no more need to check
> mem->va explicitly to avoid the error, which can make the code more
> compact and neat.
>
> Signed-off-by: Fei Shao <fshao@chromium.org>
I think that this error is supposed to catch two issues in one:
- We're called to free no memory (something that does make no sense),
this may happen for example when calling xxx_free() twice, and it
is a mistake that *must* be fixed;
- We're failing to free memory for real (which you covered)
....that said, I think that if you want to clarify the error messages
in this function, it should look something like this:
if (!mem->va) {
mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
if (mem->size)
mtk_v4l2_err(plat_dev, "Failed to free %lu bytes", mem->size);
return;
}
Cheers,
Angelo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable
2023-11-13 12:26 ` [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable Fei Shao
@ 2023-12-06 10:19 ` AngeloGioacchino Del Regno
2023-12-07 11:14 ` Fei Shao
0 siblings, 1 reply; 13+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-12-06 10:19 UTC (permalink / raw)
To: Fei Shao, Hans Verkuil
Cc: Andrew-CT Chen, Matthias Brugger, Mauro Carvalho Chehab,
Nicolas Dufresne, Nícolas F. R. A. Prado, Tiffany Lin,
Yunfei Dong, linux-arm-kernel, linux-kernel, linux-media,
linux-mediatek
Il 13/11/23 13:26, Fei Shao ha scritto:
> It's unclear why only mem->size has local copies without particular
> usage in mtk_vcodec_mem_alloc() and mtk_vcodec_mem_free(), and they
> seem removable.
>
> Drop them to make the code visually consistent, and update printk format
> identifier accordingly.
>
> Signed-off-by: Fei Shao <fshao@chromium.org>
That's probably just about personal preferences, as mem->size is not expected
to change during the flow of those functions.
That said, as much as you, I prefer not having this local copy as it's using
(a very small amount of) memory for no real reason anyway, so:
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/4] media: mediatek: vcodec: Replace dev_name in error string
2023-11-13 12:26 ` [PATCH 1/4] media: mediatek: vcodec: Replace dev_name in error string Fei Shao
@ 2023-12-06 10:19 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 13+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-12-06 10:19 UTC (permalink / raw)
To: Fei Shao, Hans Verkuil
Cc: Andrew-CT Chen, Matthias Brugger, Mauro Carvalho Chehab,
Nicolas Dufresne, Nícolas F. R. A. Prado, Tiffany Lin,
Yunfei Dong, linux-arm-kernel, linux-kernel, linux-media,
linux-mediatek
Il 13/11/23 13:26, Fei Shao ha scritto:
> mtk_v4l2_err() already uses dev_err(), so don't print the device name
> again. Print function name instead.
>
> Signed-off-by: Fei Shao <fshao@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable
2023-12-06 10:19 ` AngeloGioacchino Del Regno
@ 2023-12-07 11:14 ` Fei Shao
0 siblings, 0 replies; 13+ messages in thread
From: Fei Shao @ 2023-12-07 11:14 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Hans Verkuil, Andrew-CT Chen, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, Yunfei Dong,
linux-arm-kernel, linux-kernel, linux-media, linux-mediatek
Hi Angelo,
On Wed, Dec 6, 2023 at 6:19 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 13/11/23 13:26, Fei Shao ha scritto:
> > It's unclear why only mem->size has local copies without particular
> > usage in mtk_vcodec_mem_alloc() and mtk_vcodec_mem_free(), and they
> > seem removable.
> >
> > Drop them to make the code visually consistent, and update printk format
> > identifier accordingly.
> >
> > Signed-off-by: Fei Shao <fshao@chromium.org>
>
> That's probably just about personal preferences, as mem->size is not expected
> to change during the flow of those functions.
>
> That said, as much as you, I prefer not having this local copy as it's using
> (a very small amount of) memory for no real reason anyway, so:
Yes, and I think I should have mentioned this in the commit message...
I'll revise that in the next version.
Thanks,
Fei
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria
2023-12-06 10:19 ` AngeloGioacchino Del Regno
@ 2023-12-07 11:17 ` Fei Shao
2023-12-07 12:54 ` AngeloGioacchino Del Regno
0 siblings, 1 reply; 13+ messages in thread
From: Fei Shao @ 2023-12-07 11:17 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Hans Verkuil, Andrew-CT Chen, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, Yunfei Dong,
linux-arm-kernel, linux-kernel, linux-media, linux-mediatek
Hi Angelo,
On Wed, Dec 6, 2023 at 6:19 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 13/11/23 13:26, Fei Shao ha scritto:
> > mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
> > never been allocated or was freed properly in the previous call. That
> > makes log confusing.
> >
> > Update the error path to print log only when the caller attempts to free
> > nonzero-size buffer with VA being NULL, which indicates something indeed
> > went wrong.
> >
> > This brings another benefit that the callers no more need to check
> > mem->va explicitly to avoid the error, which can make the code more
> > compact and neat.
> >
> > Signed-off-by: Fei Shao <fshao@chromium.org>
>
> I think that this error is supposed to catch two issues in one:
> - We're called to free no memory (something that does make no sense),
> this may happen for example when calling xxx_free() twice, and it
> is a mistake that *must* be fixed;
When I made the change, I was thinking of kfree() that doesn't warn
against a NULL pointer.
I imagine mtk_vcodec_mem_free() calls with NULL VA and mem size 0
probably have the similar nuance (if the buffer exists, free it; never
mind otherwise), but I could have missed some important differences
specific to the MTK vcodec driver.
Looking at the mtk_vcodec_mem_free() usages, almost every one of those
checks VA beforehand, but nothing else - they don't warn or do
anything special when they encounter a NULL VA, and they should if
that's a concern.
Some even don't check at all (and I think that's why I ended up seeing
the errors mentioned in the cover letter). As for that, I think
there's nothing else we can fix except prepending "if (mem->va)".
So from all this, I feel perhaps we don't need to worry much about
those NULL VA, and we can further remove the checks (or at least move
it into mtk_vcodec_mem_free()) to trim the lines in the driver. That's
the reason for patch [4/4].
Not sure if that makes sense to you.
> - We're failing to free memory for real (which you covered)
>
> ....that said, I think that if you want to clarify the error messages
> in this function, it should look something like this:
>
> if (!mem->va) {
> mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
> if (mem->size)
> mtk_v4l2_err(plat_dev, "Failed to free %lu bytes", mem->size);
> return;
> }
Sure, I can revise the patch with this, but I also want to make sure
if the NULL VA print needs to be an error.
If you still think it should, I guess I'll drop the current patch
[4/4] and instead add the check before every mtk_vcodec_mem_free()
calls. This should also work for the issue I want to address in the
first place.
And thanks for the review. :)
Regards,
Fei
> Cheers,
> Angelo
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria
2023-12-07 11:17 ` Fei Shao
@ 2023-12-07 12:54 ` AngeloGioacchino Del Regno
2023-12-08 4:22 ` Fei Shao
0 siblings, 1 reply; 13+ messages in thread
From: AngeloGioacchino Del Regno @ 2023-12-07 12:54 UTC (permalink / raw)
To: Fei Shao, Yunfei Dong
Cc: Hans Verkuil, Andrew-CT Chen, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, linux-arm-kernel,
linux-kernel, linux-media, linux-mediatek
Il 07/12/23 12:17, Fei Shao ha scritto:
> Hi Angelo,
>
> On Wed, Dec 6, 2023 at 6:19 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> Il 13/11/23 13:26, Fei Shao ha scritto:
>>> mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
>>> never been allocated or was freed properly in the previous call. That
>>> makes log confusing.
>>>
>>> Update the error path to print log only when the caller attempts to free
>>> nonzero-size buffer with VA being NULL, which indicates something indeed
>>> went wrong.
>>>
>>> This brings another benefit that the callers no more need to check
>>> mem->va explicitly to avoid the error, which can make the code more
>>> compact and neat.
>>>
>>> Signed-off-by: Fei Shao <fshao@chromium.org>
>>
>> I think that this error is supposed to catch two issues in one:
>> - We're called to free no memory (something that does make no sense),
>> this may happen for example when calling xxx_free() twice, and it
>> is a mistake that *must* be fixed;
> When I made the change, I was thinking of kfree() that doesn't warn
> against a NULL pointer.
> I imagine mtk_vcodec_mem_free() calls with NULL VA and mem size 0
> probably have the similar nuance (if the buffer exists, free it; never
> mind otherwise), but I could have missed some important differences
> specific to the MTK vcodec driver.
>
> Looking at the mtk_vcodec_mem_free() usages, almost every one of those
> checks VA beforehand, but nothing else - they don't warn or do
> anything special when they encounter a NULL VA, and they should if
> that's a concern.
> Some even don't check at all (and I think that's why I ended up seeing
> the errors mentioned in the cover letter). As for that, I think
> there's nothing else we can fix except prepending "if (mem->va)".
> So from all this, I feel perhaps we don't need to worry much about
> those NULL VA, and we can further remove the checks (or at least move
> it into mtk_vcodec_mem_free()) to trim the lines in the driver. That's
> the reason for patch [4/4].
>
> Not sure if that makes sense to you.
What you say does make sense - and a lot - but still, I think that freeing
a NULL VA (= freeing nothing) is something that shouldn't happen...
>
>> - We're failing to free memory for real (which you covered)
>>
>> ....that said, I think that if you want to clarify the error messages
>> in this function, it should look something like this:
>>
>> if (!mem->va) {
>> mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
>> if (mem->size)
>> mtk_v4l2_err(plat_dev, "Failed to free %lu bytes", mem->size);
>> return;
>> }
> Sure, I can revise the patch with this, but I also want to make sure
> if the NULL VA print needs to be an error.
> If you still think it should, I guess I'll drop the current patch
> [4/4] and instead add the check before every mtk_vcodec_mem_free()
> calls. This should also work for the issue I want to address in the
> first place.
>
... because if you notice, some of the calls to mtk_vcodec_mem_free() are not
checked with `if (something->va)` beforehand, so I think that those are cases
in which freeing with a NULL VA would actually be an indication of something
going wrong and/or not as expected anyway (checking beforehand = error won't
get printed from mtk_vcodec_mem_free(), not checking = print error if va==NULL)
It's an easy check:
cd drivers/media/platform/mediatek/vcodec
grep -rb1 mtk_vcodec_mem_free
P.S.: h264_if, av1_req_lat :-)
That's why I think that you should drop your [4/4] - unless MediaTek comes in
stating that the missed checks are something unintended, and that every instance
of VA==NULL should print an error.
I honestly wouldn't be surprised if they did so, because anyway this occurs only
in two decoders...
Regards,
Angelo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria
2023-12-07 12:54 ` AngeloGioacchino Del Regno
@ 2023-12-08 4:22 ` Fei Shao
0 siblings, 0 replies; 13+ messages in thread
From: Fei Shao @ 2023-12-08 4:22 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Yunfei Dong, Hans Verkuil, Andrew-CT Chen, Matthias Brugger,
Mauro Carvalho Chehab, Nicolas Dufresne,
Nícolas F. R. A. Prado, Tiffany Lin, linux-arm-kernel,
linux-kernel, linux-media, linux-mediatek
On Thu, Dec 7, 2023 at 8:55 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 07/12/23 12:17, Fei Shao ha scritto:
> > Hi Angelo,
> >
> > On Wed, Dec 6, 2023 at 6:19 PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com> wrote:
> >>
> >> Il 13/11/23 13:26, Fei Shao ha scritto:
> >>> mtk_vcodec_mem_free() shouldn't print error if the target DMA buffer has
> >>> never been allocated or was freed properly in the previous call. That
> >>> makes log confusing.
> >>>
> >>> Update the error path to print log only when the caller attempts to free
> >>> nonzero-size buffer with VA being NULL, which indicates something indeed
> >>> went wrong.
> >>>
> >>> This brings another benefit that the callers no more need to check
> >>> mem->va explicitly to avoid the error, which can make the code more
> >>> compact and neat.
> >>>
> >>> Signed-off-by: Fei Shao <fshao@chromium.org>
> >>
> >> I think that this error is supposed to catch two issues in one:
> >> - We're called to free no memory (something that does make no sense),
> >> this may happen for example when calling xxx_free() twice, and it
> >> is a mistake that *must* be fixed;
> > When I made the change, I was thinking of kfree() that doesn't warn
> > against a NULL pointer.
> > I imagine mtk_vcodec_mem_free() calls with NULL VA and mem size 0
> > probably have the similar nuance (if the buffer exists, free it; never
> > mind otherwise), but I could have missed some important differences
> > specific to the MTK vcodec driver.
> >
> > Looking at the mtk_vcodec_mem_free() usages, almost every one of those
> > checks VA beforehand, but nothing else - they don't warn or do
> > anything special when they encounter a NULL VA, and they should if
> > that's a concern.
> > Some even don't check at all (and I think that's why I ended up seeing
> > the errors mentioned in the cover letter). As for that, I think
> > there's nothing else we can fix except prepending "if (mem->va)".
> > So from all this, I feel perhaps we don't need to worry much about
> > those NULL VA, and we can further remove the checks (or at least move
> > it into mtk_vcodec_mem_free()) to trim the lines in the driver. That's
> > the reason for patch [4/4].
> >
> > Not sure if that makes sense to you.
>
> What you say does make sense - and a lot - but still, I think that freeing
> a NULL VA (= freeing nothing) is something that shouldn't happen...
>
> >
> >> - We're failing to free memory for real (which you covered)
> >>
> >> ....that said, I think that if you want to clarify the error messages
> >> in this function, it should look something like this:
> >>
> >> if (!mem->va) {
> >> mtk_v4l2_err(plat_dev, "%s: Tried to free a NULL VA", __func__);
> >> if (mem->size)
> >> mtk_v4l2_err(plat_dev, "Failed to free %lu bytes", mem->size);
> >> return;
> >> }
> > Sure, I can revise the patch with this, but I also want to make sure
> > if the NULL VA print needs to be an error.
> > If you still think it should, I guess I'll drop the current patch
> > [4/4] and instead add the check before every mtk_vcodec_mem_free()
> > calls. This should also work for the issue I want to address in the
> > first place.
> >
>
> ... because if you notice, some of the calls to mtk_vcodec_mem_free() are not
> checked with `if (something->va)` beforehand, so I think that those are cases
> in which freeing with a NULL VA would actually be an indication of something
> going wrong and/or not as expected anyway (checking beforehand = error won't
> get printed from mtk_vcodec_mem_free(), not checking = print error if va==NULL)
>
> It's an easy check:
> cd drivers/media/platform/mediatek/vcodec
> grep -rb1 mtk_vcodec_mem_free
>
> P.S.: h264_if, av1_req_lat :-)
Yes, these are exactly what I wanted to imply in ">> Some even don't
check at all", and I should have pointed them out to avoid
ambiguity...
And I understand your concern. Presuming the NULL VA case is and will
always be safe to ignore can be too assertive, and getting explicit
error logs is always better than lurking bugs.
>
> That's why I think that you should drop your [4/4] - unless MediaTek comes in
> stating that the missed checks are something unintended, and that every instance
> of VA==NULL should print an error.
>
> I honestly wouldn't be surprised if they did so, because anyway this occurs only
> in two decoders...
Agree, it would be nice if Yunfei can share some thoughts here, or I
can reach out to him through other channels for alignment first, and
adjust this series based on the response.
The h264_if part was written a while ago (2016) and the av1_req_lat
part is relatively new (mid 2023), I hope it won't be too hard to
reach a conclusion for those.
Regards,
Fei
>
> Regards,
> Angelo
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-12-08 4:23 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-13 12:26 [PATCH 0/4] Improvement around mtk_vcodec_mem_free() logging and usage Fei Shao
2023-11-13 12:26 ` [PATCH 1/4] media: mediatek: vcodec: Replace dev_name in error string Fei Shao
2023-12-06 10:19 ` AngeloGioacchino Del Regno
2023-11-13 12:26 ` [PATCH 2/4] media: mediatek: vcodec: Drop unnecessary variable Fei Shao
2023-12-06 10:19 ` AngeloGioacchino Del Regno
2023-12-07 11:14 ` Fei Shao
2023-11-13 12:26 ` [PATCH 3/4] media: mediatek: vcodec: Fix mtk_vcodec_mem_free() error log criteria Fei Shao
2023-12-06 10:19 ` AngeloGioacchino Del Regno
2023-12-07 11:17 ` Fei Shao
2023-12-07 12:54 ` AngeloGioacchino Del Regno
2023-12-08 4:22 ` Fei Shao
2023-11-13 12:26 ` [PATCH 4/4] media: mediatek: vcodec: Drop VA check against mtk_vcodec_mem_free() Fei Shao
2023-12-06 10:19 ` AngeloGioacchino Del Regno
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®