[PATCH v1 1/1] clk: npcm7xx: get fixed clocks from DT

Tali Perry tali.perry1 at gmail.com
Wed Dec 5 02:49:27 AEDT 2018


Hi Stephan,

Thanks for all the comments!

This patch include one change so it's one commit.
This clock module includes 4 PLLs and then a tree of muxes and dividers.
All muxes and dividers are preset before Linux boots. The presetting can
change according to the board.
Linux drivers need to know what the frequencies are, but they can not
change it,
so this whole driver is intended as read only mechanism for clocks.

On the first version which was up-streamed the PLLs input clk value was
defined inside the driver.

After the review I was asked that the fixed clock will be on the DT. This
is this fix.


This patch was submitted, but not pushed to Linux:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1610776.html

Meanwhile first version was pushed to the Kernel, So recreate a patch that
is relative between the two patches.


More comments inline..



On Fri, Nov 30, 2018 at 2:23 AM Stephen Boyd <sboyd at kernel.org> wrote:

> Quoting tali.perry1 at gmail.com (2018-11-11 05:47:12)
> > From: Tali Perry <tali.perry1 at gmail.com>
> >
> > Nuvoton NPCM7XX Clock Controller
> > fix base address and of_clk_get_by_name error handling.
> >     Also update error messages to be more informative.
> >
> >     In case clk_base allocation is erronoeous the return value is null.
> >     Also fix handling of of_clk_get_by_name returns an error.
> >     Print a better error message pointing to the dt-binding documention.
> >
> > This patch is re-submitted since it was already pushed to main
> > (just the diff, without the full driver which is already in
> > master branch.)
> >
> >
> > Signed-off-by: Tali Perry <tali.perry1 at gmail.com>
> > Reviewed-by: Rob Herring <robh at kernel.org>
> > Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
> >
>
> I don't know what's going on with this patch. Is it something new? Can
> you break it up into logical changes and submit them with proper commit
> text? The signoff chain is also odd. Can you follow
> Documentation/process/submitting-patches.rst?
>
> > ---
> >  drivers/clk/clk-npcm7xx.c | 99
> +++++++++++++++++++++++++++++++++++------------
> >  1 file changed, 75 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/clk/clk-npcm7xx.c b/drivers/clk/clk-npcm7xx.c
> > index 740af90a9508..91a937720f4e 100644
> > --- a/drivers/clk/clk-npcm7xx.c
> > +++ b/drivers/clk/clk-npcm7xx.c
> > @@ -7,17 +7,26 @@
> >   * Copyright (C) 2018 Nuvoton Technologies tali.perry at nuvoton.com
> >   */
> >
> > -#include <linux/module.h>
> > -#include <linux/clk-provider.h>
> > -#include <linux/io.h>
> > -#include <linux/kernel.h>
> > -#include <linux/of.h>
> > -#include <linux/of_address.h>
> > -#include <linux/slab.h>
> > -#include <linux/err.h>
> > -#include <linux/bitfield.h>
> > -
> > -#include <dt-bindings/clock/nuvoton,npcm7xx-clock.h>
> > +
> > +
> > +
> > + #include <linux/module.h>
> > + #include <linux/clk.h>
> > + #include <linux/clk-provider.h>
> > + #include <linux/device.h>
> > + #include <linux/io.h>
> > + #include <linux/kernel.h>
> > + #include <linux/of.h>
> > + #include <linux/of_device.h>
> > + #include <linux/of_platform.h>
> > + #include <linux/of_address.h>
> > + #include <linux/platform_device.h>
> > + #include <linux/slab.h>
> > + #include <linux/err.h>
> > + #include <linux/rational.h>
> > + #include <linux/bitfield.h>
> > + #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h>
>
> Is any of this hunk necessary or relevant to the subject of this patch?
>
> > +
> >
> >  struct npcm7xx_clk_pll {
> > @@ -44,7 +56,8 @@ static unsigned long
> npcm7xx_clk_pll_recalc_rate(struct clk_hw *hw,
> >         u64 ret;
> >
> >         if (parent_rate == 0) {
> > -               pr_err("%s: parent rate is zero", __func__);
> > +               pr_err("%s: parent rate is zero. reg=%x\n", __func__,
> > +                       (u32)(pll->pllcon));
>
> Maybe you should print clk name instead of register?
>

Tali: There are only 4 pllcon registers. I don't mind if it's the address
and not the name.

>
> >                 return 0;
> >         }
> >
> > @@ -61,13 +74,12 @@ static unsigned long
> npcm7xx_clk_pll_recalc_rate(struct clk_hw *hw,
> >         return ret;
> >  }
> >
> > -static const struct clk_ops npcm7xx_clk_pll_ops = {
> > +const struct clk_ops npcm7xx_clk_pll_ops = {
>
> Why?
>

Tali: I will return the static.

>
> >         .recalc_rate = npcm7xx_clk_pll_recalc_rate,
> >  };
> >
> > -static struct clk_hw *
> > -npcm7xx_clk_register_pll(void __iomem *pllcon, const char *name,
> > -                        const char *parent_name, unsigned long flags)
> > +static struct clk_hw *npcm7xx_clk_register_pll(void __iomem *pllcon,
> > +               const char *name, const char *parent_name, unsigned long
> flags)
> >  {
> >         struct npcm7xx_clk_pll *pll;
> >         struct clk_init_data init;
> > @@ -78,7 +90,8 @@ npcm7xx_clk_register_pll(void __iomem *pllcon, const
> char *name,
> >         if (!pll)
> >                 return ERR_PTR(-ENOMEM);
> >
> > -       pr_debug("%s reg, name=%s, p=%s\n", __func__, name, parent_name);
> > +       pr_debug("%s reg, reg=0x%x, name=%s, p=%s\n",
> > +               __func__, (unsigned int)pllcon, name, parent_name);
>
> What's going on here? Why cast?
>
Tali: I will remove this print all together.

>
> >
> >         init.name = name;
> >         init.ops = &npcm7xx_clk_pll_ops;
> > @@ -544,9 +557,11 @@ static void __init npcm7xx_clk_init(struct
> device_node *clk_np)
> >         void __iomem *clk_base;
> >         struct resource res;
> >         struct clk_hw *hw;
> > +       struct clk *clk;
> >         int ret;
> >         int i;
> >
> > +       clk_base = NULL;
>
> Why?
>

Tali: to init it. If DT is badly defined the value will remain NULL.


>
> >         ret = of_address_to_resource(clk_np, 0, &res);
> >         if (ret) {
> >                 pr_err("%s: failed to get resource, ret %d\n",
> clk_np->name,
> > @@ -560,14 +575,44 @@ static void __init npcm7xx_clk_init(struct
> device_node *clk_np)
> >
> >         npcm7xx_clk_data = kzalloc(sizeof(*npcm7xx_clk_data->hws) *
> >                 NPCM7XX_NUM_CLOCKS + sizeof(npcm7xx_clk_data),
> GFP_KERNEL);
> > -       if (!npcm7xx_clk_data)
> > +
> > +       npcm7xx_clk_data->num = 0;
>
> kzalloc already does that initialization to 0 for you.
>
> > +
> > +       if (!npcm7xx_clk_data->hws) {
> > +               pr_err("Can't alloc npcm7xx_clk_data\n");
>
> We don't need allocation error messages.
>
> >                 goto npcm7xx_init_np_err;
> > +       }
> >
> >         npcm7xx_clk_data->num = NPCM7XX_NUM_CLOCKS;
> >
> >         for (i = 0; i < NPCM7XX_NUM_CLOCKS; i++)
> >                 npcm7xx_clk_data->hws[i] = ERR_PTR(-EPROBE_DEFER);
> >
> > +       /* Read fixed clocks. These 3 clocks must be defined in DT */
> > +       clk = of_clk_get_by_name(clk_np, NPCM7XX_CLK_S_REFCLK);
> > +       if (IS_ERR(clk)) {
> > +               pr_err("failed to find external REFCLK on device tree,
> err=%ld\n",
> > +                       PTR_ERR(clk));
> > +               clk_put(clk);
> > +               goto npcm7xx_init_fail_no_clk_on_dt;
> > +       }
> > +
> > +       clk = of_clk_get_by_name(clk_np, NPCM7XX_CLK_S_SYSBYPCK);
> > +       if (IS_ERR(clk)) {
> > +               pr_err("failed to find external SYSBYPCK on device tree,
> err=%ld\n",
> > +                       PTR_ERR(clk));
> > +               clk_put(clk);
> > +               goto npcm7xx_init_fail_no_clk_on_dt;
> > +       }
> > +
> > +       clk = of_clk_get_by_name(clk_np, NPCM7XX_CLK_S_MCBYPCK);
> > +       if (IS_ERR(clk)) {
> > +               pr_err("failed to find external MCBYPCK on device tree,
> err=%ld\n",
> > +                       PTR_ERR(clk));
> > +               clk_put(clk);
> > +               goto npcm7xx_init_fail_no_clk_on_dt;
> > +       }
>
> I assume the DTS is not shipped?
>

Tali: DTS for npcm is shipped in a separate patchset.

>
> > +
> >         /* Register plls */
> >         for (i = 0; i < ARRAY_SIZE(npcm7xx_plls); i++) {
> >                 const struct npcm7xx_clk_pll_data *pll_data =
> &npcm7xx_plls[i];
> > @@ -584,16 +629,16 @@ static void __init npcm7xx_clk_init(struct
> device_node *clk_np)
> >         }
> >
> >         /* Register fixed dividers */
> > -       hw = clk_hw_register_fixed_factor(NULL, NPCM7XX_CLK_S_PLL1_DIV2,
> > +       clk = clk_register_fixed_factor(NULL, NPCM7XX_CLK_S_PLL1_DIV2,
>
> This is going backwards. Please use clk_hw APIs.
>
Tali: Will fix.

>
> >                         NPCM7XX_CLK_S_PLL1, 0, 1, 2);
> > -       if (IS_ERR(hw)) {
> > +       if (IS_ERR(clk)) {
> >                 pr_err("npcm7xx_clk: Can't register fixed div\n");
> >                 goto npcm7xx_init_fail;
> >         }
> >
> > -       hw = clk_hw_register_fixed_factor(NULL, NPCM7XX_CLK_S_PLL2_DIV2,
> > +       clk = clk_register_fixed_factor(NULL, NPCM7XX_CLK_S_PLL2_DIV2,
> >                         NPCM7XX_CLK_S_PLL2, 0, 1, 2);
> > -       if (IS_ERR(hw)) {
> > +       if (IS_ERR(clk)) {
> >                 pr_err("npcm7xx_clk: Can't register div2\n");
> >                 goto npcm7xx_init_fail;
> >         }
> > @@ -646,11 +691,17 @@ static void __init npcm7xx_clk_init(struct
> device_node *clk_np)
> >
> >         return;
> >
> > +npcm7xx_init_fail_no_clk_on_dt:
> > +       pr_err("see Documentation/devicetree/bindings/clock/");
> > +       pr_err("nuvoton,npcm750-clk.txt  for details\n");
> >  npcm7xx_init_fail:
> > -       kfree(npcm7xx_clk_data->hws);
> > +       if (npcm7xx_clk_data->num)
> > +               kfree(npcm7xx_clk_data->hws);
> >  npcm7xx_init_np_err:
> > -       iounmap(clk_base);
> > +       if (clk_base != NULL)
> > +               iounmap(clk_base);
> >  npcm7xx_init_error:
> >         of_node_put(clk_np);
> > +       pr_err("clk setup fail\n");
>
> Is this hunk of changes related to the subject of this patch? I don't
> think it is, so it just leads to more confusion.
>

Tali: I added a goto option for the case that the DTS doesn't have the
reference clocks this module needs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20181204/9b365f25/attachment-0001.html>


More information about the openbmc mailing list