Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp492263pxv; Fri, 9 Jul 2021 02:40:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPJTkWupBOXF3vK90nZe2BI1mv2L0n3NhAx2oLQvT1zCgFhMHoy6Zw5cfykw0zIiFGhyc4 X-Received: by 2002:a6b:2b04:: with SMTP id r4mr27945291ior.195.1625823618496; Fri, 09 Jul 2021 02:40:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625823618; cv=none; d=google.com; s=arc-20160816; b=QQHW8F6In9W2n+FqNyzZAfWGpWp3mESezaNb57XskgCLdsc4z4/EoKebwLc4qJrJuZ 5LlItkIkQ2LI+Bf+CdIjLHqfhXK236Mi0IwCHbH4c0DK9sBYgPMQmCgWaztdvsX70GKQ Pns331P2f9ZFIRq1nte6TWRPqjn6tn+tn1lmokJmOuZDUQwaujymLXA+fKBR+fcyskyj ghuiPx4kUv/LzGr4v6BvovKjY0MzoKiOPJeRe9MCmbCV6XqJYJipun/pUccCPs4K/sDo ABkXAT9S3mXlfHFyxYu2Ykm4FI6YqJKvJNvZWfQdgFH1cyfrTjWnuxeAUy81QOYwlm0b mCPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=CPm+UWTNiAIbOXTnyThDLwHKCYRI8nfAa3UJkpw22i4=; b=O+PUarylVscmoHCAo5D55ZexOcCiNJR8r8i9Zjgk2MjLx18QUvnxNvEk3mu8TlflaE GNebOB2M/N4yu4VKvtIRIYthwh0GJ2+gtyAqJet+39AqgQCEhzXlcw6cugPD24mYtFfW Xk3ktglDfYF9QilvNpsxiVPihu7irPsZ2tgtJfqbbz7PSbval92DsjHdX5YyJFoZ1LCO zcwkn5HRO45YhqnmovrMPGsEcX2Q58A1TurvRPLp46S6IsaH7emUCPuiRA+BYn/dSG+d MrUoQqGLI4w/QwCOEFaQZLr2X7aJVV0lJ4lnE6chfyZxgCyWoNNHaZeBKaCdKQYbi/o9 msVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YUqkR0wA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t6si6077254iov.63.2021.07.09.02.40.06; Fri, 09 Jul 2021 02:40:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YUqkR0wA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231956AbhGIJmT (ORCPT + 99 others); Fri, 9 Jul 2021 05:42:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229503AbhGIJmT (ORCPT ); Fri, 9 Jul 2021 05:42:19 -0400 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E9C6C0613DD for ; Fri, 9 Jul 2021 02:39:35 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id k11so11797279ioa.5 for ; Fri, 09 Jul 2021 02:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CPm+UWTNiAIbOXTnyThDLwHKCYRI8nfAa3UJkpw22i4=; b=YUqkR0wAiqFcellO135dfvE1OHkkkK/UZtngpoUb3duLFViGdej3lqzs8rW7zYXdYT XmBLzurgGguT+eVuQn2OAsWRYR3unlhnQcXwui28sTOdyJ15FzH4dp2WS1zgAKDmnHNT 2mSGfcPf4WAcEwUjTfYwFFKUANeZUflOb5DpA/HaPSICE3kHmX1QFEGBASd+mJtymGF0 21+C1kdfx6N5QmEefng8HIYihwp6tLrgj0WmSE0vjmw6Np0IP9FsOjL/yiwxcU2O9hbf 0/E20dNh1Eqh2HZoUqydzpfBUwy0tIgaL3dry9m/YYb4Qpxcl4CVy8s+MNTCv5k0dVuT W3fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CPm+UWTNiAIbOXTnyThDLwHKCYRI8nfAa3UJkpw22i4=; b=UTymx7hTNLpRzjzhm71PncIGnyVphOSjg0bVgPkwCoFDhTRBNnsDKy08S+nwZZ9nB7 eC4VxX81YyPX0yEEkT3RO7Maabu5lJTLKtEdCkzNRBrGuJgHbqbE2b+gr7vNczeLCDT+ 13Rbxl0MdSvsLJiHI1XyA/niCo9KUOkEZAr6H+2+ODXMFP6tEAXkVJJdmX95avnc7eao 4VxjWPsPC3yELvaq0kxHM8dBkcYPx3P6QS2t/CAoQtHXuS3JQIBrTnqbBFz1J9G2vSJi 62zpzoJ5LdK7BYHVlgtiS3xvtgYBKvgIl1KWPjN4vvZV5fVJkbGjmpvZpFEAv8ZyUsN0 Rs3w== X-Gm-Message-State: AOAM533UrrBs8JpUhDqwpRd6MEtK0qeG+LzMPWh0HUgEHYYsC6N2SRSO 3lv/yGqoq3WKhlroj74FmFWxoMNkBfEFIE7DuEwgGg== X-Received: by 2002:a02:b155:: with SMTP id s21mr27123288jah.50.1625823574468; Fri, 09 Jul 2021 02:39:34 -0700 (PDT) MIME-Version: 1.0 References: <20210707062157.21176-1-yunfei.dong@mediatek.com> <20210707062157.21176-8-yunfei.dong@mediatek.com> In-Reply-To: <20210707062157.21176-8-yunfei.dong@mediatek.com> From: Tzung-Bi Shih Date: Fri, 9 Jul 2021 17:39:23 +0800 Message-ID: Subject: Re: [PATCH v1, 07/14] media: mtk-vcodec: Add msg queue feature for lat and core architecture To: Yunfei Dong Cc: Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , Hsin-Yi Wang , Fritz Koenig , Irui Wang , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 7, 2021 at 2:22 PM Yunfei Dong 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?