From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
Date: Mon, 26 Dec 2011 11:10:30 +0000 [thread overview]
Message-ID: <20111226111030.GC8722@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20111224155227.GC1803@richard-laptop>
On Sat, Dec 24, 2011 at 11:52:29PM +0800, Richard Zhao wrote:
> On Sat, Dec 24, 2011 at 01:42:29PM +0000, Mark Brown wrote:
> > On Sat, Dec 24, 2011 at 09:28:33PM +0800, Richard Zhao wrote:
> > > If you think regulator thansition latency is board specific, then the board
> > > dts can overrite it.
> > We should just query this information from the regulator subsystem
> > (there's hooks but currently nothing implements them). The regulators
> > can define their own bindings if they need to read it from device tree,
> > most of them should be able to do this as a function of knowing about
> > the device. None of this is specific to cpufreq so cpufreq shouldn't
> > have to define its own support for this.
> I'd like to query the latency by call clk and regulator APIs. but as you said
> both of them have not implemented it yet. I think, for now, we can use the
The *call* is there in the regulator subsystem, it's just that none of
the drivers back it up with an actual implementation yet. Which turns
out to be a good thing as cpufreq can't currently understand variable
latencies and the governors don't deal well with non-trivial latencies
anyway.
> property to get the total latency. Once I can get it at runtime, I'll remove
> it. So the definition of trans-latency is just the same as cpufreq transition_latency,
> people get less confused. What do you think?
The problem with device tree is that once you've defined a binding
you're stuck with it, it's very hard to change - witness all the magic
number based stuff with the interrupt bindings for example
next prev parent reply other threads:[~2011-12-26 11:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 7:09 [PATCH v4 0/7] add a generic cpufreq driver Richard Zhao
2011-12-22 7:09 ` [PATCH v4 1/7] ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp Richard Zhao
2011-12-22 7:09 ` [PATCH v4 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate " Richard Zhao
2011-12-22 7:09 ` [PATCH v4 3/7] cpufreq: OMAP: " Richard Zhao
2011-12-22 7:09 ` [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver Richard Zhao
2011-12-23 13:18 ` Mark Brown
2011-12-24 8:55 ` Richard Zhao
2011-12-24 12:24 ` Mark Brown
2011-12-24 13:28 ` Richard Zhao
2011-12-24 13:42 ` Mark Brown
2011-12-24 15:52 ` Richard Zhao
2011-12-26 11:10 ` Mark Brown [this message]
2011-12-26 13:44 ` Richard Zhao
2011-12-26 14:22 ` Mark Brown
2011-12-27 1:51 ` Richard Zhao
2011-12-27 10:53 ` Mark Brown
2012-01-03 9:06 ` Russell King - ARM Linux
2012-01-03 13:25 ` Richard Zhao
2012-01-03 13:47 ` Russell King - ARM Linux
2012-01-03 14:15 ` Richard Zhao
2012-01-03 20:26 ` Mark Brown
2011-12-24 13:10 ` Jamie Iles
2011-12-24 13:24 ` Richard Zhao
2011-12-22 7:09 ` [PATCH v4 5/7] dts/imx6q: add cpufreq property Richard Zhao
2011-12-22 7:09 ` [PATCH v4 6/7] arm/imx6q: register arm_clk as cpu to clkdev Richard Zhao
2011-12-22 7:09 ` [PATCH v4 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ Richard Zhao
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=20111226111030.GC8722@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).