public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@nokia.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: "Karpov Denis.2 (EXT-Teleca/Helsinki)"
	<ext-denis.2.karpov@nokia.com>, Tony Lindgren <tony@atomide.com>,
	"khilman@deeprootsystems.com" <khilman@deeprootsystems.com>,
	linux-mmc Mailing List <linux-mmc@vger.kernel.org>,
	linux-omap Mailing List <linux-omap@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Madhusudhan Chikkature <madhu.cr@ti.com>
Subject: Re: [PATCH 4/8] omap_hsmmc: set DVFS/PM constraints
Date: Thu, 14 Jan 2010 10:28:30 +0200	[thread overview]
Message-ID: <4B4ED5AE.1090807@nokia.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1001131538560.4769@utopia.booyaka.com>

Paul Walmsley wrote:
> (added Denis and Kevin)
> 
> Hello Denis, Adrian,
> 
> On Wed, 13 Jan 2010, Adrian Hunter wrote:
> 
>> >From afab8b432b37ae1f42b281e58989c8d607ed7183 Mon Sep 17 00:00:00 2001
>> From: Denis Karpov <ext-denis.2.karpov@nokia.com>
>> Date: Wed, 8 Jul 2009 16:15:08 +0200
>> Subject: [PATCH] omap_hsmmc: set DVFS/PM constraints
>>
>> Set constraint for MPU minimal frequency to maintain good
>> I/O performance.
>>
>> The constraint is set in MMC host 'ENABLED' state and dropped
>> when MMC host enters 'DISABLED' state which currently happens
>> upon 100ms of inactivity.
>>
>> Signed-off-by: Denis Karpov <ext-denis.2.karpov@nokia.com>
>> Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
>> ---
>>  arch/arm/mach-omap2/board-rx51-peripherals.c |   18 ++++++++++++++++++
>>  arch/arm/mach-omap2/hsmmc.c                  |    2 ++
>>  arch/arm/mach-omap2/hsmmc.h                  |    2 ++
>>  arch/arm/plat-omap/include/plat/mmc.h        |    3 +++
>>  drivers/mmc/host/omap_hsmmc.c                |   17 +++++++++++++++++
>>  5 files changed, 42 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
>> index ab07ca2..b6318b1 100644
>> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
>> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
>> @@ -209,6 +209,22 @@ static struct twl4030_madc_platform_data rx51_madc_data = {
>>  	.irq_line		= 1,
>>  };
>>  
>> +#if defined(CONFIG_BRIDGE_DVFS)
>> +/*
>> + * This handler can be used for setting other DVFS/PM constraints:
>> + * intr latency, wakeup latency, DMA start latency, bus throughput
>> + * according to API in mach/omap-pm.h.  Currently we only set constraints
>> + * for MPU frequency.
>> + */
>> +#define MMC_MIN_MPU_FREQUENCY	500000000	/* S500M at OPP3 */
>> +static void rx51_mmc_set_pm_constraints(struct device *dev, int on)
>> +{
>> +	omap_pm_set_min_mpu_freq(dev, (on ? MMC_MIN_MPU_FREQUENCY : 0));
>> +}
> 
> NAK.  The MMC driver (or any other driver, for that matter) must not set 
> MPU frequency constraints merely to boost performance.  Drivers have no 
> way of knowing what the power vs. performance policy is for a given device 
> or use case.

The driver doesn't but RX-51 does, which is why the code is in the RX-51
board file.  We know exactly the use cases and the effect on performance.

> If the system is not upscaling MPU frequency quickly enough, then the 
> power management policy code -- CPUFreq, in the MPU case -- or the 
> parameters for that code -- need to be adjusted.  (Of course, integrators 
> can always dump hacks like this in their own trees if they get lazy, but 
> these should be kept far, far away from mainline.)

It is unreasonable to override the policy decisions of the board maker
as defined in their board files.

Instead you must remove the omap_pm_set_min_mpu_freq() function entirely
or suffer the consequence that it can be used. i.e. it should not exist
if you don't want anyone to use it.

> 
> N.B.  As a separate matter, the MMC driver should call 
> omap_pm_set_min_bus_tput() with the maximum throughput that the current 
> MMC card can sustain to memory.  A reasonable upper bound should be easy 
> to calculate based on the MMC clock speed and the width of the MMC 
> transfers.  This will allow the kernel to adjust the bus frequency 
> appropriately as the OMAP PM core's bus utilization model improves.

Many different constraints were tried.  min_mpu_freq was the only one that
worked.

In the future, improvements to DMA and changes to PM may be able to get the
same performance without the min_mpu_freq constraint.

> 
> 
> - Paul
> 


  reply	other threads:[~2010-01-14  8:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-13 11:40 [PATCH 0/8] omap_hsmmc changes Adrian Hunter
2010-01-13 11:40 ` [PATCH 1/8] omap_hsmmc: move gpio and regulator control from board file Adrian Hunter
2010-01-13 18:54   ` Tony Lindgren
2010-01-14  7:58     ` Adrian Hunter
2010-01-13 22:28   ` Madhusudhan
2010-01-14  8:17     ` Adrian Hunter
2010-01-13 11:40 ` [PATCH 2/8] OMAP: rename mmc-twl4030 to hsmmc Adrian Hunter
2010-01-13 11:40 ` [PATCH 3/8] OMAP: reconnect hsmmc context loss count Adrian Hunter
2010-01-14 19:55   ` Paul Walmsley
2010-01-13 11:40 ` [PATCH 4/8] omap_hsmmc: set DVFS/PM constraints Adrian Hunter
2010-01-13 22:53   ` Paul Walmsley
2010-01-14  8:28     ` Adrian Hunter [this message]
2010-01-14 19:53       ` Paul Walmsley
2010-01-15  9:04         ` Adrian Hunter
2010-01-13 11:40 ` [PATCH 5/8] omap_hsmmc: RX51: set padconfs to pull down when powering off eMMC Adrian Hunter
2010-01-13 20:37   ` Tony Lindgren
2010-01-13 20:39     ` Tony Lindgren
2010-01-13 21:00       ` Tony Lindgren
2010-01-13 23:30         ` Nishanth Menon
2010-01-14  7:57           ` Adrian Hunter
2010-01-15 13:11         ` Adrian Hunter
2010-01-13 11:40 ` [PATCH 6/8] omap_hsmmc: allow for power saving without going off Adrian Hunter
2010-01-13 11:41 ` [PATCH 7/8] omap_hsmmc: fix disable timeouts Adrian Hunter
2010-01-13 11:41 ` [PATCH 8/8] omap_hsmmc: allow for a shared VccQ 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=4B4ED5AE.1090807@nokia.com \
    --to=adrian.hunter@nokia.com \
    --cc=akpm@linux-foundation.org \
    --cc=ext-denis.2.karpov@nokia.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=madhu.cr@ti.com \
    --cc=paul@pwsan.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