public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Emilio López" <emilio@elopez.com.ar>
To: Gregory CLEMENT <gregory.clement@free-electrons.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Jason Cooper <jason@lakedaemon.net>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Mike Turquette <mturquette@linaro.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/4] clk: mvebu: fix clk init order
Date: Mon, 17 Feb 2014 12:31:37 -0300	[thread overview]
Message-ID: <53022B59.3060905@elopez.com.ar> (raw)
In-Reply-To: <53022504.1010908@free-electrons.com>

Hi,

El 17/02/14 12:04, Gregory CLEMENT escribió:
(snip)
> Please read what I have written: "if there is no output-name, which is our
> default case) this proposal just ignored the parent clock given by the device
> tree".
>
> Extract of your code from the link you pointed:
>
> const char *default_parent = "tclk";
>
> [...]
>
> of_property_read_string_index(clkspec.np, "clock-output-names",
> 					      clkspec.args_count ? clkspec.args[0] : 0,
> 					      &default_parent);
>
> example of a valid dts:
> 			gateclk: clock-gating-control@18220 {
> 				compatible = "marvell,foo-bar-gating-clock";
> 				reg = <0x18220 0x4>;
> 				clocks = <&coreclk 1>;
> 				#clock-cells = <1>;
> 			};
>
> So in this fictional but still valid example, the device tree indicates that the parent
> clock of the gating clock is the 2nd clock provided by the coreclk which is currently
> "cpuclk". As no clock-output-names is used, then this will be totally ignore and instead
> of using "cpuclk" as parent "tclk" will be used.

I can see your point now, but as this is completely fictional, I'd say 
it's irrelevant. You can just add the names if Marvell ever makes a chip 
that sources the gates from the second coreclk. As far as I can see on 
the device trees in Linux, all mvebu hardware always sources them from 
tclk. Don't try to over-engineer your driver for something that is 
unlikely to happen in reality.

If you in the future need to support another legacy platform with a 
half-cooked DT not listing the names, you can always list the right 
parent on the divisor table (see link for example) and override the default.

http://lxr.free-electrons.com/source/drivers/clk/mvebu/kirkwood.c?v=3.13#L222

> I hope this example will show you, what I disagree with this proposal and why it
> introduce some regression.

It's not a regression if things don't break :-)

Cheers,

Emilio

  reply	other threads:[~2014-02-17 15:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-25 18:19 [PATCH 0/4] clk: mvebu: fix clk init order Sebastian Hesselbarth
2014-01-25 18:19 ` [PATCH 1/4] clk: mvebu: armada-370: maintain clock " Sebastian Hesselbarth
2014-01-25 18:19 ` [PATCH 2/4] clk: mvebu: armada-xp: " Sebastian Hesselbarth
2014-01-25 18:19 ` [PATCH 3/4] clk: mvebu: dove: " Sebastian Hesselbarth
2014-01-25 18:19 ` [PATCH 4/4] clk: mvebu: kirkwood: " Sebastian Hesselbarth
2014-01-25 21:32 ` [PATCH 0/4] clk: mvebu: fix clk " Emilio López
2014-01-25 21:44   ` Sebastian Hesselbarth
2014-01-25 22:11     ` Emilio López
2014-01-26  0:25       ` Ezequiel Garcia
2014-01-27 14:39 ` Thomas Petazzoni
2014-01-27 18:21   ` Sebastian Hesselbarth
2014-01-27 18:28     ` Jason Cooper
2014-01-30 10:24 ` Gregory CLEMENT
2014-01-30 10:31   ` Sebastian Hesselbarth
2014-02-03 23:16     ` Willy Tarreau
2014-02-03 23:36       ` Sebastian Hesselbarth
2014-02-04 14:58         ` Gregory CLEMENT
2014-02-04 20:07           ` Thomas Petazzoni
2014-02-05 14:08 ` Mike Turquette
2014-02-05 17:43   ` Jason Cooper
2014-02-05 18:34 ` Jason Cooper
2014-02-06 17:08   ` Ezequiel Garcia
2014-02-06 18:08     ` Jason Cooper
2014-02-17 14:13   ` Ezequiel Garcia
2014-02-17 14:25     ` Gregory CLEMENT
2014-02-17 14:42       ` Emilio López
2014-02-17 15:04         ` Gregory CLEMENT
2014-02-17 15:31           ` Emilio López [this message]
2014-02-17 15:21       ` Ezequiel Garcia
2014-02-17 15:28         ` Gregory CLEMENT
2014-02-17 15:44           ` Ezequiel Garcia
2014-02-17 15:59             ` Gregory CLEMENT
2014-02-17 18:19               ` Ezequiel Garcia
2014-02-18  9:47                 ` Gregory CLEMENT
2014-02-19 16:28                   ` Ezequiel Garcia
2014-02-19 20:24                   ` Emilio López

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=53022B59.3060905@elopez.com.ar \
    --to=emilio@elopez.com.ar \
    --cc=andrew@lunn.ch \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=thomas.petazzoni@free-electrons.com \
    /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