Re: [PATCH] clk: respect the clock dependencies in of_clk_init

From: Gregory CLEMENT
Date: Fri Feb 07 2014 - 10:13:12 EST


On 07/02/2014 16:00, Emilio LÃpez wrote:
> El 07/02/14 11:49, Gregory CLEMENT escribiÃ:
>> On 07/02/2014 15:43, Ezequiel Garcia wrote:
>>> On Fri, Feb 07, 2014 at 09:24:30AM -0500, Jason Cooper wrote:
>>>> On Fri, Feb 07, 2014 at 10:06:08AM -0300, Emilio LÃpez wrote:
>>>>
>>>> [snip a great explanation]
>>>>
>>>> Guys, can I get some Tested-by's on this?
>>>>
>>>
>>> In case someone missed Emilio's comment about it, I gave his oneliner
>>> a test on A370 Reference Design. It worked just as well as Sebastian's.
>>
>> Well ok it's working but this patch is not better than Sebastian, it is
>> even worth. I don't think it is a good idea at all to totally ignore the
>> information given by the device tree.
>
> With a bit more work, you can replace the clk_get magic with a call to
> of_clk_get_parent_name() or similar to be able to keep overriding stuff
> from DT. This way it would completely match the behaviour on
> mvebu_coreclk_setup (default to "tclk", allow overriding with DT).
>

I think you didn't have a look on our implementation: the name of the clock
are created by the driver during the initialization. That's why we need that
the parent clock are initialized before the gating clock. I know that for the
sunxi clock you choose to list all your clock name in the device tree, but we
didn't make this choice on purpose. It is not as trivial as you suggested.

I didn't have a look on the atmel clocks, and I don't know if they have this
kind of issue, as they also have to deal with multiple parents, they may
have different issues.

Gregory

> Emilio
>


--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/