[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1605667293.8636.5.camel@mtksdaap41>
Date: Wed, 18 Nov 2020 10:41:33 +0800
From: Yingjoe Chen <yingjoe.chen@...iatek.com>
To: Weiyi Lu <weiyi.lu@...iatek.com>
CC: Matthias Brugger <matthias.bgg@...il.com>,
Rob Herring <robh@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
Nicolas Boichat <drinkcat@...omium.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>,
<linux-mediatek@...ts.infradead.org>, <linux-clk@...r.kernel.org>,
<srv_heupstream@...iatek.com>
Subject: Re: [PATCH v5 14/24] clk: mediatek: Add MT8192 imp i2c wrapper
clock support
On Mon, 2020-11-09 at 10:03 +0800, Weiyi Lu wrote:
> Add MT8192 imp i2c wrapper clock provider
>
> Signed-off-by: Weiyi Lu <weiyi.lu@...iatek.com>
> ---
> drivers/clk/mediatek/Kconfig | 6 ++
> drivers/clk/mediatek/Makefile | 1 +
> drivers/clk/mediatek/clk-mt8192-imp_iic_wrap.c | 119 +++++++++++++++++++++++++
> 3 files changed, 126 insertions(+)
> create mode 100644 drivers/clk/mediatek/clk-mt8192-imp_iic_wrap.c
>
> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index eb549f8..8acc7d6 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -515,6 +515,12 @@ config COMMON_CLK_MT8192_IMGSYS
> help
> This driver supports MediaTek MT8192 imgsys and imgsys2 clocks.
>
> +config COMMON_CLK_MT8192_IMP_IIC_WRAP
> + bool "Clock driver for MediaTek MT8192 imp_iic_wrap"
> + depends on COMMON_CLK_MT8192
> + help
> + This driver supports MediaTek MT8192 imp_iic_wrap clocks.
> +
> config COMMON_CLK_MT8516
> bool "Clock driver for MediaTek MT8516"
> depends on ARCH_MEDIATEK || COMPILE_TEST
<...>
> +
> +static struct platform_driver clk_mt8192_imp_iic_wrap_drv = {
> + .probe = mtk_clk_simple_probe,
Good to have this generic probe function. Now several mtk clk drivers
are just a few data.
But this series still add >10 configs for mt8192 clock drivers. Why do
we need separate configs for clocks of different domain? I don't think
they need lots of resource. We should review the rationale and reduce
the numbers.
Joe.C
Powered by blists - more mailing lists