Hi Mike, Rob,
Devices in a SoC can have multiple possible clock sources which is
perfectly captured through clk framework.
But the device itself may not be aware of the complex hierarchy above it.
In this case how do you suggest a board (through DT) should select its
preference.
Is there some work already going on in this direction ?
--
regards
Shiraz Hashim
On Wed, Nov 7, 2012 at 11:42 AM, Shiraz Hashim
<[email protected]> wrote:
> Hi Mike, Rob,
>
> Devices in a SoC can have multiple possible clock sources which is
> perfectly captured through clk framework.
>
> But the device itself may not be aware of the complex hierarchy above it.
> In this case how do you suggest a board (through DT) should select its
> preference.
>
> Is there some work already going on in this direction ?
Just to make it clear, I already have referred the clock DT bindings and
Shawn Guo patch on removing clk look up registration from kernel code.
Here I am talking about possibility of selecting desired clock hierarchy
by the boards about which device nodes are not aware.
--
regards
Shiraz Hashim
Quoting Shiraz Hashim (2012-11-06 22:36:10)
> On Wed, Nov 7, 2012 at 11:42 AM, Shiraz Hashim
> <[email protected]> wrote:
> > Hi Mike, Rob,
> >
> > Devices in a SoC can have multiple possible clock sources which is
> > perfectly captured through clk framework.
> >
> > But the device itself may not be aware of the complex hierarchy above it.
> > In this case how do you suggest a board (through DT) should select its
> > preference.
> >
> > Is there some work already going on in this direction ?
>
> Just to make it clear, I already have referred the clock DT bindings and
> Shawn Guo patch on removing clk look up registration from kernel code.
>
> Here I am talking about possibility of selecting desired clock hierarchy
> by the boards about which device nodes are not aware.
>
One way to achieve this is to use clk_set_rate as a way to switch
parents at run-time. The OMAP CCF code currently does this when
relocking PLLs and makes use of __clk_reparent to update the clock
framework's representation of the hierarchy dynamically.
Maybe something like the following is helpful to you:
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=arch/arm/mach-omap2/dpll3xxx.c;h=f72dedb4eee892ce4cd5bdf22cc8c22510f3d526;hb=clk-omap-3.8#l542
Regards,
Mike
> --
> regards
> Shiraz Hashim
Hi Mike,
On Tue, Nov 13, 2012 at 2:52 AM, Mike Turquette <[email protected]> wrote:
> Quoting Shiraz Hashim (2012-11-06 22:36:10)
>> On Wed, Nov 7, 2012 at 11:42 AM, Shiraz Hashim
>> <[email protected]> wrote:
>> > Hi Mike, Rob,
>> >
>> > Devices in a SoC can have multiple possible clock sources which is
>> > perfectly captured through clk framework.
>> >
>> > But the device itself may not be aware of the complex hierarchy above it.
>> > In this case how do you suggest a board (through DT) should select its
>> > preference.
>> >
>> > Is there some work already going on in this direction ?
>>
>> Just to make it clear, I already have referred the clock DT bindings and
>> Shawn Guo patch on removing clk look up registration from kernel code.
>>
>> Here I am talking about possibility of selecting desired clock hierarchy
>> by the boards about which device nodes are not aware.
>>
>
> One way to achieve this is to use clk_set_rate as a way to switch
> parents at run-time. The OMAP CCF code currently does this when
> relocking PLLs and makes use of __clk_reparent to update the clock
> framework's representation of the hierarchy dynamically.
>
> Maybe something like the following is helpful to you:
> http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=arch/arm/mach-omap2/dpll3xxx.c;h=f72dedb4eee892ce4cd5bdf22cc8c22510f3d526;hb=clk-omap-3.8#l542
Thanks for the information.
So the generic SoC part can be handled through set_rate but
what about boards preferences and restrictions. For e.g., it prefers
to route a clock from a particular clk source only and wants its own
fixed (as per its design) clk source selections.
--
regards
Shiraz Hashim