public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
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

  reply	other threads:[~2009-09-02  2:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LFD.2.00.0905211430220.4390@localhost.localdomain>
     [not found] ` <alpine.LFD.2.00.0907301801240.17818@localhost.localdomain>
2009-09-01 22:22   ` Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes Linus Walleij
2009-09-02  2:25     ` Bill Gatliff [this message]
2009-09-02  8:36     ` [linux-pm] " Francesco VIRLINZI
2009-09-02 21:44       ` Linus Walleij
2009-09-02 21:58       ` Russell King - ARM Linux
2009-09-03 14:50         ` Francesco VIRLINZI
2009-09-03 17:12           ` Russell King - ARM Linux
2009-09-03 20:15             ` Linus Walleij
2009-09-03 21:28               ` Woodruff, Richard
2009-09-04  7:34             ` Francesco VIRLINZI
2009-10-18 17:28       ` Linus Walleij
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$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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