* sys_clkout2
@ 2011-12-13 21:28 Gary Thomas
2011-12-13 21:56 ` sys_clkout2 Paul Walmsley
0 siblings, 1 reply; 5+ messages in thread
From: Gary Thomas @ 2011-12-13 21:28 UTC (permalink / raw)
To: linux-omap
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sys_clkout2
2011-12-13 21:28 sys_clkout2 Gary Thomas
@ 2011-12-13 21:56 ` Paul Walmsley
2011-12-13 22:23 ` sys_clkout2 Paul Walmsley
2011-12-13 23:26 ` sys_clkout2 Gary Thomas
0 siblings, 2 replies; 5+ messages in thread
From: Paul Walmsley @ 2011-12-13 21:56 UTC (permalink / raw)
To: Gary Thomas; +Cc: linux-omap
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sys_clkout2
2011-12-13 21:56 ` sys_clkout2 Paul Walmsley
@ 2011-12-13 22:23 ` Paul Walmsley
2011-12-13 23:26 ` sys_clkout2 Gary Thomas
1 sibling, 0 replies; 5+ messages in thread
From: Paul Walmsley @ 2011-12-13 22:23 UTC (permalink / raw)
To: Gary Thomas; +Cc: linux-omap
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sys_clkout2
2011-12-13 21:56 ` sys_clkout2 Paul Walmsley
2011-12-13 22:23 ` sys_clkout2 Paul Walmsley
@ 2011-12-13 23:26 ` Gary Thomas
2011-12-14 1:34 ` sys_clkout2 Paul Walmsley
1 sibling, 1 reply; 5+ messages in thread
From: Gary Thomas @ 2011-12-13 23:26 UTC (permalink / raw)
To: Paul Walmsley; +Cc: linux-omap
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sys_clkout2
2011-12-13 23:26 ` sys_clkout2 Gary Thomas
@ 2011-12-14 1:34 ` Paul Walmsley
0 siblings, 0 replies; 5+ messages in thread
From: Paul Walmsley @ 2011-12-14 1:34 UTC (permalink / raw)
To: Gary Thomas; +Cc: linux-omap
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-12-14 1:34 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-13 21:28 sys_clkout2 Gary Thomas
2011-12-13 21:56 ` sys_clkout2 Paul Walmsley
2011-12-13 22:23 ` sys_clkout2 Paul Walmsley
2011-12-13 23:26 ` sys_clkout2 Gary Thomas
2011-12-14 1:34 ` sys_clkout2 Paul Walmsley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.