Question about fixed-clock

[Daniel Mack]

Hi,

This might be a stupid question, but I'm somehow stuck here. I'm using a
driver with the following DTS sub-node:

ref25: ref25M {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
};

clock-generator@0 {
/* ... */
#clock-cells = <1>;
clocks = <&ref25>;
}

The device driver for clock-generator uses something like the following
call to get its clock:

clk = of_clk_get(np, 0);

but the return value is ERR_PTR(-ENOENT) and I also can't find this
clock in the clk debugfs tree.

This is on a OMAP/AM33xx device with kernel 3.8-rc7 plus the -next tips
of arm-soc and omap, but with no other special clock options selected in
the config. Is there anything I'm missing to correctly instantiate the
dummy clock?


Thanks for a pointer,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Daniel Mack]

On Tue, Feb 19, 2013 at 12:55 AM, Daniel Mack <zon...@gmail.com> wrote:
> Hi,
>
> This might be a stupid question, but I'm somehow stuck here. I'm using a
> driver with the following DTS sub-node:
>
> ref25: ref25M {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <25000000>;
> };
>
> clock-generator@0 {
> /* ... */
> #clock-cells = <1>;

Sorry - this is actually <0>.

[Fabio Estevam]

Hi Daniel,

On Mon, Feb 18, 2013 at 8:55 PM, Daniel Mack <zon...@gmail.com> wrote:
> Hi,
>
> This might be a stupid question, but I'm somehow stuck here. I'm using a
> driver with the following DTS sub-node:
>
> ref25: ref25M {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <25000000>;
> };
>
> clock-generator@0 {
> /* ... */
> #clock-cells = <1>;
> clocks = <&ref25>;
> }
>
> The device driver for clock-generator uses something like the following
> call to get its clock:
>
> clk = of_clk_get(np, 0);
>
> but the return value is ERR_PTR(-ENOENT) and I also can't find this
> clock in the clk debugfs tree.
>
> This is on a OMAP/AM33xx device with kernel 3.8-rc7 plus the -next tips
> of arm-soc and omap, but with no other special clock options selected in
> the config. Is there anything I'm missing to correctly instantiate the
> dummy clock?

Have you registered it with clk_register_fixed_rate() ?

In imx we use imx_clk_fixed, which in turns call clk_register_fixed_rate().

Take a look at arch/arm/mach-imx/clk-imx51-imx53.c for a reference.

[Afzal Mohammed]

Hi Daniel,

On Tue, Feb 19, 2013 at 12:55:52AM +0100, Daniel Mack wrote:

> ref25: ref25M {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <25000000>;
> };
>
> clock-generator@0 {
> /* ... */
> #clock-cells = <1>;
> clocks = <&ref25>;
> }
>
> The device driver for clock-generator uses something like the following
> call to get its clock:
>
> clk = of_clk_get(np, 0);
>
> but the return value is ERR_PTR(-ENOENT) and I also can't find this
> clock in the clk debugfs tree.

Hope invoking of_clk_init before clock generator driver helps

Regards
Afzal

[Daniel Mack]

Hi Fabio,
Hi Afzal,

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.


Thanks,
Daniel

[Daniel Mack]

On 19.02.2013 18:22, Mike Turquette wrote:
> Quoting Daniel Mack (2013-02-19 01:53:18)

> You can provide a patch, but your example above is for a dummy clock,
> correct?

No, it's a real clock with a fixed frequency on the board, which feeds
another clock chip. I thought this is what fixed-clock is for, just like
what a fixed-regulator does? Or how would you describe such a thing in
DT, in order to use it as input to another device?

> It would be best to post your patch along with a real-world
> use for calling of_clk_init().

Not sure what you mean exactly, but the patch is attached. However, I
still think I lack some understanding here - the fact that compatible
strings have to be passed explicitly from generic code feels wrong.


Thanks,
Daniel

[Daniel Mack]

Hi eyerone,

> 0001-ARM-OMAP-generic-add-call-to-of_clk_init.patch
>
>
> From 850120371830ffb5e2146aeb2d21c724d6ded09e Mon Sep 17 00:00:00 2001
> From: Daniel Mack <zon...@gmail.com>
> Date: Tue, 19 Feb 2013 12:05:25 +0100
> Subject: [PATCH] ARM: OMAP: generic: add call to of_clk_init()
>
> This is needed to instanciate fixed clocks in the DT.
>
> Signed-off-by: Daniel Mack <zon...@gmail.com>
> ---
> arch/arm/mach-omap2/board-generic.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index 0274ff7..3580f16 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -15,6 +15,7 @@
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/irqdomain.h>
> +#include <linux/clk-provider.h>
>
> #include <asm/mach/arch.h>
>
> @@ -35,6 +36,11 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
> { }
> };
>
> +static const __initconst struct of_device_id clk_match[] = {
> + { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> + {}
> +};
> +
> static void __init omap_generic_init(void)
> {
> omap_sdrc_init(NULL, NULL);
> @@ -49,6 +55,7 @@ static void __init omap_generic_init(void)
> omap4_panda_display_init_of();
> else if (of_machine_is_compatible("ti,omap4-sdp"))
> omap_4430sdp_display_init_of();
> + of_clk_init(clk_match);
> }
>
> #ifdef CONFIG_SOC_OMAP2420

Any opinion about this approach?

[Afzal Mohammed]

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.

[Daniel Mack]

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

[Mark Brown]

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?

[Daniel Mack]

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 :)

[Sebastian Hesselbarth]

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

[Mark Brown]

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...