From: Weiyi Lu <weiyi.lu@mediatek.com>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
Nicolas Boichat <drinkcat@chromium.org>,
Rob Herring <robh@kernel.org>,
Stephen Boyd <sboyd@codeaurora.org>,
James Liao <jamesjj.liao@mediatek.com>,
<srv_heupstream@mediatek.com>, <linux-kernel@vger.kernel.org>,
<stable@vger.kernel.org>, Fan Chen <fan.chen@mediatek.com>,
<linux-mediatek@lists.infradead.org>, <linux-clk@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 08/12] clk: mediatek: Add MT8183 clock support
Date: Wed, 27 Feb 2019 10:51:37 +0800 [thread overview]
Message-ID: <1551235897.1047.11.camel@mtksdaap41> (raw)
In-Reply-To: <155120345816.260864.13433355004684800350@swboyd.mtv.corp.google.com>
On Tue, 2019-02-26 at 09:50 -0800, Stephen Boyd wrote:
> Quoting Weiyi Lu (2019-02-01 00:30:12)
> > diff --git a/drivers/clk/mediatek/clk-mt8183.c b/drivers/clk/mediatek/clk-mt8183.c
> > new file mode 100644
> > index 000000000000..e9de9fe774ca
> > --- /dev/null
> > +++ b/drivers/clk/mediatek/clk-mt8183.c
> > @@ -0,0 +1,1285 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// Copyright (c) 2018 MediaTek Inc.
> > +// Author: Weiyi Lu <weiyi.lu@mediatek.com>
> > +
> > +#include <linux/delay.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +
> [....]
> > +
> > +static int clk_mt8183_top_probe(struct platform_device *pdev)
> > +{
> > + struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + void __iomem *base;
> > + struct clk_onecell_data *clk_data;
> > + struct device_node *node = pdev->dev.of_node;
> > +
> > + base = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(base)) {
> > + pr_err("%s(): ioremap failed\n", __func__);
>
> This API already prints an error so please remove this duplicate error
> message
>
ok, I'll remove those duplicate error message in next version.
> > + return PTR_ERR(base);
> > + }
> > +
> > + clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
> > +
> > + mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks),
> > + clk_data);
> > +
> > + mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
> > +
> > + mtk_clk_register_muxes(top_muxes, ARRAY_SIZE(top_muxes),
> > + node, &mt8183_clk_lock, clk_data);
> > +
> > + mtk_clk_register_composites(top_aud_muxes, ARRAY_SIZE(top_aud_muxes),
> > + base, &mt8183_clk_lock, clk_data);
> > +
> > + mtk_clk_register_composites(top_aud_divs, ARRAY_SIZE(top_aud_divs),
> > + base, &mt8183_clk_lock, clk_data);
> > +
> > + mtk_clk_register_gates(node, top_clks, ARRAY_SIZE(top_clks),
> > + clk_data);
> > +
> > + return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> > +}
> > +
> > +static int clk_mt8183_infra_probe(struct platform_device *pdev)
> > +{
> > + struct clk_onecell_data *clk_data;
> > + struct device_node *node = pdev->dev.of_node;
> > +
> > + clk_data = mtk_alloc_clk_data(CLK_INFRA_NR_CLK);
> > +
> > + mtk_clk_register_gates(node, infra_clks, ARRAY_SIZE(infra_clks),
> > + clk_data);
> > +
> > + return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> > +}
> > +
> > +static int clk_mt8183_mcu_probe(struct platform_device *pdev)
> > +{
> > + struct clk_onecell_data *clk_data;
> > + struct device_node *node = pdev->dev.of_node;
> > + void __iomem *base;
> > + struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +
> > + base = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(base)) {
> > + pr_err("%s(): ioremap failed\n", __func__);
> > + return PTR_ERR(base);
> > + }
> > +
> > + clk_data = mtk_alloc_clk_data(CLK_MCU_NR_CLK);
>
> Can this fail? It doesn't seem to be checked for failure so I guess we
> don't care?
>
It might fail but we have data validity checks in all the
mtk_clk_register APIs.
> > +
> > + mtk_clk_register_composites(mcu_muxes, ARRAY_SIZE(mcu_muxes), base,
> > + &mt8183_clk_lock, clk_data);
> > +
> > + return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> > +}
> > +
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2019-02-27 2:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 8:30 [PATCH v4 00/12] Mediatek MT8183 clock and scpsys support Weiyi Lu
2019-02-01 8:30 ` Weiyi Lu
2019-02-20 19:18 ` Stephen Boyd
2019-02-21 8:36 ` Matthias Brugger
2019-02-22 7:48 ` Stephen Boyd
2019-02-26 4:00 ` Weiyi Lu
2019-02-26 17:45 ` Stephen Boyd
2019-02-01 8:30 ` [PATCH v4 01/12] clk: mediatek: Disable tuner_en before change PLL rate Weiyi Lu
2019-02-26 15:59 ` Matthias Brugger
2019-02-27 3:51 ` Weiyi Lu
2019-02-27 4:39 ` Weiyi Lu
2019-02-01 8:30 ` [PATCH v4 02/12] clk: mediatek: add new clkmux register API Weiyi Lu
2019-02-01 8:30 ` [PATCH v4 03/12] clk: mediatek: add configurable pcwibits and fmin to mtk_pll_data Weiyi Lu
2019-02-01 8:30 ` [PATCH v4 04/12] soc: mediatek: add new flow for mtcmos power Weiyi Lu
2019-02-08 18:30 ` Matthias Brugger
2019-02-01 8:30 ` [PATCH v4 05/12] dt-bindings: ARM: Mediatek: Document bindings for MT8183 Weiyi Lu
2019-02-01 8:30 ` [PATCH v4 06/12] clk: mediatek: Add dt-bindings for MT8183 clocks Weiyi Lu
2019-02-01 8:30 ` [PATCH v4 07/12] clk: mediatek: Add flags support for mtk_gate data Weiyi Lu
2019-02-01 8:30 ` [PATCH v4 08/12] clk: mediatek: Add MT8183 clock support Weiyi Lu
2019-02-26 17:50 ` Stephen Boyd
2019-02-27 2:51 ` Weiyi Lu [this message]
2019-02-01 8:30 ` [PATCH v4 09/12] dt-bindings: soc: fix typo of MT8173 power dt-bindings Weiyi Lu
2019-02-07 15:35 ` Matthias Brugger
2019-02-01 8:30 ` [PATCH v4 10/12] dt-bindings: soc: Add MT8183 " Weiyi Lu
2019-02-08 18:33 ` Matthias Brugger
2019-02-01 8:30 ` [PATCH v4 11/12] soc: mediatek: Add MT8183 scpsys support Weiyi Lu
2019-02-01 8:30 ` [PATCH v4 12/12] clk: mediatek: Allow changing PLL rate when it is off Weiyi Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1551235897.1047.11.camel@mtksdaap41 \
--to=weiyi.lu@mediatek.com \
--cc=drinkcat@chromium.org \
--cc=fan.chen@mediatek.com \
--cc=jamesjj.liao@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=sboyd@kernel.org \
--cc=srv_heupstream@mediatek.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).