[PATCH 0/4] clk: mvebu: fix clk init order

[Gregory CLEMENT]

On 17/02/2014 15:42, Emilio López wrote:
> Hi Gregory, Ezequiel,
> 
>  >> Are we still in time to consider Emilio's oneline proposal?
>>> (Emilio: would you mind preparing a suitable patch against dove,
>>> kirkwood, armada370/xp, so we can see the real thing?).
> 
> The patch is in a common file, so it does not need patching anything for 
> each platform.
> 
>> I am still strongly against this proposal because hard-coded the parent
>> clock name in the driver seems very wrong
> 
> It is hardcoded already when the parent is registered, so I do not 
> understand your concern.
> 
> http://lxr.free-electrons.com/source/drivers/clk/mvebu/common.c?v=3.13#L34
> 
>> and moreover in some circumstances
>> (if there is no output-name, which is our default case) this proposal
>> just ignored the parent clock given by the device tree and this looked
>> more wrong.
> 
> I have sent a second patch addressing this comment, but you do not seem 
> to have taken too serious a look at it.
> 
> http://www.spinics.net/lists/arm-kernel/msg305922.html
> 

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 at 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 hope this example will show you, what I disagree with this proposal and why it
introduce some regression.

Regards,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com