>>-----Original Message-----
>>From: Menon, Nishanth
>>Sent: Thursday, January 06, 2011 8:29 PM
>>To: Gopinath, Thara
>>Cc: Gulati, Shweta; l-o
>>Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
>>
>>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!!
Oh there is a patch in my bag where we use a single macro for each voltage
across the voltage and opp layer!! Not yet posted because I am waiting for
voltage layer to be merged.
>>> 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
What are you complaining about here? I thought Shweta's patch
was making the mpu entries in the opp table similar to the
ones in the link above. Anything I am missing?
>>
>>
>>>
>>>>>> /* 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?
All as in SDP, Blaze and Panda, today by default we boot up at 1 Ghz.
I have not heard of anybody asking to lower the frequencies. If you are
talking about any customer board, I am not the person to comment.
Regards
Thara
>>
>>> 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
