Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4559169pxv; Tue, 6 Jul 2021 04:02:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz59KyVAuEopzyssFxdhlVOrJaQk9xUTfnKOJczw7kCzIi4S9SIqrH/oqUbG5nV1SOliPW8 X-Received: by 2002:a17:907:2089:: with SMTP id pv9mr17616466ejb.246.1625569367841; Tue, 06 Jul 2021 04:02:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625569367; cv=none; d=google.com; s=arc-20160816; b=TsL6oTapAa7gCJQpkcjqG3n5e3pb1zXqZlqCXqiaXwjsB8isbmDZuYNdwPV+Do6/YF pn1T5HyREVKKGJJx2SK1iNp9tDDG+16bW2nCqRRdXKRzqZ1oyu653Vzsp62SD/sZr3ZS Epfgw4gRjmm+YuAK8yOUD+Ji+UtZl89qgMWLPWqig0Oe8jzc7Ci/yPyF1Mv6ZCQUtefn fMt6HuENqwsrhKcCia3JStHJiGeFzOACxioed0MNV+w6PU6Y9u3lcozAbHu9gx0pAf6c A+iIXQCY8qIEkYNZ2oaMtV3ubsNoVJyYPKJ0dBq0gA4Xa0Zh9NuRc5v9lRAB0qLkFhZt 0gRA== 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=+HHpMaVaRdcfE11Iv9zB2/7DEGNbwGm556b5Rknsy4U=; b=GGZOeEFe8aOnrVCbVJmV991RAPuDek5c7GV4tKZFYsDjqStgN+R61zhT/i6eBASiur d1pTPGOdm1A8VpGczBGMywRg9iD1j+NiZL/RKPq8SHONZ2SNXamFnCoBPsw5SKZM+DTi HnO/gczGI7YxKuWN8OSVh2han3poer2TNuA6bMQfCxxjsMnP2JJvmFEcm5HpKo4mweTK 3vbKy4sXyo8n4D6LlZgGGy32qCCjZNzoLvN/nu3tixJCGauNbcwXR/RADkQAMK8YmKIq 3b6KbsPHZQfCzefQOuFoJBVwXoVd//3tO1Xbj3gB5z2oEhaVqRB3U+kUqMIh03m+8DCh s4vA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sZaUCdrr; 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 f26si14078620edy.22.2021.07.06.04.02.24; Tue, 06 Jul 2021 04:02:47 -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=sZaUCdrr; 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 S231839AbhGFLDp (ORCPT + 99 others); Tue, 6 Jul 2021 07:03:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231846AbhGFLDn (ORCPT ); Tue, 6 Jul 2021 07:03:43 -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 7BA0BC06175F for ; Tue, 6 Jul 2021 04:01:04 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id h6so7371714iok.6 for ; Tue, 06 Jul 2021 04:01:04 -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=+HHpMaVaRdcfE11Iv9zB2/7DEGNbwGm556b5Rknsy4U=; b=sZaUCdrrS3e1iP5DPMjU61A5DEXd+QmYzjBzm1GL2Me4/JyUDJN0ev3edXVJGIGmkm 8l7fy5hX3An2cIInjdvXVT9Tn+5aQnD3MzSPn8V2wnLhPFsbWWHF577BOAPtkRnqGHtf W2LlWCGJz3xMgpRK8DgdIFHn15khciULuguy/j56gDktDWMlJ45x71MEV7Qo728tSvmb AJrZ3DqI254Ds24HVNPXhN9HDro7EUgxHUZNbPHejS1s2amJgmlCsT8dMQ2zVO3TGrYN Vj6kB29JnaR2v1rPV6e9t1AVzsVUzHxteeYGlSl2cQR7UcDuyR6XSPdYxdt1FvspOGNE lnuQ== 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=+HHpMaVaRdcfE11Iv9zB2/7DEGNbwGm556b5Rknsy4U=; b=uYMhm8ob8C2L6m64oZ+lNRsru+uWpyyNUoIQ6DO7Q85g9cuHAFC0Xa1I9uWi4jJ97O yZPkf4D6+lDWL8UhDDtk/DKqn5s8puw0SELkiPMVE2KT3lGoIAoOB+d0jAZLGloJzWey B4Sb0BD7LHHONRZp668hU6xaz+vf3xfUjBQa87OqkBE1D6PYt0PQ2KQkbmHlLKVNL4ub 5cvRbKzwzAel8H2E6AkGMZuewpzU9vN/cBK5iasFl4CFZuASOHAL0Bz18Jzgv72FtWxU LlPwjpIo9j6Pfzmk/ogY1V1GNkKy6XQyIvMHd86SCBWd3BtJuYeTQ8alLW08POEusmTv 7REQ== X-Gm-Message-State: AOAM530ndIwWCOB8ydkeeerxC2fRdtJEjWTiGbsOt11LtoHuEafavS7a frBrL7DYOztnCW+RkU9JtL6ukBFELMmT/gUfzhStUg== X-Received: by 2002:a02:c73b:: with SMTP id h27mr9187900jao.126.1625569263462; Tue, 06 Jul 2021 04:01:03 -0700 (PDT) MIME-Version: 1.0 References: <1625038079-25815-1-git-send-email-kyrie.wu@mediatek.com> <1625038079-25815-8-git-send-email-kyrie.wu@mediatek.com> In-Reply-To: <1625038079-25815-8-git-send-email-kyrie.wu@mediatek.com> From: Tzung-Bi Shih Date: Tue, 6 Jul 2021 19:00:52 +0800 Message-ID: Subject: Re: [PATCH v2,7/9] media: mtk-jpegenc: Use component framework to manage each hardware information To: "kyrie.wu" Cc: Hans Verkuil , Mauro Carvalho Chehab , Rob Herring , Bin Liu , Matthias Brugger , Tzung-Bi Shih , Project_Global_Chrome_Upstream_Group@mediatek.com, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Tomasz Figa , xia.jiang@mediatek.com, maoguang.meng@mediatek.com, srv_heupstream@mediatek.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 30, 2021 at 3:28 PM kyrie.wu wrote: > +static const struct of_device_id mtk_jpegenc_drv_ids[] = { Remove the extra space between "static" and "const". > + { > + .compatible = "mediatek,mt8195-jpgenc0", > + .data = (void *)MTK_JPEGENC_HW0, > + }, > + { > + .compatible = "mediatek,mt8195-jpgenc1", > + .data = (void *)MTK_JPEGENC_HW1, > + }, > + {}, > +}; Should be guarded by CONFIG_OF. > +static struct component_match *mtk_jpegenc_match_add(struct mtk_jpeg_dev *jpeg) > +{ > + struct device *dev = jpeg->dev; > + struct component_match *match = NULL; > + int i; > + char compatible[128] = {0}; It doesn't need to be initialized. > + > + for (i = 0; i < ARRAY_SIZE(mtk_jpegenc_drv_ids); i++) { > + struct device_node *comp_node; > + enum mtk_jpegenc_hw_id comp_idx; > + const struct of_device_id *of_id; > + > + memcpy(compatible, mtk_jpegenc_drv_ids[i].compatible, > + sizeof(mtk_jpegenc_drv_ids[i].compatible)); Shouldn't rely on the source length. Also needs to use strcpy-family for better handling the NULL terminator. > + if (!of_device_is_available(comp_node)) { > + of_node_put(comp_node); > + v4l2_err(&jpeg->v4l2_dev, "Fail to get jpeg enc HW node\n"); To be consistent, use "Failed". > + of_id = of_match_node(mtk_jpegenc_drv_ids, comp_node); > + if (!of_id) { > + v4l2_err(&jpeg->v4l2_dev, "Failed to get match node\n"); > + return ERR_PTR(-EINVAL); Shouldn't it call of_node_put() before returning? > + comp_idx = (enum mtk_jpegenc_hw_id)of_id->data; > + v4l2_info(&jpeg->v4l2_dev, "Get component:hw_id(%d),jpeg_dev(0x%p),comp_node(0x%p)\n", > + comp_idx, jpeg, comp_node); > + > + jpeg->component_node[comp_idx] = comp_node; > + > + component_match_add_release(dev, &match, mtk_vdec_release_of, > + mtk_vdec_compare_of, comp_node); Shouldn't it need to break if it already found? > + if (!jpeg->variant->is_encoder) { > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + jpeg->reg_base[MTK_JPEGENC_HW0] = > + devm_ioremap_resource(&pdev->dev, res); If !is_encoder, why is it still using MTK_JPEGENC_HW0? > + if (IS_ERR(jpeg->reg_base[MTK_JPEGENC_HW0])) { > + ret = PTR_ERR(jpeg->reg_base[MTK_JPEGENC_HW0]); > + return ret; Just return the PTR_ERR if it doesn't need to goto. > - pm_runtime_enable(&pdev->dev); > + if (jpeg->variant->is_encoder) { > + match = mtk_jpegenc_match_add(jpeg); > + if (IS_ERR_OR_NULL(match)) > + goto err_vfd_jpeg_register; > + > + video_set_drvdata(jpeg->vdev, jpeg); > + platform_set_drvdata(pdev, jpeg); > + ret = component_master_add_with_match(&pdev->dev, > + &mtk_jpegenc_ops, match); > + if (ret < 0) > + goto err_vfd_jpeg_register; Shouldn't it call of_node_put() for un-doing mtk_jpegenc_match_add()? > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h > @@ -125,6 +125,8 @@ struct mtk_jpegenc_pm { > * @larb: SMI device > * @job_timeout_work: IRQ timeout structure > * @variant: driver variant to be used > + * @irqlock: spinlock protecting for irq > + * @dev_mutex: the mutex protecting for device The patch adds more than 2 fields in the struct. They also need short descriptions here. > */ > struct mtk_jpeg_dev { > struct mutex lock; > @@ -136,12 +138,18 @@ struct mtk_jpeg_dev { > void *alloc_ctx; > struct video_device *vdev; > struct device *larb; > - struct delayed_work job_timeout_work; > const struct mtk_jpeg_variant *variant; > > + struct clk *clk_jpeg; It is not used. > /** > * struct mtk_jpeg_fmt - driver's internal color format data > * @fourcc: the fourcc code, 0 if not applicable > @@ -194,6 +204,7 @@ struct mtk_jpeg_q_data { > * @enc_quality: jpeg encoder quality > * @restart_interval: jpeg encoder restart interval > * @ctrl_hdl: controls handler > + * @done_queue_lock: spinlock protecting for buffer done queue Probably put in the wrong patch? > +int mtk_jpegenc_init_pm(struct mtk_jpeg_dev *mtkdev) > +{ > + struct platform_device *pdev; > + struct mtk_jpegenc_pm *pm; > + struct mtk_jpegenc_clk *jpegenc_clk; > + struct mtk_jpegenc_clk_info *clk_info; > + int i, ret; > + > + pdev = mtkdev->plat_dev; > + pm->dev = &pdev->dev; > + pm = &mtkdev->pm; > + pm->mtkdev = mtkdev; > + jpegenc_clk = &pm->venc_clk; Could they be inlined to above where the variables are declared.