From: Mikko Perttunen <mikko.perttunen@kapsi.fi>
To: Stephen Warren <swarren@wwwdotorg.org>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Thierry Reding <thierry.reding@gmail.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
David Airlie <airlied@linux.ie>,
Mike Turquette <mturquette@linaro.org>,
myungjoo.ham@samsung.com, kyungmin.park@samsung.com,
devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver
Date: Tue, 17 Jun 2014 19:59:35 +0300 [thread overview]
Message-ID: <53A073F7.20700@kapsi.fi> (raw)
In-Reply-To: <53A069B6.6070902@wwwdotorg.org>
On 06/17/2014 07:15 PM, Stephen Warren wrote:
> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote:
>> On 06/16/2014 10:02 PM, Stephen Warren wrote:
>>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote:
>
>>> This binding looks quite anaemic vs.
>>> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt; I
>>> would expect that this binding needs all the EMC register data from the
>>> tegra20-emc binding too. Can the two bindings be identical?
>>
>> There's even less stuff needed right now, as all what ultimately the EMC
>> driver does is call clk_set_rate on the EMC clock. As the T124 EMC
>> driver gains more features, they should get more similar.
>
> IIRC, even changing the EMC clock rate requires modifying the memory
> controller's programming (e.g. delays/taps/tuning etc.). That's exactly
> what the more complex stuff in the nvidia,tegra20-emc.txt is all about.
> I not convinced that a driver that just modifies the clock rate without
> adjusting the EMC programming will work reliably.
Indeed, changing the EMC clock rate is a somewhat complicated sequence
of ~10 steps. The kernel even won't let one the rate be change directly,
as the change would be propagated to PLL_M which cannot have its rate
changed while it is enabled. I suppose the sequence should be hidden in
the EMC clk's set_rate implementation, which I guess would leave just
the rate policy to this driver.
next prev parent reply other threads:[~2014-06-17 16:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 13:35 [RFC PATCH 0/4] Tegra124: EMC scaling Tomeu Vizoso
2014-06-16 13:35 ` [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver Tomeu Vizoso
2014-06-16 14:03 ` Mikko Perttunen
[not found] ` <1402925713-25426-2-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2014-06-16 20:02 ` Stephen Warren
[not found] ` <539F4D44.3070309-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-17 12:16 ` Tomeu Vizoso
2014-06-17 16:15 ` Stephen Warren
2014-06-17 16:59 ` Mikko Perttunen [this message]
[not found] ` <53A069B6.6070902-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-18 17:23 ` Tomeu Vizoso
2014-06-18 17:46 ` Stephen Warren
2014-06-18 22:03 ` Thierry Reding
2014-06-18 22:09 ` Stephen Warren
2014-06-18 23:14 ` Thierry Reding
2014-06-18 23:24 ` Stephen Warren
2014-06-18 22:00 ` Thierry Reding
2014-06-18 22:19 ` Stéphane Marchesin
2014-06-18 22:33 ` Stephen Warren
2014-06-18 23:20 ` Thierry Reding
2014-06-17 22:35 ` Thierry Reding
2014-06-18 8:57 ` Peter De Schrijver
2014-06-16 13:35 ` [RFC PATCH 2/4] ARM: tegra: Add Tegra124 EMC support Tomeu Vizoso
2014-06-17 22:38 ` Thierry Reding
2014-06-16 13:35 ` [RFC PATCH 3/4] drm/tegra: Request memory bandwidth for the display controller Tomeu Vizoso
2014-06-16 20:06 ` Stephen Warren
2014-06-17 22:43 ` Thierry Reding
2014-06-16 13:35 ` [RFC PATCH 4/4] cpufreq: tegra: Register a minimum EMC frequency based on the CPU clock Tomeu Vizoso
2014-06-16 14:08 ` Mikko Perttunen
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=53A073F7.20700@kapsi.fi \
--to=mikko.perttunen@kapsi.fi \
--cc=airlied@linux.ie \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=myungjoo.ham@samsung.com \
--cc=rjw@rjwysocki.net \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
--cc=tomeu.vizoso@collabora.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).