Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191227094606.143637-1-jian.hu@amlogic.com> <20191227094606.143637-4-jian.hu@amlogic.com>
In-Reply-To: <20191227094606.143637-4-jian.hu@amlogic.com>
From:   Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Fri, 27 Dec 2019 18:04:33 +0100
Message-ID: <CAFBinCB2XF1unfEGbApuoXR3ZBRMwgc4EuqSjgKWKm_2G16S5g@mail.gmail.com>
Subject: Re: [PATCH v5 3/5] clk: meson: a1: add support for Amlogic A1 PLL
 clock driver
To:     Jian Hu <jian.hu@amlogic.com>
Cc:     Jerome Brunet <jbrunet@baylibre.com>,
        Neil Armstrong <narmstrong@baylibre.com>,
        Kevin Hilman <khilman@baylibre.com>,
        Rob Herring <robh@kernel.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Qiufang Dai <qiufang.dai@amlogic.com>,
        Jianxin Pan <jianxin.pan@amlogic.com>,
        Victor Wan <victor.wan@amlogic.com>,
        Chandle Zou <chandle.zou@amlogic.com>,
        linux-clk@vger.kernel.org, linux-amlogic@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Jian,

On Fri, Dec 27, 2019 at 10:46 AM Jian Hu <jian.hu@amlogic.com> wrote:
[...]
> +               .parent_data = &(const struct clk_parent_data){
> +                       .fw_name = "xtal_fixpll",
> +               },
in the Meson8b and G12A (I assume it's the same on GXBB, I didn't
check it) we have a space between " clk_parent_data)" and "{"
this applies to at least one more occurrence below

[...]
> +               /*
> +                * This clock is used by APB bus which setted in Romcode
nit-pick: I'm not sure about the grammar here: setted -> "is set"?
and to make sure I understand this correctly: do you mean the "boot
ROM" with "Romcode"?

[...]
> +static int meson_a1_pll_probe(struct platform_device *pdev)
> +{
> +       const struct meson_eeclkc_data *data;
what do you need this "data" variable for?

> +       struct device *dev = &pdev->dev;
> +       struct resource *res;
> +       void __iomem *base;
> +       struct regmap *map;
> +       int ret, i;
> +
> +       data = of_device_get_match_data(dev);
> +       if (!data)
> +               return -EINVAL;
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> +       base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(base))
> +               return PTR_ERR(base);
> +
> +       map = devm_regmap_init_mmio(dev, base, &clkc_regmap_config);
> +       if (IS_ERR(map))
> +              return PTR_ERR(map);
> +
> +       /* Populate regmap for the regmap backed clocks */
> +       for (i = 0; i < data->regmap_clk_num; i++)
> +               data->regmap_clks[i]->map = map;
why can't we use a1_pll_regmaps directly here?

> +
> +       for (i = 0; i < data->hw_onecell_data->num; i++) {
> +               /* array might be sparse */
> +               if (!data->hw_onecell_data->hws[i])
> +                       continue;
> +
> +               ret = devm_clk_hw_register(dev, data->hw_onecell_data->hws[i]);
and why can't we use a1_pll_hw_onecell_data directly here?

[...]
> +static const struct meson_eeclkc_data a1_pll_data = {
> +               .regmap_clks = a1_pll_regmaps,
> +               .regmap_clk_num = ARRAY_SIZE(a1_pll_regmaps),
> +               .hw_onecell_data = &a1_pll_hw_onecell_data,
> +};
if _probe would access these directly then you can drop meson_eeclkc_data
that is a good thing in my opinion because I was confused by the
"eeclk" since the patch description says that there's no EE or AO
domain on the A1 SoCs


Martin