yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] storm99999:
Ok, so I spent more time going through the current source, so sorry if this is a bit out of date.

msm_proc_comm writes directly to hardware, or at least a memory address associated with it. It spin locks and unlocks around the hardware access, so it is safe to call from anywhere. It is in the file proc_comm.c and used nearly everywhere, so getting it to be called elsewhere should not be a problem.

I'd try a call like:

msm_proc_comm(PCOM_CLKCTL_RPC_MAX_RATE, clk_name, clk_rate);

msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, clk_name, clk_rate);

Wedged in a clk_enable call. Not sure if the first is needed, but it increases the chance of working.

Something akin to

if (clk_name != clk_gpu)

{carry on}

else

{modify any actual input}

Because of how the values are stored by msm_proc_comm (readl, writel to an address), we may have problems overclocking not just because of hardware limitations, but also the space used to store the clk might be too small.

There are two options for storing clk in ram, a constant and a multiplier or a variable. If it's the latter, we may have very little space to overclock depending on the memory architecture. There would be at least ~10%, not sure. If it's the former, and it's 32Mhz * mult, we can (probably) go as far as an 87% oc without using more memory. This is all conjecture.

The only problem is that I have been as of yet unable to set up a build environment. I'll keep trying, and once I do, I'll try running the GPU at the 2D rate in a 3D app, safer that way.

We really aught to get the kernel to write to a log all default values. It would be easier than finding them in code, as I'm pretty certain that they're read from ROM (or hopefully RAM, so read and write operate on the same sector) on the GPU. All get_clk functions use the readl portion of msm_proc_comm and the set_clk use the writel portion.

Without analyzing the *clk struct for each clock, I cannot definitively tell if the get and set's access the same point in ram.

I'll spend some time with the new code to see if any of this still applies, or if, hell, I'm making any sense.

EDIT:

Also, cpufreq exposes the CPU clock to userspace. Could we port it? I think that they use similar communication methods and similar reasons to modify the speeds.
[Nexus One Android Development] IOInterrupt:
Yes, obviously getting control is expected, but the level of performance is an unknown. I for one would more than likely underclock.
[Nexus One Android Development] storm99999:
Well, we know that there is a separate 2D 3D clock. I would think most people would underclock 2D, overclock 3D to get the best of both, though a 2D performance bump would be nice so that launchers don't stutter as bad.
[Nexus One Android Development] codito:
Use LauncherPro, it doesn't stutter at all. It's AMAZING.
[Nexus One Android Development] storm99999:
I do, but I still notice it stutter once in a while. Very minor.

Come to think of it, I get the feeling that OC'ing the bus would be more valuable than anything else. It wouldn't use as much power as OC'ing everything else while at the same time helps with the universal IO bottleneck. Does anyone know if the 128mhz bus is just the graphics bus or is it the system bus?
[Nexus One Android Development] jlevy73:
I believe, from what I can tell that the 128mhz is just the graphics bus.
[Nexus One Android Development] jlevy73:
Personally I would like the ability to overclock both. 2D would be nice as you said for launchers since they all stutter a little. But a 3D overclock would make a big difference not only in gaming but would open up a whole other for things like live wallpapers, boot animations, etc.
[Nexus One Android Development] Geniusdog254:
The EBI1 clock is just the first Externel Bus Interface for the board. I'm not sure what else (if anything) is wired up to it other than apparently the GPU from the code I'm seeing. I'm not sure what effect boosting it would do, but it's worth a shot.

I haven't really messed with the msm_proc_comm command yet because I wasn't sure how to work it and I didn't wanna break anything critical. That sounds like the better way to do it, since we wouldn't be relying on other code to set it we'd be talking direct to the hardware. Also, about using the debug code to read the clocks, that's what I did.

If you run something like this on the clock enable, it'll print the speed to the kernel log:

pr_info("gpu_clk_set_debug: %D clock set at %D" *get the clock variable here*, *get clock speed here*)

I put a little more info on that in the OP a while ago if you wanna check it out.
[Nexus One Android Development] storm99999:
I didn't mean just the clocks, more like the entire *clk struct. If we knew if it was setting the actual clock or the max, it would be more helpful.

I would prefer to use the functions the rest of the kernel uses, but the entire purpose of the locked function is to be a safety wrapper. I presume safety isn't our goal yet. It looks like the safety wrapper can yet be worked around but direct hardware access will tell us whether or not overclocking is even possible.

It looks like my evening is going to be dedicated to picking apart the Code Aurora commit and getting a kernel to build.
[Nexus One Android Development] Geniusdog254:
Me too haha. Is it sad that my relaxation night has now become pick-apart-a-kernel night? Lol.

I'm updating my build environment now with the latest CodeAurora stuff, but my damn connection is slow (30-50KB/s down) today. So it could be an hour or two before I have a fully working kernel build again.
[Nexus One Android Development] storm99999:
I got my kernel to compile, but it rendered my device unbootable until I nandroid restored. I didn't even flash the image...

The only change I added was:

pr_info("kgsl %s: %d, Type: %d", clk->name, rate, clk->flags);

At the start of clk_set_locked.

I thought I nuked my phone... I guess I'm going to take a break from making a kernel for a bit.

Anyways, I got the Code Aurora stuff downloaded, I think they've stripped the protection mechanisms, or at least they're not as evident. Everything is based around clk_set_min_rate and clk_set_max_rate, which wasn't exposed in the old driver.

In addition, it ignores flags, and the clock is set from kgsl_driver.clk_freq[0-5]. Extracting that array and rewriting it at some point could be one way to do it, the other is to find where it's initialized. A third way would be to set the minimum speed at the maximum speed, on the off chance that it does not scale. I just have no idea where it is initialized, though probably from some hardware table. I'll hunt it down somewhere, so long as I don't have to get the entire kernel source again...

EDIT: Oh hai! I found where it is initialized, in kgsl_platform_probe near the end of kgsl.c:

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;
}

Just cut off the end after guessing a safe value, and hopefully it will change.

EDIT2: pdev is set before kgsl is initialized. I have no idea where the above function is called from, but the frequencies are still interceptable right there.
[Nexus One Android Development] IOInterrupt:
I talked about this section of code a couple of pages back. The kgsl_platform_probe() function is a device initialization function. It is called as soon as the driver is loaded.

pdev is basically a pointer to platform_device structure (as defined in include/linux/platform_device.h)
[Nexus One Android Development] storm99999:
Sorry, I just noticed that, I tend to skim.

The part I highlighted is where we don't have to worry about any driver structures or pointers. This is the one point where one data structure transfers the data to the driver as an integer.

I can't actually test it, but replacing that above segment with:

if (pdata) {
kgsl_driver.clk_freq[KGSL_AXI_HIGH_3D] = 128000000;
kgsl_driver.clk_freq[KGSL_AXI_HIGH_2D] = 128000000;
kgsl_driver.clk_freq[KGSL_2D_MIN_FREQ] = 256000000;
kgsl_driver.clk_freq[KGSL_2D_MAX_FREQ] = 256000000;
kgsl_driver.clk_freq[KGSL_3D_MIN_FREQ] = 386000000;
kgsl_driver.clk_freq[KGSL_3D_MAX_FREQ] = 386000000;
}

would work, though the numbers are shots in the dark, and we may still be hardware limited here.
[Nexus One Android Development] dogiedogie:
Guys just a heads up, I would strongly recommend you DONT touch the bus unless you are absolutely sure that is the only thing linked into it. In computing (my area), multiple systems are linked to even the 'gpu' bus, and we could seriously screw something as random as bluetooth while moving that, as it will force any linked systems to OC as well.
[Nexus One Android Development] pzumk:
interesting. Keep up the great work!
[Nexus One Android Development] intersectRaven:
Couldn't get this to boot up. :( The kernel throws an oops everytime. Anyways, I'll just wait for the more learned developers here port it. :)
[Nexus One Android Development] Geniusdog254:
I think it's because the Qualcomm kernel doesn't have the Nexus board files. I'm gunna try and migrate the files into my working kernel & see if it'll boot.
[Nexus One Android Development] Dany0:
Yay! We're getting somewhere ^^
[Nexus One Android Development] jlevy73:
I spent a number of hours last night and this morning on the kernel and couldn't get it to boot. Have you had better luck with it?
[Nexus One Android Development] intersectRaven:
I integrated the driver into my .34 kernel so I don't think that's the problem. Anyways goodluck on your attempt! :)
[Nexus One Android Development] eViL D::
Any noticeable differences?
[Nexus One Android Development] intersectRaven:
Please define noticeable. :p Usual problems are present like the kzalloc thing and some deprecated functions. Anyways, I just had an idea as to why my port isn't working and am going to try it now. (even though it's just 5 in the morning here...) :p
[Nexus One Android Development] IOInterrupt:
You seem pretty vague about exactly what you have done..... Did you compile the QualComm provided source into your kernel? Did you even make any changes to the source?
[Nexus One Android Development] IOInterrupt:
The default of ebi1 is 128mhz correct? I don't see where that is specified within the qualcomm source, but I do see where that is set within the android KGSL code. Check into drivers/video/msm/gpu/kgsl/kgsl.c. This may already be where GD tried making his initial modifications.

I have started to think we should be able to directly manipulate the Kernel GSL code if needed. After all pdata which sets the clock frequencies simply refers the platform_device structure that is defined by KGSL. If we could simply add onto KGSL to watch for modifications, we could watch and negate any changes to the frequencies set by the gpu drivers.
[Nexus One Android Development] intersectRaven:
I copied the drivers/gpu/msm folder into my source and fixed any compile errors by applying known changes (like including slab.h for kzalloc errors) and using the new clock interface instead of the previous one (which is going to be returned in .35). In answer to your questions, yes to both. :)

*also the dmac functions

**I just finished my hunch and it still won't boot... :(
[Nexus One Android Development] IOInterrupt:
Thanks for the clarification. Did you run any benchmarks after changing clock speeds?
[Nexus One Android Development] Domskibus:
Really exciting to read this stuff.:)

Good luck!
[Nexus One Android Development] dogiedogie:
Me too, shame its all in gibberish to us xD
[Nexus One Android Development] cabbieBot:
Pardon my ignorance, but from what I understand, the FPS issue on the EVO (i know this is on a nexus board) is possibly related to HTC not ponying up for the qualcomm drivers. If they released the drivers, is it possible this makes it easier for ya'll to break the 30 FPS cap?
[Nexus One Android Development] :
You might want to look at the acer liquid E gles drivers, we get 16.3fps on nenamark1 gles 2 benchmark, phh has a theory that our drivers might have an OC code, that acer implemented for the liquid E, try contacting him about it.
[Nexus One Android Development] tolis626:
Hey guys,I found out just today what you've been doing and am really fascinated.Well done!

I am currently an owner of a Hero but will get a Desire soon and might hop in the dance.I might not be of much help here,my programming knowledge is limited to making the turtle move in MicroWorlds! :p

But this seems to be more a Linux than an Android kind of thing.What I would do is to contact a Linux dev and ask for help.These guys can work wonders,trust me.They helped me make my old,crappy PC running like a 2000 euro modern PC.

Also,there are many skilled devs here in XDA which I believe would gladly help as everyone would like to be able to squeeze the best performance out of their device.Try to PM them and ask for help,I'm sure they won't deny it!

I will only try a practical and much theoretical approach.In a PC,if you try overclocking the CPU there are 2 alternatives,scaling the multiplier or the FSB.If you scale the multiplier you only overclock the CPU and can overclock until the CPU itself limits you.But if you scale the FSB you overclock the whole system.What I would try would be scaling the Snapdragon's FSB(or whatever there is here) by a very small percentage(like 5%) and see what happens.Just a thought though!

Anyway,great work guys!Keep it up!Keep working wonders and..Keep walking! :p

PS:My English might be good enough but I suck at using technical terms so forgive any mistakes I might have done.And for god's sake,don't try this at home! :p
[Nexus One Android Development] coolbho3000:
The Liquid does do significantly better in OpenGL ES benchmarks. From a quick look, though, there doesn't seem to be a difference (in terms of clock speed). It might have other optimizations.
[Nexus One Android Development] dogiedogie:
Any 3-5% is a good 3-5% :) Its nice to identify the areas we can work on:

1) Direct clock increasements

2) Energy optimisations, undervoltaging

3) OpenGL coding

4) (different?) optimisations from the Liquid
[Nexus One Android Development] kenfly:
Educational purposes

Sorry if this is in the wrong forum butI'd like to ask anyone something.

Where would I begin to learn to do the things you fine gentlemen are doing right here, with development and drivers, kernels and such. I will be starting a computer science major in college and would like some sort of head start. Advice would be GREATLY appreciated.

-Ken

PS: Keep up the good work!
[Nexus One Android Development] IOInterrupt:
To be honest a couple of us are just winging it and diving straight into the code, but we also have experience with other languages
[Nexus One Android Development] storm99999:
Well, if anyone wants to look at the Liquid E drivers, check here:

http://global-download.acer.com/GDFiles/Document/App.%20Guide/App.%20Guide_Acer_1.0_A21E_A.zip?acerid=634129635838372198&Step1=Smart%20Handheld&Step2=Liquid&Step3=Liquid%20E&OS=a02&LC=it&BC=Acer&SC=EMEA_17

That's the kernel source from the Liquid E straight from Acer.

I'll be poking around a bit to see what I can find.

EDIT:

Alright, I checked it, the clock.c is waaay different. The clocks are explicitly defined, etc, it's a lot easier to work with. All the clock functions are exported and not locked off. I think if we can't import the other driver, the Acer driver looks far better. Lastly, I'm not sure, but I think the GPU is overclocked from 256 to 445mhz. I'll check KGSL right quick to know.

EDIT2:

It uses the new KGSL, so I guess we can use it as a reference implementation, though we may still have board code problems. Good news is that it looks like the new driver is very likely to give us a solid improvement.
[Nexus One Android Development] IOInterrupt:
Pardon my ignorance, but I haven't looked at the acer drivers. Exactly what hardware are these drivers for? I presume the Snapdragon gpu? I'm rather interested, but not at my computer atm.
[Nexus One Android Development] Geniusdog254:
Yes they are for Snapdragon hardware. Interestingly enough, it's only clocked at 768mhz, but it apparently is also a different production die, since it is as unstable at 1ghz as we are at 1.267ghz. Its obviously designed differently, so it could have a different GPU although that would be strange. I find it difficult to believe that Acer (who won't move nearly as many devices as HTC could) could convince Qualcomm to run a special production just for them, but it obviously happened.

Also, sorry for not being so active on this project as of late. Its been a holiday weekend and I've been enjoying real life spending time with family & friends, but tomorrow I should have time to look at this. I've also been having 4G problems on my Evo that I'm trying to fix, but it'll have to be swapped. I'll check it out tomorrow though, in between working on the new Evo kernel source that was just released, and planning a paintball retreat with some buds for next weekend.
[Nexus One Android Development] Geniusdog254:
Hate to double post here, but just read the last page. Sorry :o

Nice to see you on here coolbho, what do you think of the new drivers?

If the GPU is actually clocked at 445 that would definitely explain it, but I find it hard to believe that they would clock it that over the recommended values. I could understand maybe ~350 or in that range, but almost doubling the speed of all the other Snapdragon GPUs seems like a stretch to me. Just my $.02

I'll download the Liquid source tomorrow and check it out. Most of my work for now will be on the Evo kernel, since we now have full source for it, but I'll still work on the Nexus kernel every so often. This code is pretty much interchangeable anyway.
[Nexus One Android Development] storm99999:
I'm actually certain I was wrong. I was looking at the clock table for the MSM7x27's. However, the block I identified a bit back is still available to use in the Acer code. Too bad the mahimahi board files are missing here too.

Another tidbit:

/* Only increases to max rate will succeed, but that's actually good
* for debugging purposes. So we don't check for error. */

found in the set clock rate debug code. If this is universal, that would explain why in the current code changes don't happen. We're setting the minimum rate, not the max, and it appears there's bugs once we go beyond the default.

In addition, there's a function clk_round_rate that maybe I didn't notice in the past code, but since we do not know what clocks are supported, we can use this function to round it off to one that is. I hope that it doesn't round to only used/non-oc values.
[Nexus One Android Development] charnsingh_online:
One advice. Almost everything has a maximum cap whether u take CPU clock speed camera resolution. U can only go beyond if u extend that cap. Same is true for gpu. I haven't done a lot of research on it but there is cap somewhere which doesn't let u go beyond it
[Nexus One Android Development] Geniusdog254:
I would think it would only round to the stock values. Why go through the work of coding in values that will never be used in a release kernel? I bet if we set it higher than the stock with that function, it'll round back down to stock.

Where is that function defined?

I'll look into that. I think so far our best bet is figuring out msm_proc_comm to write directly to the hardware instead of relying on HTC code that is gunna round us back down. AFAICT, doing that should let us keep the clock set how we want.
[Nexus One Android Development] :
The acer liquid A1/E have a standard underclock snapdragon scorpion cpu, same as any other qsd8x50 device.
[Nexus One Android Development] storm99999:
The function is defined in the Acer clock.c source. I just thought that if it could round using an algorithm instead of a table, we'd be able to find acceptable clock speeds once we get access instead of guessing. However, in clock-pcom.c we have:

/* Not really supported; pc_clk_set_rate() does rounding on it's own. */

In the same file, clk_ops is defined to say that any clk->set_max_rate() calls pc_clk_set_max_rate which calls msm_proc_comm directly with no interference. The only point of pc_clk_set_max_rate is to capture any errors and report them on the logs.

clk->set_max_rate() is used in the function clk_set_max_rate() in clock.c which has its symbol exported. So, with the CodeAurora driver, we'd be calling msm_proc_comm in a user friendly way, as a nearly direct call (with error correction of course) is already used in kgsl.c.

Now, this gets into the problem of what we can actually do. The new driver supports accessing the clock in a very clean way and, according to tests, using this driver as is already confers a massive improvement in speed. There's two problems however. We'd have to figure out how to port it, which won't take too long. We have the engine, we have the chassis, we just got to figure out the transmission. The other problem is where is the user space portion? No source has a nice convenient binary blob. Will it only become available after the Liquid E gets rooted? Or do I just not understand how this works (likely)?

The other route is simpler but with fewer rewards. We just get the current source, find out how to export the clk_set_max_rate() call to kgsl.c, and set it from there. That would give us msm_proc_comm() access. We then just need to find out how to set it and update it whenever an interrupt requests the driver to change state. The downside is that we won't get the advantages of the new driver and we'd have to subvert hidden functionality.

I wish I knew how to set up a working kernel, I'd be a lot more helpful that way.

EDIT:

EDIT2: Made new post, seemed more appropriate.
[Nexus One Android Development] Geniusdog254:
By new driver do you mean the new QCOM stuff or the Acer ones? If we figured out what file we needed, we could get someone with a Liquid E to ADB pull it. It wouldn't be that difficult.

As for method two, we wouldn't really have to export the clk_set_max_rate function would we? I still haven't figured out the whole EXPORT_SYMBOL thing lol. Couldn't we just use msm_proc_comm directly instead of through clk_set_max_rate? Sure theres no error catching, but that way we avoid the whole export_symbol thing. I could be wrong though.

EDIT: Stupid me. pc_clk_set_rate just directly calls msm_proc_comm anyway. I'm tired and over my head here lol.

If you want to set up a kernel, I recommend reading this. It's really simple to follow and will get you a working kernel within a couple hours depending on your connection speed.

Also, I did some more looking at code, even though we seem to know what we need to do now and it's just how to do it. Even so, in devices.c I found this. It's not directly relevant, but it seemed interesting nonetheless: http://pastebin.com/T8CrECyp

Sorry for the pastebin, but it's pretty long.
[Nexus One Android Development] storm99999:
From last post:

Alright, I think I figured out the EXPORT_SYMBOL system. After a function is defined, you EXPORT_SYMBOL(function_name); at the end. For whatever module you want to use the symbol, you just have a constructor. All the ones kgsl uses are defined in $kernel_dir/include/kernel/clk.h . I think. If this doesn't work, the other two methods I've found is to put extern before the constructor and modify the Kbuild files. Examining the one linked to clk.h gets me nowhere.

Anyways, the Acer Liquid E uses the new qualcomm drivers, they're very similar as far as I see, just Acer's is implemented which is a slight advantage.

And on the Cyan source guide, I tried that, typed make, and it instantly spit out an error message that I couldn't google. I did have it set up for cross compiling. It may have just been a broken build and I'll resync my source tonight.

Most interesting from your pastebin, there's two EBIs. I wonder what the second's linked to. Second most is that the codecs look like they have a clock. Hmm...