Hi Daniel,
On Tue, Feb 19, 2013 at 09:09:31AM +0530, Afzal Mohammed wrote:
> Hope invoking of_clk_init before clock generator driver helps
Mails coming from this id are in my personal capacity.
On Tue, Feb 19, 2013 at 10:53:18AM +0100, Daniel Mack wrote:
> On 19.02.2013 02:33, Fabio Estevam wrote:
> > Have you registered it with clk_register_fixed_rate() ?
> Hmm no, I didn't do anything else than adding it to the DT in the first
> place, hoping that a driver will pick it up and add the clock for me.
> But it turns out that of_clk_init() is not called at all on my platform.
>
> I'm doing this now from omap_generic_init() and it works. If that's an
> appropriate place to call it, I can provide a patch.
Initially didn't realize that it was for an am335x based one.
I feel that for a platform having it's clock tree in DT, of_clk_init
would take care of it, but if clock tree data is not in DT, clock
tree would have to be extended in a non-DT way.
Regards
Afzal
Hi Afzal,
thanks for looking into this.
On 07.03.2013 19:42, Afzal Mohammed wrote:
> On Tue, Feb 19, 2013 at 09:09:31AM +0530, Afzal Mohammed wrote:
>
>> Hope invoking of_clk_init before clock generator driver helps
>
> Mails coming from this id are in my personal capacity.
>
> On Tue, Feb 19, 2013 at 10:53:18AM +0100, Daniel Mack wrote:
>> On 19.02.2013 02:33, Fabio Estevam wrote:
>
>>> Have you registered it with clk_register_fixed_rate() ?
>
>> Hmm no, I didn't do anything else than adding it to the DT in the first
>> place, hoping that a driver will pick it up and add the clock for me.
>> But it turns out that of_clk_init() is not called at all on my platform.
>>
>> I'm doing this now from omap_generic_init() and it works. If that's an
>> appropriate place to call it, I can provide a patch.
>
> Initially didn't realize that it was for an am335x based one.
>
> I feel that for a platform having it's clock tree in DT, of_clk_init
> would take care of it, but if clock tree data is not in DT, clock
> tree would have to be extended in a non-DT way.
Hmm, I don't follow. So for generic OMAP board in general which does
*not* have its SoC clocks in DT, the question is who's in charge of
registering out-of-SoC fixed clocks that are defined in DT.
Note that the clock I'm dealing with here is _outside_ of the SoC, and I
just need to have it in DT, so it can feed another clock chip's input pin.
Grep'ing through arch/arm, it seems that the imx arch does the same
thing my patch does, but I could also imagine that it should be done
somewhere from the DT core. I copied Grant, Rob and Mark for more comments.
Thanks,
Daniel
On Thu, Mar 07, 2013 at 11:31:59PM +0100, Daniel Mack wrote:
> On 07.03.2013 19:42, Afzal Mohammed wrote:
> > I feel that for a platform having it's clock tree in DT, of_clk_init
> > would take care of it, but if clock tree data is not in DT, clock
> > tree would have to be extended in a non-DT way.
> Hmm, I don't follow. So for generic OMAP board in general which does
> *not* have its SoC clocks in DT, the question is who's in charge of
> registering out-of-SoC fixed clocks that are defined in DT.
> Note that the clock I'm dealing with here is _outside_ of the SoC, and I
> just need to have it in DT, so it can feed another clock chip's input pin.
> Grep'ing through arch/arm, it seems that the imx arch does the same
> thing my patch does, but I could also imagine that it should be done
> somewhere from the DT core. I copied Grant, Rob and Mark for more comments.
Wouldn't this just be set up by the DT in the same way that other
off-SoC hardware is?
On 08.03.2013 03:15, Mark Brown wrote:
> On Thu, Mar 07, 2013 at 11:31:59PM +0100, Daniel Mack wrote:
>> On 07.03.2013 19:42, Afzal Mohammed wrote:
>
>>> I feel that for a platform having it's clock tree in DT, of_clk_init
>>> would take care of it, but if clock tree data is not in DT, clock
>>> tree would have to be extended in a non-DT way.
>
>> Hmm, I don't follow. So for generic OMAP board in general which does
>> *not* have its SoC clocks in DT, the question is who's in charge of
>> registering out-of-SoC fixed clocks that are defined in DT.
>
>> Note that the clock I'm dealing with here is _outside_ of the SoC, and I
>> just need to have it in DT, so it can feed another clock chip's input pin.
>
>> Grep'ing through arch/arm, it seems that the imx arch does the same
>> thing my patch does, but I could also imagine that it should be done
>> somewhere from the DT core. I copied Grant, Rob and Mark for more comments.
>
> Wouldn't this just be set up by the DT in the same way that other
> off-SoC hardware is?
Well, I thought so too. To repeat, in my DT, I have:
ref25: ref25M {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
};
to represent an osciallator on the board. I need to specify it here so I
can pass a reference to another chip:
si5351a: clock-generator@60 {
compatible = "silabs,si5351a";
clocks = <&ref25>;
};
I would have expected that "fixed-clock" is matched by a driver lurking
around for DT boards, just like what the "fixed-regulator" driver does
for instance. But the clock device isn't initialized unless board code
explicitly calls of_clk_init() with a table mentioning "fixed-clock", as
in my patch.
I don't know the clock framework well enough, but it seems that either
all DT boards are supposed to do the same in their generic bits (which
sounds like a lot of code duplication), or the fixed-clock driver should
behave like any other driver wrt its probing from DT. I'm open to
suggestions :)
Daniel
On 03/08/2013 02:30 PM, Daniel Mack wrote:
> On 08.03.2013 03:15, Mark Brown wrote:
>> On Thu, Mar 07, 2013 at 11:31:59PM +0100, Daniel Mack wrote:
>>> On 07.03.2013 19:42, Afzal Mohammed wrote:
>>> Grep'ing through arch/arm, it seems that the imx arch does the same
>>> thing my patch does, but I could also imagine that it should be done
>>> somewhere from the DT core. I copied Grant, Rob and Mark for more comments.
>>
>> Wouldn't this just be set up by the DT in the same way that other
>> off-SoC hardware is?
>
> [...]
>
> I don't know the clock framework well enough, but it seems that either
> all DT boards are supposed to do the same in their generic bits (which
> sounds like a lot of code duplication), or the fixed-clock driver should
> behave like any other driver wrt its probing from DT. I'm open to
> suggestions :)
Daniel,
the current common clock framework does not register any of its "core"
clocks, i.e. fixed-clock, et.al. I haven't had a look at the way regulator
api registers them. But if you find the way reasonable, why not propose
a patch for ccf that registers at least a set of the core clocks itself?
Sebastian
On Fri, Mar 08, 2013 at 02:30:27PM +0100, Daniel Mack wrote:
> On 08.03.2013 03:15, Mark Brown wrote:
> > Wouldn't this just be set up by the DT in the same way that other
> > off-SoC hardware is?
> Well, I thought so too. To repeat, in my DT, I have:
OK, I got CCed in part way through the thread.
> I would have expected that "fixed-clock" is matched by a driver lurking
> around for DT boards, just like what the "fixed-regulator" driver does
> for instance. But the clock device isn't initialized unless board code
> explicitly calls of_clk_init() with a table mentioning "fixed-clock", as
> in my patch.
> I don't know the clock framework well enough, but it seems that either
> all DT boards are supposed to do the same in their generic bits (which
> sounds like a lot of code duplication), or the fixed-clock driver should
> behave like any other driver wrt its probing from DT. I'm open to
> suggestions :)
Your expectation sounds like what I'd expect too...