[PROJ] Overclocking the Adreno GPU on Snapdragon Devices
Let me save you the time of reading all this. In it's current form, this is impossible. An inside connect at Qualcomm has told us we can't change the GPU clock from userland or kernel. That mean's we're screwed basically. Here is the post by Jack_R1:
Checked, as promised. Bad news. If I sum it up in one sentence - GPU overclock w/o touching the rest of the system is plain impossible, and GPU overclock while trying to play with the whole system is most probably still impossible (pending further deeper check), and it's definitely impossible for anyone that doesn't have the clock diagram, which is NDA, thus won't be available. The reason isn't software, and don't ask, what it is - I won't give direct explanations.
I've written a long post with some explanations of clock networks, to educate those that want to learn and prevent some of big mistakes that I've seen along this thread, and it's pending approval, since I don't want to accidentally spill more than I can share. I hope it gets approved and I'll post it. It should give some more insight.
The only good news is - global overclocking that affects 1GHz CPU clock will affect GPU too.
I'm sure we all heard about being able to overclock the GPU on some of the old MSM devices, but the Snapdragon handles the graphics chip in a different way. The goal of this thread is to try and overclock the GPU on Snapdragon devices as well.
There is nothing GPU related in acpuclock-scorpion.c at least for setting clock speed as far as I can tell.
In board-mahimahi.c there is some kgsl init code, but so far as I can tell it isn't setting the clock there, instead it seems to be pointing to PWR_RAIL_GRP_CLK to set the clock. It defines the variable in board-mahimahi.c but I'm not sure where that variable is set, since it doesn't seem to be in any of the other board files as far as I can tell. I could be completely off here too though.
In drivers/video/msm/gpu/kgsl/kgsl.c there is a method called kgsl_clk_enable that seems to be called whenever the GPU is enabled. It looks like this:
/* the hw and clk enable/disable funcs must be either called from softirq or
* with mutex held */
static void kgsl_clk_enable(void)
The line that's been commented out is the original value, I replaced it with my value on the line below it in a failed attempt to overclock it. Probably a stupid effort on my part, I doubt it's that simple, but it was worth a shot.
According to the clk.h files in the standard linux kernel, clk_set_rate is obviously a method to set the clock rate. The first variable is a struct that tells it which clock to set, and the second variable is a long value that is the rate you want it set at.
Is it setting the right clock there for Snapdragon chips? Or is it only the clock for older chips?
Actually I've looked again, the kgsl files are ONLY for the newer Qualcomm chips, the QSD8x50 Snapdragons & the midrange MSM7x27 series that replaced the old MSM7x00a chips like in the Dream & Magic. At least thats the way it seems to me judging from what Qualcomm & AMD have written in the source.
I'm in way over my head with this source, I'm but a lowly Java dev
, but I really wanna solve this. Can anyone with a little more experience than me throw in a little more info? Sorry if it doesn't make much sense, if it isn't clear just ask me & I'll try to explain a little more.
Okay I did a little more digging and those kgsl settings should work for QSD8x50 chips. In the config file, under Drivers, Graphics Support, it allows you to enable 3D accelleration for QSD8x50 & MSM7x27 chips. The tag for that is CONFIG_MSM_KGSL_MMU. If you check in kgsl.c it checks to see if that is enabled in the config, and if it is then it compiles and uses kgsl.c & all of the kgsl code. That tells me that the clock is either not being set, or the wrong clock is being set. I'm adding some debug code right now so I can see in dmesg what code is actually being run.
Another status update. Adding the debug code showed that it is setting the clock at my level whenever the kgsl initializes. Also, as IntersectRaven pointed out, clocks.h in arch/arm/mach-msm nicely lays out what each clock is:
grp_clock = Graphics clock
ebi1_clock = External Bus Interface 1 clock
imem_clock = Internal Graphics Memory clock
If you want to add your own debug code to it, calling the method "pr_info" and passing it a string with the message you want will output it to the kernel logs you can view with dmesg. An example would be "pr_info("kgsl: clock set at 245mhz\n");"
I now know the values for all the GPU related clocks.
<6>[ 70.681793] kgsl: grp_clock= 256000000
<6>[ 70.682464] kgsl: imem_clock= 256000000
<6>[ 70.683441] kgsl: ebi1_clock= 128000000
If you want to get these values yourself, the following code in the kgsl_clk_enable method will output them to the kernel log:
int clkg = clk_get_rate(kgsl_driver.grp_clk);
int clki = clk_get_rate(kgsl_driver.imem_clk);
int clke = clk_get_rate(kgsl_driver.ebi1_clk);
// this will get the clock rate & print it in the kernel log
pr_info("kgsl: grp_clock = %d", clkg);
pr_info("kgsl: imem_clock = %d", clki);
pr_info("kgsl: ebi1_clock = %d", clke);
Just add that into the function I mentioned and it will output it to the kernel log, quite often in fact, so I wouldn't leave it in there except to see the values
EDIT 4: 7-2-2010
Qualcomm has now released a new driver. It looks a lot better for our purposes. I'm looking through it today but I have other stuff I need to do. I will look at it, but I can't promise I can devote much time to it until at least Sunday.
I've collaborate with storm99999 over GTalk and things aren't looking good. Here's what it comes down to:
- If we try and lock it with any of the clk_set_rate methods, there is no effect. Not matter how we change it, it just stays at the original value. This either means it's set in the radio (impossible for us to change) or that it's set one time on boot and never changes, but we just don't know where it's actually set (more likely, but I'm not sure either way)
- If we try and change it with msm_proc_comm, which is a direct interface to the hardware, it causes the kernel not to boot at all. This is really really strange. We can monitor the clock with pr_info as before, and if we read the data1 argument, it prints to the kernel fine, but if we try and read the data2 arg passed to msm_proc_comm, it also freezes on boot.
We seem to be out of ideas here. We're open to any reasonable
suggestions, so if you have any, PLEASE let us know in this thread or PM one of us. Or you can email me at firstname.lastname@example.org
Follow me on Twitter @Geniusdog254
If you like my work, please buy one of my apps on the Market or donate
- Reflex-A-Tron - A colorful, addicting, & fun game to test yourself & challenge friends for only $.99!
- Search2Play - Control your music with your device's buttons!
- Task'd - A beautiful to-do list app!
Android Dev Phone 1 - Dec. '08
Rogers HTC Dream - Sept. '09
AT&T Nexus One - March '10
Motorola Droid - Apr. '10
HTC Evo - Jun. '10
HTC Evo 3D - Jun. '11
Sprint Galaxy Nexus - May '12