From: Paul Walmsley <paul@pwsan.com>
To: linux-omap@vger.kernel.org
Subject: [PATCH 0/2] Add clock post-rate-change notifier
Date: Fri, 20 Jun 2008 17:13:39 -0600 [thread overview]
Message-ID: <20080620231155.21640.89851.stgit@localhost.localdomain> (raw)
This series adds a clock rate change notifier to the OMAP clock
framework. Currently only post-rate-change notification is
implemented, although pre-rate-change notification is in the works.
Clock post-rate-change notifiers are intended for drivers that need to
be notified when other code (such as power management code) changes
their clock's rate. DSPBridge is apparently one such user, but
drivers for UART, MCSPI, etc. are also candidates for these notifiers.
Drivers should use these notifiers by adding function pointers for
clk_notifier_register() and clk_notifier_unregister() to their
platform_data structure. Ensure that the function pointers are not
NULL before calling, since non-OMAP platforms may not support this
notifier:
if (pdata->clk_notifier_register)
(*pdata->clk_notifier_register)(clk, &test_nb);
The callback code must not call back into the clock framework nor
sleep, as the clock framework spinlock is held for the duration of the
callbacks. Callback functions should be short and lightweight.
...
A few implementation notes. Upon request, an alternate design was
also investigated based on the existing CPUFreq notifiers. That
design was set aside, due to the following problems:
- CPUFreq notifier callbacks can sleep. This will break the clock
framework, since it calls the notifier inside a spinlock.
- Identifying the changed clock from the callback would require a new
platform_data-based function in the clock framework, since struct
cpufreq_freqs has no good way to pass it.
- CPUFreq notifiers depend on CPUFreq, which not everyone uses.
There was also some concern expressed that separate CPUFreq notifiers
and clk rate notifiers could race. (That would only apply to the
clocks that are changed by CPUFreq, and any clocks downstream from
it.) This doesn't appear to be a problem in practice, since CPUFreq
post-rate notifiers can only start after the clk post-rate notifiers
have completed and exited the clock framework.
The current implementation has been moderately tested with multiple
clock notifiers on both DPLLs and a downstream clock on 3430SDP. Also
compile-tested for N800.
- Paul
text data bss dec hex filename
3404721 158888 108176 3671785 3806e9 vmlinux.3430sdp.orig
3405361 158896 108176 3672433 380971 vmlinux.3430sdp.patched
arch/arm/mach-omap2/clock.c | 37 ++++++++--
arch/arm/mach-omap2/clock24xx.c | 42 ++++++++++-
arch/arm/mach-omap2/clock34xx.c | 10 +++
arch/arm/plat-omap/clock.c | 144 +++++++++++++++++++++++++++++++++++++
include/asm-arm/arch-omap/clock.h | 21 +++++
5 files changed, 246 insertions(+), 8 deletions(-)
next reply other threads:[~2008-06-20 23:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 23:13 Paul Walmsley [this message]
2008-06-20 23:13 ` [PATCH 1/2] add common post-rate-change notifier code Paul Walmsley
2008-06-20 23:14 ` [PATCH 2/2] implement clock dynamic notifier array Paul Walmsley
2008-06-26 13:52 ` [PATCH 0/2] Add clock post-rate-change notifier Tony Lindgren
2008-07-21 10:49 ` Rajendra Nayak
2008-07-23 5:09 ` Paul Walmsley
2008-07-23 17:09 ` Koen Kooi
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=20080620231155.21640.89851.stgit@localhost.localdomain \
--to=paul@pwsan.com \
--cc=linux-omap@vger.kernel.org \
/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