All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	Irui Wang <irui.wang@mediatek.com>,
	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 v1, 07/14] media: mtk-vcodec: Add msg queue feature for lat and core architecture
Date: Fri, 9 Jul 2021 17:39:23 +0800	[thread overview]
Message-ID: <CA+Px+wUjJwksVfU6N8VZ9WMw-F-DHu67XwvDvMoiMcUBKF=P6Q@mail.gmail.com> (raw)
In-Reply-To: <20210707062157.21176-8-yunfei.dong@mediatek.com>

On Wed, Jul 7, 2021 at 2:22 PM Yunfei Dong <yunfei.dong@mediatek.com> wrote:
> @@ -464,6 +469,11 @@ struct mtk_vcodec_enc_pdata {
>   * comp_dev: component hardware device
>   * component_node: component node
>   * comp_idx: component index
> + *
> + * core_read: Wait queue used to signalize when core get useful lat buffer
> + * core_queue: List of V4L2 lat_buf
To be neat, replace "Wait" to "wait" and "List" to "list".

> +int vdec_msg_queue_init(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue,
> +       core_decode_cb_t core_decode,
> +       int private_size)
> +{
> +       struct vdec_lat_buf *lat_buf;
> +       int i, err;
> +
> +       init_waitqueue_head(&msg_queue->lat_read);
> +       INIT_LIST_HEAD(&msg_queue->lat_queue);
> +       spin_lock_init(&msg_queue->lat_lock);
> +       msg_queue->num_lat = 0;
> +
> +       msg_queue->wdma_addr.size = vde_msg_queue_get_trans_size(
> +               ctx->picinfo.buf_w, ctx->picinfo.buf_h);
> +
> +       err = mtk_vcodec_mem_alloc(ctx, &msg_queue->wdma_addr);
> +       if (err) {
> +               mtk_v4l2_err("failed to allocate wdma_addr buf");
> +               return -ENOMEM;
> +       }
> +       msg_queue->wdma_rptr_addr = msg_queue->wdma_addr.dma_addr;
> +       msg_queue->wdma_wptr_addr = msg_queue->wdma_addr.dma_addr;
> +
> +       for (i = 0; i < NUM_BUFFER_COUNT; i++) {
> +               lat_buf = &msg_queue->lat_buf[i];
> +
> +               lat_buf->wdma_err_addr.size = VDEC_ERR_MAP_SZ_AVC;
> +               err = mtk_vcodec_mem_alloc(ctx, &lat_buf->wdma_err_addr);
> +               if (err) {
> +                       mtk_v4l2_err("failed to allocate wdma_err_addr buf[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->slice_bc_addr.size = VDEC_LAT_SLICE_HEADER_SZ;
> +               err = mtk_vcodec_mem_alloc(ctx, &lat_buf->slice_bc_addr);
> +               if (err) {
> +                       mtk_v4l2_err("failed to allocate wdma_addr buf[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->private_data = kzalloc(private_size, GFP_KERNEL);
> +               if (!lat_buf->private_data) {
> +                       mtk_v4l2_err("failed to allocate private_data[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->ctx = ctx;
> +               lat_buf->core_decode = core_decode;
> +               vdec_msg_queue_buf_to_lat(lat_buf);
> +       }
Doesn't it need to call mtk_vcodec_mem_free() and kfree() for any failure paths?

> +struct vdec_lat_buf *vdec_msg_queue_get_core_buf(
> +       struct mtk_vcodec_dev *dev)
> +{
> +       struct vdec_lat_buf *buf;
> +       int ret;
> +
> +       spin_lock(&dev->core_lock);
> +       if (list_empty(&dev->core_queue)) {
> +               mtk_v4l2_debug(3, "core queue is NULL, num_core = %d", dev->num_core);
> +               spin_unlock(&dev->core_lock);
> +               ret = wait_event_freezable(dev->core_read,
> +                       !list_empty(&dev->core_queue));
> +               if (ret)
> +                       return NULL;
Should be !ret?

> +void vdec_msg_queue_buf_to_core(struct mtk_vcodec_dev *dev,
> +       struct vdec_lat_buf *buf)
> +{
> +       spin_lock(&dev->core_lock);
> +       list_add_tail(&buf->core_list, &dev->core_queue);
> +       dev->num_core++;
> +       wake_up_all(&dev->core_read);
> +       mtk_v4l2_debug(3, "queu buf addr: (0x%p)", buf);
Typo.

> +bool vdec_msg_queue_wait_lat_buf_full(struct vdec_msg_queue *msg_queue)
> +{
> +       long timeout_jiff;
> +       int ret, i;
> +
> +       for (i = 0; i < NUM_BUFFER_COUNT + 2; i++) {
> +              timeout_jiff = msecs_to_jiffies(1000);
> +              ret = wait_event_timeout(msg_queue->lat_read,
> +                    msg_queue->num_lat == NUM_BUFFER_COUNT, timeout_jiff);
> +              if (ret) {
> +                     mtk_v4l2_debug(3, "success to get lat buf: %d",
> +                            msg_queue->num_lat);
> +                     return true;
> +              }
> +       }
Why does it need the loop?  i is unused.

> +void vdec_msg_queue_deinit(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue)
> +{
> +       struct vdec_lat_buf *lat_buf;
> +       struct mtk_vcodec_mem *mem;
> +       int i;
> +
> +       mem = &msg_queue->wdma_addr;
> +       if (mem->va)
> +               mtk_vcodec_mem_free(ctx, mem);
> +       for (i = 0; i < NUM_BUFFER_COUNT; i++) {
> +               lat_buf = &msg_queue->lat_buf[i];
> +
> +               mem = &lat_buf->wdma_err_addr;
> +               if (mem->va)
> +                       mtk_vcodec_mem_free(ctx, mem);
> +
> +               mem = &lat_buf->slice_bc_addr;
> +               if (mem->va)
> +                       mtk_vcodec_mem_free(ctx, mem);
> +
> +               if (lat_buf->private_data)
> +                       kfree(lat_buf->private_data);
> +       }
> +
> +       msg_queue->init_done = false;
Have no idea what init_done does in the code.  It is not included in
any branch condition.

> +/**
> + * vdec_msg_queue_init - init lat buffer information.
> + * @ctx: v4l2 ctx
> + * @msg_queue: used to store the lat buffer information
> + * @core_decode: core decode callback for each codec
> + * @private_size: the private data size used to share with core
> + */
> +int vdec_msg_queue_init(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue,
> +       core_decode_cb_t core_decode,
> +       int private_size);
Would prefer to have *msg_queue as the first argument (also applies to
all operators of vdec_msg_queue).

> +/**
> + * vdec_msg_queue_get_core_buf - get used core buffer for lat decode.
> + * @dev: mtk vcodec device
> + */
> +struct vdec_lat_buf *vdec_msg_queue_get_core_buf(
> +       struct mtk_vcodec_dev *dev);
This is weird: vdec_msg_queue's operator but manipulating mtk_vcodec_dev?

> +
> +/**
> + * vdec_msg_queue_buf_to_core - queue buf to the core for core decode.
> + * @dev: mtk vcodec device
> + * @buf: current lat buffer
> + */
> +void vdec_msg_queue_buf_to_core(struct mtk_vcodec_dev *dev,
> +       struct vdec_lat_buf *buf);
Also weird.

> +/**
> + * vdec_msg_queue_buf_to_lat - queue buf to lat for lat decode.
> + * @buf: current lat buffer
> + */
> +void vdec_msg_queue_buf_to_lat(struct vdec_lat_buf *buf);
It should at least accept a struct vdec_msg_queue argument (or which
msg queue should the buf put into?).

> +/**
> + * vdec_msg_queue_update_ube_rptr - used to updata the ube read point.
Typo.

> +/**
> + * vdec_msg_queue_update_ube_wptr - used to updata the ube write point.
Typo.

> +/**
> + * vdec_msg_queue_deinit - deinit lat buffer information.
> + * @ctx: v4l2 ctx
> + * @msg_queue: used to store the lat buffer information
> + */
> +void vdec_msg_queue_deinit(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue);
Would prefer to have *msg_queue as the first argument.


The position of struct vdec_msg_queue is weird.  It looks like the msg
queue is only for struct vdec_lat_buf.  If so, would vdec_msg_queue be
better to call vdec_lat_queue or something similar?

It shouldn't touch the core queue in mtk_vcodec_dev anyway.  Is it
possible to generalize the queue-related code for both lat and core
queues?

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>,
	Irui Wang <irui.wang@mediatek.com>,
	 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 v1, 07/14] media: mtk-vcodec: Add msg queue feature for lat and core architecture
Date: Fri, 9 Jul 2021 17:39:23 +0800	[thread overview]
Message-ID: <CA+Px+wUjJwksVfU6N8VZ9WMw-F-DHu67XwvDvMoiMcUBKF=P6Q@mail.gmail.com> (raw)
In-Reply-To: <20210707062157.21176-8-yunfei.dong@mediatek.com>

On Wed, Jul 7, 2021 at 2:22 PM Yunfei Dong <yunfei.dong@mediatek.com> wrote:
> @@ -464,6 +469,11 @@ struct mtk_vcodec_enc_pdata {
>   * comp_dev: component hardware device
>   * component_node: component node
>   * comp_idx: component index
> + *
> + * core_read: Wait queue used to signalize when core get useful lat buffer
> + * core_queue: List of V4L2 lat_buf
To be neat, replace "Wait" to "wait" and "List" to "list".

> +int vdec_msg_queue_init(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue,
> +       core_decode_cb_t core_decode,
> +       int private_size)
> +{
> +       struct vdec_lat_buf *lat_buf;
> +       int i, err;
> +
> +       init_waitqueue_head(&msg_queue->lat_read);
> +       INIT_LIST_HEAD(&msg_queue->lat_queue);
> +       spin_lock_init(&msg_queue->lat_lock);
> +       msg_queue->num_lat = 0;
> +
> +       msg_queue->wdma_addr.size = vde_msg_queue_get_trans_size(
> +               ctx->picinfo.buf_w, ctx->picinfo.buf_h);
> +
> +       err = mtk_vcodec_mem_alloc(ctx, &msg_queue->wdma_addr);
> +       if (err) {
> +               mtk_v4l2_err("failed to allocate wdma_addr buf");
> +               return -ENOMEM;
> +       }
> +       msg_queue->wdma_rptr_addr = msg_queue->wdma_addr.dma_addr;
> +       msg_queue->wdma_wptr_addr = msg_queue->wdma_addr.dma_addr;
> +
> +       for (i = 0; i < NUM_BUFFER_COUNT; i++) {
> +               lat_buf = &msg_queue->lat_buf[i];
> +
> +               lat_buf->wdma_err_addr.size = VDEC_ERR_MAP_SZ_AVC;
> +               err = mtk_vcodec_mem_alloc(ctx, &lat_buf->wdma_err_addr);
> +               if (err) {
> +                       mtk_v4l2_err("failed to allocate wdma_err_addr buf[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->slice_bc_addr.size = VDEC_LAT_SLICE_HEADER_SZ;
> +               err = mtk_vcodec_mem_alloc(ctx, &lat_buf->slice_bc_addr);
> +               if (err) {
> +                       mtk_v4l2_err("failed to allocate wdma_addr buf[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->private_data = kzalloc(private_size, GFP_KERNEL);
> +               if (!lat_buf->private_data) {
> +                       mtk_v4l2_err("failed to allocate private_data[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->ctx = ctx;
> +               lat_buf->core_decode = core_decode;
> +               vdec_msg_queue_buf_to_lat(lat_buf);
> +       }
Doesn't it need to call mtk_vcodec_mem_free() and kfree() for any failure paths?

> +struct vdec_lat_buf *vdec_msg_queue_get_core_buf(
> +       struct mtk_vcodec_dev *dev)
> +{
> +       struct vdec_lat_buf *buf;
> +       int ret;
> +
> +       spin_lock(&dev->core_lock);
> +       if (list_empty(&dev->core_queue)) {
> +               mtk_v4l2_debug(3, "core queue is NULL, num_core = %d", dev->num_core);
> +               spin_unlock(&dev->core_lock);
> +               ret = wait_event_freezable(dev->core_read,
> +                       !list_empty(&dev->core_queue));
> +               if (ret)
> +                       return NULL;
Should be !ret?

> +void vdec_msg_queue_buf_to_core(struct mtk_vcodec_dev *dev,
> +       struct vdec_lat_buf *buf)
> +{
> +       spin_lock(&dev->core_lock);
> +       list_add_tail(&buf->core_list, &dev->core_queue);
> +       dev->num_core++;
> +       wake_up_all(&dev->core_read);
> +       mtk_v4l2_debug(3, "queu buf addr: (0x%p)", buf);
Typo.

> +bool vdec_msg_queue_wait_lat_buf_full(struct vdec_msg_queue *msg_queue)
> +{
> +       long timeout_jiff;
> +       int ret, i;
> +
> +       for (i = 0; i < NUM_BUFFER_COUNT + 2; i++) {
> +              timeout_jiff = msecs_to_jiffies(1000);
> +              ret = wait_event_timeout(msg_queue->lat_read,
> +                    msg_queue->num_lat == NUM_BUFFER_COUNT, timeout_jiff);
> +              if (ret) {
> +                     mtk_v4l2_debug(3, "success to get lat buf: %d",
> +                            msg_queue->num_lat);
> +                     return true;
> +              }
> +       }
Why does it need the loop?  i is unused.

> +void vdec_msg_queue_deinit(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue)
> +{
> +       struct vdec_lat_buf *lat_buf;
> +       struct mtk_vcodec_mem *mem;
> +       int i;
> +
> +       mem = &msg_queue->wdma_addr;
> +       if (mem->va)
> +               mtk_vcodec_mem_free(ctx, mem);
> +       for (i = 0; i < NUM_BUFFER_COUNT; i++) {
> +               lat_buf = &msg_queue->lat_buf[i];
> +
> +               mem = &lat_buf->wdma_err_addr;
> +               if (mem->va)
> +                       mtk_vcodec_mem_free(ctx, mem);
> +
> +               mem = &lat_buf->slice_bc_addr;
> +               if (mem->va)
> +                       mtk_vcodec_mem_free(ctx, mem);
> +
> +               if (lat_buf->private_data)
> +                       kfree(lat_buf->private_data);
> +       }
> +
> +       msg_queue->init_done = false;
Have no idea what init_done does in the code.  It is not included in
any branch condition.

> +/**
> + * vdec_msg_queue_init - init lat buffer information.
> + * @ctx: v4l2 ctx
> + * @msg_queue: used to store the lat buffer information
> + * @core_decode: core decode callback for each codec
> + * @private_size: the private data size used to share with core
> + */
> +int vdec_msg_queue_init(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue,
> +       core_decode_cb_t core_decode,
> +       int private_size);
Would prefer to have *msg_queue as the first argument (also applies to
all operators of vdec_msg_queue).

> +/**
> + * vdec_msg_queue_get_core_buf - get used core buffer for lat decode.
> + * @dev: mtk vcodec device
> + */
> +struct vdec_lat_buf *vdec_msg_queue_get_core_buf(
> +       struct mtk_vcodec_dev *dev);
This is weird: vdec_msg_queue's operator but manipulating mtk_vcodec_dev?

> +
> +/**
> + * vdec_msg_queue_buf_to_core - queue buf to the core for core decode.
> + * @dev: mtk vcodec device
> + * @buf: current lat buffer
> + */
> +void vdec_msg_queue_buf_to_core(struct mtk_vcodec_dev *dev,
> +       struct vdec_lat_buf *buf);
Also weird.

> +/**
> + * vdec_msg_queue_buf_to_lat - queue buf to lat for lat decode.
> + * @buf: current lat buffer
> + */
> +void vdec_msg_queue_buf_to_lat(struct vdec_lat_buf *buf);
It should at least accept a struct vdec_msg_queue argument (or which
msg queue should the buf put into?).

> +/**
> + * vdec_msg_queue_update_ube_rptr - used to updata the ube read point.
Typo.

> +/**
> + * vdec_msg_queue_update_ube_wptr - used to updata the ube write point.
Typo.

> +/**
> + * vdec_msg_queue_deinit - deinit lat buffer information.
> + * @ctx: v4l2 ctx
> + * @msg_queue: used to store the lat buffer information
> + */
> +void vdec_msg_queue_deinit(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue);
Would prefer to have *msg_queue as the first argument.


The position of struct vdec_msg_queue is weird.  It looks like the msg
queue is only for struct vdec_lat_buf.  If so, would vdec_msg_queue be
better to call vdec_lat_queue or something similar?

It shouldn't touch the core queue in mtk_vcodec_dev anyway.  Is it
possible to generalize the queue-related code for both lat and core
queues?

_______________________________________________
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>,
	Irui Wang <irui.wang@mediatek.com>,
	 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 v1, 07/14] media: mtk-vcodec: Add msg queue feature for lat and core architecture
Date: Fri, 9 Jul 2021 17:39:23 +0800	[thread overview]
Message-ID: <CA+Px+wUjJwksVfU6N8VZ9WMw-F-DHu67XwvDvMoiMcUBKF=P6Q@mail.gmail.com> (raw)
In-Reply-To: <20210707062157.21176-8-yunfei.dong@mediatek.com>

On Wed, Jul 7, 2021 at 2:22 PM Yunfei Dong <yunfei.dong@mediatek.com> wrote:
> @@ -464,6 +469,11 @@ struct mtk_vcodec_enc_pdata {
>   * comp_dev: component hardware device
>   * component_node: component node
>   * comp_idx: component index
> + *
> + * core_read: Wait queue used to signalize when core get useful lat buffer
> + * core_queue: List of V4L2 lat_buf
To be neat, replace "Wait" to "wait" and "List" to "list".

> +int vdec_msg_queue_init(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue,
> +       core_decode_cb_t core_decode,
> +       int private_size)
> +{
> +       struct vdec_lat_buf *lat_buf;
> +       int i, err;
> +
> +       init_waitqueue_head(&msg_queue->lat_read);
> +       INIT_LIST_HEAD(&msg_queue->lat_queue);
> +       spin_lock_init(&msg_queue->lat_lock);
> +       msg_queue->num_lat = 0;
> +
> +       msg_queue->wdma_addr.size = vde_msg_queue_get_trans_size(
> +               ctx->picinfo.buf_w, ctx->picinfo.buf_h);
> +
> +       err = mtk_vcodec_mem_alloc(ctx, &msg_queue->wdma_addr);
> +       if (err) {
> +               mtk_v4l2_err("failed to allocate wdma_addr buf");
> +               return -ENOMEM;
> +       }
> +       msg_queue->wdma_rptr_addr = msg_queue->wdma_addr.dma_addr;
> +       msg_queue->wdma_wptr_addr = msg_queue->wdma_addr.dma_addr;
> +
> +       for (i = 0; i < NUM_BUFFER_COUNT; i++) {
> +               lat_buf = &msg_queue->lat_buf[i];
> +
> +               lat_buf->wdma_err_addr.size = VDEC_ERR_MAP_SZ_AVC;
> +               err = mtk_vcodec_mem_alloc(ctx, &lat_buf->wdma_err_addr);
> +               if (err) {
> +                       mtk_v4l2_err("failed to allocate wdma_err_addr buf[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->slice_bc_addr.size = VDEC_LAT_SLICE_HEADER_SZ;
> +               err = mtk_vcodec_mem_alloc(ctx, &lat_buf->slice_bc_addr);
> +               if (err) {
> +                       mtk_v4l2_err("failed to allocate wdma_addr buf[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->private_data = kzalloc(private_size, GFP_KERNEL);
> +               if (!lat_buf->private_data) {
> +                       mtk_v4l2_err("failed to allocate private_data[%d]", i);
> +                       return -ENOMEM;
> +               }
> +
> +               lat_buf->ctx = ctx;
> +               lat_buf->core_decode = core_decode;
> +               vdec_msg_queue_buf_to_lat(lat_buf);
> +       }
Doesn't it need to call mtk_vcodec_mem_free() and kfree() for any failure paths?

> +struct vdec_lat_buf *vdec_msg_queue_get_core_buf(
> +       struct mtk_vcodec_dev *dev)
> +{
> +       struct vdec_lat_buf *buf;
> +       int ret;
> +
> +       spin_lock(&dev->core_lock);
> +       if (list_empty(&dev->core_queue)) {
> +               mtk_v4l2_debug(3, "core queue is NULL, num_core = %d", dev->num_core);
> +               spin_unlock(&dev->core_lock);
> +               ret = wait_event_freezable(dev->core_read,
> +                       !list_empty(&dev->core_queue));
> +               if (ret)
> +                       return NULL;
Should be !ret?

> +void vdec_msg_queue_buf_to_core(struct mtk_vcodec_dev *dev,
> +       struct vdec_lat_buf *buf)
> +{
> +       spin_lock(&dev->core_lock);
> +       list_add_tail(&buf->core_list, &dev->core_queue);
> +       dev->num_core++;
> +       wake_up_all(&dev->core_read);
> +       mtk_v4l2_debug(3, "queu buf addr: (0x%p)", buf);
Typo.

> +bool vdec_msg_queue_wait_lat_buf_full(struct vdec_msg_queue *msg_queue)
> +{
> +       long timeout_jiff;
> +       int ret, i;
> +
> +       for (i = 0; i < NUM_BUFFER_COUNT + 2; i++) {
> +              timeout_jiff = msecs_to_jiffies(1000);
> +              ret = wait_event_timeout(msg_queue->lat_read,
> +                    msg_queue->num_lat == NUM_BUFFER_COUNT, timeout_jiff);
> +              if (ret) {
> +                     mtk_v4l2_debug(3, "success to get lat buf: %d",
> +                            msg_queue->num_lat);
> +                     return true;
> +              }
> +       }
Why does it need the loop?  i is unused.

> +void vdec_msg_queue_deinit(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue)
> +{
> +       struct vdec_lat_buf *lat_buf;
> +       struct mtk_vcodec_mem *mem;
> +       int i;
> +
> +       mem = &msg_queue->wdma_addr;
> +       if (mem->va)
> +               mtk_vcodec_mem_free(ctx, mem);
> +       for (i = 0; i < NUM_BUFFER_COUNT; i++) {
> +               lat_buf = &msg_queue->lat_buf[i];
> +
> +               mem = &lat_buf->wdma_err_addr;
> +               if (mem->va)
> +                       mtk_vcodec_mem_free(ctx, mem);
> +
> +               mem = &lat_buf->slice_bc_addr;
> +               if (mem->va)
> +                       mtk_vcodec_mem_free(ctx, mem);
> +
> +               if (lat_buf->private_data)
> +                       kfree(lat_buf->private_data);
> +       }
> +
> +       msg_queue->init_done = false;
Have no idea what init_done does in the code.  It is not included in
any branch condition.

> +/**
> + * vdec_msg_queue_init - init lat buffer information.
> + * @ctx: v4l2 ctx
> + * @msg_queue: used to store the lat buffer information
> + * @core_decode: core decode callback for each codec
> + * @private_size: the private data size used to share with core
> + */
> +int vdec_msg_queue_init(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue,
> +       core_decode_cb_t core_decode,
> +       int private_size);
Would prefer to have *msg_queue as the first argument (also applies to
all operators of vdec_msg_queue).

> +/**
> + * vdec_msg_queue_get_core_buf - get used core buffer for lat decode.
> + * @dev: mtk vcodec device
> + */
> +struct vdec_lat_buf *vdec_msg_queue_get_core_buf(
> +       struct mtk_vcodec_dev *dev);
This is weird: vdec_msg_queue's operator but manipulating mtk_vcodec_dev?

> +
> +/**
> + * vdec_msg_queue_buf_to_core - queue buf to the core for core decode.
> + * @dev: mtk vcodec device
> + * @buf: current lat buffer
> + */
> +void vdec_msg_queue_buf_to_core(struct mtk_vcodec_dev *dev,
> +       struct vdec_lat_buf *buf);
Also weird.

> +/**
> + * vdec_msg_queue_buf_to_lat - queue buf to lat for lat decode.
> + * @buf: current lat buffer
> + */
> +void vdec_msg_queue_buf_to_lat(struct vdec_lat_buf *buf);
It should at least accept a struct vdec_msg_queue argument (or which
msg queue should the buf put into?).

> +/**
> + * vdec_msg_queue_update_ube_rptr - used to updata the ube read point.
Typo.

> +/**
> + * vdec_msg_queue_update_ube_wptr - used to updata the ube write point.
Typo.

> +/**
> + * vdec_msg_queue_deinit - deinit lat buffer information.
> + * @ctx: v4l2 ctx
> + * @msg_queue: used to store the lat buffer information
> + */
> +void vdec_msg_queue_deinit(
> +       struct mtk_vcodec_ctx *ctx,
> +       struct vdec_msg_queue *msg_queue);
Would prefer to have *msg_queue as the first argument.


The position of struct vdec_msg_queue is weird.  It looks like the msg
queue is only for struct vdec_lat_buf.  If so, would vdec_msg_queue be
better to call vdec_lat_queue or something similar?

It shouldn't touch the core queue in mtk_vcodec_dev anyway.  Is it
possible to generalize the queue-related code for both lat and core
queues?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-09  9:39 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07  6:21 [PATCH v1, 00/14] Using component framework to support multi hardware decode Yunfei Dong
2021-07-07  6:21 ` Yunfei Dong
2021-07-07  6:21 ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 01/14] media: mtk-vcodec: Get numbers of register bases from DT Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 02/14] media: mtk-vcodec: Refactor vcodec pm interface Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 03/14] media: mtk-vcodec: Use component framework to manage each hardware information Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-08 10:04   ` Tzung-Bi Shih
2021-07-08 10:04     ` Tzung-Bi Shih
2021-07-08 10:04     ` Tzung-Bi Shih
2021-07-07  6:21 ` [PATCH v1, 04/14] dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-08 10:04   ` Tzung-Bi Shih
2021-07-08 10:04     ` Tzung-Bi Shih
2021-07-08 10:04     ` Tzung-Bi Shih
2021-07-14 23:13     ` Rob Herring
2021-07-14 23:13       ` Rob Herring
2021-07-14 23:13       ` Rob Herring
2021-07-07  6:21 ` [PATCH v1, 05/14] media: mtk-vcodec: Use pure single core for MT8183 Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 06/14] media: mtk-vcodec: Add irq interface for core hardware Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-09  7:59   ` Tzung-Bi Shih
2021-07-09  7:59     ` Tzung-Bi Shih
2021-07-09  7:59     ` Tzung-Bi Shih
2021-07-12  8:07     ` mtk12024
2021-07-12  8:07       ` mtk12024
2021-07-12  8:07       ` mtk12024
2021-07-07  6:21 ` [PATCH v1, 07/14] media: mtk-vcodec: Add msg queue feature for lat and core architecture Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-09  9:39   ` Tzung-Bi Shih [this message]
2021-07-09  9:39     ` Tzung-Bi Shih
2021-07-09  9:39     ` Tzung-Bi Shih
2021-07-12  7:27     ` mtk12024
2021-07-12  7:27       ` mtk12024
2021-07-12  7:27       ` mtk12024
2021-07-13  8:55       ` Tzung-Bi Shih
2021-07-13  8:55         ` Tzung-Bi Shih
2021-07-13  8:55         ` Tzung-Bi Shih
2021-07-07  6:21 ` [PATCH v1, 08/14] media: mtk-vcodec: Generalize power and clock on/off interfaces Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 09/14] media: mtk-vcodec: Add new interface to lock different hardware Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 10/14] media: mtk-vcodec: Add core thread Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 11/14] media: mtk-vcodec: Support 34bits dma address for vdec Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 12/14] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-14 23:14   ` Rob Herring
2021-07-14 23:14     ` Rob Herring
2021-07-14 23:14     ` Rob Herring
2021-07-07  6:21 ` [PATCH v1, 13/14] media: mtk-vcodec: Add core dec and dec end ipi msg Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21 ` [PATCH v1, 14/14] media: mtk-vcodec: Use codec type to separate different hardware Yunfei Dong
2021-07-07  6:21   ` Yunfei Dong
2021-07-07  6:21   ` 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='CA+Px+wUjJwksVfU6N8VZ9WMw-F-DHu67XwvDvMoiMcUBKF=P6Q@mail.gmail.com' \
    --to=tzungbi@google.com \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=Yunfei.Dong@mediatek.com \
    --cc=acourbot@chromium.org \
    --cc=andrew-ct.chen@mediatek.com \
    --cc=devicetree@vger.kernel.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=tfiga@google.com \
    --cc=tiffany.lin@mediatek.com \
    --cc=tzungbi@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.