* [PATCH v6 4/6] media: mediatek: encoder: Add support for VCP encode process
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
Adapt the encoder driver to support VCP firmware interface.
Set the encoder driver firmware type to 'VCP'.
Allocate RC buffers using the VCP device.
Send the shared memory address to VCP and map the encoder VSI address
to the CPU address space using the VCP shared memory address.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
---
.../mediatek/vcodec/common/mtk_vcodec_fw.c | 6 +++++
.../mediatek/vcodec/common/mtk_vcodec_fw.h | 1 +
.../vcodec/common/mtk_vcodec_fw_priv.h | 1 +
.../vcodec/common/mtk_vcodec_fw_vcp.c | 6 +++++
.../vcodec/encoder/mtk_vcodec_enc_drv.c | 3 +++
.../vcodec/encoder/venc/venc_common_if.c | 23 ++++++++++++++-----
.../mediatek/vcodec/encoder/venc_vpu_if.c | 14 ++++++++++-
7 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
index 0381acceda25..7a504f093bd8 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
@@ -105,3 +105,9 @@ int mtk_vcodec_fw_get_type(struct mtk_vcodec_fw *fw)
return fw->type;
}
EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_type);
+
+struct device *mtk_vcodec_fw_get_dev(struct mtk_vcodec_fw *fw)
+{
+ return fw->ops->get_fw_dev(fw);
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_dev);
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
index e7304a7dd3e0..56c26b91651e 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
@@ -43,5 +43,6 @@ int mtk_vcodec_fw_ipi_send(struct mtk_vcodec_fw *fw, int id,
int mtk_vcodec_fw_get_type(struct mtk_vcodec_fw *fw);
int mtk_vcodec_fw_get_ipi(enum mtk_vcodec_fw_type type, int hw_id);
int mtk_vcodec_fw_get_venc_ipi(enum mtk_vcodec_fw_type type);
+struct device *mtk_vcodec_fw_get_dev(struct mtk_vcodec_fw *fw);
#endif /* _MTK_VCODEC_FW_H_ */
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.h
index 0a2a9b010244..710c83c871f4 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.h
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.h
@@ -29,6 +29,7 @@ struct mtk_vcodec_fw_ops {
int (*ipi_send)(struct mtk_vcodec_fw *fw, int id, void *buf,
unsigned int len, unsigned int wait);
void (*release)(struct mtk_vcodec_fw *fw);
+ struct device *(*get_fw_dev)(struct mtk_vcodec_fw *fw);
};
#if IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VCODEC_VPU)
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
index 6b69ce44d4bb..2859fe78f67d 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
@@ -500,6 +500,11 @@ static void mtk_vcodec_vcp_release(struct mtk_vcodec_fw *fw)
}
+static struct device *mtk_vcodec_vcp_get_fw_dev(struct mtk_vcodec_fw *fw)
+{
+ return fw->vcp->vcp_device->dev;
+}
+
static const struct mtk_vcodec_fw_ops mtk_vcodec_vcp_msg = {
.load_firmware = mtk_vcodec_vcp_load_firmware,
.get_vdec_capa = mtk_vcodec_vcp_get_vdec_capa,
@@ -508,6 +513,7 @@ static const struct mtk_vcodec_fw_ops mtk_vcodec_vcp_msg = {
.ipi_register = mtk_vcodec_vcp_set_ipi_register,
.ipi_send = mtk_vcodec_vcp_ipi_send,
.release = mtk_vcodec_vcp_release,
+ .get_fw_dev = mtk_vcodec_vcp_get_fw_dev,
};
struct mtk_vcodec_fw *mtk_vcodec_fw_vcp_init(void *priv, enum mtk_vcodec_fw_use fw_use)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
index 4e4541b2fc8e..2f6ee0cd15e3 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
@@ -262,6 +262,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
} else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp",
&rproc_phandle)) {
fw_type = SCP;
+ } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vcp",
+ &rproc_phandle)) {
+ fw_type = VCP;
} else {
dev_err(&pdev->dev, "[MTK VCODEC] Could not get venc IPI device");
return -ENODEV;
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
index 050b827f0fd0..d981155aeb8c 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
@@ -480,8 +480,13 @@ static void venc_free_rc_buf(struct venc_inst *inst,
{
int i;
struct device *dev;
+ struct mtk_vcodec_fw *fw = inst->ctx->dev->fw_handler;
+
+ if (mtk_vcodec_fw_get_type(fw) == VCP)
+ dev = mtk_vcodec_fw_get_dev(fw);
+ else
+ dev = &inst->ctx->dev->plat_dev->dev;
- dev = &inst->ctx->dev->plat_dev->dev;
mtk_venc_mem_free(inst, dev, &bufs->rc_code);
for (i = 0; i < core_num; i++)
@@ -530,12 +535,18 @@ static int venc_alloc_rc_buf(struct venc_inst *inst,
struct device *dev;
void *tmp_va;
- dev = &inst->ctx->dev->plat_dev->dev;
- if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
- return -ENOMEM;
+ if (mtk_vcodec_fw_get_type(fw) == VCP) {
+ dev = mtk_vcodec_fw_get_dev(fw);
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
+ return -ENOMEM;
+ } else {
+ dev = &inst->ctx->dev->plat_dev->dev;
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
+ return -ENOMEM;
- tmp_va = mtk_vcodec_fw_map_dm_addr(fw, bufs->rc_code.pa);
- memcpy(bufs->rc_code.va, tmp_va, bufs->rc_code.size);
+ tmp_va = mtk_vcodec_fw_map_dm_addr(fw, bufs->rc_code.pa);
+ memcpy(bufs->rc_code.va, tmp_va, bufs->rc_code.size);
+ }
for (i = 0; i < core_num; i++) {
if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_info[i]))
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
index 7772b8442ebc..0f4693e04a9f 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
@@ -8,13 +8,23 @@
#include "venc_ipi_msg.h"
#include "venc_vpu_if.h"
+#define VSI_OFFSET_MASK 0x0FFFFFFF
+
static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
{
const struct venc_vpu_ipi_msg_init_comm *msg = data;
struct mtk_vcodec_fw *fw = vpu->ctx->dev->fw_handler;
+ u64 pa_start, vsi_offset;
vpu->inst_addr = msg->init_ack.vpu_inst_addr;
- vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, vpu->inst_addr);
+
+ if (mtk_vcodec_fw_get_type(fw) == VCP) {
+ pa_start = (u64)fw->vcp->iova_addr;
+ vsi_offset = (msg->vpu_vsi_addr & VSI_OFFSET_MASK) - (pa_start & VSI_OFFSET_MASK);
+ vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, ENCODER_MEM) + vsi_offset;
+ } else {
+ vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, msg->vpu_vsi_addr);
+ }
/* Firmware version field value is unspecified on MT8173. */
if (mtk_vcodec_fw_get_type(fw) == VPU)
@@ -155,6 +165,8 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
out.base.venc_inst = (unsigned long)vpu;
if (MTK_ENC_DRV_IS_COMM(vpu->ctx)) {
out.codec_type = vpu->ctx->q_data[MTK_Q_DATA_DST].fmt->fourcc;
+ if (mtk_vcodec_fw_get_type(vpu->ctx->dev->fw_handler) == VCP)
+ out.shared_iova = vpu->ctx->dev->fw_handler->vcp->iova_addr;
msg_size = sizeof(struct venc_ap_ipi_msg_init_comm);
} else {
msg_size = sizeof(struct venc_ap_ipi_msg_init);
--
2.45.2
^ permalink raw reply related
* [PATCH v6 5/6] media: mediatek: encoder: Add a new platform data member
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
Add a new platform data member to indicate each encoder IC, so that the
get chip name function by 'of_device_is_compatible' can be removed.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
.../mediatek/vcodec/encoder/mtk_vcodec_enc.c | 22 ++-----------------
.../vcodec/encoder/mtk_vcodec_enc_drv.c | 6 +++++
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 2 ++
3 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
index f0344888f2cf..b2f911746c01 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
@@ -198,33 +198,15 @@ static int vidioc_enum_fmt_vid_out(struct file *file, void *priv,
pdata->num_output_formats);
}
-static int mtk_vcodec_enc_get_chip_name(struct mtk_vcodec_enc_ctx *ctx)
-{
- struct device *dev = &ctx->dev->plat_dev->dev;
-
- if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-enc"))
- return 8173;
- else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-enc"))
- return 8183;
- else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-enc"))
- return 8192;
- else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-enc"))
- return 8195;
- else if (of_device_is_compatible(dev->of_node, "mediatek,mt8188-vcodec-enc"))
- return 8188;
- else
- return 8173;
-}
-
static int vidioc_venc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
struct mtk_vcodec_enc_ctx *ctx = file_to_enc_ctx(file);
+ const struct mtk_vcodec_enc_pdata *pdata = ctx->dev->venc_pdata;
struct device *dev = &ctx->dev->plat_dev->dev;
- int platform_name = mtk_vcodec_enc_get_chip_name(ctx);
strscpy(cap->driver, dev->driver->name, sizeof(cap->driver));
- snprintf(cap->card, sizeof(cap->card), "MT%d video encoder", platform_name);
+ snprintf(cap->card, sizeof(cap->card), "MT%d video encoder", pdata->venc_model_num);
return 0;
}
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
index 2f6ee0cd15e3..7b644f55963b 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
@@ -390,6 +390,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
}
static const struct mtk_vcodec_enc_pdata mt8173_avc_pdata = {
+ .venc_model_num = 8173,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
.output_formats = mtk_video_formats_output,
@@ -400,6 +401,7 @@ static const struct mtk_vcodec_enc_pdata mt8173_avc_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8173_vp8_pdata = {
+ .venc_model_num = 8173,
.capture_formats = mtk_video_formats_capture_vp8,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_vp8),
.output_formats = mtk_video_formats_output,
@@ -410,6 +412,7 @@ static const struct mtk_vcodec_enc_pdata mt8173_vp8_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8183_pdata = {
+ .venc_model_num = 8183,
.uses_ext = true,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
@@ -421,6 +424,7 @@ static const struct mtk_vcodec_enc_pdata mt8183_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8188_pdata = {
+ .venc_model_num = 8188,
.uses_ext = true,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
@@ -433,6 +437,7 @@ static const struct mtk_vcodec_enc_pdata mt8188_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8192_pdata = {
+ .venc_model_num = 8192,
.uses_ext = true,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
@@ -444,6 +449,7 @@ static const struct mtk_vcodec_enc_pdata mt8192_pdata = {
};
static const struct mtk_vcodec_enc_pdata mt8195_pdata = {
+ .venc_model_num = 8195,
.uses_ext = true,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
index 0529564027c4..769fb5009964 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
@@ -21,6 +21,7 @@
/**
* struct mtk_vcodec_enc_pdata - compatible data for each IC
*
+ * @venc_model_num: encoder model number
* @uses_ext: whether the encoder uses the extended firmware messaging format
* @min_bitrate: minimum supported encoding bitrate
* @max_bitrate: maximum supported encoding bitrate
@@ -33,6 +34,7 @@
* @uses_common_fw_iface: whether the encoder uses common driver interface
*/
struct mtk_vcodec_enc_pdata {
+ u16 venc_model_num;
bool uses_ext;
u64 min_bitrate;
u64 max_bitrate;
--
2.45.2
^ permalink raw reply related
* [PATCH v6 2/6] media: mediatek: encoder: Add a new encoder driver interface
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
Introduce a new encoder kernel driver interface to ensure compatibility
with the updated encoder software driver running in firmware.
The new driver interface is expected to support more encoder formats,
share more encode parameters between kernel and firmware.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
.../mediatek/vcodec/common/mtk_vcodec_fw.c | 13 +
.../mediatek/vcodec/common/mtk_vcodec_fw.h | 1 +
.../platform/mediatek/vcodec/encoder/Makefile | 1 +
.../mediatek/vcodec/encoder/mtk_vcodec_enc.c | 14 +-
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 8 +-
.../vcodec/encoder/venc/venc_common_if.c | 674 ++++++++++++++++++
.../vcodec/encoder/venc/venc_h264_if.c | 8 +-
.../mediatek/vcodec/encoder/venc_drv_if.h | 11 +-
8 files changed, 712 insertions(+), 18 deletions(-)
create mode 100644 drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
index 4ed7639dfa30..0381acceda25 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
@@ -18,6 +18,19 @@ int mtk_vcodec_fw_get_ipi(enum mtk_vcodec_fw_type type, int hw_id)
}
EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_ipi);
+int mtk_vcodec_fw_get_venc_ipi(enum mtk_vcodec_fw_type type)
+{
+ switch (type) {
+ case SCP:
+ return SCP_IPI_VENC_H264;
+ case VCP:
+ return VCP_IPI_ENCODER;
+ default:
+ return -EINVAL;
+ }
+}
+EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_venc_ipi);
+
struct mtk_vcodec_fw *mtk_vcodec_fw_select(void *priv, enum mtk_vcodec_fw_type type,
enum mtk_vcodec_fw_use fw_use)
{
diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
index 142e2e87905c..e7304a7dd3e0 100644
--- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
+++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
@@ -42,5 +42,6 @@ int mtk_vcodec_fw_ipi_send(struct mtk_vcodec_fw *fw, int id,
void *buf, unsigned int len, unsigned int wait);
int mtk_vcodec_fw_get_type(struct mtk_vcodec_fw *fw);
int mtk_vcodec_fw_get_ipi(enum mtk_vcodec_fw_type type, int hw_id);
+int mtk_vcodec_fw_get_venc_ipi(enum mtk_vcodec_fw_type type);
#endif /* _MTK_VCODEC_FW_H_ */
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/Makefile b/drivers/media/platform/mediatek/vcodec/encoder/Makefile
index e621b5b7e5e6..9d3229d56e39 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/Makefile
+++ b/drivers/media/platform/mediatek/vcodec/encoder/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o
mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc/venc_h264_if.o \
+ venc/venc_common_if.o \
mtk_vcodec_enc.o \
mtk_vcodec_enc_drv.o \
mtk_vcodec_enc_pm.o \
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
index 48cb5dded70a..f0344888f2cf 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc.c
@@ -81,11 +81,11 @@ static int vidioc_venc_s_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
mtk_v4l2_venc_dbg(2, ctx, "V4L2_CID_MPEG_VIDEO_H264_PROFILE val = %d", ctrl->val);
- p->h264_profile = ctrl->val;
+ p->profile = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
mtk_v4l2_venc_dbg(2, ctx, "V4L2_CID_MPEG_VIDEO_H264_LEVEL val = %d", ctrl->val);
- p->h264_level = ctrl->val;
+ p->level = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_H264_I_PERIOD:
mtk_v4l2_venc_dbg(2, ctx, "V4L2_CID_MPEG_VIDEO_H264_I_PERIOD val = %d", ctrl->val);
@@ -385,8 +385,8 @@ static void mtk_venc_set_param(struct mtk_vcodec_enc_ctx *ctx,
mtk_v4l2_venc_err(ctx, "Unsupported fourcc =%d", q_data_src->fmt->fourcc);
break;
}
- param->h264_profile = enc_params->h264_profile;
- param->h264_level = enc_params->h264_level;
+ param->profile = enc_params->profile;
+ param->level = enc_params->level;
/* Config visible resolution */
param->width = q_data_src->visible_width;
@@ -402,8 +402,8 @@ static void mtk_venc_set_param(struct mtk_vcodec_enc_ctx *ctx,
mtk_v4l2_venc_dbg(0, ctx,
"fmt 0x%x, P/L %d/%d w/h %d/%d buf %d/%d fps/bps %d/%d gop %d i_per %d",
- param->input_yuv_fmt, param->h264_profile,
- param->h264_level, param->width, param->height,
+ param->input_yuv_fmt, param->profile,
+ param->level, param->width, param->height,
param->buf_width, param->buf_height,
param->frm_rate, param->bitrate,
param->gop_size, param->intra_period);
@@ -1157,6 +1157,8 @@ static void mtk_venc_worker(struct work_struct *work)
frm_buf.fb_addr[i].size =
(size_t)src_buf->vb2_buf.planes[i].length;
}
+ frm_buf.num_planes = src_buf->vb2_buf.num_planes;
+
bs_buf.va = vb2_plane_vaddr(&dst_buf->vb2_buf, 0);
bs_buf.dma_addr = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
bs_buf.size = (size_t)dst_buf->vb2_buf.planes[0].length;
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
index 0cddfa13594f..53369adc083b 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
@@ -69,8 +69,8 @@ enum mtk_encode_param {
* @framerate_denom: frame rate denominator. ex: framerate_num=30 and
* framerate_denom=1 means FPS is 30
* @h264_max_qp: Max value for H.264 quantization parameter
- * @h264_profile: V4L2 defined H.264 profile
- * @h264_level: V4L2 defined H.264 level
+ * @profile: V4L2 defined profile
+ * @level: V4L2 defined level
* @force_intra: force/insert intra frame
*/
struct mtk_enc_params {
@@ -84,8 +84,8 @@ struct mtk_enc_params {
unsigned int framerate_num;
unsigned int framerate_denom;
unsigned int h264_max_qp;
- unsigned int h264_profile;
- unsigned int h264_level;
+ unsigned int profile;
+ unsigned int level;
unsigned int force_intra;
};
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
new file mode 100644
index 000000000000..050b827f0fd0
--- /dev/null
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_if.c
@@ -0,0 +1,674 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2025 MediaTek Inc.
+ */
+
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_drv.h"
+#include "../venc_drv_base.h"
+#include "../venc_drv_if.h"
+#include "../venc_vpu_if.h"
+#include "../../common/mtk_vcodec_intr.h"
+#include "../../common/mtk_vcodec_util.h"
+
+#define SEQ_HEADER_SIZE 1024
+#define PPS_SIZE 128
+#define MAX_DPB_SIZE 16
+#define MAX_VENC_CORE 3
+#define VENC_CONFIG_LENGTH 115
+#define VENC_CONFIG_DATA 128
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+/**
+ * enum venc_bs_mode - encode bitstream mode
+ * @VENC_BS_MODE_SPS: encode sps
+ * @VENC_BS_MODE_PPS: encode pps
+ * @VENC_BS_MODE_VPS: encode vps
+ * @VENC_BS_MODE_SEQ_HDR: encode sequence header
+ * @VENC_BS_MODE_FRAME: encode frame
+ * @VENC_BS_MODE_FRAME_FINAL: encode final frame
+ * @VENC_BS_MODE_MAX: max value
+ */
+enum venc_bs_mode {
+ VENC_BS_MODE_SPS = 0,
+ VENC_BS_MODE_PPS,
+ VENC_BS_MODE_VPS,
+ VENC_BS_MODE_SEQ_HDR,
+ VENC_BS_MODE_FRAME,
+ VENC_BS_MODE_FRAME_FINAL,
+ VENC_BS_MODE_MAX
+};
+
+/**
+ * struct venc_config - Structure for encoder configuration
+ * AP-W/R : AP is writer/reader on this item
+ * MCU-W/R: MCU is write/reader on this item
+ * @input_fourcc: input format fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: visible width of resolution
+ * @pic_h: visible height of resolution
+ * @buf_w: buffer alignment width of resolution
+ * @buf_h: buffer alignment height of resolution
+ * @gop_size: group of picture size (IDR frame period)
+ * @intra_period: I frame period
+ * @framerate: frame rate in fps
+ * @profile: profile_idc in SPS
+ * @level: level_idc in SPS
+ * @core_num: encoder core num
+ * @dpb_size: encode dpb size
+ * @reserved: reserved fields config
+ */
+struct venc_config {
+ __u32 input_fourcc;
+ __u32 bitrate;
+ __u32 pic_w;
+ __u32 pic_h;
+ __u32 buf_w;
+ __u32 buf_h;
+ __u32 gop_size;
+ __u32 intra_period;
+ __u32 framerate;
+ __u32 profile;
+ __u32 level;
+ __u32 core_num;
+ __u32 dpb_size;
+ __u32 reserved[VENC_CONFIG_LENGTH];
+};
+
+/**
+ * struct venc_config_data - Structure for configuration data
+ * @config_data: extended configuration data besides the basic configuration
+ */
+struct venc_config_data {
+ unsigned int config_data[VENC_CONFIG_DATA];
+};
+
+/**
+ * struct venc_work_buf - Structure for working buffer information
+ * AP-W/R : AP is writer/reader on this item
+ * MCU-W/R: MCU is write/reader on this item
+ * @iova: IO virtual address
+ * @pa: physical address
+ * @pa_64: for 64bit pa padding
+ * @va: virtual address
+ * @va_padding: for 64bit va padding
+ * @size: buffer size
+ * @size_padding: for 64bit size padding
+ */
+struct venc_work_buf {
+ unsigned long long iova;
+ union {
+ unsigned int pa;
+ unsigned long long pa_64;
+ };
+ union {
+ void *va;
+ unsigned long long va_padding;
+ };
+ union {
+ unsigned int size;
+ unsigned long long size_padding;
+ };
+};
+
+/**
+ * struct venc_work_buf_list - Structure for encode working buffer list
+ * @rc_code: RC code buffer
+ * @rc_info: RC info buffer
+ * @luma: luma buffer
+ * @chroma: chroma buffer
+ * @sub_luma: sub luma buffer
+ * @sub_write: sub write buffer
+ * @col_mv: col_mv buffer
+ * @wpp: wpp buffer
+ * @wpp_nbm: wpp nbm buffer
+ * @skip_frame: skip frame buffer
+ */
+struct venc_work_buf_list {
+ struct venc_work_buf rc_code;
+ struct venc_work_buf rc_info[MAX_VENC_CORE];
+ struct venc_work_buf luma[MAX_DPB_SIZE];
+ struct venc_work_buf chroma[MAX_DPB_SIZE];
+ struct venc_work_buf sub_luma[MAX_DPB_SIZE];
+ struct venc_work_buf sub_write[MAX_DPB_SIZE];
+ struct venc_work_buf col_mv[MAX_DPB_SIZE];
+ struct venc_work_buf wpp[MAX_VENC_CORE];
+ struct venc_work_buf wpp_nbm[MAX_VENC_CORE];
+ struct venc_work_buf skip_frame;
+};
+
+/**
+ * struct venc_info - Structure for encode frame and bs information
+ * @fb_addr: frame buffer address array
+ * @fb_size: frame buffer size array
+ * @bs_addr: bitstream buffer address
+ * @bs_size: bitstream buffer size
+ */
+struct venc_info {
+ unsigned long long fb_addr[VIDEO_MAX_PLANES];
+ unsigned int fb_size[VIDEO_MAX_PLANES];
+ unsigned long long bs_addr;
+ unsigned long long bs_size;
+};
+
+/**
+ * struct venc_vsi - Structure for VCP driver control and info share
+ * AP-W/R : AP is writer/reader on this item
+ * VCP-W/R: VCP is write/reader on this item
+ * @config: encoder configuration
+ * @data: encoder configuration data
+ * @bufs: encoder working buffers
+ * @venc: encoder information
+ */
+struct venc_vsi {
+ struct venc_config config;
+ struct venc_config_data data;
+ struct venc_work_buf_list bufs;
+ struct venc_info venc;
+};
+
+/**
+ * struct venc_inst - Structure for encoder instance
+ * @hw_base: hardware io address
+ * @pps_buf: PPS buffer
+ * @seq_buf: sequence header buffer
+ * @work_buf_allocated: work buffer allocated or not
+ * @frm_cnt: encoded frame count
+ * @skip_frm_cnt: encoded skip frame count
+ * @prepend_hdr: prepend header flag
+ * @vpu_inst: vpu instance
+ * @vsi: encode vsi
+ * @ctx: encoder context
+ */
+struct venc_inst {
+ void __iomem *hw_base;
+ struct mtk_vcodec_mem pps_buf;
+ struct mtk_vcodec_mem seq_buf;
+ bool work_buf_allocated;
+ unsigned int frm_cnt;
+ unsigned int skip_frm_cnt;
+ unsigned int prepend_hdr;
+ struct venc_vpu_inst vpu_inst;
+ struct venc_vsi *vsi;
+ struct mtk_vcodec_enc_ctx *ctx;
+};
+
+static int venc_init(struct mtk_vcodec_enc_ctx *ctx)
+{
+ int ret = 0;
+ struct venc_inst *inst;
+
+ inst = kzalloc_obj(inst, GFP_KERNEL);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->ctx = ctx;
+ inst->vpu_inst.ctx = ctx;
+ inst->vpu_inst.id = mtk_vcodec_fw_get_venc_ipi(ctx->dev->fw_handler->type);
+ inst->hw_base = mtk_vcodec_get_reg_addr(inst->ctx->dev->reg_base, VENC_SYS);
+
+ ret = vpu_enc_init(&inst->vpu_inst);
+ inst->vsi = (struct venc_vsi *)inst->vpu_inst.vsi;
+
+ if (ret) {
+ kfree(inst);
+ return ret;
+ }
+
+ ctx->drv_handle = inst;
+
+ return 0;
+}
+
+static inline u32 venc_read_reg(struct venc_inst *inst, u32 addr)
+{
+ return readl(inst->hw_base + addr);
+}
+
+static unsigned int venc_wait_encode_done(struct venc_inst *inst)
+{
+ unsigned int irq_status = 0;
+ struct mtk_vcodec_enc_ctx *ctx = (struct mtk_vcodec_enc_ctx *)inst->ctx;
+
+ if (!mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
+ WAIT_INTR_TIMEOUT_MS, 0)) {
+ irq_status = ctx->irq_status;
+ mtk_venc_debug(ctx, "irq_status %x <-", irq_status);
+ }
+ return irq_status;
+}
+
+static void venc_set_bufs(struct venc_inst *inst,
+ struct venc_frm_buf *frm_buf,
+ struct mtk_vcodec_mem *bs_buf)
+{
+ unsigned int i;
+
+ if (frm_buf) {
+ for (i = 0; i < frm_buf->num_planes; i++) {
+ inst->vsi->venc.fb_addr[i] = frm_buf->fb_addr[i].dma_addr;
+ inst->vsi->venc.fb_size[i] = frm_buf->fb_addr[i].size;
+ mtk_venc_debug(inst->ctx, "%s: fb_buf[%d]: %llx(%d)\n",
+ __func__, i,
+ inst->vsi->venc.fb_addr[i],
+ inst->vsi->venc.fb_size[i]);
+ }
+ }
+
+ if (bs_buf) {
+ inst->vsi->venc.bs_addr = bs_buf->dma_addr;
+ inst->vsi->venc.bs_size = bs_buf->size;
+ mtk_venc_debug(inst->ctx, "%s: bs_buf: %llx(%d)\n",
+ __func__,
+ inst->vsi->venc.bs_addr,
+ (unsigned int)inst->vsi->venc.bs_size);
+ }
+}
+
+static int venc_encode_sps(struct venc_inst *inst,
+ struct mtk_vcodec_mem *bs_buf,
+ unsigned int *bs_size)
+{
+ int ret = 0;
+ unsigned int irq_status;
+
+ venc_set_bufs(inst, NULL, bs_buf);
+ ret = vpu_enc_encode(&inst->vpu_inst, VENC_BS_MODE_SPS, NULL, bs_buf, NULL);
+ if (ret)
+ return ret;
+
+ irq_status = venc_wait_encode_done(inst);
+ if (irq_status != MTK_VENC_IRQ_STATUS_SPS) {
+ mtk_venc_err(inst->ctx, "expect irq status %d", MTK_VENC_IRQ_STATUS_SPS);
+ return -EINVAL;
+ }
+
+ *bs_size = venc_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+ mtk_venc_debug(inst->ctx, "sps bs size %d <-", *bs_size);
+
+ return ret;
+}
+
+static int venc_encode_pps(struct venc_inst *inst,
+ struct mtk_vcodec_mem *bs_buf,
+ unsigned int *bs_size)
+{
+ int ret = 0;
+ unsigned int irq_status;
+
+ venc_set_bufs(inst, NULL, bs_buf);
+ ret = vpu_enc_encode(&inst->vpu_inst, VENC_BS_MODE_PPS, NULL, bs_buf, NULL);
+ if (ret)
+ return ret;
+
+ irq_status = venc_wait_encode_done(inst);
+ if (irq_status != MTK_VENC_IRQ_STATUS_PPS) {
+ mtk_venc_err(inst->ctx, "expect irq status %d", MTK_VENC_IRQ_STATUS_PPS);
+ return -EINVAL;
+ }
+
+ *bs_size = venc_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+ mtk_venc_debug(inst->ctx, "pps bs size %d <-", *bs_size);
+
+ return ret;
+}
+
+static int venc_encode_header(struct venc_inst *inst,
+ struct mtk_vcodec_mem *bs_buf,
+ unsigned int *bs_size)
+{
+ int ret = 0;
+ unsigned int bs_size_sps;
+ unsigned int bs_size_pps;
+
+ ret = venc_encode_sps(inst, bs_buf, &bs_size_sps);
+ if (ret)
+ return ret;
+
+ ret = venc_encode_pps(inst, &inst->pps_buf, &bs_size_pps);
+ if (ret)
+ return ret;
+
+ memcpy(bs_buf->va + bs_size_sps, inst->pps_buf.va, bs_size_pps);
+ *bs_size = bs_size_sps + bs_size_pps;
+
+ return ret;
+}
+
+static int venc_encode_frame(struct venc_inst *inst,
+ struct venc_frm_buf *frm_buf,
+ struct mtk_vcodec_mem *bs_buf,
+ unsigned int *bs_size)
+{
+ int ret = 0;
+ unsigned int irq_status;
+
+ venc_set_bufs(inst, frm_buf, bs_buf);
+ ret = vpu_enc_encode(&inst->vpu_inst, VENC_BS_MODE_FRAME, frm_buf, bs_buf, NULL);
+ if (ret)
+ return ret;
+
+ irq_status = venc_wait_encode_done(inst);
+ if (irq_status != MTK_VENC_IRQ_STATUS_FRM) {
+ mtk_venc_err(inst->ctx, "expect irq status %d", MTK_VENC_IRQ_STATUS_FRM);
+ return -EINVAL;
+ }
+
+ *bs_size = venc_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+
+ ++inst->frm_cnt;
+
+ return ret;
+}
+
+static int venc_encode(void *handle,
+ enum venc_start_opt opt,
+ struct venc_frm_buf *frm_buf,
+ struct mtk_vcodec_mem *bs_buf,
+ struct venc_done_result *result)
+{
+ int ret = 0;
+ struct venc_inst *inst = (struct venc_inst *)handle;
+ struct mtk_vcodec_enc_ctx *ctx;
+ unsigned int bs_size_hdr;
+
+ if (WARN_ON(!inst || !inst->vsi))
+ return -EINVAL;
+
+ ctx = inst->ctx;
+
+ mtk_venc_debug(ctx, "%s: opt: %d\n", __func__, opt);
+
+ enable_irq(ctx->dev->enc_irq);
+ switch (opt) {
+ case VENC_START_OPT_ENCODE_SEQUENCE_HEADER: {
+ ret = venc_encode_header(inst, bs_buf, &bs_size_hdr);
+ if (ret)
+ goto encode_err;
+
+ result->bs_size = bs_size_hdr;
+ result->is_key_frm = false;
+ break;
+ }
+
+ case VENC_START_OPT_ENCODE_FRAME: {
+ if (!inst->prepend_hdr) {
+ ret = venc_encode_frame(inst, frm_buf, bs_buf, &result->bs_size);
+ if (ret)
+ goto encode_err;
+
+ result->is_key_frm = inst->vpu_inst.is_key_frm;
+ break;
+ }
+
+ ret = venc_encode_header(inst, &inst->seq_buf, &bs_size_hdr);
+ if (ret)
+ goto encode_err;
+
+ ret = venc_encode_frame(inst, frm_buf, bs_buf, &result->bs_size);
+ if (ret)
+ goto encode_err;
+
+ memmove(bs_buf->va + bs_size_hdr, bs_buf->va, result->bs_size);
+ memcpy(bs_buf->va, inst->seq_buf.va, bs_size_hdr);
+ result->bs_size += bs_size_hdr;
+
+ inst->prepend_hdr = 0;
+ result->is_key_frm = inst->vpu_inst.is_key_frm;
+ break;
+ }
+
+ default:
+ mtk_venc_err(inst->ctx, "venc_opt %d not supported", opt);
+ ret = -EINVAL;
+ break;
+ }
+
+encode_err:
+ disable_irq(ctx->dev->enc_irq);
+ mtk_venc_debug(ctx, "opt %d, return %d", opt, ret);
+
+ return ret;
+}
+
+static int mtk_venc_mem_alloc(struct venc_inst *inst,
+ struct device *dev,
+ struct venc_work_buf *buf)
+{
+ dma_addr_t dma_addr;
+
+ if (WARN_ON(!dev || !buf))
+ return -EINVAL;
+
+ if (buf->size == 0)
+ return 0;
+
+ buf->va = dma_alloc_coherent(dev, buf->size, &dma_addr, GFP_KERNEL);
+ if (!buf->va)
+ return -ENOMEM;
+
+ buf->iova = (unsigned long long)dma_addr;
+
+ mtk_venc_debug(inst->ctx, "allocate buffer, size: %d, va: %p, iova: 0x%llx",
+ buf->size, buf->va, buf->iova);
+
+ return 0;
+}
+
+static void mtk_venc_mem_free(struct venc_inst *inst,
+ struct device *dev,
+ struct venc_work_buf *buf)
+{
+ if (WARN_ON(!dev || !buf))
+ return;
+
+ if (!buf->va)
+ return;
+
+ mtk_venc_debug(inst->ctx, "free buffer, size: %d, va: %p, iova: 0x%llx",
+ buf->size, buf->va, buf->iova);
+
+ dma_free_coherent(dev, buf->size, buf->va, buf->iova);
+ buf->va = NULL;
+ buf->iova = 0;
+ buf->size = 0;
+}
+
+static void venc_free_rc_buf(struct venc_inst *inst,
+ struct venc_work_buf_list *bufs,
+ unsigned int core_num)
+{
+ int i;
+ struct device *dev;
+
+ dev = &inst->ctx->dev->plat_dev->dev;
+ mtk_venc_mem_free(inst, dev, &bufs->rc_code);
+
+ for (i = 0; i < core_num; i++)
+ mtk_venc_mem_free(inst, dev, &bufs->rc_info[i]);
+}
+
+static void venc_free_work_buf(struct venc_inst *inst)
+{
+ int i;
+ struct venc_work_buf_list *bufs = &inst->vsi->bufs;
+ unsigned int core_num = inst->vsi->config.core_num;
+ unsigned int dpb_size = inst->vsi->config.dpb_size;
+ struct device *dev;
+
+ if (bufs->rc_code.va)
+ venc_free_rc_buf(inst, bufs, core_num);
+
+ dev = &inst->ctx->dev->plat_dev->dev;
+
+ for (i = 0; i < core_num; i++) {
+ mtk_venc_mem_free(inst, dev, &bufs->wpp[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->wpp_nbm[i]);
+ }
+
+ for (i = 0; i < dpb_size; i++) {
+ mtk_venc_mem_free(inst, dev, &bufs->luma[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->chroma[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->sub_luma[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->sub_write[i]);
+ mtk_venc_mem_free(inst, dev, &bufs->col_mv[i]);
+ }
+
+ if (inst->pps_buf.va)
+ mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
+
+ if (inst->seq_buf.va)
+ mtk_vcodec_mem_free(inst->ctx, &inst->seq_buf);
+}
+
+static int venc_alloc_rc_buf(struct venc_inst *inst,
+ struct venc_work_buf_list *bufs,
+ unsigned int core_num)
+{
+ int i;
+ struct mtk_vcodec_fw *fw = inst->ctx->dev->fw_handler;
+ struct device *dev;
+ void *tmp_va;
+
+ dev = &inst->ctx->dev->plat_dev->dev;
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
+ return -ENOMEM;
+
+ tmp_va = mtk_vcodec_fw_map_dm_addr(fw, bufs->rc_code.pa);
+ memcpy(bufs->rc_code.va, tmp_va, bufs->rc_code.size);
+
+ for (i = 0; i < core_num; i++) {
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_info[i]))
+ goto err_rc_buf;
+ }
+
+ return 0;
+
+err_rc_buf:
+ venc_free_rc_buf(inst, bufs, core_num);
+
+ return -ENOMEM;
+}
+
+static int venc_alloc_work_buf(struct venc_inst *inst)
+{
+ int i, ret;
+ struct venc_work_buf_list *bufs = &inst->vsi->bufs;
+ unsigned int core_num = inst->vsi->config.core_num;
+ unsigned int dpb_size = inst->vsi->config.dpb_size;
+ struct device *dev;
+
+ if (bufs->rc_code.size != 0) {
+ ret = venc_alloc_rc_buf(inst, bufs, core_num);
+ if (ret) {
+ mtk_venc_err(inst->ctx, "cannot allocate rc buf");
+ return -ENOMEM;
+ }
+ }
+
+ dev = &inst->ctx->dev->plat_dev->dev;
+
+ for (i = 0; i < core_num; i++) {
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->wpp[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->wpp_nbm[i]))
+ goto err_alloc;
+ }
+
+ for (i = 0; i < dpb_size; i++) {
+ if (mtk_venc_mem_alloc(inst, dev, &bufs->luma[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->chroma[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->sub_luma[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->sub_write[i]) ||
+ mtk_venc_mem_alloc(inst, dev, &bufs->col_mv[i]))
+ goto err_alloc;
+ }
+
+ /* the pps_buf and seq_buf are used by AP side only */
+ inst->pps_buf.size = PPS_SIZE;
+ ret = mtk_vcodec_mem_alloc(inst->ctx, &inst->pps_buf);
+ if (ret) {
+ mtk_venc_err(inst->ctx, "cannot allocate pps_buf");
+ goto err_alloc;
+ }
+
+ inst->seq_buf.size = SEQ_HEADER_SIZE;
+ ret = mtk_vcodec_mem_alloc(inst->ctx, &inst->seq_buf);
+ if (ret) {
+ mtk_venc_err(inst->ctx, "cannot allocate seq_buf");
+ goto err_alloc;
+ }
+ return 0;
+
+err_alloc:
+ venc_free_work_buf(inst);
+ return -ENOMEM;
+}
+
+static int venc_set_param(void *handle,
+ enum venc_set_param_type type,
+ struct venc_enc_param *enc_prm)
+{
+ int ret = 0;
+ struct venc_inst *inst = (struct venc_inst *)handle;
+
+ switch (type) {
+ case VENC_SET_PARAM_ENC:
+ if (WARN_ON(!inst->vsi))
+ return -EINVAL;
+ inst->vsi->config.input_fourcc = enc_prm->input_yuv_fmt;
+ inst->vsi->config.bitrate = enc_prm->bitrate;
+ inst->vsi->config.pic_w = enc_prm->width;
+ inst->vsi->config.pic_h = enc_prm->height;
+ inst->vsi->config.buf_w = enc_prm->buf_width;
+ inst->vsi->config.buf_h = enc_prm->buf_height;
+ inst->vsi->config.gop_size = enc_prm->gop_size;
+ inst->vsi->config.framerate = enc_prm->frm_rate;
+ inst->vsi->config.intra_period = enc_prm->intra_period;
+ inst->vsi->config.profile = enc_prm->profile;
+ inst->vsi->config.level = enc_prm->level;
+
+ ret = vpu_enc_set_param(&inst->vpu_inst, type, enc_prm);
+ if (ret)
+ break;
+
+ if (inst->work_buf_allocated) {
+ venc_free_work_buf(inst);
+ inst->work_buf_allocated = false;
+ }
+ ret = venc_alloc_work_buf(inst);
+ if (ret)
+ break;
+ inst->work_buf_allocated = true;
+ break;
+ case VENC_SET_PARAM_PREPEND_HEADER:
+ inst->prepend_hdr = 1;
+ break;
+ default:
+ ret = vpu_enc_set_param(&inst->vpu_inst, type, enc_prm);
+ break;
+ }
+
+ return ret;
+}
+
+static int venc_deinit(void *handle)
+{
+ int ret = 0;
+ struct venc_inst *inst = (struct venc_inst *)handle;
+
+ ret = vpu_enc_deinit(&inst->vpu_inst);
+
+ if (inst->work_buf_allocated)
+ venc_free_work_buf(inst);
+
+ kfree(inst);
+
+ return ret;
+}
+
+const struct venc_common_if venc_if = {
+ .init = venc_init,
+ .encode = venc_encode,
+ .set_param = venc_set_param,
+ .deinit = venc_deinit,
+};
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
index d2f4d732d2f7..320c505cdb21 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c
@@ -723,9 +723,9 @@ static void h264_enc_set_vsi_configs(struct venc_h264_inst *inst,
inst->vsi->config.framerate = enc_prm->frm_rate;
inst->vsi->config.intra_period = enc_prm->intra_period;
inst->vsi->config.profile =
- h264_get_profile(inst, enc_prm->h264_profile);
+ h264_get_profile(inst, enc_prm->profile);
inst->vsi->config.level =
- h264_get_level(inst, enc_prm->h264_level);
+ h264_get_level(inst, enc_prm->level);
inst->vsi->config.wfd = 0;
}
@@ -742,9 +742,9 @@ static void h264_enc_set_vsi_34_configs(struct venc_h264_inst *inst,
inst->vsi_34->config.framerate = enc_prm->frm_rate;
inst->vsi_34->config.intra_period = enc_prm->intra_period;
inst->vsi_34->config.profile =
- h264_get_profile(inst, enc_prm->h264_profile);
+ h264_get_profile(inst, enc_prm->profile);
inst->vsi_34->config.level =
- h264_get_level(inst, enc_prm->h264_level);
+ h264_get_level(inst, enc_prm->level);
inst->vsi_34->config.wfd = 0;
}
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.h b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.h
index 889440a436b6..3c2a1b5e9312 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.h
@@ -66,8 +66,8 @@ enum venc_set_param_type {
* struct venc_enc_prm - encoder settings for VENC_SET_PARAM_ENC used in
* venc_if_set_param()
* @input_fourcc: input yuv format
- * @h264_profile: V4L2 defined H.264 profile
- * @h264_level: V4L2 defined H.264 level
+ * @profile: V4L2 defined profile
+ * @level: V4L2 defined level
* @width: image width
* @height: image height
* @buf_width: buffer width
@@ -79,8 +79,8 @@ enum venc_set_param_type {
*/
struct venc_enc_param {
enum venc_yuv_fmt input_yuv_fmt;
- unsigned int h264_profile;
- unsigned int h264_level;
+ unsigned int profile;
+ unsigned int level;
unsigned int width;
unsigned int height;
unsigned int buf_width;
@@ -107,9 +107,11 @@ struct venc_frame_info {
/*
* struct venc_frm_buf - frame buffer information used in venc_if_encode()
* @fb_addr: plane frame buffer addresses
+ * @num_planes: number of planes
*/
struct venc_frm_buf {
struct mtk_vcodec_fb fb_addr[MTK_VCODEC_MAX_PLANES];
+ unsigned int num_planes;
};
/*
@@ -124,6 +126,7 @@ struct venc_done_result {
extern const struct venc_common_if venc_h264_if;
extern const struct venc_common_if venc_vp8_if;
+extern const struct venc_common_if venc_if;
/*
* venc_if_init - Create the driver handle
--
2.45.2
^ permalink raw reply related
* [PATCH v6 6/6] media: mediatek: encoder: Add MT8196 encoder compatible data
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
MT8196 encoder use common firmware interface, add compatible data to
support MT8196 encoding, and need set dma mask to support 34bit.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
---
.../vcodec/encoder/mtk_vcodec_enc_drv.c | 19 +++++++++++++++++++
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
index 7b644f55963b..d7328d013ff6 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c
@@ -20,6 +20,8 @@
#include "mtk_vcodec_enc_pm.h"
#include "../common/mtk_vcodec_intr.h"
+#define VENC_DMA_BIT_MASK 34
+
static const struct mtk_video_fmt mtk_video_formats_output[] = {
{
.fourcc = V4L2_PIX_FMT_NV12M,
@@ -309,6 +311,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
goto err_res;
}
+ if (dev->venc_pdata->set_dma_bit_mask)
+ dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(VENC_DMA_BIT_MASK));
+
mutex_init(&dev->enc_mutex);
mutex_init(&dev->dev_mutex);
spin_lock_init(&dev->dev_ctx_lock);
@@ -460,6 +465,19 @@ static const struct mtk_vcodec_enc_pdata mt8195_pdata = {
.core_id = VENC_SYS,
};
+static const struct mtk_vcodec_enc_pdata mt8196_pdata = {
+ .venc_model_num = 8196,
+ .capture_formats = mtk_video_formats_capture_h264,
+ .num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
+ .output_formats = mtk_video_formats_output,
+ .num_output_formats = ARRAY_SIZE(mtk_video_formats_output),
+ .min_bitrate = 64,
+ .max_bitrate = 100000000,
+ .core_id = VENC_SYS,
+ .uses_common_fw_iface = true,
+ .set_dma_bit_mask = true,
+};
+
static const struct of_device_id mtk_vcodec_enc_match[] = {
{.compatible = "mediatek,mt8173-vcodec-enc",
.data = &mt8173_avc_pdata},
@@ -469,6 +487,7 @@ static const struct of_device_id mtk_vcodec_enc_match[] = {
{.compatible = "mediatek,mt8188-vcodec-enc", .data = &mt8188_pdata},
{.compatible = "mediatek,mt8192-vcodec-enc", .data = &mt8192_pdata},
{.compatible = "mediatek,mt8195-vcodec-enc", .data = &mt8195_pdata},
+ {.compatible = "mediatek,mt8196-vcodec-enc", .data = &mt8196_pdata},
{},
};
MODULE_DEVICE_TABLE(of, mtk_vcodec_enc_match);
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
index 769fb5009964..475953d39aa4 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
@@ -32,6 +32,7 @@
* @core_id: stand for h264 or vp8 encode index
* @uses_34bit: whether the encoder uses 34-bit iova
* @uses_common_fw_iface: whether the encoder uses common driver interface
+ * @set_dma_bit_mask: whether the encoder need set extra DMA bit mask
*/
struct mtk_vcodec_enc_pdata {
u16 venc_model_num;
@@ -45,6 +46,7 @@ struct mtk_vcodec_enc_pdata {
u8 core_id;
bool uses_34bit;
bool uses_common_fw_iface;
+ bool set_dma_bit_mask;
};
/*
--
2.45.2
^ permalink raw reply related
* [PATCH v6 3/6] media: mediatek: encoder: Add support for common firmware interface
From: Irui Wang @ 2026-04-23 7:33 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Krzysztof Kozlowski, angelogioacchino.delregno,
nicolas.dufresne, Tiffany Lin, kyrie wu
Cc: Yunfei Dong, Maoguang Meng, Longfei Wang, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260423073345.27402-1-irui.wang@mediatek.com>
The existing encoder firmware interface implied just one type of codec:
H.264. Future encoders may support additional codecs; however adding
entire sets of interfaces for them is not scalable.
Instead, a new "common" firmware interface is defined for non codec
specific messages. The new messages encapsulate the old ones for
backward compatibility.
This patch adds support for these new messages.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
.../vcodec/encoder/mtk_vcodec_enc_drv.h | 3 ++
.../mediatek/vcodec/encoder/venc_drv_if.c | 3 +-
.../mediatek/vcodec/encoder/venc_ipi_msg.h | 26 +++++++++++++++
.../mediatek/vcodec/encoder/venc_vpu_if.c | 33 ++++++++++++-------
4 files changed, 52 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
index 53369adc083b..0529564027c4 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h
@@ -16,6 +16,7 @@
#define MTK_ENC_CTX_IS_EXT(ctx) ((ctx)->dev->venc_pdata->uses_ext)
#define MTK_ENC_IOVA_IS_34BIT(ctx) ((ctx)->dev->venc_pdata->uses_34bit)
+#define MTK_ENC_DRV_IS_COMM(ctx) (((ctx)->dev->venc_pdata->uses_common_fw_iface))
/**
* struct mtk_vcodec_enc_pdata - compatible data for each IC
@@ -29,6 +30,7 @@
* @num_output_formats: number of entries in output_formats
* @core_id: stand for h264 or vp8 encode index
* @uses_34bit: whether the encoder uses 34-bit iova
+ * @uses_common_fw_iface: whether the encoder uses common driver interface
*/
struct mtk_vcodec_enc_pdata {
bool uses_ext;
@@ -40,6 +42,7 @@ struct mtk_vcodec_enc_pdata {
size_t num_output_formats;
u8 core_id;
bool uses_34bit;
+ bool uses_common_fw_iface;
};
/*
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
index e83747b8d69a..f8c9349c18c0 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_drv_if.c
@@ -19,13 +19,14 @@
int venc_if_init(struct mtk_vcodec_enc_ctx *ctx, unsigned int fourcc)
{
int ret = 0;
+ const bool uses_common_fw_iface = MTK_ENC_DRV_IS_COMM(ctx);
switch (fourcc) {
case V4L2_PIX_FMT_VP8:
ctx->enc_if = &venc_vp8_if;
break;
case V4L2_PIX_FMT_H264:
- ctx->enc_if = &venc_h264_if;
+ ctx->enc_if = uses_common_fw_iface ? &venc_if : &venc_h264_if;
break;
default:
return -EINVAL;
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_ipi_msg.h b/drivers/media/platform/mediatek/vcodec/encoder/venc_ipi_msg.h
index bb16d96a7f57..ce3c2c8059fb 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_ipi_msg.h
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_ipi_msg.h
@@ -45,6 +45,20 @@ struct venc_ap_ipi_msg_init {
uint64_t venc_inst;
};
+/**
+ * struct venc_ap_ipi_msg_init_comm - AP to VPU init cmd structure
+ * @base: AP to VPU init cmd structure
+ * @codec_type: encoder type
+ * @reserved: reserved field
+ * @shared_iova: shared iova
+ */
+struct venc_ap_ipi_msg_init_comm {
+ struct venc_ap_ipi_msg_init base;
+ u32 codec_type;
+ u32 reserved;
+ u64 shared_iova;
+};
+
/**
* struct venc_ap_ipi_msg_set_param - AP to VPU set_param cmd structure
* @msg_id: message id (AP_IPIMSG_XXX_ENC_SET_PARAM)
@@ -175,6 +189,18 @@ struct venc_vpu_ipi_msg_init {
uint32_t venc_abi_version;
};
+/**
+ * struct venc_vpu_ipi_msg_init_comm - VPU ack AP init cmd structure
+ * @init_ack: AP init cmd structure
+ * @vpu_vsi_addr: VSI address from VPU
+ * @reserved: reserved field
+ */
+struct venc_vpu_ipi_msg_init_comm {
+ struct venc_vpu_ipi_msg_init init_ack;
+ u32 vpu_vsi_addr;
+ u32 reserved;
+};
+
/**
* struct venc_vpu_ipi_msg_set_param - VPU ack AP set_param cmd structure
* @msg_id: message id (VPU_IPIMSG_XXX_ENC_SET_PARAM_DONE)
diff --git a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
index 0c825aa7224d..7772b8442ebc 100644
--- a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
@@ -10,24 +10,25 @@
static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
{
- const struct venc_vpu_ipi_msg_init *msg = data;
+ const struct venc_vpu_ipi_msg_init_comm *msg = data;
+ struct mtk_vcodec_fw *fw = vpu->ctx->dev->fw_handler;
- vpu->inst_addr = msg->vpu_inst_addr;
- vpu->vsi = mtk_vcodec_fw_map_dm_addr(vpu->ctx->dev->fw_handler,
- msg->vpu_inst_addr);
+ vpu->inst_addr = msg->init_ack.vpu_inst_addr;
+ vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, vpu->inst_addr);
/* Firmware version field value is unspecified on MT8173. */
- if (mtk_vcodec_fw_get_type(vpu->ctx->dev->fw_handler) == VPU)
+ if (mtk_vcodec_fw_get_type(fw) == VPU)
return;
/* Check firmware version. */
- mtk_venc_debug(vpu->ctx, "firmware version: 0x%x\n", msg->venc_abi_version);
- switch (msg->venc_abi_version) {
+ mtk_venc_debug(vpu->ctx, "firmware version: 0x%x\n",
+ msg->init_ack.venc_abi_version);
+ switch (msg->init_ack.venc_abi_version) {
case 1:
break;
default:
mtk_venc_err(vpu->ctx, "unhandled firmware version 0x%x\n",
- msg->venc_abi_version);
+ msg->init_ack.venc_abi_version);
vpu->failure = 1;
break;
}
@@ -133,7 +134,8 @@ static int vpu_enc_send_msg(struct venc_vpu_inst *vpu, void *msg,
int vpu_enc_init(struct venc_vpu_inst *vpu)
{
int status;
- struct venc_ap_ipi_msg_init out = { };
+ size_t msg_size;
+ struct venc_ap_ipi_msg_init_comm out = { };
init_waitqueue_head(&vpu->wq_hd);
vpu->signaled = 0;
@@ -149,9 +151,16 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
return -EINVAL;
}
- out.msg_id = AP_IPIMSG_ENC_INIT;
- out.venc_inst = (unsigned long)vpu;
- if (vpu_enc_send_msg(vpu, &out, sizeof(out))) {
+ out.base.msg_id = AP_IPIMSG_ENC_INIT;
+ out.base.venc_inst = (unsigned long)vpu;
+ if (MTK_ENC_DRV_IS_COMM(vpu->ctx)) {
+ out.codec_type = vpu->ctx->q_data[MTK_Q_DATA_DST].fmt->fourcc;
+ msg_size = sizeof(struct venc_ap_ipi_msg_init_comm);
+ } else {
+ msg_size = sizeof(struct venc_ap_ipi_msg_init);
+ }
+
+ if (vpu_enc_send_msg(vpu, &out, msg_size)) {
mtk_venc_err(vpu->ctx, "AP_IPIMSG_ENC_INIT fail");
return -EINVAL;
}
--
2.45.2
^ permalink raw reply related
* Re: [PATCH net] net: airoha: stop net_device TX queue before updating CPU index
From: Lorenzo Bianconi @ 2026-04-23 7:42 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]
> Currently, airoha_eth driver updates the CPU index register prior of
> verifying whether the number of free descriptors has fallen below the
> threshold.
> Move net_device TX queue length check before updating the TX CPU index
> in order to update TX CPU index even if there are more packets to be
> transmitted but the net_device TX queue is going to be stopped
> accounting the inflight packets.
>
> Fixes: 1d304174106c ("net: airoha: Implement BQL support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..5d327237e274 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2058,17 +2058,16 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>
> skb_tx_timestamp(skb);
> netdev_tx_sent_queue(txq, skb->len);
> + if (q->ndesc - q->queued < q->free_thr) {
> + netif_tx_stop_queue(txq);
> + q->txq_stopped = true;
> + }
>
> if (netif_xmit_stopped(txq) || !netdev_xmit_more())
> airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid),
> TX_RING_CPU_IDX_MASK,
> FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
>
> - if (q->ndesc - q->queued < q->free_thr) {
> - netif_tx_stop_queue(txq);
> - q->txq_stopped = true;
> - }
> -
> spin_unlock_bh(&q->lock);
>
> return NETDEV_TX_OK;
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-xmit-stop-condition-344dc0292a19
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko retported issues:
https://sashiko.dev/#/patchset/20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467%40kernel.org
- Could this cause a deadlock if exactly q->free_thr descriptors are free?
This does not seem a problem to me since, even if the netdev tx queue is
stopped as described in the report, the airoha_qdma_tx_napi_poll() will free
space in the queue and subsequent packets will update REG_TX_CPU_IDX register.
- Is it possible for this loop to read past the end of the frags array?
As pointed out by Sashiko, this issue is not introduced by this patch and I
will fix with a dedicated patch.
- Might this lead to memory corruption if the tcp header is not in the linear area?
This issue is not introduced by this patch and I will fix with a dedicated patch.
- If an error occurs during transmission, the driver jumps to the error label
frees the skb, and returns NETDEV_TX_OK without ringing the qdma cpu index doorbell?
Similar to the first issue, this does not seem a problem to me since subsequent
packets will update REG_TX_CPU_IDX register.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
From: Ard Biesheuvel @ 2026-04-23 7:43 UTC (permalink / raw)
To: Lothar Rubusch, Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-2-l.rubusch@gmail.com>
Hi Lothar,
On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The driver allocated memory for work_data in the non-blocking read
> path but never free'd it again. After first read-out the memory pointer
> seemed to be recycled and never was allocated again, due to some errors
> in the logic, so that the leak was not growing.
>
Why can't we just reuse the work_data, instead of alloc/freeing it every time?
> Add kfree(work_data) in the completion callback on error. then add
> kfree(work_data) after the data is consumed in the subsequent read
> call. Finally ensure atomic_dec() is called only after the data has
> been consumed or an error occurred to prevent race conditions.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 43 ++++++++++++++++++++--------------
> 1 file changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c
> b/drivers/crypto/atmel-sha204a.c
> index dbb39ed0cea1..19720bdd446d 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -25,13 +25,17 @@ static void atmel_sha204a_rng_done(struct
> atmel_i2c_work_data *work_data,
> struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
> struct hwrng *rng = areq;
>
> - if (status)
> + if (status) {
> dev_warn_ratelimited(&i2c_priv->client->dev,
> "i2c transaction failed (%d)\n",
> status);
> + kfree(work_data);
> + rng->priv = 0;
> + atomic_dec(&i2c_priv->tfm_count);
> + return;
> + }
>
> rng->priv = (unsigned long)work_data;
> - atomic_dec(&i2c_priv->tfm_count);
> }
>
> static int atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void
> *data,
> @@ -42,31 +46,36 @@ static int
> atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
>
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> - /* keep maximum 1 asynchronous read in flight at any time */
> - if (!atomic_add_unless(&i2c_priv->tfm_count, 1, 1))
> - return 0;
> -
> + /* Verify if data available from last run */
> if (rng->priv) {
> work_data = (struct atmel_i2c_work_data *)rng->priv;
> max = min(sizeof(work_data->cmd.data), max);
> memcpy(data, &work_data->cmd.data, max);
> - rng->priv = 0;
> - } else {
> - work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
> - if (!work_data) {
> - atomic_dec(&i2c_priv->tfm_count);
> - return -ENOMEM;
> - }
> - work_data->ctx = i2c_priv;
> - work_data->client = i2c_priv->client;
>
> - max = 0;
> + /* Now, free memory */
> + kfree(work_data);
> + rng->priv = 0;
> + atomic_dec(&i2c_priv->tfm_count);
> + return max;
> }
>
> + /* When a request is still in-flight but not processed */
> + if (atomic_read(&i2c_priv->tfm_count) > 0)
> + return 0;
> +
> + /* Start a new request */
> + work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
> + if (!work_data)
> + return -ENOMEM;
> +
> + atomic_inc(&i2c_priv->tfm_count);
> + work_data->ctx = i2c_priv;
> + work_data->client = i2c_priv->client;
> +
> atmel_i2c_init_random_cmd(&work_data->cmd);
> atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
>
> - return max;
> + return 0;
> }
>
> static int atmel_sha204a_rng_read(struct hwrng *rng, void *data, size_t max,
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH 2/8] xor/arm: Replace vectorized implementation with arm64's intrinsics
From: Christoph Hellwig @ 2026-04-23 7:44 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-12-ardb+git@google.com>
Nice!
Acked-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 3/8] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Christoph Hellwig @ 2026-04-23 7:46 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-13-ardb+git@google.com>
> +extern void __xor_eor3_2(unsigned long bytes, unsigned long * __restrict p1,
> + const unsigned long * __restrict p2);
Does the alias magic prevent this from being in a header? If so a comment
would be nice, otherwise moving it to a header would be even better.
^ permalink raw reply
* Re: [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Christoph Hellwig @ 2026-04-23 7:47 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-17-ardb+git@google.com>
On Wed, Apr 22, 2026 at 07:17:03PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> arm_neon.h is a compiler header which needs some scaffolding to work
> correctly in the linux context, and so it is better not to include it
> directly. Both ARM and arm64 now provide asm/neon-intrinsics.h which
> takes care of this.
This could potentially clash with the raid6 library rework I'm doing
for 7.2. Although git has become pretty good about renamed files, so
maybe it won't be so bad.
^ permalink raw reply
* Re: [PATCH v3] ASoC: dt-bindings: mediatek: Convert mtk-btcvsd-snd to DT Schema
From: Krzysztof Kozlowski @ 2026-04-23 7:48 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-sound, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260421193858.347258-1-l.scorcia@gmail.com>
On Tue, Apr 21, 2026 at 08:38:35PM +0100, Luca Leonardo Scorcia wrote:
> +title: Mediatek ALSA BT SCO CVSD/MSBC Driver
s/Driver//
> +
> +maintainers:
> + - Luca Leonardo Scorcia <l.scorcia@gmail.com>
> +
> +properties:
> + compatible:
> + const: mediatek,mtk-btcvsd-snd
> +
> + reg:
> + minItems: 2
Drop
> + maxItems: 2
and actually drop this too and list the items with description - PKV and
SRAM_BANK2 regions
> +
> + reg-names:
> + items:
> + - const: pkv
> + - const: sram-bank2
Old binding did not have reg-names and nothing in commit msg explains
changes done to the binding.
To remind: if you change the binding, you must mention it and explain
WHY.
I don't see any use of that, so why did you add it?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/8] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Ard Biesheuvel @ 2026-04-23 7:48 UTC (permalink / raw)
To: Christoph Hellwig, Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Russell King,
Arnd Bergmann, Eric Biggers
In-Reply-To: <20260423074614.GB31018@lst.de>
On Thu, 23 Apr 2026, at 09:46, Christoph Hellwig wrote:
>> +extern void __xor_eor3_2(unsigned long bytes, unsigned long * __restrict p1,
>> + const unsigned long * __restrict p2);
>
> Does the alias magic prevent this from being in a header?
Yes, it emits the ELF symbol for the alias, and this is only permitted
in the compilation unit that defines the original.
> If so a comment
> would be nice, otherwise moving it to a header would be even better.
Ack.
^ permalink raw reply
* Re: [PATCH net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
From: Lorenzo Bianconi @ 2026-04-23 7:51 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3452 bytes --]
> Do not wake every netdev TX queue across all ports sharing the QDMA
> running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs()
> but only the ones that are mapped the specific QDMA stopped hw TX queue.
> This patch can potentially avoid waking already stopped netdev TX queues
> that are mapped to a different QDMA hw TX queue.
> Introduce airoha_qdma_get_txq utility routine.
>
> Fixes: b94769eb2f30 ("net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 19 +++++++++++++++----
> drivers/net/ethernet/airoha/airoha_eth.h | 5 +++++
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..2ca569501045 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -847,13 +847,24 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
> {
> struct airoha_qdma *qdma = q->qdma;
> struct airoha_eth *eth = qdma->eth;
> - int i;
> + int i, qid = q - &qdma->q_tx[0];
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> struct airoha_gdm_port *port = eth->ports[i];
> + int j;
> +
> + if (!port)
> + continue;
>
> - if (port && port->qdma == qdma)
> - netif_tx_wake_all_queues(port->dev);
> + if (port->qdma != qdma)
> + continue;
> +
> + for (j = 0; j < port->dev->num_tx_queues; j++) {
> + if (airoha_qdma_get_txq(qdma, j) != qid)
> + continue;
> +
> + netif_wake_subqueue(port->dev, j);
> + }
> }
> q->txq_stopped = false;
> }
> @@ -1965,7 +1976,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> u16 index;
> u8 fport;
>
> - qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx);
> + qid = airoha_qdma_get_txq(qdma, skb_get_queue_mapping(skb));
> tag = airoha_get_dsa_tag(skb, dev);
>
> msg0 = FIELD_PREP(QDMA_ETH_TXMSG_CHAN_MASK,
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index 87b328cfefb0..c3ea7aadbd82 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -631,6 +631,11 @@ u32 airoha_rmw(void __iomem *base, u32 offset, u32 mask, u32 val);
> #define airoha_qdma_clear(qdma, offset, val) \
> airoha_rmw((qdma)->regs, (offset), (val), 0)
>
> +static inline u16 airoha_qdma_get_txq(struct airoha_qdma *qdma, u16 qid)
> +{
> + return qid % ARRAY_SIZE(qdma->q_tx);
> +}
> +
> static inline bool airoha_is_lan_gdm_port(struct airoha_gdm_port *port)
> {
> /* GDM1 port on EN7581 SoC is connected to the lan dsa switch.
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-wake_netdev_txqs-optmization-65171ce4ebad
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko retported issues:
https://sashiko.dev/#/patchset/20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53%40kernel.org
- Can this cause an infinite NETDEV_TX_BUSY livelock when a QDMA hardware queue is full?
The issue is already fixed in the following patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org/
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
From: Ard Biesheuvel @ 2026-04-23 7:55 UTC (permalink / raw)
To: Lothar Rubusch, Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-3-l.rubusch@gmail.com>
On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
> 32 bytes of entropy, and a 2-byte CRC. The current blocking read
> implementation was incorrectly copying data starting from the
> count byte, leading to offset data and truncated entropy.
>
> Additionally, the chip requires significant execution time to
> generate random numbers, going by the datasheet. Reading the I2C bus
> too early results in the chip NACK-ing or returning a partial buffer
> followed by zeros.
>
> Verification:
> Tests before showed repeadetly reading only 8 bytes of entropy:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020
>
> After this patch applied, the result will be as follows:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> 00000020
>
> Fix these issues by:
> Increase cmd.msecs to 30ms to provide sufficient execution time. Then
> set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
> hardware response. Eventually, correct the memcpy() offset to index 1 of
> the data buffer to skip the count byte and retrieve exactly 32 bytes of
> entropy.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index 19720bdd446d..f7dc00d0f4cd 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -19,6 +19,9 @@
> #include <linux/workqueue.h>
> #include "atmel-i2c.h"
>
> +#define ATMEL_RNG_BLOCK_SIZE 32
> +#define ATMEL_RNG_EXEC_TIME 30
> +
> static void atmel_sha204a_rng_done(struct atmel_i2c_work_data
> *work_data,
> void *areq, int status)
> {
> @@ -91,13 +94,15 @@ static int atmel_sha204a_rng_read(struct hwrng
> *rng, void *data, size_t max,
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> atmel_i2c_init_random_cmd(&cmd);
> + cmd.msecs = ATMEL_RNG_EXEC_TIME;
> + cmd.rxsize = RANDOM_RSP_SIZE;
>
Please fix atmel_i2c_init_random_cmd() instead if it doesn't set the right
values for these fields. But afaict, you are decreasing the execution time
here, so I struggle to see how this could explain the improved behavior.
> ret = atmel_i2c_send_receive(i2c_priv->client, &cmd);
> if (ret)
> return ret;
>
> - max = min(sizeof(cmd.data), max);
> - memcpy(data, cmd.data, max);
> + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> + memcpy(data, &cmd.data[1], max);
>
This looks correct - better to put this in a separate patch.
> return max;
> }
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v3 3/3] crypto: atmel-sha204a - fix non-blocking read logic
From: Ard Biesheuvel @ 2026-04-23 7:56 UTC (permalink / raw)
To: Lothar Rubusch, Herbert Xu, Thorsten Blum, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, Linus Walleij
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260422210936.20095-4-l.rubusch@gmail.com>
On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> The non-blocking path was (also) failing to provide valid entropy
> due to improper buffer management and a lack of hardware execution
> time.
>
> Ensure cmd.msecs (30ms) and cmd.rxsize (35ms) are initialized before
> enqueuing the background work. Fix the data offset to skip the
> 1-byte hardware count header when copying bits to the caller. Correctly
> return 0 (busy) to the hwrng core while hardware execution is in
> progress, preventing zero-filled buffers, which was the situation
> before.
>
> With this fix applied, tests will look similar to this:
> $ socat -u OPEN:/dev/hwrng,nonblock - | head -c 32 | hexdump -C
> 00000000 23 cc 42 3c 90 b1 38 fc 54 37 35 4b 09 c5 e1 0d
> |#.B<..8.T75K....|
> 2026/03/23 14:30:18 socat[858] E read(5, 0x55be363000, 8192): Resource
> temporarily unavailable
> 00000010 73 3b af d9 02 70 76 bd 2d 59 4b 12 01 ac ae 2b
> |s;...pv.-YK....+|
> 00000020
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A
> random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c
> b/drivers/crypto/atmel-sha204a.c
> index f7dc00d0f4cd..04cbf80c1411 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -33,7 +33,6 @@ static void atmel_sha204a_rng_done(struct
> atmel_i2c_work_data *work_data,
> "i2c transaction failed (%d)\n",
> status);
> kfree(work_data);
> - rng->priv = 0;
> atomic_dec(&i2c_priv->tfm_count);
> return;
> }
> @@ -49,20 +48,19 @@ static int
> atmel_sha204a_rng_read_nonblocking(struct hwrng *rng, void *data,
>
> i2c_priv = container_of(rng, struct atmel_i2c_client_priv, hwrng);
>
> - /* Verify if data available from last run */
> if (rng->priv) {
> work_data = (struct atmel_i2c_work_data *)rng->priv;
> - max = min(sizeof(work_data->cmd.data), max);
> - memcpy(data, &work_data->cmd.data, max);
> + max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> + memcpy(data, &work_data->cmd.data[1], max);
>
Please combine this with the buffer size fix in the previous patch.
> - /* Now, free memory */
> + /* Free memory and clear the in-flight flag */
> kfree(work_data);
> rng->priv = 0;
> atomic_dec(&i2c_priv->tfm_count);
> return max;
> }
>
> - /* When a request is still in-flight but not processed */
> + /* If a request is still in-flight, return 0 (busy) */
> if (atomic_read(&i2c_priv->tfm_count) > 0)
> return 0;
>
> @@ -76,8 +74,14 @@ static int atmel_sha204a_rng_read_nonblocking(struct
> hwrng *rng, void *data,
> work_data->client = i2c_priv->client;
>
> atmel_i2c_init_random_cmd(&work_data->cmd);
> +
> + /* Set the execution time for the RNG command (from datasheet) */
> + work_data->cmd.msecs = ATMEL_RNG_EXEC_TIME;
> + work_data->cmd.rxsize = RANDOM_RSP_SIZE;
> +
Again, this is either redundant or wrong.
> atmel_i2c_enqueue(work_data, atmel_sha204a_rng_done, rng);
>
> + /* Return 0 to indicate 'busy', data will be ready on next call */
> return 0;
> }
>
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v3 06/11] iommu: Defer __iommu_group_free_device() to be outside group->mutex
From: Baolu Lu @ 2026-04-23 7:55 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Robin Murphy, Joerg Roedel,
Bjorn Helgaas, Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Kevin Tian, linux-arm-kernel, iommu, linux-kernel, linux-acpi,
linux-pci, vsethi, Shuai Xue
In-Reply-To: <3f5d229267d1f4d918641bc5b896f54b5c4b7782.1776381841.git.nicolinc@nvidia.com>
On 4/17/26 07:28, Nicolin Chen wrote:
> __iommu_group_remove_device() holds group->mutex across the entire call to
> __iommu_group_free_device() that performs sysfs removals, tracing, and the
> final kfree_rcu(). But in fact, most of these operations don't really need
> the group->mutex.
>
> The group_device structure will support a work_struct to quarantine broken
> devices asynchronously. The work function must hold group->mutex to safely
> update group state. cancel_work_sync() must be called, to cancel that work
> before freeing the device. But doing so under group->mutex would deadlock
> if the worker is already running and waiting to acquire the same lock.
>
> Separate the assertion from __iommu_group_free_device() to another helper
> __iommu_group_empty_assert_owner_cnt().
>
> Defer the __iommu_group_free_device() until the mutex is released.
>
> This is a preparatory refactor with no functional change.
>
> Signed-off-by: Nicolin Chen<nicolinc@nvidia.com>
> ---
> drivers/iommu/iommu.c | 35 +++++++++++++++++++++++------------
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index d1be62a07904a..810e7b94a1ae2 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -627,6 +627,19 @@ static struct iommu_domain *pasid_array_entry_to_domain(void *entry)
>
> DEFINE_MUTEX(iommu_probe_device_lock);
>
> +static void __iommu_group_empty_assert_owner_cnt(struct iommu_group *group)
> +{
> + lockdep_assert_held(&group->mutex);
> + /*
> + * If the group has become empty then ownership must have been
> + * released, and the current domain must be set back to NULL or
> + * the default domain.
> + */
Nit: this comment doesn't quite match the following code. The code
doesn't check "group->domain != NULL". Or perhaps in that case,
group->default_domain must be NULL?
Furthermore, if a device is currently quarantined, group->domain will be
the blocking_domain. If that quarantined device is then hot-removed and
happens to be the last device in the group, will this WARN_ON trigger
unnecessarily?
> + if (list_empty(&group->devices))
> + WARN_ON(group->owner_cnt ||
> + group->domain != group->default_domain);
> +}
> +
> static int __iommu_probe_device(struct device *dev, struct list_head *group_list)
> {
> struct iommu_group *group;
Thanks,
baolu
^ permalink raw reply
* Re: [PATCH v2 0/2] gpio: drop bitmap_complement() where feasible
From: Bartosz Golaszewski @ 2026-04-23 7:58 UTC (permalink / raw)
To: Linus Walleij, Andy Shevchenko, Bartosz Golaszewski,
Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, Yury Norov,
linux-gpio, linux-kernel, linux-arm-kernel, Yury Norov
Cc: Bartosz Golaszewski
In-Reply-To: <20260417175955.375275-1-ynorov@nvidia.com>
On Fri, 17 Apr 2026 13:59:52 -0400, Yury Norov wrote:
> The gpio drivers reproduce the following pattern:
>
> bitmap_complement(tmp, data1, nbits);
> bitmap_and(dst, data2, tmp, nbits);
>
> This can be done in a single pass:
>
> [...]
Tweaked the grammar in commit messages and applied, thanks!
[1/2] gpio: pca953x: drop bitmap_complement() where feasible
https://git.kernel.org/brgl/c/a56604e397575647bfc425a8df176948577a364e
[2/2] gpio: xilinx: drop bitmap_complement() where feasible
https://git.kernel.org/brgl/c/2757a5b1bca76a1b6378496b669a2baf1faddec5
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] arm64: traps: Add a macro to simplify the condition codes check
From: Marc Zyngier @ 2026-04-23 8:04 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, smostafa, kees, catalin.marinas, Jinjie Ruan,
linux-kernel, mrigendra.chaubey, leitao, will, linux-arm-kernel
In-Reply-To: <ae6f2b57-4644-424e-aab7-84042dca23e6@arm.com>
On Thu, 23 Apr 2026 06:29:09 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>
>
> On 20/03/26 1:58 PM, Jinjie Ruan wrote:
> > Add DEFINE_COND_CHECK macro to define the simple __check_* functions
> > to simplify the condition codes check.
> >
> > No functional changes.
> >
> > Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> > ---
> > arch/arm64/kernel/traps.c | 59 ++++++++++-----------------------------
> > 1 file changed, 15 insertions(+), 44 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > index 914282016069..6216fe9e8e42 100644
> > --- a/arch/arm64/kernel/traps.c
> > +++ b/arch/arm64/kernel/traps.c
> > @@ -49,45 +49,21 @@
> > #include <asm/system_misc.h>
> > #include <asm/sysreg.h>
> >
> > -static bool __kprobes __check_eq(unsigned long pstate)
> > -{
> > - return (pstate & PSR_Z_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_ne(unsigned long pstate)
> > -{
> > - return (pstate & PSR_Z_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_cs(unsigned long pstate)
> > -{
> > - return (pstate & PSR_C_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_cc(unsigned long pstate)
> > -{
> > - return (pstate & PSR_C_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_mi(unsigned long pstate)
> > -{
> > - return (pstate & PSR_N_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_pl(unsigned long pstate)
> > -{
> > - return (pstate & PSR_N_BIT) == 0;
> > -}
> > -
> > -static bool __kprobes __check_vs(unsigned long pstate)
> > -{
> > - return (pstate & PSR_V_BIT) != 0;
> > -}
> > -
> > -static bool __kprobes __check_vc(unsigned long pstate)
> > -{
> > - return (pstate & PSR_V_BIT) == 0;
> > -}
> > +#define DEFINE_COND_CHECK(name, flag, expected) \
> > +static bool __kprobes __check_##name(unsigned long pstate) \
> > +{ \
> > + return ((pstate & (flag)) != 0) == (expected); \
> > +}
> > +
> > +DEFINE_COND_CHECK(eq, PSR_Z_BIT, true)
> > +DEFINE_COND_CHECK(ne, PSR_Z_BIT, false)
> > +DEFINE_COND_CHECK(cs, PSR_C_BIT, true)
> > +DEFINE_COND_CHECK(cc, PSR_C_BIT, false)
> > +DEFINE_COND_CHECK(mi, PSR_N_BIT, true)
> > +DEFINE_COND_CHECK(pl, PSR_N_BIT, false)
> > +DEFINE_COND_CHECK(vs, PSR_V_BIT, true)
> > +DEFINE_COND_CHECK(vc, PSR_V_BIT, false)
> > +DEFINE_COND_CHECK(al, 0, false) /* Always true */
>
> (((pstate & 0 == 0) != 0) == false) ---> return true
>
> Although this looks OK but wondering if __check_al() should
> be left unchanged for simplicity. OR could all its call sites
> be changed assuming an unconditional 'true' return thus later
> __check_al() can be dropped.
Which call site? We emulate an instruction, and we're not in control
of the condition code associated with it. The condition code directly
indexes into aarch32_opcode_cond_checks[].
Anyway, this is a moot point, as we have consensus to not touch that
code at all.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: Marc Zyngier @ 2026-04-23 8:08 UTC (permalink / raw)
To: Sebastian Ene
Cc: oupton, will, ayrton, catalin.marinas, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui, stable
In-Reply-To: <aejOu98q1lEZoFfW@google.com>
On Wed, 22 Apr 2026 14:35:55 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> On Wed, Apr 22, 2026 at 01:24:02PM +0100, Marc Zyngier wrote:
> > On Wed, 22 Apr 2026 11:25:40 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > Prevent the pKVM hypervisor from making assumptions that the
> > > endpoint memory access descriptor (EMAD) comes right after the
> > > FF-A memory region header and enforce a strict placement for it
> > > when validating an FF-A memory lend/share transaction.
>
> Hello Marc,
>
> >
> > As I read this, you want to remove a bad assumption...
> >
> > >
> > > Prior to FF-A version 1.1 the header of the memory region
> > > didn't contain an offset to the endpoint memory access descriptor.
> > > The layout of a memory transaction looks like this:
> > >
> > > Field name | Offset
> > > -- 0
> > > [ Header (ffa_mem_region) |__ ep_mem_offset
> > > EMAD 1 (ffa_mem_region_attributes) |
> > > ]
> > >
> > > Reject the host from specifying a memory access descriptor offset
> > > that is different than the size of the memory region header.
> >
> > And yet you decide that you want to enforce this assumption. I don't
> > understand how you arrive to this conclusion.
> >
> > Looking at the spec, it appears that the offset is *designed* to allow
> > a gap between the header and the EMAD. Refusing to handle a it seems to be a
> > violation of the spec.
> >
> > What am I missing?
>
> While the spec allows the gap to be variable (since version 1.1), the
> arm ff-a driver places it at a fixed position in:
> ffa_mem_region_additional_setup()
> https://elixir.bootlin.com/linux/v7.0/source/drivers/firmware/arm_ffa/driver.c#L671
That's an implementation detail, and you shouldn't rely on this.
> and makes use of the same assumption in: ffa_mem_desc_offset().
> https://elixir.bootlin.com/linux/v7.0/source/include/linux/arm_ffa.h#L448
> The later one seems wrong IMO. because we should compute the offset
> based on the value stored in ep_mem_offset and not adding it up with
> sizeof(struct ffa_mem_region).
>
> Maybe this should be the fix instead and not the one in pKVM ? What do
> you think ?
I think you should parse the buffers as the spec intends them, without
assumptions or limitations.
>
> The current implementation in pKVM makes use of the
> ffa_mem_desc_offset() to validate the first EMAD. If a compromised host
> places an EMAD at a different offset than sizeof(struct ffa_mem_region),
> then pKVM will not validate that EMAD.
Why compromised? Isn't that a perfectly valid thing to do? What I
understand is that the FFA 1.1 implementation in pKVM doesn't match
the expectations of the spec. If that's indeed the case, pKVM should
be fixed to accept these messages correctly, or stop using FFA 1.1.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] crypto: ixp4xx: Fix null-pointer dereference in chainup_buffers()
From: Herbert Xu @ 2026-04-23 8:11 UTC (permalink / raw)
To: Ruoyu Wang
Cc: clabbe, linusw, kaloz, davem, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260421093917.1001688-1-ruoyuw560@gmail.com>
On Tue, Apr 21, 2026 at 05:39:17PM +0800, Ruoyu Wang wrote:
> chainup_buffers() builds a linked list of buffer descriptors for a
> scatterlist. If dma_pool_alloc() fails while constructing the list, the
> current code sets buf to NULL and later dereferences it unconditionally
> at the end of the function:
>
> buf->next = NULL;
> buf->phys_next = 0;
>
> This can lead to a null-pointer dereference on allocation failure.
>
> If the failure happens after part of the descriptor chain has already
> been allocated and DMA-mapped, the partially constructed chain also
> needs to be released.
>
> Fix this by unwinding the partially constructed chain, resetting the
> caller-provided hook descriptor, and returning NULL on allocation
> failure.
>
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c | 24 +++++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> index fcc0cf4df637..63ef28cd5766 100644
> --- a/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> +++ b/drivers/crypto/intel/ixp4xx/ixp4xx_crypto.c
> @@ -874,6 +874,11 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> struct buffer_desc *buf, gfp_t flags,
> enum dma_data_direction dir)
> {
> + struct buffer_desc *first = buf;
> +
> + first->next = NULL;
> + first->phys_next = 0;
> +
> for (; nbytes > 0; sg = sg_next(sg)) {
> unsigned int len = min(nbytes, sg->length);
> struct buffer_desc *next_buf;
> @@ -883,10 +888,15 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> nbytes -= len;
> ptr = sg_virt(sg);
> next_buf = dma_pool_alloc(buffer_pool, flags, &next_buf_phys);
> - if (!next_buf) {
> - buf = NULL;
> - break;
> - }
> + if (!next_buf)
> + goto err_unwind;
> +
> + /*
> + * Keep the chain well-formed even on partial construction,
> + * so free_buf_chain() can safely unwind it on failure.
> + */
> + next_buf->next = NULL;
> + next_buf->phys_next = 0;
> sg_dma_address(sg) = dma_map_single(dev, ptr, len, dir);
> buf->next = next_buf;
> buf->phys_next = next_buf_phys;
> @@ -899,6 +909,12 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
> buf->next = NULL;
> buf->phys_next = 0;
> return buf;
> +
> +err_unwind:
> + free_buf_chain(dev, first->next, first->phys_next);
> + first->next = NULL;
> + first->phys_next = 0;
> + return NULL;
All callers of chainup_buffers try to unwind by calling free_buf_chain
too, although a couple of them might do so incorrectly.
It looks like the callers need the unwind path anyway, so perhaps
just fix up the callers so that their unwind paths actually work?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix BQL imbalance in TX path
From: Lorenzo Bianconi @ 2026-04-23 8:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Hariprasad Kelam
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4017 bytes --]
> Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight
> packets are accounted only for the AIROHA_NUM_TX_RING netdev TX
> queues. The queue index is computed as:
>
> qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx)
> txq = netdev_get_tx_queue(dev, qid);
>
> However, airoha_qdma_tx_napi_poll() accounts completions across all
> netdev TX queues (num_tx_queues), leading to inconsistent BQL
> accounting.
>
> Also reset all netdev TX queues in the ndo_stop callback.
>
> Fixes: 1d304174106c ("net: airoha: Implement BQL support")
> Fixes: c9f947769b77 ("net: airoha: Reset BQL stopping the netdevice")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 19f67c7dd8e1..6c7390f0de5d 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -929,10 +929,9 @@ static int airoha_qdma_tx_napi_poll(struct napi_struct *napi, int budget)
> q->queued--;
>
> if (skb) {
> - u16 queue = skb_get_queue_mapping(skb);
> struct netdev_queue *txq;
>
> - txq = netdev_get_tx_queue(skb->dev, queue);
> + txq = skb_get_tx_queue(skb->dev, skb);
> netdev_tx_completed_queue(txq, 1, skb->len);
> dev_kfree_skb_any(skb);
> }
> @@ -1711,7 +1710,7 @@ static int airoha_dev_stop(struct net_device *dev)
> if (err)
> return err;
>
> - for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> + for (i = 0; i < dev->num_tx_queues; i++)
> netdev_tx_reset_subqueue(dev, i);
>
> airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> @@ -2002,7 +2001,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>
> spin_lock_bh(&q->lock);
>
> - txq = netdev_get_tx_queue(dev, qid);
> + txq = skb_get_tx_queue(dev, skb);
> nr_frags = 1 + skb_shinfo(skb)->nr_frags;
>
> if (q->queued + nr_frags >= q->ndesc) {
>
> ---
> base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
> change-id: 20260421-airoha-fix-bql-7fff7cebbc9a
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
commenting on Sashiko reported issues:
https://sashiko.dev/#/patchset/20260421-airoha-fix-bql-v1-1-f135afe4275b%40kernel.org
- This isn't a bug in this patch, but does using 0xff as a sentinel value cause a permanent stall?
I do not think this is a real issue since, according to my understanding, the NIC
never writes 0xff in irq_q queue.
- This is another pre-existing issue, but does freeing the SKB here cause a DMA use-after-free
for multi-fragment packets?
This issue is not related to this patch, and I will fix it in a dedicated
patch storing the skb pointer in the last descriptor in airoha_dev_xmit()
- Since the QDMA hardware and NAPI instance are shared among multiple ports (qdma->users),
could active NAPI polling cause a BUG_ON() in dql_completed()?
This is not an issue related to this patch since here we are just resetting
all the netdev tx queues instead of just the first ARRAY_SIZE(qdma->q_tx)
ones.
- This isn't a bug in this patch, but does failing to wait for the DMA engines to become
idle before unmapping buffers cause memory corruption?
This issue is not related to this patch and it will be fixed with a dedicated
patch.
- This is also pre-existing, but can this mapping cause a kernel panic on highmem systems?
Can we have fragments in high memory? e.g on ARM architecture? Anyway, as
pointed out by Sashiko, this issue is not related to this patch.
- This isn't introduced here, but does this logic cause a permanent TX stall?
this issue is already fixed in the following patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org/
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 0/7] media: synopsys: enhancements and i.MX95 support
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
This series enhances the Synopsys DesignWare MIPI CSI-2 receiver driver
with multiple stream support and adds i.MX95 platform support.
The i.MX95 variant is similar to i.MX93 but uses IDI instead of IPI. Since
IDI is software transparent, only a different register map is needed.
Tested on i.MX93 and i.MX95 platforms.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Add two new patches
- Simplify error handling by keeping goto labels instead of early returns
- Removes redundant register availability check
- Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
readl_poll_timeout() with direct register address
- Fixes stopstate condition logic
- Check PHY stopstate after sensor enable instead of before to ensure
correct timing.
- Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
balance performance and responsiveness.
- Add dedicated constraint block for i.MX95 to reflect different clock
requirements (only per clock needed vs i.MX93 which needs both per and
pixel clocks)
- Update commit message to include more details about interface differences
- Add Reviewed-by tag from Frank Li <Frank.Li@nxp.com>
- Update commit message
- See each patch's changelog for details.
- Link to v1: https://lore.kernel.org/r/20260415-csi2_imx95-v1-0-7d63f3508719@oss.nxp.com
---
Guoniu Zhou (7):
media: synopsys: Fix out-of-bounds check in enum_mbus_code
media: synopsys: Fix IPI using hardcoded datatype
media: synopsys: Add support for RAW16 Bayer formats
media: synopsys: Add support for multiple streams
media: synopsys: Add PHY stopstate wait for i.MX93
media: dt-bindings: add NXP i.MX95 compatible string
media: synopsys: Add support for i.MX95
.../bindings/media/rockchip,rk3568-mipi-csi2.yaml | 16 +++
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 109 +++++++++++++++++++--
2 files changed, 118 insertions(+), 7 deletions(-)
---
base-commit: 4fbeef21f5387234111b5d52924e77757626faa5
change-id: 20260414-csi2_imx95-65ad0e7f630a
Best regards,
--
Guoniu Zhou <guoniu.zhou@oss.nxp.com>
^ permalink raw reply
* [PATCH v2 1/7] media: synopsys: Fix out-of-bounds check in enum_mbus_code
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
dw_mipi_csi2rx_enum_mbus_code() contains an off-by-one error in the
bounds check for code->index, allowing an access past the end of the
formats array.
Fixes: 355a11004066 ("media: synopsys: add driver for the designware mipi csi-2 receiver")
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- New added in v2
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index ce17f986279e..02eb4a6cafad 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -430,7 +430,7 @@ dw_mipi_csi2rx_enum_mbus_code(struct v4l2_subdev *sd,
return 0;
case DW_MIPI_CSI2RX_PAD_SINK:
- if (code->index > csi2->formats_num)
+ if (code->index >= csi2->formats_num)
return -EINVAL;
code->code = csi2->formats[code->index].code;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/7] media: synopsys: Fix IPI using hardcoded datatype
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
The imx93_csi2rx_dphy_ipi_enable() function configures the IPI datatype
using csi2->formats->csi_dt, which is initialized during probe but never
updated in set_fmt(). This causes the IPI to always use the probe-time
default datatype, ignoring the actual media bus format negotiated at
runtime. When userspace requests a different format, the IPI hardware is
configured with the wrong datatype, resulting in incorrect image output.
Fix by updating csi2->formats in the set_fmt callback to reflect the
currently negotiated format, ensuring the IPI configuration matches the
runtime datatype.
Fixes: ec40b431f0ab ("media: synopsys: csi2rx: add i.MX93 support")
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- New added in v2
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index 02eb4a6cafad..b3f90da8b43c 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -470,6 +470,11 @@ static int dw_mipi_csi2rx_set_fmt(struct v4l2_subdev *sd,
*src = *sink;
+ /* Store the CSIS format descriptor for active formats. */
+ if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE)
+ csi2->formats = fmt ? :
+ dw_mipi_csi2rx_find_format(csi2, default_format.code);
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/7] media: synopsys: Add support for RAW16 Bayer formats
From: Guoniu Zhou @ 2026-04-23 8:22 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com>
Add higher bit-depth raw image data support for the sensors, which supports
16-bit output.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Update commit message
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index b3f90da8b43c..d572d2eb3bcb 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -252,6 +252,26 @@ static const struct dw_mipi_csi2rx_format formats[] = {
.depth = 12,
.csi_dt = MIPI_CSI2_DT_RAW12,
},
+ {
+ .code = MEDIA_BUS_FMT_SBGGR16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SGBRG16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SGRBG16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SRGGB16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
};
static inline struct dw_mipi_csi2rx_device *to_csi2(struct v4l2_subdev *sd)
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox