linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Bresticker <abrestic@google.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Mike Turquette <mturquette@linaro.org>,
	Prashant Gaikwad <pgaikwad@nvidia.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>, Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [RFC PATCH 3/3] clk: tegra: Implement Tegra124 shared/cbus clks
Date: Wed, 14 May 2014 10:58:26 -0700	[thread overview]
Message-ID: <CAL1qeaGS-78QaiMN-3zXYYXu+K1s7u2rFXQkt7-MRJQS1-sW5A@mail.gmail.com> (raw)
In-Reply-To: <20140514142739.GA8612@ulmo>

On Wed, May 14, 2014 at 7:27 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> As for shared clocks I'm only aware of one use-case, namely EMC scaling.
> Using clocks for that doesn't seem like the best option to me. While it
> can probably fix the immediate issue of choosing an appropriate
> frequency for the EMC clock it isn't a complete solution for the problem
> that we're trying to solve. From what I understand EMC scaling is one
> part of ensuring quality of service. The current implementations of that
> seems to abuse clocks (essentially one X.emc clock per X clock) to
> signal the amount of memory bandwidth required by any given device. But
> there are other parts to the puzzle. Latency allowance is one. The value
> programmed to the latency allowance registers for example depends on the
> EMC frequency.
>
> Has anyone ever looked into using a different framework to model all of
> these requirements? PM QoS looks like it might fit, but if none of the
> existing frameworks have what we need, perhaps something new can be
> created.

On Exynos we use devfreq, though in that case we monitor performance
counters to determine how internal buses should be scaled - not sure
if Tegra SoCs have similar counters that could be used for this
purpose.  It seems like EMC scaling would fit nicely within the PM QoS
framework, perhaps with a new PM_QOS_MEMORY_THROUGHPUT class.

-Andrew

  reply	other threads:[~2014-05-14 17:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 14:06 [RFC PATCH 0/3] Introduce shared and cbus clocks Peter De Schrijver
2014-05-13 14:06 ` [RFC PATCH 1/3] clk: Implement cbus and shared clocks Peter De Schrijver
2014-05-13 14:06 ` [RFC PATCH 2/3] clk: tegra: Implement common shared clks Peter De Schrijver
2014-05-13 14:06 ` [RFC PATCH 3/3] clk: tegra: Implement Tegra124 shared/cbus clks Peter De Schrijver
2014-05-13 18:09   ` Stephen Warren
2014-05-13 21:52     ` Andrew Bresticker
2014-05-14 14:27     ` Thierry Reding
2014-05-14 17:58       ` Andrew Bresticker [this message]
2014-05-15 10:17         ` Peter De Schrijver
2014-05-14 19:35       ` Mike Turquette
2014-05-15 10:59         ` Peter De Schrijver
2014-05-26 13:07         ` Thierry Reding
2014-05-29 23:22           ` Nishanth Menon
2014-05-30  4:47             ` Mike Turquette
2014-05-30 13:24               ` Nishanth Menon
2014-05-15 10:52       ` Peter De Schrijver
2014-05-15 20:20         ` Stephen Warren
2014-05-16 19:58           ` Mike Turquette

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=CAL1qeaGS-78QaiMN-3zXYYXu+K1s7u2rFXQkt7-MRJQS1-sW5A@mail.gmail.com \
    --to=abrestic@google.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@linaro.org \
    --cc=pawel.moll@arm.com \
    --cc=pdeschrijver@nvidia.com \
    --cc=pgaikwad@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    /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).