LEGION MODZ
I have enabled a lock on this site to keep trollz out. This is a team of Android hackerz that believes in teamwork. So, Kinfolk if you wouldn't mind, please register and log in and help us grow. A.S.A.P...
LEGION MODZ
I have enabled a lock on this site to keep trollz out. This is a team of Android hackerz that believes in teamwork. So, Kinfolk if you wouldn't mind, please register and log in and help us grow. A.S.A.P...
LEGION MODZ
Would you like to react to this message? Create an account in a few clicks or log in to continue.

LEGION MODZ

We Are Legion
 
HomePortalGalleryLatest imagesSearchRegisterLog in

 

 tut on oc and undervolting

Go down 
AuthorMessage
WARP3D420\Admin
BIG DOG STATUS
BIG DOG STATUS
WARP3D420\Admin


Posts : 195
Points : 3003999
Thanks : 7
Join date : 2014-01-02
Age : 46
Location : In da Swamps

tut on oc and undervolting Empty
PostSubject: tut on oc and undervolting   tut on oc and undervolting Icon_minitimeMon Jan 13, 2014 5:55 pm


tut on oc
by guevor

The system uses a series of programmed pll clocks which in turn can be used as a basis to other clocks. Let's say for this case pll_x is used for the base of processor clock.
The frequency table are in tegra_pll_x_freq_table processor. Seeing the type definition clk_pll_freq_table in clock.h we know that has entries consisting of 6 values​​. (input_rate, output_rate, n, m, p, cpcon)
These values ​​allow tegra2_pll_clk_set_rate function to set the pll frequency.
The values ​​of interest are the frequency of input and output that indicates the input frequency base to be used and what frequency we want to set (it will use the frequency corresponding to the current base and the output frequency we want). m * p values ​​give us the divisor and n is the multiplier. For simplicity we say that n/(m*p) will give us the multiplier, which applied to the base frequency will give the target frequency.

So if we want to add new frequencies, we must add entries in this structure (tegra_pll_x_freq_table) so the system knows how to program a frequency we want to use.
Add 4 entries for each frequency we want to add (one for each base frequency: 12000000,13000000,19200000,26000000 in our case), with multipliers/dividers to calculate the frequency for which we are adding.

If we add higher frequencies than at present, we have to change the maximum (max_rate) in the tegra_clk_virtual_cpu and tegra_clk_cclk structures, otherwise the system will ignore it. Also have to change the limits for our type of processor in sku_limits. For this case the cpu, cclk y pll_x in the values ​​for our processor (0x04, 0x08, 0x0F).

Finally we modify the table of frequencies used by the processor (frequency list and their order). Is defined at cpufreq_tables and contains a list of lists where we can add a new list or not to touch anything and modify an existing list.
We can look at the existing list freq_table_1p2GHz or in my source I added the list freq_table_1p7GHz.
Contains a list of frequencies that the system can select. It uses the list whose maximum corresponds to the maximum indicated above.


tut on under-volting
by guevor

This part is much more sensitive and therefore can affect much to the duration of the battery as to stability. I have no formula (unfortunately for me) on how to modify the values, so the task has been more trial and error.
The first thing to know is that one must distinguish between the core voltage and the cpu and should be the latter inferior to the first. In tegra2_dvfs_rel_vdd_cpu_vdd_core function establishes the relationship between the two, being the default 120mV core above the cpu.
Basically what we do if we have added frequencies higher than normal, is to increase the voltage so that they are stable (depend on each processor). I recommend (at first) increment in the same extent all the values ​​involved (maximum voltage).

Therefore we can modify:

Table core_millivolts, establishing the voltages that core can use.

Table cpu_millivolts, establishing the voltages that cpu can use. It contains all the steps and should take into account the difference with the core discussed earlier. If we added any frequency, we add the corresponding voltages.

Tables core_speedo_nominal_millivolts and cpu_speedo_nominal_millivolts contain a nominal voltage of both the core and the cpu.

The maximum and nominal voltages in structures tegra2_dvfs_rail_vdd_cpu, tegra2_dvfs_rail_vdd_core and tegra2_dvfs_rail_vdd_aon.

Finally we adjust the settings for dvfs_init ("cpu", 1,) according to the list of frequencies we want to use (adding if we added new frequencies or changing them if changed change some)

With these changes we should be able to overclock, although we know that although you can configure (once started) a maximum frequency below the maximum that we put on the tables, there is a problem and many times after suspending the system will use the maximum frequency of the table. To avoid this we must make some changes in cpufreq.c

patch for drivers/cpufreq/cpufreq.c

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e157205..2626e2d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1048,18 +1048,27 @@ static int cpufreq_add_dev(struct sys_device *sys_dev)

/* Set governor before ->init, so that driver could check it */
#ifdef CONFIG_HOTPLUG_CPU
+ struct cpufreq_policy *cp;
for_each_online_cpu(sibling) {
- struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling);
+ cp = per_cpu(cpufreq_cpu_data, sibling);
if (cp && cp->governor &&
- (cpumask_test_cpu(cpu, cp->related_cpus))) {
+ (cpumask_test_cpu(cpu, cp->related_cpus))) {
+ dprintk("found sibling CPU, copying policy\n");
policy->governor = cp->governor;
+ policy->min = cp->min;
+ policy->max = cp->max;
+ policy->user_policy.min = cp->user_policy.min;
+ policy->user_policy.max = cp->user_policy.max;
found = 1;
break;
}
}
#endif
if (!found)
+ {
+ dprintk("failed to find sibling CPU, falling back to defaults\n");
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
+ }
/* call driver. From then on the cpufreq must be able
* to accept all calls to ->verify and ->setpolicy for this CPU
*/
@@ -1071,6 +1080,16 @@ static int cpufreq_add_dev(struct sys_device *sys_dev)
policy->user_policy.min = policy->min;
policy->user_policy.max = policy->max;

+ if (found)
+ {
+ /* Calling the driver can overwrite policy frequencies again */
+ dprintk("Overriding policy max and min with sibling settings\n");
+ policy->min = cp->min;
+ policy->max = cp->max;
+ policy->user_policy.min = cp->user_policy.min;
+ policy->user_policy.max = cp->user_policy.max;
+ }
Back to top Go down
https://legionmodz.forumotion.com/u1
 
tut on oc and undervolting
Back to top 
Page 1 of 1

Permissions in this forum:You cannot reply to topics in this forum
LEGION MODZ :: EXTRA$ :: ANDROID HACKING 101-
Jump to: