All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Richard Zhao <richard.zhao@linaro.org>
Cc: linux@arm.linux.org.uk, arnd@arndb.de,
	mark.langsdorf@calxeda.com, linaro-dev@lists.linaro.org,
	marc.zyngier@arm.com, catalin.marinas@arm.com,
	devicetree-discuss@lists.ozlabs.org, patches@linaro.org,
	bryanh@codeaurora.org, cpufreq@vger.kernel.org,
	grant.likely@secretlab.ca, rdunlap@xenotime.net,
	eric.miao@linaro.org, rob.herring@calxeda.com,
	kernel@pengutronix.de, jamie@jamieiles.com, davej@redhat.com,
	davidb@codeaurora.org, shawn.guo@linaro.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2011-12-26 11:10 UTC|newest]

Thread overview: 52+ 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 ` 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   ` 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   ` Richard Zhao
2011-12-22  7:09 ` [PATCH v4 3/7] cpufreq: OMAP: " Richard Zhao
2011-12-22  7:09   ` Richard Zhao
2011-12-22  7:09 ` [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver Richard Zhao
2011-12-22  7:09   ` Richard Zhao
2011-12-23 13:18   ` Mark Brown
2011-12-23 13:18     ` Mark Brown
2011-12-24  8:55     ` Richard Zhao
2011-12-24  8:55       ` Richard Zhao
2011-12-24 12:24       ` Mark Brown
2011-12-24 12:24         ` Mark Brown
2011-12-24 13:28         ` Richard Zhao
2011-12-24 13:28           ` Richard Zhao
2011-12-24 13:42           ` Mark Brown
2011-12-24 13:42             ` Mark Brown
2011-12-24 15:52             ` Richard Zhao
2011-12-24 15:52               ` Richard Zhao
2011-12-26 11:10               ` Mark Brown [this message]
2011-12-26 11:10                 ` Mark Brown
     [not found]                 ` <20111226111030.GC8722-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-12-26 13:44                   ` Richard Zhao
2011-12-26 13:44                     ` Richard Zhao
2011-12-26 14:22                     ` Mark Brown
2011-12-26 14:22                       ` Mark Brown
2011-12-27  1:51                       ` Richard Zhao
2011-12-27  1:51                         ` Richard Zhao
     [not found]                         ` <20111227015109.GJ15863-iWYTGMXpHj9ITqJhDdzsOjpauB2SiJktrE5yTffgRl4@public.gmane.org>
2011-12-27 10:53                           ` Mark Brown
2011-12-27 10:53                             ` Mark Brown
2012-01-03  9:06                     ` Russell King - ARM Linux
2012-01-03  9:06                       ` Russell King - ARM Linux
2012-01-03 13:25                       ` Richard Zhao
2012-01-03 13:25                         ` Richard Zhao
     [not found]                         ` <CAH8gqwVHc9ROQYZNe6b-cUN0ycWhYj8=vJ0geBXUCYN1+XENQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-03 13:47                           ` Russell King - ARM Linux
2012-01-03 13:47                             ` Russell King - ARM Linux
2012-01-03 14:15                             ` Richard Zhao
2012-01-03 14:15                               ` Richard Zhao
2012-01-03 20:26                             ` Mark Brown
2012-01-03 20:26                               ` Mark Brown
2011-12-24 13:10   ` Jamie Iles
2011-12-24 13:10     ` Jamie Iles
2011-12-24 13:24     ` Richard Zhao
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   ` 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   ` Richard Zhao
     [not found] ` <1324537753-30590-1-git-send-email-richard.zhao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-12-22  7:09   ` [PATCH v4 7/7] arm/imx6q: select ARCH_HAS_CPUFREQ Richard Zhao
2011-12-22  7:09     ` 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=arnd@arndb.de \
    --cc=bryanh@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=davidb@codeaurora.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=eric.miao@linaro.org \
    --cc=grant.likely@secretlab.ca \
    --cc=jamie@jamieiles.com \
    --cc=kernel@pengutronix.de \
    --cc=linaro-dev@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=mark.langsdorf@calxeda.com \
    --cc=patches@linaro.org \
    --cc=rdunlap@xenotime.net \
    --cc=richard.zhao@linaro.org \
    --cc=rob.herring@calxeda.com \
    --cc=shawn.guo@linaro.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.