From: Tzung-Bi Shih <tzungbi@google.com>
To: Yunfei Dong <yunfei.dong@mediatek.com>
Cc: Alexandre Courbot <acourbot@chromium.org>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Tzung-Bi Shih <tzungbi@chromium.org>,
Tiffany Lin <tiffany.lin@mediatek.com>,
Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Tomasz Figa <tfiga@google.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Fritz Koenig <frkoenig@chromium.org>,
Dafna Hirschfeld <dafna.hirschfeld@collabora.com>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Daniel Vetter <daniel@ffwll.ch>,
dri-devel <dri-devel@lists.freedesktop.org>,
Irui Wang <irui.wang@mediatek.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Steve Cho <stevecho@chromium.org>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org,
Project_Global_Chrome_Upstream_Group@mediatek.com
Subject: Re: [PATCH v2, 03/12] media: mtk-vcodec: get capture queue buffer size from scp
Date: Wed, 29 Dec 2021 13:36:33 +0800 [thread overview]
Message-ID: <Ycvz4UrmbngVzIv2@google.com> (raw)
In-Reply-To: <20211228094146.20505-4-yunfei.dong@mediatek.com>
On Tue, Dec 28, 2021 at 05:41:37PM +0800, Yunfei Dong wrote:
> From: Yunfei Dong <yunfei.dong@mediatek.corp-partner.google.com>
[...]
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> index 130ecef2e766..87891ebd7246 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> @@ -466,6 +466,8 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
> }
> ctx->state = MTK_STATE_INIT;
> }
> + } else {
> + ctx->capture_fourcc = fmt->fourcc;
> }
>
> /*
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index a23a7646437c..95e07cf2cd3e 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -277,6 +277,7 @@ struct vdec_pic_info {
> * to be used with encoder and stateful decoder.
> * @is_flushing: set to true if flushing is in progress.
> * @current_codec: current set input codec, in V4L2 pixel format
> + * @capture_fourcc: capture queue type in V4L2 pixel format
> *
> * @colorspace: enum v4l2_colorspace; supplemental to pixelformat
> * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
> @@ -322,6 +323,7 @@ struct mtk_vcodec_ctx {
> bool is_flushing;
>
> u32 current_codec;
> + u32 capture_fourcc;
What is the purpose of capture_fourcc? It is not used.
> +/**
> + * struct vdec_ap_ipi_get_param - for AP_IPIMSG_SET_PARAM
> + * @msg_id : AP_IPIMSG_DEC_START
> + * @inst_id : instance ID. Used if the ABI version >= 2.
> + * @data : picture information
> + * @param_type : get param type
> + * @codec_type : Codec fourcc
> + */
> +struct vdec_ap_ipi_get_param {
> + uint32_t msg_id;
> + uint32_t inst_id;
> + uint32_t data[4];
> + uint32_t param_type;
> + uint32_t codec_type;
> +};
Are AP_IPIMSG_SET_PARAM and AP_IPIMSG_DEC_START typos?
> +/**
> + * struct vdec_vpu_ipi_init_ack - for VPU_IPIMSG_DEC_INIT_ACK
> + * @msg_id : VPU_IPIMSG_DEC_INIT_ACK
> + * @status : VPU exeuction result
> + * @ap_inst_addr : AP vcodec_vpu_inst instance address
> + * @data : picture information from SCP.
> + * @param_type : get param type
> + */
> +struct vdec_vpu_ipi_get_param_ack {
> + uint32_t msg_id;
> + int32_t status;
> + uint64_t ap_inst_addr;
> + uint32_t data[4];
> + uint32_t param_type;
> + uint32_t reserved;
> +};
Same here: is VPU_IPIMSG_DEC_INIT_ACK a typo?
What is the purpose of the "reserved" field?
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
[...]
> +static void handle_get_param_msg_ack(
> + const struct vdec_vpu_ipi_get_param_ack *msg)
> +{
> + struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)
> + (unsigned long)msg->ap_inst_addr;
Does it really need to cast twice?
> +
> + mtk_vcodec_debug(vpu, "+ ap_inst_addr = 0x%llx", msg->ap_inst_addr);
> +
> + /* param_type is enum vdec_get_param_type */
> + switch(msg->param_type) {
> + case 2:
What is 2? Is it GET_PARAM_PIC_INFO?
> +int vpu_dec_get_param(struct vdec_vpu_inst *vpu, uint32_t *data,
> + unsigned int len, unsigned int param_type)
> +{
> + struct vdec_ap_ipi_get_param msg;
> + int i;
> + int err;
> +
> + mtk_vcodec_debug_enter(vpu);
> +
> + if (len > ARRAY_SIZE(msg.data)) {
> + mtk_vcodec_err(vpu, "invalid len = %d\n", len);
> + return -EINVAL;
> + }
> +
> + memset(&msg, 0, sizeof(msg));
> + msg.msg_id = AP_IPIMSG_DEC_GET_PARAM;
> + msg.inst_id = vpu->inst_id;
> + for (i = 0; i < len; i++)
> + msg.data[i] = data[i];
Would it be more concise if using memcpy?
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> index 4cb3c7f5a3ad..963f8d4877b7 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> @@ -28,6 +28,8 @@ struct mtk_vcodec_ctx;
> * @wq : wait queue to wait VPU message ack
> * @handler : ipi handler for each decoder
> * @codec_type : use codec type to separate different codecs
> + * @capture_type : used capture type to separate different capture format
> + * @fb_sz : frame buffer size of each plane
> */
> struct vdec_vpu_inst {
> int id;
> @@ -42,6 +44,8 @@ struct vdec_vpu_inst {
> wait_queue_head_t wq;
> mtk_vcodec_ipi_handler handler;
> unsigned int codec_type;
> + unsigned int capture_type;
> + unsigned int fb_sz[2];
> };
capture_type is not used in the patch.
Does fb_sz take effect in later patches?
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Tzung-Bi Shih <tzungbi@google.com>
To: Yunfei Dong <yunfei.dong@mediatek.com>
Cc: Alexandre Courbot <acourbot@chromium.org>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Tzung-Bi Shih <tzungbi@chromium.org>,
Tiffany Lin <tiffany.lin@mediatek.com>,
Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Tomasz Figa <tfiga@google.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Fritz Koenig <frkoenig@chromium.org>,
Dafna Hirschfeld <dafna.hirschfeld@collabora.com>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Daniel Vetter <daniel@ffwll.ch>,
dri-devel <dri-devel@lists.freedesktop.org>,
Irui Wang <irui.wang@mediatek.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Steve Cho <stevecho@chromium.org>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org,
Project_Global_Chrome_Upstream_Group@mediatek.com
Subject: Re: [PATCH v2, 03/12] media: mtk-vcodec: get capture queue buffer size from scp
Date: Wed, 29 Dec 2021 13:36:33 +0800 [thread overview]
Message-ID: <Ycvz4UrmbngVzIv2@google.com> (raw)
In-Reply-To: <20211228094146.20505-4-yunfei.dong@mediatek.com>
On Tue, Dec 28, 2021 at 05:41:37PM +0800, Yunfei Dong wrote:
> From: Yunfei Dong <yunfei.dong@mediatek.corp-partner.google.com>
[...]
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> index 130ecef2e766..87891ebd7246 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> @@ -466,6 +466,8 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
> }
> ctx->state = MTK_STATE_INIT;
> }
> + } else {
> + ctx->capture_fourcc = fmt->fourcc;
> }
>
> /*
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index a23a7646437c..95e07cf2cd3e 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -277,6 +277,7 @@ struct vdec_pic_info {
> * to be used with encoder and stateful decoder.
> * @is_flushing: set to true if flushing is in progress.
> * @current_codec: current set input codec, in V4L2 pixel format
> + * @capture_fourcc: capture queue type in V4L2 pixel format
> *
> * @colorspace: enum v4l2_colorspace; supplemental to pixelformat
> * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
> @@ -322,6 +323,7 @@ struct mtk_vcodec_ctx {
> bool is_flushing;
>
> u32 current_codec;
> + u32 capture_fourcc;
What is the purpose of capture_fourcc? It is not used.
> +/**
> + * struct vdec_ap_ipi_get_param - for AP_IPIMSG_SET_PARAM
> + * @msg_id : AP_IPIMSG_DEC_START
> + * @inst_id : instance ID. Used if the ABI version >= 2.
> + * @data : picture information
> + * @param_type : get param type
> + * @codec_type : Codec fourcc
> + */
> +struct vdec_ap_ipi_get_param {
> + uint32_t msg_id;
> + uint32_t inst_id;
> + uint32_t data[4];
> + uint32_t param_type;
> + uint32_t codec_type;
> +};
Are AP_IPIMSG_SET_PARAM and AP_IPIMSG_DEC_START typos?
> +/**
> + * struct vdec_vpu_ipi_init_ack - for VPU_IPIMSG_DEC_INIT_ACK
> + * @msg_id : VPU_IPIMSG_DEC_INIT_ACK
> + * @status : VPU exeuction result
> + * @ap_inst_addr : AP vcodec_vpu_inst instance address
> + * @data : picture information from SCP.
> + * @param_type : get param type
> + */
> +struct vdec_vpu_ipi_get_param_ack {
> + uint32_t msg_id;
> + int32_t status;
> + uint64_t ap_inst_addr;
> + uint32_t data[4];
> + uint32_t param_type;
> + uint32_t reserved;
> +};
Same here: is VPU_IPIMSG_DEC_INIT_ACK a typo?
What is the purpose of the "reserved" field?
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
[...]
> +static void handle_get_param_msg_ack(
> + const struct vdec_vpu_ipi_get_param_ack *msg)
> +{
> + struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)
> + (unsigned long)msg->ap_inst_addr;
Does it really need to cast twice?
> +
> + mtk_vcodec_debug(vpu, "+ ap_inst_addr = 0x%llx", msg->ap_inst_addr);
> +
> + /* param_type is enum vdec_get_param_type */
> + switch(msg->param_type) {
> + case 2:
What is 2? Is it GET_PARAM_PIC_INFO?
> +int vpu_dec_get_param(struct vdec_vpu_inst *vpu, uint32_t *data,
> + unsigned int len, unsigned int param_type)
> +{
> + struct vdec_ap_ipi_get_param msg;
> + int i;
> + int err;
> +
> + mtk_vcodec_debug_enter(vpu);
> +
> + if (len > ARRAY_SIZE(msg.data)) {
> + mtk_vcodec_err(vpu, "invalid len = %d\n", len);
> + return -EINVAL;
> + }
> +
> + memset(&msg, 0, sizeof(msg));
> + msg.msg_id = AP_IPIMSG_DEC_GET_PARAM;
> + msg.inst_id = vpu->inst_id;
> + for (i = 0; i < len; i++)
> + msg.data[i] = data[i];
Would it be more concise if using memcpy?
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> index 4cb3c7f5a3ad..963f8d4877b7 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> @@ -28,6 +28,8 @@ struct mtk_vcodec_ctx;
> * @wq : wait queue to wait VPU message ack
> * @handler : ipi handler for each decoder
> * @codec_type : use codec type to separate different codecs
> + * @capture_type : used capture type to separate different capture format
> + * @fb_sz : frame buffer size of each plane
> */
> struct vdec_vpu_inst {
> int id;
> @@ -42,6 +44,8 @@ struct vdec_vpu_inst {
> wait_queue_head_t wq;
> mtk_vcodec_ipi_handler handler;
> unsigned int codec_type;
> + unsigned int capture_type;
> + unsigned int fb_sz[2];
> };
capture_type is not used in the patch.
Does fb_sz take effect in later patches?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Tzung-Bi Shih <tzungbi@google.com>
To: Yunfei Dong <yunfei.dong@mediatek.com>
Cc: Alexandre Courbot <acourbot@chromium.org>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Tzung-Bi Shih <tzungbi@chromium.org>,
Tiffany Lin <tiffany.lin@mediatek.com>,
Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Tomasz Figa <tfiga@google.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Fritz Koenig <frkoenig@chromium.org>,
Dafna Hirschfeld <dafna.hirschfeld@collabora.com>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Daniel Vetter <daniel@ffwll.ch>,
dri-devel <dri-devel@lists.freedesktop.org>,
Irui Wang <irui.wang@mediatek.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Steve Cho <stevecho@chromium.org>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org,
Project_Global_Chrome_Upstream_Group@mediatek.com
Subject: Re: [PATCH v2, 03/12] media: mtk-vcodec: get capture queue buffer size from scp
Date: Wed, 29 Dec 2021 13:36:33 +0800 [thread overview]
Message-ID: <Ycvz4UrmbngVzIv2@google.com> (raw)
In-Reply-To: <20211228094146.20505-4-yunfei.dong@mediatek.com>
On Tue, Dec 28, 2021 at 05:41:37PM +0800, Yunfei Dong wrote:
> From: Yunfei Dong <yunfei.dong@mediatek.corp-partner.google.com>
[...]
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> index 130ecef2e766..87891ebd7246 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> @@ -466,6 +466,8 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
> }
> ctx->state = MTK_STATE_INIT;
> }
> + } else {
> + ctx->capture_fourcc = fmt->fourcc;
> }
>
> /*
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index a23a7646437c..95e07cf2cd3e 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -277,6 +277,7 @@ struct vdec_pic_info {
> * to be used with encoder and stateful decoder.
> * @is_flushing: set to true if flushing is in progress.
> * @current_codec: current set input codec, in V4L2 pixel format
> + * @capture_fourcc: capture queue type in V4L2 pixel format
> *
> * @colorspace: enum v4l2_colorspace; supplemental to pixelformat
> * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
> @@ -322,6 +323,7 @@ struct mtk_vcodec_ctx {
> bool is_flushing;
>
> u32 current_codec;
> + u32 capture_fourcc;
What is the purpose of capture_fourcc? It is not used.
> +/**
> + * struct vdec_ap_ipi_get_param - for AP_IPIMSG_SET_PARAM
> + * @msg_id : AP_IPIMSG_DEC_START
> + * @inst_id : instance ID. Used if the ABI version >= 2.
> + * @data : picture information
> + * @param_type : get param type
> + * @codec_type : Codec fourcc
> + */
> +struct vdec_ap_ipi_get_param {
> + uint32_t msg_id;
> + uint32_t inst_id;
> + uint32_t data[4];
> + uint32_t param_type;
> + uint32_t codec_type;
> +};
Are AP_IPIMSG_SET_PARAM and AP_IPIMSG_DEC_START typos?
> +/**
> + * struct vdec_vpu_ipi_init_ack - for VPU_IPIMSG_DEC_INIT_ACK
> + * @msg_id : VPU_IPIMSG_DEC_INIT_ACK
> + * @status : VPU exeuction result
> + * @ap_inst_addr : AP vcodec_vpu_inst instance address
> + * @data : picture information from SCP.
> + * @param_type : get param type
> + */
> +struct vdec_vpu_ipi_get_param_ack {
> + uint32_t msg_id;
> + int32_t status;
> + uint64_t ap_inst_addr;
> + uint32_t data[4];
> + uint32_t param_type;
> + uint32_t reserved;
> +};
Same here: is VPU_IPIMSG_DEC_INIT_ACK a typo?
What is the purpose of the "reserved" field?
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
[...]
> +static void handle_get_param_msg_ack(
> + const struct vdec_vpu_ipi_get_param_ack *msg)
> +{
> + struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)
> + (unsigned long)msg->ap_inst_addr;
Does it really need to cast twice?
> +
> + mtk_vcodec_debug(vpu, "+ ap_inst_addr = 0x%llx", msg->ap_inst_addr);
> +
> + /* param_type is enum vdec_get_param_type */
> + switch(msg->param_type) {
> + case 2:
What is 2? Is it GET_PARAM_PIC_INFO?
> +int vpu_dec_get_param(struct vdec_vpu_inst *vpu, uint32_t *data,
> + unsigned int len, unsigned int param_type)
> +{
> + struct vdec_ap_ipi_get_param msg;
> + int i;
> + int err;
> +
> + mtk_vcodec_debug_enter(vpu);
> +
> + if (len > ARRAY_SIZE(msg.data)) {
> + mtk_vcodec_err(vpu, "invalid len = %d\n", len);
> + return -EINVAL;
> + }
> +
> + memset(&msg, 0, sizeof(msg));
> + msg.msg_id = AP_IPIMSG_DEC_GET_PARAM;
> + msg.inst_id = vpu->inst_id;
> + for (i = 0; i < len; i++)
> + msg.data[i] = data[i];
Would it be more concise if using memcpy?
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> index 4cb3c7f5a3ad..963f8d4877b7 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> @@ -28,6 +28,8 @@ struct mtk_vcodec_ctx;
> * @wq : wait queue to wait VPU message ack
> * @handler : ipi handler for each decoder
> * @codec_type : use codec type to separate different codecs
> + * @capture_type : used capture type to separate different capture format
> + * @fb_sz : frame buffer size of each plane
> */
> struct vdec_vpu_inst {
> int id;
> @@ -42,6 +44,8 @@ struct vdec_vpu_inst {
> wait_queue_head_t wq;
> mtk_vcodec_ipi_handler handler;
> unsigned int codec_type;
> + unsigned int capture_type;
> + unsigned int fb_sz[2];
> };
capture_type is not used in the patch.
Does fb_sz take effect in later patches?
WARNING: multiple messages have this Message-ID (diff)
From: Tzung-Bi Shih <tzungbi@google.com>
To: Yunfei Dong <yunfei.dong@mediatek.com>
Cc: Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
Dafna Hirschfeld <dafna.hirschfeld@collabora.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Steve Cho <stevecho@chromium.org>,
Irui Wang <irui.wang@mediatek.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Fritz Koenig <frkoenig@chromium.org>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
Tzung-Bi Shih <tzungbi@chromium.org>,
Tomasz Figa <tfiga@google.com>, Rob Herring <robh+dt@kernel.org>,
linux-mediatek@lists.infradead.org,
Hsin-Yi Wang <hsinyi@chromium.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Tiffany Lin <tiffany.lin@mediatek.com>,
linux-arm-kernel@lists.infradead.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
srv_heupstream@mediatek.com,
Alexandre Courbot <acourbot@chromium.org>,
linux-kernel@vger.kernel.org,
Hans Verkuil <hverkuil-cisco@xs4all.nl>
Subject: Re: [PATCH v2, 03/12] media: mtk-vcodec: get capture queue buffer size from scp
Date: Wed, 29 Dec 2021 13:36:33 +0800 [thread overview]
Message-ID: <Ycvz4UrmbngVzIv2@google.com> (raw)
In-Reply-To: <20211228094146.20505-4-yunfei.dong@mediatek.com>
On Tue, Dec 28, 2021 at 05:41:37PM +0800, Yunfei Dong wrote:
> From: Yunfei Dong <yunfei.dong@mediatek.corp-partner.google.com>
[...]
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> index 130ecef2e766..87891ebd7246 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> @@ -466,6 +466,8 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
> }
> ctx->state = MTK_STATE_INIT;
> }
> + } else {
> + ctx->capture_fourcc = fmt->fourcc;
> }
>
> /*
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index a23a7646437c..95e07cf2cd3e 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -277,6 +277,7 @@ struct vdec_pic_info {
> * to be used with encoder and stateful decoder.
> * @is_flushing: set to true if flushing is in progress.
> * @current_codec: current set input codec, in V4L2 pixel format
> + * @capture_fourcc: capture queue type in V4L2 pixel format
> *
> * @colorspace: enum v4l2_colorspace; supplemental to pixelformat
> * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
> @@ -322,6 +323,7 @@ struct mtk_vcodec_ctx {
> bool is_flushing;
>
> u32 current_codec;
> + u32 capture_fourcc;
What is the purpose of capture_fourcc? It is not used.
> +/**
> + * struct vdec_ap_ipi_get_param - for AP_IPIMSG_SET_PARAM
> + * @msg_id : AP_IPIMSG_DEC_START
> + * @inst_id : instance ID. Used if the ABI version >= 2.
> + * @data : picture information
> + * @param_type : get param type
> + * @codec_type : Codec fourcc
> + */
> +struct vdec_ap_ipi_get_param {
> + uint32_t msg_id;
> + uint32_t inst_id;
> + uint32_t data[4];
> + uint32_t param_type;
> + uint32_t codec_type;
> +};
Are AP_IPIMSG_SET_PARAM and AP_IPIMSG_DEC_START typos?
> +/**
> + * struct vdec_vpu_ipi_init_ack - for VPU_IPIMSG_DEC_INIT_ACK
> + * @msg_id : VPU_IPIMSG_DEC_INIT_ACK
> + * @status : VPU exeuction result
> + * @ap_inst_addr : AP vcodec_vpu_inst instance address
> + * @data : picture information from SCP.
> + * @param_type : get param type
> + */
> +struct vdec_vpu_ipi_get_param_ack {
> + uint32_t msg_id;
> + int32_t status;
> + uint64_t ap_inst_addr;
> + uint32_t data[4];
> + uint32_t param_type;
> + uint32_t reserved;
> +};
Same here: is VPU_IPIMSG_DEC_INIT_ACK a typo?
What is the purpose of the "reserved" field?
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
[...]
> +static void handle_get_param_msg_ack(
> + const struct vdec_vpu_ipi_get_param_ack *msg)
> +{
> + struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)
> + (unsigned long)msg->ap_inst_addr;
Does it really need to cast twice?
> +
> + mtk_vcodec_debug(vpu, "+ ap_inst_addr = 0x%llx", msg->ap_inst_addr);
> +
> + /* param_type is enum vdec_get_param_type */
> + switch(msg->param_type) {
> + case 2:
What is 2? Is it GET_PARAM_PIC_INFO?
> +int vpu_dec_get_param(struct vdec_vpu_inst *vpu, uint32_t *data,
> + unsigned int len, unsigned int param_type)
> +{
> + struct vdec_ap_ipi_get_param msg;
> + int i;
> + int err;
> +
> + mtk_vcodec_debug_enter(vpu);
> +
> + if (len > ARRAY_SIZE(msg.data)) {
> + mtk_vcodec_err(vpu, "invalid len = %d\n", len);
> + return -EINVAL;
> + }
> +
> + memset(&msg, 0, sizeof(msg));
> + msg.msg_id = AP_IPIMSG_DEC_GET_PARAM;
> + msg.inst_id = vpu->inst_id;
> + for (i = 0; i < len; i++)
> + msg.data[i] = data[i];
Would it be more concise if using memcpy?
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> index 4cb3c7f5a3ad..963f8d4877b7 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
> @@ -28,6 +28,8 @@ struct mtk_vcodec_ctx;
> * @wq : wait queue to wait VPU message ack
> * @handler : ipi handler for each decoder
> * @codec_type : use codec type to separate different codecs
> + * @capture_type : used capture type to separate different capture format
> + * @fb_sz : frame buffer size of each plane
> */
> struct vdec_vpu_inst {
> int id;
> @@ -42,6 +44,8 @@ struct vdec_vpu_inst {
> wait_queue_head_t wq;
> mtk_vcodec_ipi_handler handler;
> unsigned int codec_type;
> + unsigned int capture_type;
> + unsigned int fb_sz[2];
> };
capture_type is not used in the patch.
Does fb_sz take effect in later patches?
next prev parent reply other threads:[~2021-12-29 5:37 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-28 9:41 [PATCH v2, 00/12] media: mtk-vcodec: support for MT8192 decoder Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` [PATCH v2, 01/12] media: mtk-vcodec: Add vdec enable/disable hardware helpers Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-29 5:35 ` Tzung-Bi Shih
2021-12-29 5:35 ` Tzung-Bi Shih
2021-12-29 5:35 ` Tzung-Bi Shih
2021-12-29 5:35 ` Tzung-Bi Shih
2021-12-28 9:41 ` [PATCH v2, 02/12] media: mtk-vcodec: Using firmware type to separate different firmware architecture Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-29 5:36 ` Tzung-Bi Shih
2021-12-29 5:36 ` Tzung-Bi Shih
2021-12-29 5:36 ` Tzung-Bi Shih
2021-12-29 5:36 ` Tzung-Bi Shih
2021-12-28 9:41 ` [PATCH v2, 03/12] media: mtk-vcodec: get capture queue buffer size from scp Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-29 5:36 ` Tzung-Bi Shih [this message]
2021-12-29 5:36 ` Tzung-Bi Shih
2021-12-29 5:36 ` Tzung-Bi Shih
2021-12-29 5:36 ` Tzung-Bi Shih
2021-12-29 6:52 ` yunfei.dong
2021-12-29 6:52 ` yunfei.dong
2021-12-29 6:52 ` yunfei.dong
2021-12-29 6:52 ` yunfei.dong
2021-12-29 7:27 ` Tzung-Bi Shih
2021-12-29 7:27 ` Tzung-Bi Shih
2021-12-29 7:27 ` Tzung-Bi Shih
2021-12-29 7:27 ` Tzung-Bi Shih
2021-12-28 9:41 ` [PATCH v2, 04/12] media: mtk-vcodec: Read max resolution from dec_capability Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-29 5:56 ` Tzung-Bi Shih
2021-12-29 5:56 ` Tzung-Bi Shih
2021-12-29 5:56 ` Tzung-Bi Shih
2021-12-29 5:56 ` Tzung-Bi Shih
2021-12-28 9:41 ` [PATCH v2, 05/12] media: mtk-vcodec: Call v4l2_m2m_set_dst_buffered() set capture buffer buffered Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-29 6:36 ` Tzung-Bi Shih
2021-12-29 6:36 ` Tzung-Bi Shih
2021-12-29 6:36 ` Tzung-Bi Shih
2021-12-29 6:36 ` Tzung-Bi Shih
2021-12-28 9:41 ` [PATCH v2, 06/12] media: mtk-vcodec: Refactor get and put capture buffer flow Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` [PATCH v2, 07/12] media: mtk-vcodec: Refactor supported vdec formats and framesizes Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` [PATCH v2, 08/12] media: mtk-vcodec: Add format to support MT21C Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` [PATCH v2, 09/12] media: mtk-vcodec: disable vp8 4K capability Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` [PATCH v2, 10/12] media: mtk-vcodec: Fix v4l2-compliance fail Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` [PATCH v2, 11/12] media: mtk-vcodec: Extract H264 common code Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` [PATCH v2, 12/12] media: mtk-vcodec: Add h264 decoder driver for mt8192 Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
2021-12-28 9:41 ` Yunfei Dong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ycvz4UrmbngVzIv2@google.com \
--to=tzungbi@google.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=acourbot@chromium.org \
--cc=andrew-ct.chen@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=benjamin.gaignard@collabora.com \
--cc=dafna.hirschfeld@collabora.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=frkoenig@chromium.org \
--cc=hsinyi@chromium.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=irui.wang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=robh+dt@kernel.org \
--cc=srv_heupstream@mediatek.com \
--cc=stevecho@chromium.org \
--cc=tfiga@google.com \
--cc=tiffany.lin@mediatek.com \
--cc=tzungbi@chromium.org \
--cc=yunfei.dong@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.