sys_clkout2

sys_clkout2

[Gary Thomas]

What's the best way to enable sys_clkout2 (DM3730, latest kernel)?
I've managed to set it up properly and it runs in U-Boot, but the
kernel is disabling it.  It's a bit of a tangle trying to figure out
not only what piece of code is undoing my work, but how to get the
clock to keep running.  I want the clkout_cntrl register set to 0x8a,
so any guidance on how to make this happen would be greatly appreciated.

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: sys_clkout2

[Paul Walmsley]

On Tue, 13 Dec 2011, Gary Thomas wrote:

> What's the best way to enable sys_clkout2 (DM3730, latest kernel)?
> I've managed to set it up properly and it runs in U-Boot, but the
> kernel is disabling it.  It's a bit of a tangle trying to figure out
> not only what piece of code is undoing my work, but how to get the
> clock to keep running.

It's probably getting disabled by omap2_clk_disable_unused() in 
mach-omap2/clock.c, which runs at the end of kernel init.

> I want the clkout_cntrl register set to 0x8a,
> so any guidance on how to make this happen would be greatly appreciated.

I presume you have some external device that relies on sys_clkout2 for its 
clock input?  

If the device has a Linux driver associated with it, the clean way to fix 
it would be to add a clkdev line for it into mach-omap2/clock3xxx_data.c.  
Something like

	CLK("devname",	"fck",	&sys_clkout2,	CK_3XXX),

where "devname" is the name of your device.  Then add some code into that 
driver to enable and disable the clock as needed.  Something like

...

struct clk *c;

c = clk_get(dev_name(dev), "fck");
WARN(IS_ERR(c), "cannot clk_get() device functional clock");
clk_enable(c);

...

and then clk_disable() it later in your driver when you don't need it.

If you don't have a driver, you can hack a quick one up that just deals 
with the clock, and add it to your board file.

Or if you just want a dirty hack, you can probably get away with just 
adding the ENABLE_ON_INIT flag to the sys_clkout2 .flags field in 
mach-omap2/clock3xxx_data.c.


- Paul

Re: sys_clkout2

[Paul Walmsley]

Hi

one error:

On Tue, 13 Dec 2011, Paul Walmsley wrote:

> struct clk *c;
> 
> c = clk_get(dev_name(dev), "fck");

This should just be 

c = clk_get(dev, "fck");

sorry about that...
> 


- Paul

Re: sys_clkout2

[Gary Thomas]

On 2011-12-13 14:56, Paul Walmsley wrote:
> On Tue, 13 Dec 2011, Gary Thomas wrote:
>
>> What's the best way to enable sys_clkout2 (DM3730, latest kernel)?
>> I've managed to set it up properly and it runs in U-Boot, but the
>> kernel is disabling it.  It's a bit of a tangle trying to figure out
>> not only what piece of code is undoing my work, but how to get the
>> clock to keep running.
>
> It's probably getting disabled by omap2_clk_disable_unused() in
> mach-omap2/clock.c, which runs at the end of kernel init.
>
>> I want the clkout_cntrl register set to 0x8a,
>> so any guidance on how to make this happen would be greatly appreciated.
>
> I presume you have some external device that relies on sys_clkout2 for its
> clock input?

Precisely.  Do I need to do anything special to control how the clock is
configured, e.g. div & src settings?

>
> If the device has a Linux driver associated with it, the clean way to fix
> it would be to add a clkdev line for it into mach-omap2/clock3xxx_data.c.
> Something like
>
> 	CLK("devname",	"fck",	&sys_clkout2,	CK_3XXX),
>
> where "devname" is the name of your device.  Then add some code into that
> driver to enable and disable the clock as needed.  Something like
>
> ...
>
> struct clk *c;
>
> c = clk_get(dev_name(dev), "fck");
> WARN(IS_ERR(c), "cannot clk_get() device functional clock");
> clk_enable(c);
>
> ...
>
> and then clk_disable() it later in your driver when you don't need it.
>
> If you don't have a driver, you can hack a quick one up that just deals
> with the clock, and add it to your board file.
>
> Or if you just want a dirty hack, you can probably get away with just
> adding the ENABLE_ON_INIT flag to the sys_clkout2 .flags field in
> mach-omap2/clock3xxx_data.c.

Thanks, I'll give this a try when I have eyes on the hardware (Wednesday)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: sys_clkout2

[Paul Walmsley]

On Tue, 13 Dec 2011, Gary Thomas wrote:

> On 2011-12-13 14:56, Paul Walmsley wrote:
>
> > I presume you have some external device that relies on sys_clkout2 for 
> > its clock input?
>
> Precisely.

Okay, so the "clean" way to do this is to write a short driver for that 
device, if there isn't one already, that takes care of configuring the 
clock settings that you need.

> Do I need to do anything special to control how the clock is configured, 
> e.g. div & src settings?

You can change the divider immediately upstream from the sys_clkout2 
output by calling clk_set_rate() on the sys_clkout2 struct clk that you 
got back from clk_get() in the example that I sent.  

You can change the source for sys_clkout2 by calling clk_set_parent() on 
clkout2_src_ck.  This is a separate clock, so you'd need to add a new 
clkdev entry for this for your driver, and you'd need to clk_get() it and 
also clk_get() the new parent source clock that you'd want to use.  Looks 
like these are your choices for parents:

static const struct clksel clkout2_src_clksel[] = {
	{ .parent = &core_ck,		.rates = clkout2_src_core_rates },
	{ .parent = &sys_ck,		.rates = clkout2_src_sys_rates },
	{ .parent = &cm_96m_fck,	.rates = clkout2_src_96m_rates },
	{ .parent = &omap_54m_fck,	.rates = clkout2_src_54m_rates },
	{ .parent = NULL }
};

> > Or if you just want a dirty hack, you can probably get away with just
> > adding the ENABLE_ON_INIT flag to the sys_clkout2 .flags field in
> > mach-omap2/clock3xxx_data.c.
> 
> Thanks, I'll give this a try when I have eyes on the hardware (Wednesday)

N.B., the kernel clock framework init code won't change clock parents or 
divisors, except when doing so is needed to disable or enable the clock.  

So if you are programming those from U-boot, you probably won't need to 
change the parent or divisors from kernel code.


- Paul