From: Bill Gatliff <bgat@billgatliff.com>
To: Linus Walleij <linus.ml.walleij@gmail.com>
Cc: Paul Mundt <lethal@linux-sh.org>,
Linux Power Management List <linux-pm@lists.osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org, Len Brown <lenb@kernel.org>
Subject: Re: Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes
Date: Tue, 01 Sep 2009 21:25:20 -0500 [thread overview]
Message-ID: <4A9DD790.50302@billgatliff.com> (raw)
In-Reply-To: <63386a3d0909011522m7a175d3eyb3bbe8a29a5fd104@mail.gmail.com>
Linus Walleij wrote:
> I've felt a need for clock notifiers and we've cheated by using
> CPUfreq because it so happens that the clocking in system-wide
> and whenever the CPU freq change so may the other clocks.
>
> But if I put code into a PrimeCell MMC/SPI/I2C driver or whatever and
> use CPUfreq that's very unelegant, and for other platforms where
> the CPU freq don't change when this particular device clk freq
> change plain misleading.
>
> A clk pre/postchange notifier pair would really help and would
> make for elegant drivers that can handle clock freq transitions.
>
A lot of ARM chips have peripherals that are driven by PLLs that run
quasi-independently of the CPU clock.
If I guess correctly at what is being described above, a notifier chain
for the users of a clock would be a clean way for peripherals to deal
with clock speed *and* CPU speed changes, indeed. A clock source that
was affected by cpufreq would place itself on the cpufreq notifier
chain, and also provide a notifier chain for peripherals that are driven
by that clock. When a cpufreq notification arrived, if the clock
couldn't adjust for the cpufreq change it would use its notifier chain
to tell all downstream peripherals about it.
A lot of peripherals could then focus just on the clock notifier chain,
and would no longer care about cpufreq. I like it.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
WARNING: multiple messages have this Message-ID (diff)
From: bgat@billgatliff.com (Bill Gatliff)
To: linux-arm-kernel@lists.infradead.org
Subject: Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes
Date: Tue, 01 Sep 2009 21:25:20 -0500 [thread overview]
Message-ID: <4A9DD790.50302@billgatliff.com> (raw)
In-Reply-To: <63386a3d0909011522m7a175d3eyb3bbe8a29a5fd104@mail.gmail.com>
Linus Walleij wrote:
> I've felt a need for clock notifiers and we've cheated by using
> CPUfreq because it so happens that the clocking in system-wide
> and whenever the CPU freq change so may the other clocks.
>
> But if I put code into a PrimeCell MMC/SPI/I2C driver or whatever and
> use CPUfreq that's very unelegant, and for other platforms where
> the CPU freq don't change when this particular device clk freq
> change plain misleading.
>
> A clk pre/postchange notifier pair would really help and would
> make for elegant drivers that can handle clock freq transitions.
>
A lot of ARM chips have peripherals that are driven by PLLs that run
quasi-independently of the CPU clock.
If I guess correctly at what is being described above, a notifier chain
for the users of a clock would be a clean way for peripherals to deal
with clock speed *and* CPU speed changes, indeed. A clock source that
was affected by cpufreq would place itself on the cpufreq notifier
chain, and also provide a notifier chain for peripherals that are driven
by that clock. When a cpufreq notification arrived, if the clock
couldn't adjust for the cpufreq change it would use its notifier chain
to tell all downstream peripherals about it.
A lot of peripherals could then focus just on the clock notifier chain,
and would no longer care about cpufreq. I like it.
b.g.
--
Bill Gatliff
bgat at billgatliff.com
next prev parent reply other threads:[~2009-09-02 2:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-21 19:12 Montreal Linux Power Management Mini-Summit -- July 13, 2009 Len Brown
2009-05-24 11:35 ` Rafael J. Wysocki
2009-05-24 11:35 ` Rafael J. Wysocki
2009-05-28 5:36 ` Magnus Damm
2009-05-28 9:32 ` [linux-pm] " Paul Mundt
2009-07-12 16:56 ` Len Brown
2009-07-30 22:04 ` Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes Len Brown
2009-09-01 22:22 ` Linus Walleij
2009-09-01 22:22 ` Linus Walleij
2009-09-01 22:22 ` Linus Walleij
2009-09-02 2:25 ` Bill Gatliff [this message]
2009-09-02 2:25 ` Bill Gatliff
2009-09-02 8:36 ` Francesco VIRLINZI
2009-09-02 8:36 ` [linux-pm] " Francesco VIRLINZI
2009-09-02 21:44 ` Linus Walleij
2009-09-02 21:44 ` Linus Walleij
2009-09-02 21:58 ` Russell King - ARM Linux
2009-09-02 21:58 ` Russell King - ARM Linux
2009-09-03 14:50 ` Francesco VIRLINZI
2009-09-03 14:50 ` Francesco VIRLINZI
2009-09-03 17:12 ` Russell King - ARM Linux
2009-09-03 17:12 ` [linux-pm] " Russell King - ARM Linux
2009-09-03 20:15 ` Linus Walleij
2009-09-03 20:15 ` Linus Walleij
2009-09-03 21:28 ` Woodruff, Richard
2009-09-03 21:28 ` [linux-pm] " Woodruff, Richard
2009-09-04 7:34 ` Francesco VIRLINZI
2009-09-04 7:34 ` [linux-pm] " Francesco VIRLINZI
2009-10-18 17:28 ` Linus Walleij
2009-10-18 17:28 ` Linus Walleij
2009-10-19 7:44 ` Francesco VIRLINZI
2009-10-19 7:44 ` Francesco VIRLINZI
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=4A9DD790.50302@billgatliff.com \
--to=bgat@billgatliff.com \
--cc=lenb@kernel.org \
--cc=lethal@linux-sh.org \
--cc=linus.ml.walleij@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.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 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.