devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).