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
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>
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> > >
© 2016 - 2024 Red Hat, Inc.