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

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

[shweta.gulati]

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),
 	/* MPU OPP3 - OPP-Turbo */
-	OPP_INITIALIZER("mpu", false, 800000000, 1260000),
+	OPP_INITIALIZER("mpu", true, 800000000, 1260000),
 	/* MPU OPP4 - OPP-SB */
-	OPP_INITIALIZER("mpu", false, 1008000000, 1350000),
+	OPP_INITIALIZER("mpu", true, 1008000000, 1350000),
 	/* L3 OPP1 - OPP50 */
 	OPP_INITIALIZER("l3_main_1", true, 100000000, 930000),
 	/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
-- 
1.7.0.4

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

[Nishanth Menon]

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).

>   	/* 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.

>   	/* MPU OPP4 - OPP-SB */
> -	OPP_INITIALIZER("mpu", false, 1008000000, 1350000),
> +	OPP_INITIALIZER("mpu", true, 1008000000, 1350000),
>   	/* L3 OPP1 - OPP50 */
>   	OPP_INITIALIZER("l3_main_1", true, 100000000, 930000),
>   	/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */


-- 
Regards,
Nishanth Menon

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

[Gopinath, Thara]

>>-----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
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.

>>
>>>   	/* 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.
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.

Regards
Thara

>>
>>>   	/* MPU OPP4 - OPP-SB */
>>> -	OPP_INITIALIZER("mpu", false, 1008000000, 1350000),
>>> +	OPP_INITIALIZER("mpu", true, 1008000000, 1350000),
>>>   	/* L3 OPP1 - OPP50 */
>>>   	OPP_INITIALIZER("l3_main_1", true, 100000000, 930000),
>>>   	/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
>>
>>
>>--
>>Regards,
>>Nishanth Menon

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

[Nishanth Menon]

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

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

[Gopinath, Thara]

>>-----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@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!!

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

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

[Nishanth Menon]

Gopinath, Thara had written, on 01/06/2011 09:09 AM, the following:
[..]
>>>> 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.

I think I would find that patch interesting - Just fyi, the SR series is 
already in omap-for-linus branch and slated for .38-rc1, so feel free to 
post additional changes.

>>>> 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?

Yes, I am lost as to what the official voltage at PMIC level is for each 
OPP for OMAP4 is now :(! there are half a dozen trees out there - Ubuntu 
kernel, generic linux tree, android kernel tree etc - so the claim of 
one tree containing official table is kinda interesting as one wonders 
what one gets with other trees ;).

>>>>>>>   	/* 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.
> 
Right, so lets keep it disabled for the moment as it does not even match 
$subject and violates the concept of a single patch doing a single thing 
- enabling higher frequencies at this point of time is premature IMHO.

-- 
Regards,
Nishanth Menon

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

[Gopinath, Thara]

>>-----Original Message-----
>>From: Menon, Nishanth
>>Sent: Thursday, January 06, 2011 8:49 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 09:09 AM, the following:
>>[..]
>>>>>> 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.
>>
>>I think I would find that patch interesting - Just fyi, the SR series is
>>already in omap-for-linus branch and slated for .38-rc1, so feel free to
>>post additional changes.

Yes I will post it.

>>
>>>>>> 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?
>>
>>Yes, I am lost as to what the official voltage at PMIC level is for each
>>OPP for OMAP4 is now :(! there are half a dozen trees out there - Ubuntu
>>kernel, generic linux tree, android kernel tree etc - so the claim of
>>one tree containing official table is kinda interesting as one wonders
>>what one gets with other trees ;).

Are you sure all these tree do not have the same voltage values for mpu rail
on OMAP4? Because as far as I am aware I am the one who has been writing this code and I have never used any other values. So then it is kind of
interesting!

>>
>>>>>>>>>   	/* 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.
>>>
>>Right, so lets keep it disabled for the moment as it does not even match
>>$subject and violates the concept of a single patch doing a single thing
>>- enabling higher frequencies at this point of time is premature IMHO.

Ah! I am not debating the subject vs content issue here at all! You are
very much in the right regarding that. All I am asking is is there a
genuine issue in enabling the higher OPP's for mpu on OMAP4 today.

Regards
Thara

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

[Nishanth Menon]

Gopinath, Thara had written, on 01/06/2011 09:26 AM, the following:
> 
>>> -----Original Message-----
>>> From: Menon, Nishanth
>>> Sent: Thursday, January 06, 2011 8:49 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 09:09 AM, the following:
>>> [..]
>>>>>>> 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.
>>> I think I would find that patch interesting - Just fyi, the SR series is
>>> already in omap-for-linus branch and slated for .38-rc1, so feel free to
>>> post additional changes.
> 
> Yes I will post it.
> 
>>>>>>> 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?
>>> Yes, I am lost as to what the official voltage at PMIC level is for each
>>> OPP for OMAP4 is now :(! there are half a dozen trees out there - Ubuntu
>>> kernel, generic linux tree, android kernel tree etc - so the claim of
>>> one tree containing official table is kinda interesting as one wonders
>>> what one gets with other trees ;).
> 
> Are you sure all these tree do not have the same voltage values for mpu rail
> on OMAP4? Because as far as I am aware I am the one who has been writing this code and I have never used any other values. So then it is kind of
> interesting!

I take this back. Apologies, I missed your point and had been lazy to 
research earlier - looking at the code yet again,  I decided to look up 
official documentation :) and I finally get it - I was wrong to depend 
on some internal tree code base :(

Just FYI I looked at the public DM:
http://focus.ti.com/pdfs/wtbu/SWPS041B_FinalEPDF_12_22_2010.pdf
it pointed to the operating conditions Addendum which I only found in TI 
internal site (unfortunately).

As per this max voltages are (MPU domain)
300000000 - 976mV (nom 930mV)
600000000 - 1.155 (nom 1.1V)
800000000 - 1.323 (nom 1.26 which is coded in)
1008000000 - Nom is 1.35V (we have put that in)

Keep in mind that the voltage we put in the table is the PMIC voltage 
and the DM addendum states nominal voltage at OMAP ball level(you need 
to read (1) footnote to get the secret ;) ). What we need is to add 
additional voltage to provide at PMIC ball leve for typical board 
characteristics (this is pointed by the "Max voltage" in the addendum) 
and we allow SR to adjust to optimal voltage for that device on that board.

So the right table (if you are changing the values should be to switch 
to Max ones). I am ok on changing the voltages now that I have official 
documentation to back the change :).

-- 
Regards,
Nishanth Menon