From: Alexander Dahl <ada@thorsis.com>
To: linux-clk@vger.kernel.org
Cc: Stephen Boyd <sboyd@kernel.org>,
u.kleine-koenig@pengutronix.de,
Michael Turquette <mturquette@baylibre.com>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH v2] dt-bindings: clk: Make example a bit clearer
Date: Thu, 10 Oct 2019 16:16:00 +0200 [thread overview]
Message-ID: <2819678.zAmqMVPImI@ada> (raw)
In-Reply-To: <20190916201316.ED7EB20665@mail.kernel.org>
Hello Stephen,
I took some minutes to look at this again, because I was the one who had
difficulties understanding the documentation here in the first place.
Note: this patch/discussion is not about changing the dt-binding, but about
improving the documentation on the properties 'assigned-clocks', 'assigned-
clock-parents', and 'assigned-clock-rates'. See below:
Am Montag, 16. September 2019, 13:13:16 CEST schrieb Stephen Boyd:
> (Sorry my MUA fails at utf8 encoding emails)
>
> > On Wed, Sep 11, 2019 at 09:06:47AM -0700, Stephen Boyd wrote:
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > > > b/Documentation/devicetree/bindings/clock/clock-bindings.txt index
> > > > b646bbcf7f92..1d4942380918 100644
> > > > --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > > > +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> > > > @@ -150,16 +150,18 @@ set to 0, or can be omitted if it is not
> > > > followed by any non-zero entry.> > >
> > > > compatible = "fsl,imx-uart";
> > > > reg = <0xa000 0x1000>;
> > > > ...
> > > >
> > > > - clocks = <&osc 0>, <&pll 1>;
> > > > - clock-names = "baud", "register";
> > > > + clocks = ...
> > > > + clock-names = ...
> > >
> > > I don't see the need for this change.
> >
> > <&pll 1> is mentioned below. But it is not this instance that is
> > relevant. So I suggested to get rid of it to not be a source of
> > confusion. (But I guess you understood that.)
>
> Yes.
This was indeed one source of confusion for me. This obfuscation of Uwe would
have helped me, because it hides distracting information, which is irrelevant
for explaining assigned clock parents and might lead to false conclusions on
how those things work.
> > > > assigned-clocks = <&clkcon 0>, <&pll 2>;
> > > >
> > > > - assigned-clock-parents = <&pll 2>;
> > > > + assigned-clock-parents = <&pll 1>;
> > > >
> > > > assigned-clock-rates = <0>, <460800>;
> > > >
> > > > };
> > > >
> > > > -In this example the <&pll 2> clock is set as parent of clock <&clkcon
> > > > 0> and -the <&pll 2> clock is assigned a frequency value of 460800
> > > > Hz.
> > > > +In this example the <&pll 1> clock is set as parent of clock <&clkcon
> > > > 0> and +the <&pll 2> clock is assigned a frequency value of 460800
> > > > Hz. A parent +setting for <&pll 2> is omitted (end of list) and rate
> > > > setting for <&clkcon 0> +is skipped because set to <0>.
> > >
> > > Maybe you can comment that the "clocks" and "clock-names" properties
> > > don't matter for assigned clk rates and parents.
> >
> > Sure, a long text can explain this, but a maximal simple example is
> > very beneficial, too.
>
> The paragraph at the start of "Assigned clock parents and rates" already
> explains how these properties work. This patch isn't going to help if
> the reader hasn't read that paragraph, so reordering things isn't
> providing more clarity.
Reordering might not help. What helps on understanding things is describing
the same topic in a different way again. This is somewhat redundant, but
someone who does not fully understand explanation A might understand
explanation B better.
> If anything, I would clarify the description of
> the example by indicating what parts of the example we're talking about
> when explaining, i.e.
>
> In this example the <&pll 2> clock is set as parent of the
> <&clkcon 0> clock because the first clock specifier in the
> assigned-clocks property is <&clkcon 0> and that matches the
> first clock specifier in the assigned-clock-parents property.
> Similarly the <&pll 2> clock is assigned a frequency value of
> 460800 Hz because the second frequency in the
> assigned-clock-rates property is 460800 Hz and that matches the
> second clock specifier in the assigned-clocks property <&pll 2>.
I could go with that and send a v3 with the obfuscation from above (I'd like
to keep that) and this paragraph of yours?
Greets
Alex
next prev parent reply other threads:[~2019-10-10 14:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-23 10:03 [PATCH v2] dt-bindings: clk: Make example a bit clearer Alexander Dahl
2019-09-11 16:06 ` Stephen Boyd
2019-09-11 17:49 ` Uwe Kleine-König
2019-09-16 20:13 ` Stephen Boyd
2019-10-10 14:16 ` Alexander Dahl [this message]
2019-11-08 22:18 ` Stephen Boyd
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=2819678.zAmqMVPImI@ada \
--to=ada@thorsis.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
/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).