[Nexus One Android Development] Jack_R1:
Ok, here it is. This might be a bit long, but it also might be useful for kernel devs and other people dealing with low level code / HW functionality.

intersectRaven in his first post in this thread was the closest to the reason, why overclocking in any way that's not dependent on global overclock is not going to be possible. I checked deeper, and unfortunately, that's the news.

I'd like to expain, what are the clocks in VLSI Design and how are they generated, to help some developers that aren't familiar with the concepts. There are quite a few posts in this thread that show lack of understanding of those concepts, which leads to suggestions for trying absurd things (which add headache for those that are trying). The clock isn't magic, and it doesn't get its frequency from the air or from SW commands (well, not exactly). Knowing how the clocks work contributes to knowing how to work with them (which can be said about mostly anything in embedded programming, a good embedded SW Engineer should know HW very well).

I won't explain, what is a clock and why it's needed, so I'll start with the clock tree. There are 2 things that can be meant by it - either physical implementation of a single clock spreading across the chip, or clock hierarchy tree. I'll focus on the latter, since the former is just a matter of physical design.

The clock is born from a crystal, or a crystal oscillator. It's born with a frequency which is a physical property of the crystal. Mostly the frequency is relatively low, so to make it usable, we need to multiply it. This is done with PLL.

PLL - Phase Locked Loop. There are few of those in the design, most or all stand as primary sources. The reason is simple - PLLs need time to lock and can't be turned on/off freely, and clocks that toggle constantly - consume power. So, the source of the clock hierarchy generally looks like the diagram on Wikipedia page:

But, not all the devices in the same chip use the same frequency. Take a PC, for example: one frequency to CPU, the other to memory, the third to PCIe/AGP/PCI buses, another to the graphic chip (or generated on the card, if it's external). And these are relatively few clocks, each of the devices uses many more clocks, part of which it generates internally. So how are they generated? Either with additional PLLs as shown above, or - mostly - with clock dividers.

At the end point of each branch of clock hierarchy tree there can be either consumer of the current clock, PLL, or clock divider - with the trade-off between PLL amount and average power consumption. In devices made with power saving in mind, there will be very few PLLs inside the tree.

Dividers do just that - divide the clock. There are 2 types - M/N counters that allow choosing almost any frequency by setting M and N (but they're still dividers, not multipliers, so they can't bump the frequency up), and simple dividers that allow choosing between one of the predefined division values. M/N counters are used for specific sources that need fine clock control.

So, let's say we have a tree like the one on the left:

In this example A is a PLL, C, D, F are its consumers, B, E, G are dividers. Under B there is a sub-tree with consumers H, I and divider G with its consumers M, N. Under divider G there is a consumer L, and under divider E there are 2 additional dividers J and K with their respective consumers O and P.

So looking at this example, the frequency of M, for example, depends on the global PLL frequency (A), B divider value, and G divider value.

Each of those dividers will divide the clock that it receives, either by one of the predefined rates, or by M/N rate.

And this is how you get clocks in HW.

All that SW sees from it, on a high level of abstraction, is a completely flat structure with a function to get and to set each clock, taking a frequency as one of the parameters. But as you can see, it doesn't work like that in HW, so whatever the SW does is irrelevant. It either gets translated to specific settings for some or all of the dividers, or dropped.

Some examples:

1) Let's try to make M and N run different frequencies. Is it possible? In SW view - of course, they're just executing a function that sets clock rates for both of those clock while giving different values, and expecting it to work. But, as it's obvious from the picture, this is not possible in HW, so the clocks won't be different. What frequency they end up with is dependent on the implementation of low level drivers, but their resulting frequency will be the same in any case.

2) Let's try to make N run higher frequency than H. Is it possible? Again, SW view doesn't provide the whole picture, because unless G is a PLL - there is no way to set it to multiply the input frequency, and everything under it will certainly be no faster than B's frequency. In the best case, N will be equal to H.

3) Ok, so is it possible for G and J to run different frequencies? Yes, absolutely, since they're both sitting under A, but connected to different dividers. But still, changing the frequency for G will also change the frequency for H and I, and will also affect M and N which are below G.

I hope this was helpful.