[DEVS/KERNEL] Galaxy Nexus 1.4GHz overclock + Undervolting patches

Status
Not open for further replies.
Search This thread

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
This is a *clean* kernel based on the latest sources in AOSP (with the volume down interference fix), but also adds an undervolting interface and a 1.4GHz speed step, and brings the GPU to 384MHz instead of 307MHz. It also uses paulobrien's ramdisk for unsecure adb. :)

As with everything, use at your own risk! Overclocking/overvolting can be dangerous for your phone.

UV control + 1.4GHz GPU 384MHz. I encourage you to test this out before flashing.
UV control only - use this if you get stuttering issues at 1.4GHz GPU 384MHz
Or, if you prefer a tweaked kernel with more features, both Francisco and Paul have implemented the UV patch in their kernels. Feel free to post feed back about the UV in this thread, though.

To test: fastboot boot gnex_oc_uv.img
To flash: fastboot flash boot gnex_oc_uv.img

The undervolting interface works exactly as it does in the Nexus S CM kernel. Read the current voltages from /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table and write voltages to the same file space-delimited in mV (millivolts). SetCPU undervolting and probably some other undervolting apps support this interface.

Some users have experienced slowness with the new 1.4GHz speed. If you do, please post a dmesg and your exact symptoms (how slow? benchmark speeds, etc). Thanks to franciscofranco for implementing the overclock in his kernel and having users test. The undervolting patch alone should be 100% stable.

Here is a diff of the 1.4GHz patch and undervolting patch applied to the base kernel.

Available on my github too: http://github.com/coolbho3k

Quick video demo/screenshots:

RRhnV.png
USB50.png


I'm working on getting this phone to faster speeds than 1.4GHz, but it's not as easy as "just remove the underclock because OMAP4460 *should* be 1.5GHz."

A note about the undervolt patch: It's the only change to omap2plus_cpufreq.c in the above diff (you can see it as a single commit (with a typo :p) in the Galaxy Nexus kernel repo on my github). This patch is fairly clean in that it is implemented purely in the omap4 cpufreq driver and supports an arbitrary number of frequencies. It should also work with any recent OMAP4 kernel, not just the Galaxy Nexus. If there are any other devices that use the OMAP4 and have an unlocked bootloader, I welcome developers to try it out!
 
Last edited:

bigxie

Senior Member
Nov 14, 2010
1,374
5,860
Bay Area, CA
www.twitter.com
So, unfortunately, I'm one of those that experiences the stutters at 1.4GHz.

Symptom is pretty simple, it's super slow, with tiny bursts of regular speed. In fact, it took me almost 20 minutes to boot the kernel (I did wipe caches before flashing it). The boot animation would creep slowly, and have a couple short bursts of regular speed, then back to a crawl. Same thing as the apps were being optimized, the progress circle would spin slowly then quickly, etc.

All that's in dmesg are dpll_mpu_ck fails. Here's what I grabbed:

http://pastie.org/2979080
 

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
why is it so difficult to hit that 1.5 mark ? kinda curious :p

It's the exact problem bigxie is having, except I get it at 1.5.

bigxie: thanks for the dmesg, that answers a lot.

I *have* gotten the phone to boot at faster speeds, which should also remedy the problem illustrated above. But it is not consistently stable. It's really weird. It's an issue with something called Duty Cycle Correction, which seems to be unstable on my device, but is required for higher frequencies. DCC seems to be required at lower frequencies for some than others. I wish we could get someone from TI over here ;)

EDIT: posted the test kernel that I used to achieve the above 1.6GHz result. Flash at your own risk!
 
Last edited:

vivanshah

Senior Member
Dec 21, 2009
183
40
if we eventually set "apply on boot" for voltage and it ends up being unstable, we should still be able to get into fastboot and simply reflash the boot.img, correct?
 

bigxie

Senior Member
Nov 14, 2010
1,374
5,860
Bay Area, CA
www.twitter.com
I *have* gotten the phone to boot at faster speeds, which should also remedy the problem illustrated above. But it is not consistently stable. It's really weird. It's an issue with something called Duty Cycle Correction, which seems to be unstable on my device, but is required for higher frequencies. DCC seems to be required at lower frequencies for some than others. I wish we could get someone from TI over here ;)

EDIT: posted the test kernel that I used to achieve the above 1.6GHz result. Flash at your own risk!

Heh, maybe for you.

I get a nice Google logo when I booted the 1.6GHz :)

I think I got the short end of the stick when it comes to chips. I noticed with francisco's kernel that I was getting some screen artifacts too, most likely from running the GPU at 384MHz?

Ahh, oh well, I'm so much more interested in UV than OC anyways. Any chance you could post a non overclocked kernel with UV? :D
 

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
if we eventually set "apply on boot" for voltage and it ends up being unstable, we should still be able to get into fastboot and simply reflash the boot.img, correct?

Yes. Just do an adb reboot bootloader during the boot animation. Or, to be extra safe, use fastboot boot instead of fastboot flash until you find stable voltages.

Or, if you want, press "menu" in SetCPU's main tab and extract the safe mode zip to the internal memory. If things go haywire, boot into recovery and flash the zip and the boot voltages will be ignored.
 

Chirality

Senior Member
Sep 6, 2008
651
127
Cambridge, MA
Are you sure DCC is necessary for 1.5GHz? As you probably already know, the TI manual says DCC should be used for 1GHz and greater. But in the stock kernel code for the GN, DCC is bypassed even for 1.5GHz. I dug through the commit logs to find where they changed this:

Code:
commit eac0b0094edb42732c4ab095357d8ca9679e94bc
Author: Nishanth Menon <[email protected]>
Date:   Tue Sep 20 15:45:29 2011 -0500

    OMAP4460: DPLL: use DCC bypass until 1.5GHz

    DCC is to be bypassed untill 1.5GHz now that samples are trimmed
    for DPLL operation upto 3GHz.

    Change-Id: I55b7b52656e1630460d84876b994fce561d17b40
    Signed-off-by: Nishanth Menon <[email protected]>


commit 0e8f213258af4127f7299ed897aeafc20040c7ee
Author: Colin Cross <[email protected]>
Date:   Tue Sep 6 12:38:25 2011 -0700

    ARM: omap4: dpll44xx: Don't use DCC at 1.2GHz

    Transitioning from DCC on to DCC off seems to cause rare lockups.
    Disable DCC for 1.2 GHz, where it is not strictly necessary.
    To lock the DPLL @ 2.4 GHz DPLL trim-override needs to be used.

    Based on patch by Vishwanath BS <[email protected]>.

    Change-Id: I6979f2e5e0d8368c99a466215e6a1153510a6516
    Signed-off-by: Colin Cross <[email protected]>

It sounds like DCC isn't necessary even for 1.5GHz? If it's not possible to hit 1.5GHz on the GN, it's probably due to binning. Seems like the PRM module may also be binned, those certified to run 3GHz DPLL without DCC are used for 1.5GHz binned chips, while the chips binned for 1.2GHz don't have the good PRM modules. DCC for the MPU clock is probably not usable, since even TI couldn't get it to work without lockups.
 
  • Like
Reactions: samno

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
Heh, maybe for you.

I get a nice Google logo when I booted the 1.6GHz :)

I think I got the short end of the stick when it comes to chips. I noticed with francisco's kernel that I was getting some screen artifacts too, most likely from running the GPU at 384MHz?

Ahh, oh well, I'm so much more interested in UV than OC anyways. Any chance you could post a non overclocked kernel with UV? :D

Posted. As for 384MHz GPU, that's what the GPU is supposed to be at - Google reduced the GPU speed in the final build to save on a bit of battery, but in my experience some UV balances that out nicely.


Are you sure DCC is necessary for 1.5GHz? As you probably already know, the TI manual says DCC should be used for 1GHz and greater. But in the stock kernel code for the GN, DCC is bypassed even for 1.5GHz. I dug through the commit logs to find where they changed this:

It sounds like DCC isn't necessary even for 1.5GHz? If it's not possible to hit 1.5GHz on the GN, it's probably due to binning. Seems like the PRM module may also be binned, those certified to run 3GHz DPLL without DCC are used for 1.5GHz binned chips, while the chips binned for 1.2GHz don't have the good PRM modules. DCC for the MPU clock is probably not usable, since even TI couldn't get it to work without lockups.
I can't lock to 1.5GHz with DCC off (see bigxie's 1.4GHz dmesg - the same thing happens), but I can with DCC on (changing the value of OMAP_1_5GHz in dpll44xx.c changes the threshold at which DCC is turned on). Sometimes I can get past the Google logo with DCC on, and I can be perfectly stable within Android, sometimes (with the same binary that I made when it was stable), I can't. The above 1.6GHz kernel I posted does have DCC enabled for 1.6GHz, and at the moment, I can boot into Android. Why this happens totally beyond me right now.

Maybe some of the PRMs in GN units are binned for 1.2GHz and others for 1.5GHz. That would not, however, explain my chip, which works at 1.4GHz but not 1.5GHz (DCC off).

Where did you find that info? The 4460 documentation (for an earlier SoC revision) does say DCC needs to be turned on for over 1GHz. I can't find a technical reference manual for the revision used in the Galaxy Nexus. It would be a shame if we could not get DCC/M3 output to work ever, since we would be essentially stuck at 1.2GHz then.

Also, to pour more knowledge into this, I did look at the omap4_trim_quirks.c and tried to trim the DPLL for operation above 1.2GHz by writing to those registers directly. It seems like on my chip those registers were set up for DPLL operation up to 1.5GHz, so I increased this even more. This did not work.

Code:
Transitioning from DCC on to DCC off seems to cause rare lockups.

I did dig extensively through the commit logs, but actually did not see this particular sentence before. That's a shame - I hope we'll be able to solve that problem.

Also of note is Colin Cross's commit disabling 1.5GHz, in which he states the "tuna board is not compatible with 1.5GHz" but does not elaborate further. That's puzzling as well.
 
Last edited:
  • Like
Reactions: Raijynn

Chirality

Senior Member
Sep 6, 2008
651
127
Cambridge, MA
I can't lock to 1.5GHz with DCC off (see bigxie's 1.4GHz dmesg - the same thing happens), but I can with DCC on (changing the value of OMAP_1_5GHz in dpll44xx.c changes the threshold at which DCC is turned on). Sometimes I can get past the Google logo with DCC on, and I can be perfectly stable within Android, sometimes (with the same binary that I made when it was stable), I can't.

Sounds like you are hitting the bug that caused Google/TI to turn off DCC for 1.2GHz in the first place. It seems like getting the device to be stable with DCC would be pretty difficult, and the chip in the GN is not binned for letting the DPLL_MPU to be able to lock at 3GHz, which means it'll be very difficult to impossible to get 1.5GHz to work...

According to omap4_trim_quirks.c, it seems the chip used in the GN is a so-called "PRE_RTP" device, which is not trimmed. So it's using a software trim override to enable the DPLL_MPU to lock at 2.4GHz, and presumably beyond. It sounds like the problem with hitting frequencies higher than 1.2GHz is not due to software trim locks (since this is overridden to allow the DPLL_MPU to lock at any frequency) but rather due to limitations of the silicon itself. This would explain why, with DCC off, some people can hit 1.4GHz while others can not: the PRM is not binned for 3GHz operation, so between 2.4GHz and 3GHz, we'll have some chips running ok and others not being able to lock the DPLL.
 
Last edited:
  • Like
Reactions: Neo3D and Luxferro

noobdeagle

Senior Member
Apr 5, 2010
687
88
Adelaide, SA
surely if there were different binning the ones that fail to reach 1.5ghz would be clocked at 1.2ghz and would be sold as 4430's, considering the gnex is advertised as 4460 i would assume its something else likely with that dcc.

im sure the talented people on xda will figure it out eventually :D

also as a side note wasn't there reports of TI being unable to get good yields of 4460's ?
 
Last edited:

bigxie

Senior Member
Nov 14, 2010
1,374
5,860
Bay Area, CA
www.twitter.com
Well, at least I have some great news regarding UV. Seems like the stock voltages were waaaay high.

Code:
[email protected]:/ # cat /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
cat /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
1200mhz: 1150 mV
920mhz: 1025 mV
700mhz: 950 mV
350mhz: 875 mV
[email protected]:/ # cat /sys/devices/system/cpu/cpu1/cpufreq/UV_mV_table
cat /sys/devices/system/cpu/cpu1/cpufreq/UV_mV_table
1200mhz: 1150 mV
920mhz: 1025 mV
700mhz: 950 mV
350mhz: 875 mV



I haven't even gotten it to lock up yet, just kept going down by 25-50mV increments and using SetCPU/CF-Bench to test all the frequencies. Are these for sure being applied? ;-)
 

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
Sounds like you are hitting the bug that caused Google/TI to turn off DCC for 1.2GHz in the first place. It seems like getting the device to be stable with DCC would be pretty difficult, and the chip in the GN is not binned for letting the DPLL_MPU to be able to lock at 3GHz, which means it'll be very difficult to impossible to get 1.5GHz to work...

According to omap4_trim_quirks.c, it seems the chip used in the GN is a so-called "PRE_RTP" device, which is not trimmed. So it's using a software trim override to enable the DPLL_MPU to lock at 2.4GHz, and presumably beyond. It sounds like the problem with hitting frequencies higher than 1.2GHz is not due to software trim locks (since this is overridden to allow the DPLL_MPU to lock at any frequency) but rather due to limitations of the silicon itself. This would explain why, with DCC off, some people can hit 1.4GHz while others can not: the PRM is not binned for 3GHz operation, so between 2.4GHz and 3GHz, we'll have some chips running ok and others not being able to lock the DPLL.

I wonder if we can just use CLKOUTX2_M3 and DCC all the time (the TRM says we can't).

Well, at least I have some great news regarding UV. Seems like the stock voltages were waaaay high.

Code:
[email protected]:/ # cat /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
cat /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
1200mhz: 1150 mV
920mhz: 1025 mV
700mhz: 950 mV
350mhz: 875 mV
[email protected]:/ # cat /sys/devices/system/cpu/cpu1/cpufreq/UV_mV_table
cat /sys/devices/system/cpu/cpu1/cpufreq/UV_mV_table
1200mhz: 1150 mV
920mhz: 1025 mV
700mhz: 950 mV
350mhz: 875 mV



I haven't even gotten it to lock up yet, just kept going down by 25-50mV increments. Are these for sure being applied? ;-)
Try going real low for one of the higher frequencies, ie. 1000 mV. It'll lock up instantly. My heat testing does show these are being applied, and I can boot up at 1150mV hard coded in the kernel too. I imagine it's not too stable.
 
Last edited:

Chirality

Senior Member
Sep 6, 2008
651
127
Cambridge, MA
surely if there were different binning the ones that fail to reach 1.5ghz would be clocked at 1.2ghz and would be sold as 4430's, considering the gnex is advertised as 4460 i would assume its something else likely with that dcc.

im sure the talented people on xda will figure it out eventually :D

also as a side note wasn't there reports of TI being unable to get good yields of 4460's ?

Given what we know so far, I think it's likely that things went something like this.

Originally, TI designed the 4460 to run at >1GHz using DCC. At this point the 4460s are not binned, and all chips were thought to be able to run at 1.5GHz since with DCC this only required the DPLL to lock at 1.5GHz. But it was later discovered that DCC is not stable. TI seems to have given up on DCC entirely, but this means that the DPLL needs to be able to lock at 3GHz to run the processor at 1.5GHz. Unfortunately not all yields were able to lock DPLL this high, so the 4460s started to be binned. The 4460s that can lock DPLL at 3GHz has this ability hardwired in the efuse, and are called "speed bin." These have the ability to run the processor at 1.5GHz. The 4460s that can't lock DPLL at 3GHz are the normal bin, these can run at up to 1.2GHz, most likely because the minimum DPLL lock that can be obtained by all yields is 2.4GHz. This would explain why yields of 4460s that can clock at 1.5GHz is low, and why all 4460s on the market right now are only binned for 1.2GHz operation.
 

bigxie

Senior Member
Nov 14, 2010
1,374
5,860
Bay Area, CA
www.twitter.com
Try going real low for one of the higher frequencies, ie. 1000 mV. It'll lock up instantly. My heat testing does show these are being applied, and I can boot up at 1150mV hard coded in the kernel too. I imagine it's not too stable.

Yeah, I finally hit the barrier. So, how do you test stability? I ran tons of consecutive short/long/native benches with the max set at each frequency and if it passed all that, a run or two of CF-Bench.

I'll run it more tomorrow, but for now, it seems to me that each frequency is stable at these voltages for my device:

Screenshot_2011-12-07-02-44-58.png



Also, a little OT, but doesn't OMAP4 support NEON? How come there isn't a score in the native bench? IIRC, there was one for devices that support it.

Thanks for all the hard work you've put into this!

EDIT: Mandelbrot in Smartbench crashed this config, had to raise 1200MHz to 1100mV and it all straightened out. Quadrant, Antutu, Smartbench, CF-Bench, Asphalt 6, Fruit Ninja, etc. all run fine.
 
Last edited:
  • Like
Reactions: axial_pro

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
Yeah, I finally hit the barrier. So, how do you test stability? I ran tons of consecutive short/long/native benches with the max set at each frequency and if it passed all that, a run or two of CF-Bench.

I'll run it more tomorrow, but for now, it seems to me that each frequency is stable at these voltages for my device:

Also, a little OT, but doesn't OMAP4 support NEON? How come there isn't a score in the native bench? IIRC, there was one for devices that support it.

Thanks for all the hard work you've put into this!

The lack of a NEON benchmark is a bug that I'll just fix.
 

ande_uk

Senior Member
Mar 23, 2010
86
4
Yorkshire

my phone froze while running quadrant (the red and blue dna strand) at these voltages..

runs ok at

1200:1200
920:1100
700:1000
350:900

will probably try again half way between..

**update**

full quadrant and asphalt 6 hd run ok at

1200:1150
920:1050
700:950
350:850
 
Last edited:

Chirality

Senior Member
Sep 6, 2008
651
127
Cambridge, MA
Also, to pour more knowledge into this, I did look at the omap4_trim_quirks.c and tried to trim the DPLL for operation above 1.2GHz by writing to those registers directly. It seems like on my chip those registers were set up for DPLL operation up to 1.5GHz, so I increased this even more. This did not work.

It sounds like you already tried directly setting these trimming bits to try to get the DPLL to lock at 3GHz. But in case you haven't, perhaps this will help:

http://www.ti.com/pdfs/wtbu/SWPZ017A.pdf page 53.

Hmmm...which value are you setting in the register to try to get the DPLL to lock at a higher freq? Looking at the TRM again, it seems writting 0x29 to the CONTROL_DPLL_NWELL_TRIM_0 register overrides the DPLL trim to 0x1, which only allows DPLL up to 2.4GHz. To allow up to 3.0GHz, it looks like 0x2b should be written there instead. Also it looks like by default the override is only used when the DPLL trim register reads 0x0. But I'm guessing on the GN 4460 this register reads 0x1. Not sure if you tried to take out this conditional in your original attempt?
 
Last edited:

Arcadia310

Senior Member
Aug 13, 2010
1,093
102
What are the stock voltages set at? I'm looking to root my device and am a lot more interested in UV than OC. Why do these companies set the voltage so high on stock?

Sent from my Galaxy Nexus using XDA App
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 25
    This is a *clean* kernel based on the latest sources in AOSP (with the volume down interference fix), but also adds an undervolting interface and a 1.4GHz speed step, and brings the GPU to 384MHz instead of 307MHz. It also uses paulobrien's ramdisk for unsecure adb. :)

    As with everything, use at your own risk! Overclocking/overvolting can be dangerous for your phone.

    UV control + 1.4GHz GPU 384MHz. I encourage you to test this out before flashing.
    UV control only - use this if you get stuttering issues at 1.4GHz GPU 384MHz
    Or, if you prefer a tweaked kernel with more features, both Francisco and Paul have implemented the UV patch in their kernels. Feel free to post feed back about the UV in this thread, though.

    To test: fastboot boot gnex_oc_uv.img
    To flash: fastboot flash boot gnex_oc_uv.img

    The undervolting interface works exactly as it does in the Nexus S CM kernel. Read the current voltages from /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table and write voltages to the same file space-delimited in mV (millivolts). SetCPU undervolting and probably some other undervolting apps support this interface.

    Some users have experienced slowness with the new 1.4GHz speed. If you do, please post a dmesg and your exact symptoms (how slow? benchmark speeds, etc). Thanks to franciscofranco for implementing the overclock in his kernel and having users test. The undervolting patch alone should be 100% stable.

    Here is a diff of the 1.4GHz patch and undervolting patch applied to the base kernel.

    Available on my github too: http://github.com/coolbho3k

    Quick video demo/screenshots:

    RRhnV.png
    USB50.png


    I'm working on getting this phone to faster speeds than 1.4GHz, but it's not as easy as "just remove the underclock because OMAP4460 *should* be 1.5GHz."

    A note about the undervolt patch: It's the only change to omap2plus_cpufreq.c in the above diff (you can see it as a single commit (with a typo :p) in the Galaxy Nexus kernel repo on my github). This patch is fairly clean in that it is implemented purely in the omap4 cpufreq driver and supports an arbitrary number of frequencies. It should also work with any recent OMAP4 kernel, not just the Galaxy Nexus. If there are any other devices that use the OMAP4 and have an unlocked bootloader, I welcome developers to try it out!
    5
    would it be possible to get a pure UV kernel without the GPU overclock?

    many thanks for your hard work, and the time you take to explain everything.

    I'll post a completely stock kernel (no GPU overclock) with undervolting that when I get the chance.

    As for "undervolting for noobs," if you don't know what you're doing:

    Basically, to maintain a certain CPU frequency, you need to feed it a minimum voltage. The minimum voltage for any given frequency happens at different points for different people because of manufacturing and environmental differences ie. the piece of silicon that makes up the CPU core in your device is going to have different tolerances than the silicon in someone else's device. This is why, instead of building a fixed undervolt into the kernel, this patch allows users to tweak the voltages. The lower the voltage, the lower the power consumption, the more battery life you're going to end up getting.

    Voltages are even more important than frequency to battery life since the power consumed by a CPU is approximately proportional to current CPU frequency and to the square of the CPU voltage (Wikipedia) (this of course does not take into account the complexity of the instructions being performed or temperature variations).

    1. Make sure "set on boot" is turned off!
    2. Look at some of the screenshots posted earlier in this thread and change your settings to match those, and press "apply." In SetCPU, you can use the slider bar or the textbox to enter voltages.
    3. If you crash at any point, raise all the values by 25 mV and press "apply" again, and repeat. Sometimes a voltage set will seem stable at first, and then crash later. Just raise the voltages by 25 mV if this happens. If your phone is stable after several days of regular use, you can probably be sure that the voltages you're using are sufficiently stable for regular use.

    You can, of course, fine tune each level if you want instead of raising everything by 25; that's just a safe way of going about it.

    The idea is to get as low voltages as possible without crashing the phone. Also, I wouldn't try testing undervolt settings while your phone is needed for mission-critical things.

    Also, on the Galaxy Nexus, you can go by increments of 1 mV if you want by using the text box. You don't have to go by every 25 mV.
    4
    Hmm yes but I hoping for a more simplified version of how he has had it so difficult if possible. From what iv read it sounds like he is trying to block any attempt of over clocking, perhaps for warrenty / claims / returns purposes I dont know. But if its possible to break down the coding language to something more understand able for us mere mortal non devs

    Sent from my Galaxy Nexus using xda premium

    Nah, Colin just disabled 1.5GHz because it simply doesn't work on the Galaxy Nexus as is. Reversing his patch enables 1.5GHz, but with the "stuttering" (so it doesn't really enable 1.5GHz). But maybe we can find a workaround.

    Basically we've got a clock generator. For frequencies under 1GHz, you're supposed to run the "MPU DPLL" at double the desired speed and an internal clock divider will bring that down by 1/2, so we're running the DPLL at 2GHz at 1GHz and 2.4GHz at 1.2GHz. For 1.5GHz we would need to run the MPU DPLL at 3GHz, which is where we run into problems - it simply doesn't want to go that high on most peoples' devices.

    TI's solution to this was a feature called Duty Cycle Correction, which is needed to use the frequency without a 1/2 divider, making it so we only have to run the MPU DPLL at 1.5GHz to run the MPU at 1.5GHz. But this revision of the 4460 has a major bug where switching DCC off (to switch to lower frequencies) causes crashes. This makes DCC utterly useless, so we're kind of stuck here.

    GPU speed is independent of CPU speed as far as I can tell. And the stock with voltage control kernel in the OP does have the 384MHz GPU overclock applied.
    3
    obvious for non technical people :)
    OMAP4460 born as a 1.5GHz CPU and it is able to run at that frequency.

    Cooks wasn't able to push that CPU at that level because they weren't able to give them enough current to work stable.
    Another huge problem that cooks generally ignore is the deep idle.
    Deep idle help in saving battery but enlarge the current gap between the idle state to the load state, managing the right current in this transition is something critical and no cook as far as I seen taked this into consideration.
    The problem is that cooking mama are generally kids playing around with kernels and hacks but they often don't have the skills or the possibility to access "the required data" to correctly work. Only TI engineer can understand some tech specs of that CPUs and this is what our cooks lacks.

    The only thing sure now is that TI is selling only one type of OMAP4460 (a lower clocked version is named OMAP4430 and not OMAP4460 clocked at lower freq).
    The OMAP4460 is a 1.5GHz CPU, full stop.

    ---------- Post added at 02:06 PM ---------- Previous post was at 02:04 PM ----------



    Find this articles. We don't need forum rumors, cook rumors or stupid analogies, we need an official statement from TI to say what you are saying.
    In any case, suppose that this was true, why they created the OMAP4460 if they had the OMAP4430?
    These are some things you must understand.
    1. GN has a 4460 in it.
    2. Google underclocked the gpu in the GN to save power. It may seem like we have an over locked 4430, but that's pretty much what a 4460 is. Also, see point one.
    2. The 4460 differs from the 4430 by its increased CPU & GPU clock speeds.
    3. You don't need to be a TI engineer to understand the tech specs of the OMAP4 cpus. All the this "required data" you speak of is made available on TI's website.
    4. "Cooks" on xda are alot more intelligent than you are giving them credit for. If you have read all the posts in this thread as well as many others, you would understand that all the real devs that are messing with UV and OC have a rather concise knowledge of what they are working with. Yes. Some read TI's documentation.
    5. Just cause we have a 4460 does not mean it can run at 1.5 ghz. Not all cpus are created equal. This applies to all silicon chipsets regardless of what we are talking about. Mobile or desktop cpus, mobile or desktop gpus, mobos, etc.
    /end rant.


    Sent from my Galaxy Nexus using Tapatalk
    2
    I can't lock to 1.5GHz with DCC off (see bigxie's 1.4GHz dmesg - the same thing happens), but I can with DCC on (changing the value of OMAP_1_5GHz in dpll44xx.c changes the threshold at which DCC is turned on). Sometimes I can get past the Google logo with DCC on, and I can be perfectly stable within Android, sometimes (with the same binary that I made when it was stable), I can't.

    Sounds like you are hitting the bug that caused Google/TI to turn off DCC for 1.2GHz in the first place. It seems like getting the device to be stable with DCC would be pretty difficult, and the chip in the GN is not binned for letting the DPLL_MPU to be able to lock at 3GHz, which means it'll be very difficult to impossible to get 1.5GHz to work...

    According to omap4_trim_quirks.c, it seems the chip used in the GN is a so-called "PRE_RTP" device, which is not trimmed. So it's using a software trim override to enable the DPLL_MPU to lock at 2.4GHz, and presumably beyond. It sounds like the problem with hitting frequencies higher than 1.2GHz is not due to software trim locks (since this is overridden to allow the DPLL_MPU to lock at any frequency) but rather due to limitations of the silicon itself. This would explain why, with DCC off, some people can hit 1.4GHz while others can not: the PRM is not binned for 3GHz operation, so between 2.4GHz and 3GHz, we'll have some chips running ok and others not being able to lock the DPLL.