yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] Geniusdog254:
I'm building a kernel right now that should return all the clock values for all the graphics related stuff. It won't tell me where it's set, but I can try and change the values elsewhere if I have to and hope they stick.

To get the current frequencies I'm using the pr_info method called every time kgsl is enabled. Here is the code:

.... kgsl stuff up here ....
// this *should* get the clock rate & print it in the kernel log
pr_info("kgsl: grp_clock at ", clk_get_rate(kgsl_driver.grp_clk), "hz");
pr_info("kgsl: imem_clock at ", clk_get_rate(kgsl_driver.imem_clk), "hz");
pr_info("kgsl: ebi1_clock at ", clk_get_rate(kgsl_driver.ebi1_clk), "hz");
.... more kgsl stuff down here ....

This should return all the clock values for us, but then my C experience is nonexistant, so correct me if I made some obvious glaring mistake please.
[Nexus One Android Development] Geniusdog254:
Wow, am I the only one who cares about this at this point? :p ;)

The debug code was screwed up the first time. I changed it to this:

Which managed to return this in dmesg:

<6>[ 70.681793] kgsl: grp_clock= 256000000
<6>[ 70.682464] kgsl: imem_clock= 256000000
<6>[ 70.683441] kgsl: ebi1_clock= 128000000

So that tells us that the graphics clock and the memory clock are at 256Mhz. It may be a coincidence that the memory clock and the GPU clock are set the same, but more likely is that they are set the same so they can keep up with each other. For instance the memory bus isn't feeding the GPU more than it can handle & the GPU isn't trying to get more data than it can be fed by the memory bus. Just a theory though.
[Nexus One Android Development] e4604:
You guys are awesome, keep up the good work:)
[Nexus One Android Development] goffmj:
Awesome work.

Ok, could you please do the Evo world a favor? Could you bring this post over to the GPU project thread in the Evo section? Perhaps someone could find out what the Evo is clocked at.
[Nexus One Android Development] Geniusdog254:
I'm pretty sure the Evo is clocked the same, but I'm not sure. If I could get my Evo kernel to build, then I would try it myself. But the danged hacked source won't build on my machine, so I'm waiting for the real Evo source drop before I do any real work on mine.

EDIT: Also, I just tried changing the clock speeds before the kernel enables each the GPU & the memory bus clock, but when it goes and enables the clock, they're set back down to 256mhz. I'll try a version with the change being made after the clocks are enabled and see if that changes anything.
[Nexus One Android Development] fstluxe:
are you doing that by chaning the freq or adding this at the end of the freq something like this hexa +0x40);
[Nexus One Android Development] Geniusdog254:
Well I'm trying to set it the same way that the stock kernel sets the ebi1 clock. The stock code looks like "clk_set_rate(kgsl_driver.ebi1_clk, 128000000);"

So to try and set the other 2 clocks I used:

int imem_grp_clk = 384000000;

//other code here
clk_set_rate(kgsl_driver.imem_clk, imem_grp_clk);

//other code here
clk_set_rate(kgsl_driver.grp_clk, imem_grp_clk);

Should I be doing it another way? Like I already said, my C experience is almost nonexistant, so I'm probably doing it wrong. I know that in the original MSM7500 chips they used writel and then hex values like you showed, but that's over my head, so I don't know how to do it. If you tell me what code to put or how to do that, then I will try it and let you know.
[Nexus One Android Development] babijoee:
keep up the good work. When i see galaxy S get 50-60fps in neocore it makes me sad when n1 get 25-30fps :(
[Nexus One Android Development] midnightslide:
Wow.. amazing work so far. This gets me really excited to see what is in store for the Android community.. as well as what these phones are really capable of. Keep up the great work!!
[Nexus One Android Development] jlevy73:
Two very different chips though. The samsung uses their proprietary hummingbird chipset while the N1 uses the Snapdragon. The snapdragon outperforms hummingbird for cpu related functions but hummingbird is excellent for gpu related tasks.
[Nexus One Android Development] Geniusdog254:
Well said. The Snapdragon has excellent CPU performance for a mobile, but it uses an outdated AMD z430 GPU which has been rebranded as an Adreno 200 chip. I'm looking for a datasheet for it that may help me with setting the clocks or at least tell me more about it, but I've yet to find one. If you find one, give me a shout please :)

Also, setting the clock before or after the clocks are enabled makes no difference, they're instantly reset back to what they wore, or they're just not being changed at all. I need to find a way to set them in a way that sticks. Clk_set_rate has no effect, and clk_set_rate_sticky isn't defined in clk.h and yet it's called in board-mahimahi.c.

I will try the clk_set_rate_sticky call in just a moment. If it doesn't work then I will try some variations of writel as called in the original overclock source.
[Nexus One Android Development] jlevy73:
Just spent 20 minutes looking for a spec sheet on the Andreno and came up with nothing. Will keep looking though it has to be out there somewhere
[Nexus One Android Development] dogiedogie:
It might be worth looking at it under the AMD derivative, I too couldnt find anything about it when I looked a while ago.
[Nexus One Android Development] Geniusdog254:
Yeah that's my problem too. There isn't ANYTHING on it. There are very few Qualcomm datasheets actually out there. There are some for most of the old MSM chipsets, but none of their latest generation stuff (Snapdragon, MSM7227, etc) is available at least as far as I can find.

Another thing to consider is it may be in with the Snapdragon pages, which as far as I know haven't been publicly leaked either. Damn NDAs.

And now that I look, I can't find the method I talked about in my last post. I can't find where it was used and I don't think it was clk_set_rate_sticky either. Thats what I get for working on it at 1AM and then stopping in the middle until 4PM the next day. My bad :o

Maybe it was clk_set_rate_locked...

EDIT BINGO! Damn I knew it was there somewhere. In arch/arm/mach-msm/clock.c:

/* gross hack to set axi clk rate when turning on uartdm clock */
if (id == UART1DM_CLK && axi_clk)
clk_set_rate_locked(axi_clk, 128000000);
return msm_proc_comm(PCOM_CLKCTL_RPC_ENABLE, &id, NULL);

And of course gross hacks are exactly what all my C code is, so I'll try that method for the GRP clock right quick.
[Nexus One Android Development] jlevy73:
Nice find. Let's see how that works out.
[Nexus One Android Development] Geniusdog254:
Not very well. That method isn't defined in clk.h as I said earlier, instead it's a private method in clock.c, so it won't compile if I call it straight from kgsl, but if I copy the declaration to clk.h then it breaks clock.c.

Give me a second. Gunna try to copy it to kgsl.c, if that doesn't work then I'll try and actually set the clock in clock.c.
[Nexus One Android Development] jlevy73:
Maybe this is being looked at the wrong way. Open GL seems to be the limiting factor in terms of graphics rendering, especially ones in 3D. So even if the GPU was overclocked I wonder if limitations in Open GL would prohibit seeing any real world gains. I just found a site that discussed Open GL and how to manipulate it to improve graphics rendering. Also Open GL is now up to 4.0 as opposed to 2.0 used with the Nexus One. I am going to see if I can make any sense of the programming language being used as it involved code that looks greek to me :)
[Nexus One Android Development] Geniusdog254:
Thats true there could definitely be improvement on the GL end of things here. That stuff is WAY over my head though.

It seems most of the HTC phones with Qualcomm chipsets are limited there, sloppy coding, or whatever it may be. But at the same time, if the chip can run through the inefficient code faster, then it will still improve things. Think of it like this:

If you're running on a flat tire at 5mph, it sucks and obviously would improve drastically for the same energy if you aired the tire up. BUT, if you just put more energy into the system, you'll still go faster, just not as fast as you could with a full tire.

If that makes any sense ;)
[Nexus One Android Development] jlevy73:
Lol, that does make sense. Good analogy
[Nexus One Android Development] Geniusdog254:
Hmm. This is interesting. Whenever I call set_clk_rate_locked on any of the clock objects (kgsl_driver.grp_clk, GRP_CLK as defined in clock.h, and a custom grp_clk that points to GRP_CLK) it causes the system to freeze and not boot past the first Nexus logo or even long enough for it to write to the kernel log.
[Nexus One Android Development] Geniusdog254:
And I can't make writel work either.

I'm about out of ideas :(
[Nexus One Android Development] dogiedogie:
I would agree we have to start somewhere. We know OpenGL has room for inprovement, and we know we can and will tackle it eventually. But regardless of whether we tackle OpenGL and then GPU, or GPU, one day we are going to have to aim at that GPU ;)
[Nexus One Android Development] Guy_Fawx:
I'm not much help coding wise, but I appreciate that you guys are trying to improve Nexus Ones around the world with this overclocking of the GPU. Keep at it, I'm sure you'll think of other ideas. :)
[Nexus One Android Development] storm99999:
I've examined this area of code a bit due to interest in overclocking the GPU too.

I'll admit I am on the exact edge of my skill here, so I'm very unsure of my info.

What I've figured out:

clk_set_rate calls clk_set_rate_locked which calls pc_clk_set_rate, which calls msm_proc_comm, which I think is a direct interface to the hardware.

Based on the type of clock being modified, it seems there is a flag that controls whether the clock is directly modified, the minimum is modified, or the maximum is modified. It could be that setting the clock is working, but we can't modify the max value directly.

It may be worthwhile to change the clk struct so that it's flagged to change the max, change the struct back, and then change the actual clock. I have no idea how to do this, nor if it will work.

We can also try to skip the flags entirely using the pc_(clk) set, but those are not exposed to any other interface. I have yet to figure out how the EXPORT_SYMBOL(function); system works, but that could help us. clk_set_rate_locked could be modified too, but that changes the clock setter for every device. I have seen it used to set the camera clock. This last option would be very dangerous.

Now, if the combination of modifying the top clock and the actual clock does not work, I fear that msm_proc_comm cannot do anything and that it is locked by firmware.

Hope this helps and is in any way informative. I have no idea if any of it is right.
[Nexus One Android Development] Geniusdog254:
Yeah I looked at all of that and came to the same conclusions you did. I have absolutely no idea about EXPORT_SYMBOL, but it looks like it exports a call that any other kernel modules can call at runtime, but then if you compile to call those, you can't since it isn't in any of the included (insert correct C term for libraries here, I'm a Java dev).

Also, msm_proc_comm is a direct link to the hardware as far as I know. The problem is we're working blind. I'm pretty sure HTC has overclocked the GPU already, although not to dangerous levels or anything, just a little over the default. Just a guess on that, though coolbho seems to agree. We're working blind with this stuff, we have no idea how to change it or what to change, whereas they have NDA'd docs to look at that tell them all this good ****.

It's a damn shame that no one has leaked any of the Snapdragon datasheets yet.
[Nexus One Android Development] babijoee:
http://www.androidcentral.com/qualcomm-releases-open-source-3d-snapdragon-driver

This might be useful
[Nexus One Android Development] DocRambone:
https://www.codeaurora.org/gitweb/q...b819424af4be;hb=refs/heads/android-msm-2.6.32
[Nexus One Android Development] elegos:
Seems really cool this one... are you gonna bet you'll find something usefull in those source files? :)

Waiting for your genie :P
[Nexus One Android Development] Geniusdog254:
That looks special :)

I'll check it out. It looks like the same code we have now, but it's probably different.
[Nexus One Android Development] net.cat:
grat project man!

did u see this: http://www.androidcentral.com/qualcomm-releases-open-source-3d-snapdragon-driver

?
[Nexus One Android Development] Geniusdog254:
Thats actually what was just posted.

The code now is a lot different, and the way it sets the clocks looks a LOT like we could change it. I'll take a look when I get a chance, but I've got some other projects going on today too that could get in the way.

Just a teaser:

case KGSL_PWRFLAGS_YAMATO_CLK_ON:
if (kgsl_driver.power_flags & KGSL_PWRFLAGS_YAMATO_CLK_OFF) {
if (kgsl_driver.clk_freq[KGSL_AXI_HIGH_3D])
pm_qos_update_requirement(
PM_QOS_SYSTEM_BUS_FREQ, "kgsl_3d",
kgsl_driver.clk_freq[KGSL_AXI_HIGH_3D]);
if (kgsl_driver.clk_freq[KGSL_3D_MAX_FREQ])
clk_set_min_rate(kgsl_driver.yamato_grp_src_clk,
kgsl_driver.clk_freq[KGSL_3D_MAX_FREQ]);
if (kgsl_driver.yamato_grp_pclk)
clk_enable(kgsl_driver.yamato_grp_pclk);
clk_enable(kgsl_driver.yamato_grp_clk);
if (kgsl_driver.imem_clk != NULL)
clk_enable(kgsl_driver.imem_clk);

kgsl_driver.power_flags &=
~(KGSL_PWRFLAGS_YAMATO_CLK_OFF);
kgsl_driver.power_flags |= KGSL_PWRFLAGS_YAMATO_CLK_ON;
}

This is called on clk_enable now. The Yamato clock appears to be for 3D where as the G12 clock (not shown here) is for 2D.

More to come,

Jesse C.
[Nexus One Android Development] Dany0:
WOW DUDE!!!! I have a request/suggestion in advance:

Please make it auto-OC just in selected apps. So it would be able to run undervolted in the UI and etc. and overclocked in uh... asphalt 5 :D
[Nexus One Android Development] Geniusdog254:
That's a little over the top :(

This is a kernel hack, so nothing here is gunna be able to do that, that'd take a userland app along with a lot of tweaks to the kernel to allow userspace tweaking of the clock.
[Nexus One Android Development] Dany0:
Wait you can't make kernel changes in real-time? :confused:
[Nexus One Android Development] Geniusdog254:
You can. But you can't do things like this (sorry for the Java, it's the best example I can think of)

if(com.gameloft.asphalt isRunning()) {
kgsl_driver.clk_set_rate(KGSL_3D_MAX_RATE)
}

It would take adding kernel methods that I don't know how to do to make the clock easily user modifiable. Like with this code, SetGPU is out of the question for the moment.
[Nexus One Android Development] Dany0:
I think you should be able to do it like this:

Kernel:

adrenoclock = get.string(app.clock)

app:

clock = get.string(UI.SLIDER)

if game is running: file = open("gameclock.file"); clock = get.line("file"; 3; clock)
[Nexus One Android Development] Geniusdog254:
Unfortunately its not that simple. For one, they don't share variables like that. For 2, the clock is set at boot, so the app wouldn't have initialized that early, and it would choke because there would be no variable. Also, if the app weren't there, the same thing would happen.

I'm not saying it's impossible, I'm saying it's over my head. Lets wait until we get an overclock at all before we focus on changing the clock at run time.
[Nexus One Android Development] IOInterrupt:
Sorry, this may not even help. I'm not familiar with C at all (PHP dev here), but I ran across the following in kgsl.h which would correspond to the kgsl_pwrctrl() function.

kgsl.h

enum kgsl_clk_freq {
KGSL_AXI_HIGH_2D = 0,
KGSL_AXI_HIGH_3D = 1,
KGSL_2D_MIN_FREQ = 2,
KGSL_2D_MAX_FREQ = 3,
KGSL_3D_MIN_FREQ = 4,
KGSL_3D_MAX_FREQ = 5,
KGSL_NUM_FREQ
};

I am still poking around trying to figure out exactly how these values correlate with a particular clock speed.
[Nexus One Android Development] Geniusdog254:
I think those are just variables so it knows which clock it is. If you look in arch/arm/mach-msm/clocks.h (I think thats it, its the clock header in that directory anyway) it defines ALL the phone's clocks like that. I have never understood that being a Java dev, but it seems common practice in C. Those aren't actual rates, they're the physical clock to change.
[Nexus One Android Development] IOInterrupt:
Within kgsl.c there is an intersting bit within the __devinit (constructor) function kgsl_platform_probe()

if (pdata) {
kgsl_driver.clk_freq[KGSL_AXI_HIGH_3D] = pdata->high_axi_3d;
kgsl_driver.clk_freq[KGSL_AXI_HIGH_2D] = pdata->high_axi_2d;
kgsl_driver.clk_freq[KGSL_2D_MIN_FREQ] = pdata->min_grp2d_freq;
kgsl_driver.clk_freq[KGSL_2D_MAX_FREQ] = pdata->max_grp2d_freq;
kgsl_driver.clk_freq[KGSL_3D_MIN_FREQ] = pdata->min_grp3d_freq;
kgsl_driver.clk_freq[KGSL_3D_MAX_FREQ] = pdata->max_grp3d_freq;
}

I'm not sure if min_grp3d_freq in this case would just refer to definitions listed above or it is derived elsewhere.

I'll risk sounding like a complete noob here, but how do I get to arch/arm/mach-msm/clocks.h within git? I've never browsed code on git before.
[Nexus One Android Development] Geniusdog254:
Here's the file I'm referring to: http://android.git.kernel.org/?p=kernel/msm.git;a=blob_plain;f=arch/arm/mach-msm/clock.h;hb=HEAD

It defines all the clocks as an int in the same way. It is irrelevant for changing this clock, but it just shows about representing them as ints.
[Nexus One Android Development] IOInterrupt:
Ok, so that is actually from within the kernel used within android correct? This is all new to me, but I want to help if I can at all. I'll try not to post too much random code on here, I'm just bouncing ideas off more qualified people ;)

I only know very basic c and java.

I never followed the FPS hacks that have been done. What did you guys modify to get where you are so far?
[Nexus One Android Development] Geniusdog254:
Yes that is used in the Android kernel. If you want to browse all the source, I would look right here. That's the HTC dev page. Download the T-Mo or AT&T Nexus kernel source, and then you can browse all the source in the kernel.

That should help you look at it, but if you have a high speed connection and some time to waste, you should look here. That's the CyanogenMod wiki's page on building the kernel from source. That way you can build your own kernel if you want. If you need any more help just email me geniusdog254@gmail.com and I can try and help you set up the build environment if you want.\

P.S: Your avatar is epic!
[Nexus One Android Development] IOInterrupt:
Now look what you've done. I'll have to dual boot ubuntu or setup a VM. It's about time I start running Linux again any how. Unless of course there is some half way decent way of doing it all from Windows 7. I don't really like screwing with Cygwin, but I might consider using it if it saves me time.
[Nexus One Android Development] Geniusdog254:
Nope as far as I know there is no way to compile a kernel from Win 7, the Android dev blog says its Mac & Linux only anyway
[Nexus One Android Development] jlevy73:
A little bit of good news guys.

Qualcomm has released us some love for the GPU on the Snapdragon processor (see link below). The user space portion hasn't been released, which sucks, but at least they threw us a bone :) This might make it easier to manipulate the GPU

Here is the code: https://www.codeaurora.org/gitweb/q...b819424af4be;hb=refs/heads/android-msm-2.6.32
[Nexus One Android Development] IOInterrupt:
BTW, I am an EVO owner, I just hitchhiked over here to see what was going in this thread.
[Nexus One Android Development] jlevy73:
Oops, sorry about the link to the code, I see it was already posted :o
[Nexus One Android Development] Geniusdog254:
Thanks levy, have you looked at the new code at all? I know you don't have a lot of experience, but then neither do I, so it doesn't really matter :o

And IO, I'm a current Evo owner, but a Nexus convert, so since I still have both, I'm working mainly in this thread since my Evo kernel won't build right & we don't have real HTC source for it yet.
[Nexus One Android Development] jlevy73:
Yeah I did look at it and it seems not all the information is there. I can't seem to find the userspace portion, did you? If not, it's a start but that would mean qualcomm only released half a loaf so to speak
[Nexus One Android Development] IOInterrupt:
I believe that the userspace portion was not released.
[Nexus One Android Development] Geniusdog254:
Yeah I had read that there was no userspace half. Even so, I think we can still use this right?
[Nexus One Android Development] jlevy73:
Absolutely, there is definitely some good info in there.
[Nexus One Android Development] fstluxe:
I'm really wondering..

Why are the bigger experts so Quite about this topic does this mean that the have a lack of capability ?

no one of the Proo's= offering support here.. I'm not calling them but name.. but its a shame..
[Nexus One Android Development] IOInterrupt:
GD, have you tried setting the grp_pclk frequency within kgsl_platform_probe() (kgsl.c)? I think that may be the GPU processor.

tempclk = clk_get(&pdev->dev, "grp_pclk");
clk_set_rate(tempclk,245000000);

I presume that the N1 has grp_pclk defined in clock.h as well or it may just be grp_clk. Maybe also try adjusting the minimum and maximum frequency rates with clk_set_min_rate() and clk_set_max_rate(). Maybe they have the min and max set the same by default?

After reading more it does seem that kgsl_platform_probe, more than likely is the device initialization portion, so maybe more focus should be put here. You could also try to do it somewhere in kgsl_pwrctrl() within the KGSL_PWRFLAGS_YAMATO_CLK_ON or KGSL_PWRFLAGS_G12_CLK_ON area.

Of course if you do it in kgsl_pwrctrl you will need to replace &pdev->dev with an appropriate object (kgsl_driver.pdev I think).
[Nexus One Android Development] Geniusdog254:
What I tried before was setting the grp_clk but every time I would set it, it would instantly revert back to the normal 256mhz. I was unaware of the clk_set_min_rate & max_rate methods before (they may be just in the new code) but I will try them when I get time to build a kernel.

Before I was setting the clock on the kgsl_enable call where it already set up the EBI1 clock. I figured it would work the same for the GRP & IMEM clocks but apparently not.
[Nexus One Android Development] IOInterrupt:
It does indeed look like grp_pclk is defined by Kernel GSL (kgsl).
[Nexus One Android Development] IOInterrupt:
This is what I have gathered so far from the device initialization

kgsl_driver.yamato_grp_pclk // Graphics pbus clock
kgsl_driver.yamato_grp_clk // Graphics clock
kgsl_driver.yamato_grp_src_clk // Graphics 3D Clock
kgsl_driver.g12_grp_pclk // Graphics 2D pbus clock

You should be able to use clk_set_rate(), cls_set_min_rate(), and set_max_rate() on all of these, but I am unsure which ones require min and max rates.

clk_set_rate(kgsl_driver.yamato_grp_pclk, 245000000);

The pbus (kgsl_driver.yamato_grp_pclk) min rate is being set to the value of pdata->max_grp3d_freq, which I have yet to track down to see what the default value is.

The 2D pbus is blocking hardware access under the instance name hgsl_driver.g12_device, but the same clock can be accessed via kgsl_driver.g12_grp.pclk.

This is as far as I have gotten and I'm running home. I'll try to look at this more later today.
[Nexus One Android Development] Dany0:
Small question, can we expect big performance boost or it's so unnoticeable that it's better to underclock it and save the battery?
[Nexus One Android Development] IOInterrupt:
We actually have no idea what the actual possibilities are yet.
[Nexus One Android Development] jlevy73:
I am trying to get pershoot to take a look at the new code that was released today. He will be away for a little but when he returns hopefully he can shed some light on this.
[Nexus One Android Development] dogiedogie:
I think people are pretty confident we will get control of clock speeds and maybe voltages, but its still up to the chip itself what its stable at/doing what.