Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp6796574pxv; Fri, 30 Jul 2021 02:34:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykVsyKXG+hvTFxqlWK1umSsgvDj1k5mixzZUQXOH4/1y5od7WRFix4Uy0xPpl9fYuG53GN X-Received: by 2002:a17:907:2108:: with SMTP id qn8mr1648843ejb.549.1627637687753; Fri, 30 Jul 2021 02:34:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627637687; cv=none; d=google.com; s=arc-20160816; b=kdezx5IjmuPVzpK1G5IYFFSjthnmX5vqmkOzFhAoFIv9WOZPwGvprNT0/1ICwt/ORa g8XT6Qxjl1labHQb87ZroyTs7g3U8/pXcteahF8meX86gpQnKoJrxKqF92agz/PRd8Bt 1ZsTGKoGHe3zCOb09aPkZDwXzRD+ZUMDycSWJ8lyGxBv3VHl2HSW3lKrHOKHsGSXpxWu mnua7sqHo8wDMK44KX5NeZHr7djCTnt0d8FVznkfvxYzOcULKiVUpyxrEwxVMSe160iP F4S5eotUfT4G5SEapYdmYC3z1pD9kIXhmspTTi8BkqYx9MJXMtZt5pumgxw+g9F4+R5z AkCw== 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=z+HszHCjicRVinPAkgiPIP+xtCEpWxlQtRPDlzMA4dw=; b=XKtsjWheudEyJn8ozqDWv6lS1n6VqSYImO6N+2qpQgn7EJo518a1H/7p1+h0uqYB9E VHXcMw4PzuiFkNkIC00pcRV+Z5kpTyalK+ISyU/o6iCeiq99hywm8zX65UBcrk29wq/K F4TvOw0YGTXYFU1s/Cn90QflGSFyhwf0g3XBXRMafnYhk7dnjPMxZEpoj0SUh8z2SyGC 45qcfdjupYLCH2TwgDNkc0bX5+YkbdVT3XAwzvE04XM1TJxo+5gbN2l66ClD48ZvqxUp Kwshtdx85ztiy04paUkYv1GVAJ/btN2o7qC+3oFX6NxXYFLET5YYEcUxe97lD3+GMvFS QeaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=hLiDZgqo; 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 n20si1181740edt.533.2021.07.30.02.34.24; Fri, 30 Jul 2021 02:34: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=hLiDZgqo; 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 S238275AbhG3Jcv (ORCPT + 99 others); Fri, 30 Jul 2021 05:32:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238223AbhG3Jcu (ORCPT ); Fri, 30 Jul 2021 05:32:50 -0400 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C00C1C0613C1 for ; Fri, 30 Jul 2021 02:32:44 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id h1so10645866iol.9 for ; Fri, 30 Jul 2021 02:32:44 -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=z+HszHCjicRVinPAkgiPIP+xtCEpWxlQtRPDlzMA4dw=; b=hLiDZgqoc2mqGGzVG0XTePpocnHV5/Z4F12ZRFN7cXNXdnjWsaT3BppF5NYmsP61BN 5d+/gi6MNMKsOHODssMMcZ4pF+lW11ffAaNCAIdPEehKBxQvLdcTl9VsSrQtzOfzVE1M p5EaGNxH1nS0dqgTTROg+3uV58szbOKz3szTpdZNW2XObFCScHoZ5nC26Ujb7kl1vHE7 CCSZk+ytoZkAwuS+Dn5UD3NpA57UX6bIVGuaENP30GfUiBky6k3Mh1xxgHLa1I7zU8Ws al9oa5bIxQoBTlVXnMrGT5QG0O6gsLI+VncLRSbJi6vF6q5YqguXzYN1XfhmrZE/90/h v68w== 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=z+HszHCjicRVinPAkgiPIP+xtCEpWxlQtRPDlzMA4dw=; b=pFV4KwYCmRVaDfEQ49Mj2RKiZiORUNjQeo5BDCGKN4133RvGO7A/mDPDrucx9jS09i OH4MWfNQFxTjeKNd8/QFHODYig8fefBSlp3kYKpOS2yYXAhWiOCGEwkjo5Gpz3zC+b2R h/iEYfMOhlsdfrZbr/QzxWiXsqBTwzLqD54DyHDioiqQCGqBN+/uOJvWETL5xaBBVamE TWeq0Uf4OdKeOhg47EUPLa6jdC54VL3leYlieReImu1TLphFsX9ObSAOb1jx1gjZ6Ijg MXrVA34kiJP/cF9MLVMnA3T9vlQG+2pfloq7/Of66SN0P2lYa9jY/xoMBz4+/v3/REE6 fXRQ== X-Gm-Message-State: AOAM533ZJiZvqnaVxwYx5ECYQjfMjo05PGq1D1DjoL7xIUowVTkw4vT8 wtw1x3V1ZASzPrGzEW2ZMQq8LfDq6EdQ6BRlaG1gew== X-Received: by 2002:a02:cf2e:: with SMTP id s14mr1483427jar.74.1627637564075; Fri, 30 Jul 2021 02:32:44 -0700 (PDT) MIME-Version: 1.0 References: <20210727101051.24418-1-yunfei.dong@mediatek.com> <20210727101051.24418-5-yunfei.dong@mediatek.com> In-Reply-To: <20210727101051.24418-5-yunfei.dong@mediatek.com> From: Tzung-Bi Shih Date: Fri, 30 Jul 2021 17:32:33 +0800 Message-ID: Subject: Re: [PATCH v3, 04/15] media: mtk-vcodec: Use component framework to manage each hardware information 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 Tue, Jul 27, 2021 at 06:10:40PM +0800, Yunfei Dong wrote: > +static struct component_match *mtk_vcodec_match_add( > + struct mtk_vcodec_dev *vdec_dev) > + { Remove the extra space before {. > + struct platform_device *pdev = vdec_dev->plat_dev; > + struct component_match *match = NULL; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(mtk_vdec_drv_ids); i++) { > + struct device_node *comp_node; > + enum mtk_vdec_hw_id comp_idx; > + const struct of_device_id *of_id; Failed to see benifits to declare here in the case. To be neat, move the variable declaration to the beginning of function. > + > + comp_node = of_find_compatible_node(NULL, NULL, > + mtk_vdec_drv_ids[i].compatible); > + if (!comp_node) > + continue; If moving of_id assignment to the beginning of for-loop, use of_id->compatible. > + > + if (!of_device_is_available(comp_node)) { > + of_node_put(comp_node); > + dev_err(&pdev->dev, "Fail to get MMSYS node\n"); > + continue; > + } > + > + of_id = &mtk_vdec_drv_ids[i]; > + if (!of_id) { > + dev_err(&pdev->dev, "Failed to get match node\n"); > + return ERR_PTR(-EINVAL); > + } Move the block to the beginning of for-loop. Looking to other blocks around, does it make more sense to use `continue` instead of `return`? > + > + comp_idx = (enum mtk_vdec_hw_id)of_id->data; > + mtk_v4l2_debug(4, "Get component:hw_id(%d),vdec_dev(0x%p),comp_node(0x%p)\n", > + comp_idx, vdec_dev, comp_node); > + vdec_dev->component_node[comp_idx] = comp_node; > + > + component_match_add_release(&pdev->dev, &match, mtk_vdec_release_of, > + mtk_vdec_compare_of, comp_node); > + of_node_put(comp_node); I thought it shouldn't call of_node_put(...) which is already delegated to component framework (mtk_vdec_release_of). > + } > + > + return match; Fix the indent. > +static int mtk_vcodec_init_dec_params(struct mtk_vcodec_dev *dev) > +{ > + struct platform_device *pdev = dev->plat_dev; > + int ret; > + > + ret = mtk_vcodec_get_reg_bases(dev); > + if (ret) > + return ret; > + > + if (!dev->is_comp_supported) { > + dev->dec_irq = platform_get_irq(pdev, 0); > + if (dev->dec_irq < 0) { > + dev_err(&pdev->dev, "failed to get irq number"); > + return dev->dec_irq; > + } > + > + irq_set_status_flags(dev->dec_irq, IRQ_NOAUTOEN); > + ret = devm_request_irq(&pdev->dev, dev->dec_irq, > + mtk_vcodec_dec_irq_handler, 0, pdev->name, dev); > + if (ret) { > + dev_err(&pdev->dev, "failed to install dev->dec_irq %d (%d)", > + dev->dec_irq, ret); > + return ret; > + } > + > + ret = mtk_vcodec_init_dec_pm(pdev, &dev->pm); > + if (ret < 0) { > + dev_err(&pdev->dev, "failed to get mt vcodec clock source"); > + return ret; > + } > + } > + > + return ret; To be concise, return 0. > + comp_node = > + of_find_compatible_node(NULL, NULL, "mediatek,mtk-vcodec-core"); > + if (!comp_node) > + dev->is_comp_supported = false; > + else > + dev->is_comp_supported = true; > + of_node_put(comp_node); Looking up "mediatek,mtk-vcodec-core" to determine if it uses component framework sounds like a sub-optimal method. > @@ -311,7 +429,6 @@ static int mtk_vcodec_probe(struct platform_device *pdev) > MTK_VCODEC_DEC_NAME); > video_set_drvdata(vfd_dec, dev); > dev->vfd_dec = vfd_dec; > - platform_set_drvdata(pdev, dev); > > dev->m2m_dev_dec = v4l2_m2m_init(&mtk_vdec_m2m_ops); > if (IS_ERR((__force void *)dev->m2m_dev_dec)) { > @@ -362,8 +479,17 @@ static int mtk_vcodec_probe(struct platform_device *pdev) > mtk_v4l2_debug(0, "decoder registered as /dev/video%d", > vfd_dec->num); > > - return 0; > + if (dev->is_comp_supported) { > + ret = mtk_vcodec_init_master(dev); > + if (ret < 0) > + goto err_component_match; > + } else { > + platform_set_drvdata(pdev, dev); > + } Has asked the same question in [1]. Why it removes the platform_set_drvdata() above? mtk_vcodec_init_master() also calls platform_set_drvdata(). [1]: https://patchwork.linuxtv.org/project/linux-media/patch/20210707062157.21176-4-yunfei.dong@mediatek.com/ > + return 0; > +err_component_match: > + video_unregister_device(vfd_dec); Why video_unregister_device()? It is already called [2]. [2]: https://elixir.bootlin.com/linux/v5.14-rc3/source/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c#L344 > @@ -379,9 +505,8 @@ static int mtk_vcodec_probe(struct platform_device *pdev) > err_dec_alloc: > v4l2_device_unregister(&dev->v4l2_dev); > err_res: > - mtk_vcodec_release_dec_pm(&dev->pm); Shouldn't remove it. mtk_vcodec_init_dec_params() also needs to undo in the path. Refactoring them to mtk_vcodec_init_dec_params() makes the error handling more complicated. > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h > index 973b0b3649c6..d6bb723db106 100644 > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h > @@ -17,6 +17,11 @@ > #include > #include "mtk_vcodec_util.h" > > +#define VDEC_HW_ACTIVE 0x10 > +#define VDEC_IRQ_CFG 0x11 > +#define VDEC_IRQ_CLR 0x10 > +#define VDEC_IRQ_CFG_REG 0xa4 If moving to mtk_vcodec_dec_hw.h or mtk_vcodec_dec_hw.c makes more sense?