LKML Archive on
help / color / mirror / Atom feed
From: Stephen Boyd <>
To: Rajan Vaja <>
Cc: "" <>,
	"" <>,
	Jolly Shah <>, Michal Simek <>,
	"" <>
Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER
Date: Thu, 15 Mar 2018 11:47:12 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Quoting Rajan Vaja (2018-03-09 11:27:40)
> > From: Stephen Boyd []
> > 
> > Is the intent to register the clk twice? I believe things are working as
> > intended without this patch, so maybe you can explain a little more what
> > you're trying to fix.
> [Rajan] Yes. During of_clk_init() if some DT fixed factor clock has
> parent which is neither mentioned in output-clock-names of clock
> controller nor registered as clock provider, of_clk_init() will try to
> forcefully register in second loop. 
>                         if (force || parent_ready(clk_provider->np)) {
>                                 /* Don't populate platform devices */
>                                 of_node_set_flag(clk_provider->np,
>                                                  OF_POPULATED);
> So registration of this DT fixed-factor clock would fail as parent
> would be NULL as below (called from _of_fixed_factor_clk_setup()):
> parent_name = of_clk_get_parent_name(node, 0);
> On the other hand, even if registration failed, that node will be
> marked as OF_POPULATED, so probe of clk-fixed-factor.c will also not
> be called and that DT fixed-factor clock would never be registered. 
> Same thing is discussed at .

Ok. I believe the answer is to fix the DT to describe the parent chain
properly with clock-output-names. Otherwise, we have no good way of
figuring out what the name should be.

The alternative is to start working on a solution for having the clk
framework stop using strings to describe clk topology. My plan there is
to allow clk registration to indicate that another parent names array
should be used with clk_get() of the device or node pointer that's
associated with the clk during registration to find the parent . If we
had that, then we could hook up clks into the tree by calling clk_get()
in the framework and map through the clock-names property. This also
gets us to a point where clk names don't have to be globally unique,
which would be nice.

  reply	other threads:[~2018-03-15 18:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08 14:15 [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER Rajan Vaja
2018-03-09 18:24 ` Stephen Boyd
2018-03-09 19:27   ` Rajan Vaja
2018-03-15 18:47     ` Stephen Boyd [this message]
2018-03-16 11:49       ` Rajan Vaja
2018-05-03  9:18         ` Rajan Vaja
2018-06-02  6:40           ` Stephen Boyd
2018-06-04  3:41             ` Rajan Vaja
2018-07-06 10:54               ` Rajan Vaja
2018-07-09  7:26               ` Stephen Boyd
2018-07-17 16:32                 ` Rajan Vaja

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* 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).