Gopinath, Thara had written, on 01/06/2011 08:52 AM, the following:
-----Original Message-----
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 5:52 PM
To: Gulati, Shweta
Cc: linux-omap@xxxxxxxxxxxxxxx; Gopinath, Thara
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
it is pretty unfortunate that I have to NAK this patch in the public ML
as well.
shweta.gulati@xxxxxx wrote, on 01/06/2011 12:27 AM:
From: Shweta Gulati<shweta.gulati@xxxxxx>
There is a mismatch in voltages specified in OPP table of MPU
and voltage specified in voltage table 'omap44xx_vdd_mpu_volt_data'
This Patch corrects MPU OPP Table as
well as enable OPP-Turbo and OPP-SB for MPU by default.
Signed-off-by: Thara Gopinath<thara@xxxxxx>
Signed-off-by: Shweta Gulati<shweta.gulati@xxxxxx>
---
The patch is generated on top of Kevin's PM branch. It's needed for SR
functionality on the current pm branch. Have tested SR with this patch
with different OPP configurations from boot loader.
arch/arm/mach-omap2/opp4xxx_data.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
omap2/opp4xxx_data.c
index a11fa56..4f35361 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -25,13 +25,13 @@
static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
- OPP_INITIALIZER("mpu", true, 300000000, 1100000),
+ OPP_INITIALIZER("mpu", true, 300000000, 930000),
/* MPU OPP2 - OPP100 */
- OPP_INITIALIZER("mpu", true, 600000000, 1200000),
+ OPP_INITIALIZER("mpu", true, 600000000, 1100000),
Did we finalize on the nominal voltages yet?
As of yesterday's discussion, we were still debating about the actual
voltage at OMAP ball level, while there is a secondary voltage called
cap voltage - we have been discussing on this for some time. I suggest
strongly that we dont touch this for the time being (the voltage in
mainline is slightly higher - let it be so till the h/w folks finalize
things).
Actually no. The latest voltage layer pushed uses these voltages. Also
Arrgh... another reason to avoid messy duplicate tables!!
We have been having this setting in the internal android code base for
some time now without anybody having issues. So till the new voltages
are conveyed officially, these remain the official voltage.
Funny,
how many versions of "internal" code bases are present?
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blob;f=arch/arm/mach-omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a
/* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER("mpu", false, 800000000, 1260000),
+ OPP_INITIALIZER("mpu", true, 800000000, 1260000),
I disagree. This is not $subject. Also - not all boards will be capable
of supporting all higher frequencies rt? - remember the 3630 experience?
is'nt it wiser to enable it based on board capabilities - e.g. similar
to the patch I did for beagle XM yesterday - we wont be able to enable
higher frequencies on SDP3630 as we have not guarenteed with PDN
analysis that it is ok.
I am not sure about this for OMAP4. Have you come across a board
where these OPPs cannot be supported? We have been enabling these
OPPs internally now for quite some time across all OMAP4 boards.
*all* as in how many? SDP/Blaze, Panda and....??? How many boards are
available which is in production?
But still if you guys are paranoid about boards breaking, I am ok
With keeping these OPPs disabled by default. But then anybody running
the mainline code with a 800Mhz or 1GHz x-loader, will see a couple
of warns in the kernel code.
You do have the option of enabling the frequency for specific boards
like SDP/Blaze (e.g. if you have h/w team's signoff that these can do
high frequencies - and I think they do).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
