From: Juha Yrjola <juha.yrjola@solidboot.com>
To: "Woodruff, Richard" <r-woodruff2@ti.com>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: Recent additions to omap2 clock.c
Date: Mon, 30 Oct 2006 19:04:23 +0200 [thread overview]
Message-ID: <45463097.4000405@solidboot.com> (raw)
In-Reply-To: <EA12F909C0431D458B9D18A176BEE4A5082AD7D7@dlee02.ent.ti.com>
Hi Richard,
Thanks for reviewing the changes, and sorry for the late reply -- I was
out-of-office for two weeks.
Woodruff, Richard wrote:
> Juha,
>
> I was looking to do some merging and I see you added the following:
> 1: Force APLL always on control
> 2: Enable/Disable for osc_clk
> 3: addition delays: clk_wait_ready, wmb
>
> For 1 and 2:
> Aren't these more functions of idle control? I was looking at porting
> over some of the omap1 idle api's and I though that associating the auto
> idle's of APLLs and the like would map to this. Is there any reason you
> didn't take this route also?
It looks like the idle control of the APLLs by hardware is pretty
efficient, so we didn't see any reason to manually control their usage.
Can you think of a use case?
osc_clk is a different story. It's an external clock, and other
peripherals besides OMAP might be using it. The external oscillator
control might be controlled by only OMAP, however. In my opinion, if
the driver says clk_enable to a clock, it should be guaranteed that the
clock remains active until a matching clk_disable is called.
> For 3:
> the original clock code had a clk_safe() api which was called after
> clock enables to synchronize and let the caller know if all was ok. You
> might find when the functional clock was slow (32KHz) it might take a
> cycle for the peripheral to be accessible, generally after a wake up. If
> you are talking about a timer, you must also watch posting vs.
> non-posting and the interconnect ratio during DVFS.
I believe that clk_enable() should make sure the clock is indeed active
and usable, and not return before it is so.
> Also, status isn't always as you would infer. Some blocks didn't hook
> up the OCP control signals so they don't consult with the module before
> setting status. Other combined target/initiators like DSS only tie to
> mstandby state for idle, so you must stop mute before access works properly.
Thanks for your info. Could you elaborate on what clocks exactly need
special handling?
Cheers,
Juha
next prev parent reply other threads:[~2006-10-30 17:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-17 21:52 Recent additions to omap2 clock.c Woodruff, Richard
2006-10-30 17:04 ` Juha Yrjola [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-11-01 20:33 Woodruff, Richard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45463097.4000405@solidboot.com \
--to=juha.yrjola@solidboot.com \
--cc=linux-omap-open-source@linux.omap.com \
--cc=r-woodruff2@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox