Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table

[Nishanth Menon <nm@ti.com>]

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@vger.kernel.org; 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@ti.com wrote, on 01/06/2011 12:27 AM:
>>>> From: Shweta Gulati<shweta.gulati@ti.com>
>>>>
>>>> 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@ti.com>
>>>> Signed-off-by: Shweta Gulati<shweta.gulati@ti.com>
>>>> ---
>>>> 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