public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sekhar Nori <nsekhar@ti.com>
To: "Manjunathappa, Prakash" <prakash.pm@ti.com>
Cc: <davinci-linux-open-source@linux.davincidsp.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] arm: da850: change ASYNC/PLL0_SYSCLK3 clock rate with DVFS
Date: Tue, 10 Apr 2012 00:35:57 +0530	[thread overview]
Message-ID: <4F833315.1050109@ti.com> (raw)
In-Reply-To: <1333617232-27967-1-git-send-email-prakash.pm@ti.com>

Hi Prakash,

On 4/5/2012 2:43 PM, Manjunathappa, Prakash wrote:
> Clock for EMIF is derived from ASYNC clock domain(PLL0_SYSCLK3) and was
> configured with fixed divider as there was no significant performance
> degradation with existing NAND/NOR EMIF devices if it is not
> reconfigured accordingly at different OPPs.

This is not correct AFAICT. The divider is not fixed in current code.
There is an attempt to adjust the async1 (PLL0 SYSCLK3 rate) and keep it
constant at 100MHz by adjusting the divider at each OPP transition (see
the call to clock_set_rate() on async clock in cpufreq.c). This was
based on an earlier understanding that PLL0_SYSCLK3 can support 100MHz
at all OPPs and all AEMIF modes. Looking at the datasheet now, it is
clear that that assumption is not true.

> 
> On systems where devices other than NAND/NOR are interfaced through
> EMIF, such performance degradation may not be desirable. So change the
> PLL0_SYSCLK3 output frequency for different OPPs by re-configuring
> the divider value.

This again is not the point. The issue is that depending on what mode
you have AEMIF running in *and* depending on what OPP you are at, a
particular value of ASYNC1 clock is required to get maximum performance
out of AEMIF.

> 
> Also add Kconfig option to support platforms requiring fixed EMIF clock
> rate.

This breaks single image support for all DA850 boards. Kconfig in this
case is not an option.

Why not make the OPP table board specific while maintain a sane (and
safe) default in SoC file so there is something to fall back upon in
case a board does not need to define its own? This should also address
Christian's concern in the other e-mail thread about board specific OPP
values being hardcoded in SoC file with no way to override them.

Thanks,
Sekhar

      reply	other threads:[~2012-04-09 19:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-05  9:13 [PATCH v2] arm: da850: change ASYNC/PLL0_SYSCLK3 clock rate with DVFS Manjunathappa, Prakash
2012-04-09 19:05 ` Sekhar Nori [this message]

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=4F833315.1050109@ti.com \
    --to=nsekhar@ti.com \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prakash.pm@ti.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