From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C421C433F5 for ; Fri, 8 Apr 2022 02:43:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233277AbiDHCpF (ORCPT ); Thu, 7 Apr 2022 22:45:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231919AbiDHCo7 (ORCPT ); Thu, 7 Apr 2022 22:44:59 -0400 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E73BC128651; Thu, 7 Apr 2022 19:42:51 -0700 (PDT) X-UUID: 1668b79055aa48aeacf2f9a4eb05547a-20220408 X-UUID: 1668b79055aa48aeacf2f9a4eb05547a-20220408 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1616430123; Fri, 08 Apr 2022 10:42:46 +0800 Received: from mtkexhb01.mediatek.inc (172.21.101.102) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Fri, 8 Apr 2022 10:42:45 +0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkexhb01.mediatek.inc (172.21.101.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 Apr 2022 10:42:44 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 8 Apr 2022 10:42:44 +0800 Message-ID: <1ee8927744624fb0b6e97190e5a4b78cbee69751.camel@mediatek.com> Subject: Re: [RESEND v17 3/7] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0 From: Jason-JH Lin To: AngeloGioacchino Del Regno , "Rob Herring" , Matthias Brugger , Chun-Kuang Hu CC: Philipp Zabel , Maxime Coquelin , David Airlie , Daniel Vetter , Alexandre Torgue , "John 'Warthog9' Hawley" , , , , , , CK Hu , Fabien Parent , , , , , , , , Date: Fri, 8 Apr 2022 10:42:44 +0800 In-Reply-To: <8d5c41c0-ac7c-ed1e-726b-0d738bf22fed@collabora.com> References: <20220407030409.9664-1-jason-jh.lin@mediatek.com> <20220407030409.9664-4-jason-jh.lin@mediatek.com> <8d5c41c0-ac7c-ed1e-726b-0d738bf22fed@collabora.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Angelo, Thanks for the reviews. On Thu, 2022-04-07 at 11:11 +0200, AngeloGioacchino Del Regno wrote: > Il 07/04/22 05:04, jason-jh.lin ha scritto: > > 1. Add mt8195 mmsys compatible for vdosys0. > > 2. Add mt8195 routing table settings and fix build fail. > > 3. Add clock name, clock driver name and routing table into the > > driver data > > of mt8195 vdosys0. > > 4. Add get match data by clock name function and clock platform > > labels > > to identify which mmsys node is corresponding to vdosys0. > > > > Signed-off-by: jason-jh.lin > > --- > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +- > > drivers/soc/mediatek/mt8167-mmsys.h | 2 +- > > drivers/soc/mediatek/mt8183-mmsys.h | 2 +- > > drivers/soc/mediatek/mt8186-mmsys.h | 4 +- > > drivers/soc/mediatek/mt8192-mmsys.h | 4 +- > > drivers/soc/mediatek/mt8195-mmsys.h | 370 > > ++++++++++++++++++++ > > drivers/soc/mediatek/mt8365-mmsys.h | 4 +- > > drivers/soc/mediatek/mtk-mmsys.c | 62 ++++ > > drivers/soc/mediatek/mtk-mmsys.h | 1 + > > drivers/soc/mediatek/mtk-mutex.c | 8 +- > > include/linux/soc/mediatek/mtk-mmsys.h | 13 +- > > 12 files changed, 461 insertions(+), 17 deletions(-) > > create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h > > > > ..snip.. > > > diff --git a/drivers/soc/mediatek/mtk-mmsys.c > > b/drivers/soc/mediatek/mtk-mmsys.c > > index 4fc4c2c9ea20..b2fa239c5f5f 100644 > > --- a/drivers/soc/mediatek/mtk-mmsys.c > > +++ b/drivers/soc/mediatek/mtk-mmsys.c > > @@ -4,6 +4,8 @@ > > * Author: James Liao > > */ > > > > +#include > > +#include > > #include > > #include > > #include > > @@ -17,6 +19,7 @@ > > #include "mt8183-mmsys.h" > > #include "mt8186-mmsys.h" > > #include "mt8192-mmsys.h" > > +#include "mt8195-mmsys.h" > > #include "mt8365-mmsys.h" > > > > static const struct mtk_mmsys_driver_data > > mt2701_mmsys_driver_data = { > > @@ -72,12 +75,24 @@ static const struct mtk_mmsys_driver_data > > mt8192_mmsys_driver_data = { > > .num_routes = ARRAY_SIZE(mmsys_mt8192_routing_table), > > }; > > > > +static const struct mtk_mmsys_driver_data > > mt8195_vdosys0_driver_data = { > > + .clk_name = "cfg_vdo0", > > + .clk_driver = "clk-mt8195-vdo0", > > + .routes = mmsys_mt8195_routing_table, > > + .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table), > > +}; > > + > > static const struct mtk_mmsys_driver_data > > mt8365_mmsys_driver_data = { > > .clk_driver = "clk-mt8365-mm", > > .routes = mt8365_mmsys_routing_table, > > .num_routes = ARRAY_SIZE(mt8365_mmsys_routing_table), > > }; > > > > +static const struct of_device_id mtk_clk_platform_labels[] = { > > + { .compatible = "mediatek,mt8195-mmsys", > > + .data = (void *)"clk-mt8195"}, > > I have a hunch that MT8195 won't be the first and last SoC having > multiple > mmsys channels. I would tend to think that there will be more.... > Yes, there will be another SoC with multiple mmsys channels... > ....so, to make it clean from the beginning, I think that you should, > at > this point, assign a struct to that .data pointer, instead of > declaring a > drvdata struct into mtk_mmsys_get_match_data_by_clk_name(). > > Besides, I think that this kind of usage for __clk_get_name() may be > an API > abuse... but I'm not sure about that... in any case: > - if it's not an abuse, then you should simply pass > mt8195_vdosys0_driver_data, > or an array of pointers to mtk_mmsys_driver_data; > - if this is an abuse, you can do the same checks by looking at the > iostart > (mmio base address) of the vdosys{0,1} node(s). Do you mean that I should change clk_name to iostart like this? mt8195_vdosys0_driver_data = { .iostart = 0x1c01a000, // instead of clk_name .clk_driver = "clk-mt8195-vdo0", .routes = mmsys_mt8195_routing_table, .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table), }; Just to confirm that address information can be disclosed here. If it is not appropriate to use address here, I'll keep using clk_name. > Honestly, though, I'm not even sure that you need this different > of_device_id > array here... since you could simply wrap the mtk_mmsys_driver_data > in the > of_match_mtk_mmsys that you have below... here's another idea: > > struct mtk_mmsys_match_data { > const struct mtk_mmsys_driver_data *drv_data[]; > unsigned short num_drv_data; > }; > > ...so that: > > static int some_function_handling_multi_mmsys(struct mtk_mmsys > *mmsys, > struct > mtk_mmsys_match_data *match) > { > int i; > > i = [ logic to find the right match->drv_data entry here ] > > return i; > } > > static int mtk_mmsys_probe() > { > .... variables, something else .... > > if (match_data->num_drv_data > 1) { > /* This SoC has multiple mmsys channels */ > ret = some_function_handling_multi_mmsys(mmsys); > if (ret < 0) > return ret; > > mmsys->data = match_data->drv_data[ret]; > } else { > dev_dbg(dev, "Using single mmsys channel\n"); > mmsys->data = match_data->drv_data[0]; > } > > ...everything else that mtk_mmsys_probe does ... > } I've tried this idea in my local environment and it looks good. So I'll apply this at the next version. Thanks for your idea! > What I'm trying to communicate with this is that the currently chosen > solution > looks a bit fragile and needs to be made robust. > In comparison, even if it's not technically right to have two > different compatibles > for the same hardware (and shall not be done), the former solution, > even if wrong, > was more robust than this one, imo. > > Regards, > Angelo Because we don't have a property to identify the different mmsys directly (not using multi-mmsys handle function). Although it make the code more complicated and not robust, but I think this time it should be implemented for other multi-mmsys SoC in the feature. Regards, Jason-JH.Lin - Jason-JH Lin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C5BCBC433F5 for ; Fri, 8 Apr 2022 02:43:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7ITiMZ/qgPFyC6lK7dsVXQ8hZNIir07/g3u01yXSRLY=; b=N8wXvt8V4k1hiV 0TRK7GkdpuATx54ruM4qU5Re+sEpMIFcYBFlEtD4dnrN8sw9WJy2NyYqlBpReRdBloMSJXXSSfTne yRRukJtFfHWTxFCJDrOLhXouGzKPSlSxzSnXnojZCIK4PfP6Mk0Hlpi1+17c2cfKuUF7WMw4hCrOl 2hXCF68k6jXAuzGIEW9LHlXdMrm7GxVFOiDCVSiLfckImdu4ZzLzuV7xHbTAtdSKuJPe2dQDafQvN LJcSqTiYKkeaiOss+hXVAjSEzlVdU56joQSOx+XCmEM7PfOSuuiRYWjuvdQhtVy5sX7LWvFNzliiK k+6fhHPPukZlETCEXGkA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nceaT-00Efve-SE; Fri, 08 Apr 2022 02:43:01 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nceaP-00EfuP-Rb; Fri, 08 Apr 2022 02:43:00 +0000 X-UUID: b2133a845cc049549aeacc8173d100c6-20220407 X-UUID: b2133a845cc049549aeacc8173d100c6-20220407 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1679536719; Thu, 07 Apr 2022 19:42:55 -0700 Received: from mtkexhb01.mediatek.inc (172.21.101.102) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 Apr 2022 19:42:53 -0700 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkexhb01.mediatek.inc (172.21.101.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 Apr 2022 10:42:44 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 8 Apr 2022 10:42:44 +0800 Message-ID: <1ee8927744624fb0b6e97190e5a4b78cbee69751.camel@mediatek.com> Subject: Re: [RESEND v17 3/7] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0 From: Jason-JH Lin To: AngeloGioacchino Del Regno , "Rob Herring" , Matthias Brugger , Chun-Kuang Hu Date: Fri, 8 Apr 2022 10:42:44 +0800 In-Reply-To: <8d5c41c0-ac7c-ed1e-726b-0d738bf22fed@collabora.com> References: <20220407030409.9664-1-jason-jh.lin@mediatek.com> <20220407030409.9664-4-jason-jh.lin@mediatek.com> <8d5c41c0-ac7c-ed1e-726b-0d738bf22fed@collabora.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220407_194257_931421_D491221E X-CRM114-Status: GOOD ( 44.34 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Maxime Coquelin , David Airlie , linux-kernel@vger.kernel.org, singo.chang@mediatek.com, hsinyi@chromium.org, Alexandre Torgue , postmaster@vger.kernel.org, Project_Global_Chrome_Upstream_Group@mediatek.com, Fabien Parent , moudy.ho@mediatek.com, linux-mediatek@lists.infradead.org, roy-cw.yeh@mediatek.com, Daniel Vetter , John 'Warthog9' Hawley , CK Hu , Philipp Zabel , nancy.lin@mediatek.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Hi Angelo, Thanks for the reviews. On Thu, 2022-04-07 at 11:11 +0200, AngeloGioacchino Del Regno wrote: > Il 07/04/22 05:04, jason-jh.lin ha scritto: > > 1. Add mt8195 mmsys compatible for vdosys0. > > 2. Add mt8195 routing table settings and fix build fail. > > 3. Add clock name, clock driver name and routing table into the > > driver data > > of mt8195 vdosys0. > > 4. Add get match data by clock name function and clock platform > > labels > > to identify which mmsys node is corresponding to vdosys0. > > > > Signed-off-by: jason-jh.lin > > --- > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +- > > drivers/soc/mediatek/mt8167-mmsys.h | 2 +- > > drivers/soc/mediatek/mt8183-mmsys.h | 2 +- > > drivers/soc/mediatek/mt8186-mmsys.h | 4 +- > > drivers/soc/mediatek/mt8192-mmsys.h | 4 +- > > drivers/soc/mediatek/mt8195-mmsys.h | 370 > > ++++++++++++++++++++ > > drivers/soc/mediatek/mt8365-mmsys.h | 4 +- > > drivers/soc/mediatek/mtk-mmsys.c | 62 ++++ > > drivers/soc/mediatek/mtk-mmsys.h | 1 + > > drivers/soc/mediatek/mtk-mutex.c | 8 +- > > include/linux/soc/mediatek/mtk-mmsys.h | 13 +- > > 12 files changed, 461 insertions(+), 17 deletions(-) > > create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h > > > > ..snip.. > > > diff --git a/drivers/soc/mediatek/mtk-mmsys.c > > b/drivers/soc/mediatek/mtk-mmsys.c > > index 4fc4c2c9ea20..b2fa239c5f5f 100644 > > --- a/drivers/soc/mediatek/mtk-mmsys.c > > +++ b/drivers/soc/mediatek/mtk-mmsys.c > > @@ -4,6 +4,8 @@ > > * Author: James Liao > > */ > > > > +#include > > +#include > > #include > > #include > > #include > > @@ -17,6 +19,7 @@ > > #include "mt8183-mmsys.h" > > #include "mt8186-mmsys.h" > > #include "mt8192-mmsys.h" > > +#include "mt8195-mmsys.h" > > #include "mt8365-mmsys.h" > > > > static const struct mtk_mmsys_driver_data > > mt2701_mmsys_driver_data = { > > @@ -72,12 +75,24 @@ static const struct mtk_mmsys_driver_data > > mt8192_mmsys_driver_data = { > > .num_routes = ARRAY_SIZE(mmsys_mt8192_routing_table), > > }; > > > > +static const struct mtk_mmsys_driver_data > > mt8195_vdosys0_driver_data = { > > + .clk_name = "cfg_vdo0", > > + .clk_driver = "clk-mt8195-vdo0", > > + .routes = mmsys_mt8195_routing_table, > > + .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table), > > +}; > > + > > static const struct mtk_mmsys_driver_data > > mt8365_mmsys_driver_data = { > > .clk_driver = "clk-mt8365-mm", > > .routes = mt8365_mmsys_routing_table, > > .num_routes = ARRAY_SIZE(mt8365_mmsys_routing_table), > > }; > > > > +static const struct of_device_id mtk_clk_platform_labels[] = { > > + { .compatible = "mediatek,mt8195-mmsys", > > + .data = (void *)"clk-mt8195"}, > > I have a hunch that MT8195 won't be the first and last SoC having > multiple > mmsys channels. I would tend to think that there will be more.... > Yes, there will be another SoC with multiple mmsys channels... > ....so, to make it clean from the beginning, I think that you should, > at > this point, assign a struct to that .data pointer, instead of > declaring a > drvdata struct into mtk_mmsys_get_match_data_by_clk_name(). > > Besides, I think that this kind of usage for __clk_get_name() may be > an API > abuse... but I'm not sure about that... in any case: > - if it's not an abuse, then you should simply pass > mt8195_vdosys0_driver_data, > or an array of pointers to mtk_mmsys_driver_data; > - if this is an abuse, you can do the same checks by looking at the > iostart > (mmio base address) of the vdosys{0,1} node(s). Do you mean that I should change clk_name to iostart like this? mt8195_vdosys0_driver_data = { .iostart = 0x1c01a000, // instead of clk_name .clk_driver = "clk-mt8195-vdo0", .routes = mmsys_mt8195_routing_table, .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table), }; Just to confirm that address information can be disclosed here. If it is not appropriate to use address here, I'll keep using clk_name. > Honestly, though, I'm not even sure that you need this different > of_device_id > array here... since you could simply wrap the mtk_mmsys_driver_data > in the > of_match_mtk_mmsys that you have below... here's another idea: > > struct mtk_mmsys_match_data { > const struct mtk_mmsys_driver_data *drv_data[]; > unsigned short num_drv_data; > }; > > ...so that: > > static int some_function_handling_multi_mmsys(struct mtk_mmsys > *mmsys, > struct > mtk_mmsys_match_data *match) > { > int i; > > i = [ logic to find the right match->drv_data entry here ] > > return i; > } > > static int mtk_mmsys_probe() > { > .... variables, something else .... > > if (match_data->num_drv_data > 1) { > /* This SoC has multiple mmsys channels */ > ret = some_function_handling_multi_mmsys(mmsys); > if (ret < 0) > return ret; > > mmsys->data = match_data->drv_data[ret]; > } else { > dev_dbg(dev, "Using single mmsys channel\n"); > mmsys->data = match_data->drv_data[0]; > } > > ...everything else that mtk_mmsys_probe does ... > } I've tried this idea in my local environment and it looks good. So I'll apply this at the next version. Thanks for your idea! > What I'm trying to communicate with this is that the currently chosen > solution > looks a bit fragile and needs to be made robust. > In comparison, even if it's not technically right to have two > different compatibles > for the same hardware (and shall not be done), the former solution, > even if wrong, > was more robust than this one, imo. > > Regards, > Angelo Because we don't have a property to identify the different mmsys directly (not using multi-mmsys handle function). Although it make the code more complicated and not robust, but I think this time it should be implemented for other multi-mmsys SoC in the feature. Regards, Jason-JH.Lin - Jason-JH Lin _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BF60CC433EF for ; Fri, 8 Apr 2022 02:44:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:CC:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=eNseyG3L37SheippnLw/8ZeD+fryZpRmDm5rqnA20jQ=; b=YKJMNYBKeosXTH NfeKgO6BCS/+Qkj+wNg7tl427Eq6kbcvkTNXkNNx9zAKAxpQVL11A3J+xyDqufa4/KUv7OJeE1KTE m8qLM/QKUKrwJuSTrc/E4J+0VYcp/Nw0xVC5UTzKLObvRxVBUXOMGMSermtGafO+qlSb3wkM4wCFY 1YiEUgv09TwdhOviRgfz3IT46TXs4pZ5LgG90wdIPL8BHYJ3NRQ1ohUqERCHU7Ru1rQG7tPRsJdEC wD1lZ+lr6T/jvJyx9Gz2EHfLvu5kGlyatIA0I6oxQy3McL4ew2lbAP0tSOhIZsrIxYa9tYHwTPuSg QCoQ2WR2JYYgukbLpiWw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nceaV-00Efw9-8g; Fri, 08 Apr 2022 02:43:03 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nceaP-00EfuP-Rb; Fri, 08 Apr 2022 02:43:00 +0000 X-UUID: b2133a845cc049549aeacc8173d100c6-20220407 X-UUID: b2133a845cc049549aeacc8173d100c6-20220407 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1679536719; Thu, 07 Apr 2022 19:42:55 -0700 Received: from mtkexhb01.mediatek.inc (172.21.101.102) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 Apr 2022 19:42:53 -0700 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkexhb01.mediatek.inc (172.21.101.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 Apr 2022 10:42:44 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 8 Apr 2022 10:42:44 +0800 Message-ID: <1ee8927744624fb0b6e97190e5a4b78cbee69751.camel@mediatek.com> Subject: Re: [RESEND v17 3/7] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0 From: Jason-JH Lin To: AngeloGioacchino Del Regno , "Rob Herring" , Matthias Brugger , Chun-Kuang Hu CC: Philipp Zabel , Maxime Coquelin , David Airlie , Daniel Vetter , Alexandre Torgue , "John 'Warthog9' Hawley" , , , , , , CK Hu , Fabien Parent , , , , , , , , Date: Fri, 8 Apr 2022 10:42:44 +0800 In-Reply-To: <8d5c41c0-ac7c-ed1e-726b-0d738bf22fed@collabora.com> References: <20220407030409.9664-1-jason-jh.lin@mediatek.com> <20220407030409.9664-4-jason-jh.lin@mediatek.com> <8d5c41c0-ac7c-ed1e-726b-0d738bf22fed@collabora.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220407_194257_931421_D491221E X-CRM114-Status: GOOD ( 44.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Angelo, Thanks for the reviews. On Thu, 2022-04-07 at 11:11 +0200, AngeloGioacchino Del Regno wrote: > Il 07/04/22 05:04, jason-jh.lin ha scritto: > > 1. Add mt8195 mmsys compatible for vdosys0. > > 2. Add mt8195 routing table settings and fix build fail. > > 3. Add clock name, clock driver name and routing table into the > > driver data > > of mt8195 vdosys0. > > 4. Add get match data by clock name function and clock platform > > labels > > to identify which mmsys node is corresponding to vdosys0. > > > > Signed-off-by: jason-jh.lin > > --- > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +- > > drivers/soc/mediatek/mt8167-mmsys.h | 2 +- > > drivers/soc/mediatek/mt8183-mmsys.h | 2 +- > > drivers/soc/mediatek/mt8186-mmsys.h | 4 +- > > drivers/soc/mediatek/mt8192-mmsys.h | 4 +- > > drivers/soc/mediatek/mt8195-mmsys.h | 370 > > ++++++++++++++++++++ > > drivers/soc/mediatek/mt8365-mmsys.h | 4 +- > > drivers/soc/mediatek/mtk-mmsys.c | 62 ++++ > > drivers/soc/mediatek/mtk-mmsys.h | 1 + > > drivers/soc/mediatek/mtk-mutex.c | 8 +- > > include/linux/soc/mediatek/mtk-mmsys.h | 13 +- > > 12 files changed, 461 insertions(+), 17 deletions(-) > > create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h > > > > ..snip.. > > > diff --git a/drivers/soc/mediatek/mtk-mmsys.c > > b/drivers/soc/mediatek/mtk-mmsys.c > > index 4fc4c2c9ea20..b2fa239c5f5f 100644 > > --- a/drivers/soc/mediatek/mtk-mmsys.c > > +++ b/drivers/soc/mediatek/mtk-mmsys.c > > @@ -4,6 +4,8 @@ > > * Author: James Liao > > */ > > > > +#include > > +#include > > #include > > #include > > #include > > @@ -17,6 +19,7 @@ > > #include "mt8183-mmsys.h" > > #include "mt8186-mmsys.h" > > #include "mt8192-mmsys.h" > > +#include "mt8195-mmsys.h" > > #include "mt8365-mmsys.h" > > > > static const struct mtk_mmsys_driver_data > > mt2701_mmsys_driver_data = { > > @@ -72,12 +75,24 @@ static const struct mtk_mmsys_driver_data > > mt8192_mmsys_driver_data = { > > .num_routes = ARRAY_SIZE(mmsys_mt8192_routing_table), > > }; > > > > +static const struct mtk_mmsys_driver_data > > mt8195_vdosys0_driver_data = { > > + .clk_name = "cfg_vdo0", > > + .clk_driver = "clk-mt8195-vdo0", > > + .routes = mmsys_mt8195_routing_table, > > + .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table), > > +}; > > + > > static const struct mtk_mmsys_driver_data > > mt8365_mmsys_driver_data = { > > .clk_driver = "clk-mt8365-mm", > > .routes = mt8365_mmsys_routing_table, > > .num_routes = ARRAY_SIZE(mt8365_mmsys_routing_table), > > }; > > > > +static const struct of_device_id mtk_clk_platform_labels[] = { > > + { .compatible = "mediatek,mt8195-mmsys", > > + .data = (void *)"clk-mt8195"}, > > I have a hunch that MT8195 won't be the first and last SoC having > multiple > mmsys channels. I would tend to think that there will be more.... > Yes, there will be another SoC with multiple mmsys channels... > ....so, to make it clean from the beginning, I think that you should, > at > this point, assign a struct to that .data pointer, instead of > declaring a > drvdata struct into mtk_mmsys_get_match_data_by_clk_name(). > > Besides, I think that this kind of usage for __clk_get_name() may be > an API > abuse... but I'm not sure about that... in any case: > - if it's not an abuse, then you should simply pass > mt8195_vdosys0_driver_data, > or an array of pointers to mtk_mmsys_driver_data; > - if this is an abuse, you can do the same checks by looking at the > iostart > (mmio base address) of the vdosys{0,1} node(s). Do you mean that I should change clk_name to iostart like this? mt8195_vdosys0_driver_data = { .iostart = 0x1c01a000, // instead of clk_name .clk_driver = "clk-mt8195-vdo0", .routes = mmsys_mt8195_routing_table, .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table), }; Just to confirm that address information can be disclosed here. If it is not appropriate to use address here, I'll keep using clk_name. > Honestly, though, I'm not even sure that you need this different > of_device_id > array here... since you could simply wrap the mtk_mmsys_driver_data > in the > of_match_mtk_mmsys that you have below... here's another idea: > > struct mtk_mmsys_match_data { > const struct mtk_mmsys_driver_data *drv_data[]; > unsigned short num_drv_data; > }; > > ...so that: > > static int some_function_handling_multi_mmsys(struct mtk_mmsys > *mmsys, > struct > mtk_mmsys_match_data *match) > { > int i; > > i = [ logic to find the right match->drv_data entry here ] > > return i; > } > > static int mtk_mmsys_probe() > { > .... variables, something else .... > > if (match_data->num_drv_data > 1) { > /* This SoC has multiple mmsys channels */ > ret = some_function_handling_multi_mmsys(mmsys); > if (ret < 0) > return ret; > > mmsys->data = match_data->drv_data[ret]; > } else { > dev_dbg(dev, "Using single mmsys channel\n"); > mmsys->data = match_data->drv_data[0]; > } > > ...everything else that mtk_mmsys_probe does ... > } I've tried this idea in my local environment and it looks good. So I'll apply this at the next version. Thanks for your idea! > What I'm trying to communicate with this is that the currently chosen > solution > looks a bit fragile and needs to be made robust. > In comparison, even if it's not technically right to have two > different compatibles > for the same hardware (and shall not be done), the former solution, > even if wrong, > was more robust than this one, imo. > > Regards, > Angelo Because we don't have a property to identify the different mmsys directly (not using multi-mmsys handle function). Although it make the code more complicated and not robust, but I think this time it should be implemented for other multi-mmsys SoC in the feature. Regards, Jason-JH.Lin - Jason-JH Lin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel