From: Grazvydas Ignotas <notasas@gmail.com>
To: Adrian Hunter <adrian.hunter@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>,
Madhusudhan Chikkature <madhu.cr@ti.com>,
linux-omap Mailing List <linux-omap@vger.kernel.org>,
linux-mmc Mailing List <linux-mmc@vger.kernel.org>,
linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
Subject: Re: [PATCH 19/22] OMAP: hsmmc: implement clock switcher
Date: Thu, 5 May 2011 16:34:06 +0300 [thread overview]
Message-ID: <BANLkTin7iMibEZihx6nCHibB1GLiuJzCDA@mail.gmail.com> (raw)
In-Reply-To: <1304596282-4095-20-git-send-email-adrian.hunter@nokia.com>
On Thu, May 5, 2011 at 2:51 PM, Adrian Hunter <adrian.hunter@nokia.com> wrote:
> From: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
>
> There are 3 new platform data methods which should help us to do a clock
> switching when notification is happened or request is started.
>
> The purpose of the patch is to avoid high frequency of MMC controller on low
> OPPs due to an HW bug in OMAP 3630.
>
> The algorithm:
> - the PM governor switches the clock of L3 (and therefore L4) bus on demand
> - the MMC controller clock should follow the change
>
> We have considered two OPPs for L3/L4 bus. Thus, we have corresponding flow:
> - OPP1 -> OPP2 (in case of abort - OPP1)
> - OPP2 -> OPP1 (in case of abort - OPP2)
>
> During idle the MMC gates functional clock and we don't care about the
> frequency. Most important to get proper solution when notification comes during
> request. Then:
> - in case of OPP1 -> OPP2 we update frequency limit and it will be used for
> new coming requests (it assumes the current frequency of the controller is
> lower then new one)
> - otherwise we wait until no device has used higher frequency then upcoming
> one
>
> Known issues and limitations:
> - originally a clock notifier was used for the core L4 iclk but for upstream
> Adrian changed to a cpufreq notifier where we assume OPP1 below 400MHz and
> OPP2 above 400MHz
>
> Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
> Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
> ---
> arch/arm/mach-omap2/hsmmc.c | 180 ++++++++++++++++++++++++++++++++-
> arch/arm/plat-omap/include/plat/mmc.h | 8 ++
> 2 files changed, 187 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index 6b97fae..34cba89 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
<snip>
> +
> +static int hsmmc_clk_notifier(struct notifier_block *nb, unsigned long event,
> + void *data)
> +{
> + struct cpufreq_freqs *freqs = data;
> + unsigned int threshold = 400000; /* between opp1 and opp2 */
> +
> + switch (event) {
> + case CPUFREQ_PRECHANGE:
> + if (freqs->new < threshold && freqs->old > threshold) {
What if we go from 400000 to, say, 200000?
> + /* opp2 -> opp1 */
> + hsmmc_max_freq = HSMMC_MAX_FREQ >> 1;
> +
> + /* Timeout is 1 sec */
> + if (!wait_event_timeout(hsmmc_max_freq_wq,
> + hsmmc_max_freq_ok(),
> + msecs_to_jiffies(1000)))
> + pr_err("MMC violates maximum frequency "
> + "constraint\n");
> + }
> + break;
> + case CPUFREQ_POSTCHANGE:
> + if (freqs->old < threshold && freqs->new > threshold) {
Same here, you could go from 200000 to 400000 and then 600000 and code
would never notice it.
> + /* opp1 -> opp2 */
> + hsmmc_max_freq = HSMMC_MAX_FREQ;
> + }
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-05-05 13:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-05 11:51 [PATCH 00/22] omap_hsmmc patches Adrian Hunter
2011-05-05 11:51 ` [PATCH 01/22] OMAP: sDMA: descriptor autoloading feature Adrian Hunter
2011-05-06 6:22 ` Tony Lindgren
2011-05-05 11:51 ` [PATCH 02/22] OMAP: DMA: add omap_dma_has_sglist() Adrian Hunter
2011-05-05 11:51 ` [PATCH 03/22] OMAP: DMA: Ensure the sglist registers are cleared Adrian Hunter
2011-05-05 11:51 ` [PATCH 04/22] mmc: omap hsmmc: adaptation of sdma descriptor Adrian Hunter
2011-05-05 11:51 ` [PATCH 05/22] mmc: omap_hsmmc: fix dma sglist use Adrian Hunter
2011-05-05 11:51 ` [PATCH 06/22] mmc: omap_hsmmc: limit scatterlist size for sDMA autoloading Adrian Hunter
2011-05-05 11:51 ` [PATCH 07/22] mmc: omap_hsmmc: fix missing mmc_release_host() in no_off case Adrian Hunter
2011-05-05 13:08 ` Sergei Shtylyov
2011-05-05 11:51 ` [PATCH 08/22] mmc: omap_hsmmc: correct debug report error status mnemonics Adrian Hunter
2011-05-06 8:35 ` S, Venkatraman
2011-05-05 11:51 ` [PATCH 09/22] mmc: omap_hsmmc: move hardcoded frequency constants to definition block Adrian Hunter
2011-05-05 11:51 ` [PATCH 10/22] mmc: omap_hsmmc: reduce a bit the error handlers in probe() Adrian Hunter
2011-05-05 11:51 ` [PATCH 11/22] mmc: omap_hsmmc: split duplicate code to calc_divisor() function Adrian Hunter
2011-05-05 11:51 ` [PATCH 12/22] mmc: omap_hsmmc: introduce start_clock and re-use stop_clock Adrian Hunter
2011-05-05 11:51 ` [PATCH 13/22] mmc: omap_hsmmc: fix few bugs when set the clock divisor Adrian Hunter
2011-05-05 12:53 ` Grazvydas Ignotas
2011-05-05 11:51 ` [PATCH 14/22] mmc: omap_hsmmc: split same pieces of code to separate functions Adrian Hunter
2011-05-05 11:51 ` [PATCH 15/22] OMAP: hsmmc: Do not mux the slot if non default muxing is already done Adrian Hunter
2011-05-05 11:51 ` [PATCH 16/22] OMAP: board-rm680: set MMC nomux flag Adrian Hunter
2011-05-05 11:51 ` [PATCH 17/22] mmc: omap_hsmmc: ensure pbias configuration is always done Adrian Hunter
2011-05-05 11:51 ` [PATCH 18/22] mmc: omap_hsmmc: fix oops in omap_hsmmc_dma_cb Adrian Hunter
2011-05-05 11:51 ` [PATCH 19/22] OMAP: hsmmc: implement clock switcher Adrian Hunter
2011-05-05 13:34 ` Grazvydas Ignotas [this message]
2011-05-05 11:51 ` [PATCH 20/22] mmc: omap_hsmmc: adjust host controller clock in regard to current OPP Adrian Hunter
2011-05-05 11:51 ` [PATCH 21/22] OMAP: hsmmc: add platform data for eMMC hardware reset gpio Adrian Hunter
2011-05-05 11:51 ` [PATCH 22/22] mmc: omap_hsmmc: add a hardware reset before initialization Adrian Hunter
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=BANLkTin7iMibEZihx6nCHibB1GLiuJzCDA@mail.gmail.com \
--to=notasas@gmail.com \
--cc=adrian.hunter@nokia.com \
--cc=ext-andriy.shevchenko@nokia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=madhu.cr@ti.com \
--cc=tony@atomide.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).