• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [KERNEL] TheOC v1.7.20 kernel for MT Isaac & TG based CM7

I was just trying to test this out last night with Current Widget, and it seems that idling at those frequencies don't seem to matter, so picking 245 would be better. But I'd like to do some testing where it's under load and executing code at those frequencies to be sure.

It isn't specific to this phone, but I've seen a thread on another forum for the optimus V that showed some really good scientific (closest thing anyway) results for this.
 
What I ment is, sence I loaded the ROM and the kernel under an outdated clockwork, is there a reason to reapply anything. I haven't noticed a problem yet.
 
What I ment is, sence I loaded the ROM and the kernel under an outdated clockwork, is there a reason to reapply anything. I haven't noticed a problem yet.

I'd say, if you're not having any issues, then I wouldn't mess with it. If you start running into issues, then I'd say your first step would be do a wipe and reflash everything at that point. But for now, I'd say just go with what you have. Unless of course, you feel like redoing everything. :D
 
On my phone, when I was doing my original testing, I was only changing the voltage on one frequency at a time. Basically, my phone just doesn't seem to have the same flexibility in voltage range as yours. :( You wanna trade? LOL. :D

Tempting offer, but I'll pass ;)

I'm back to this kernel after trying bKernel for a couple of days, that one has some extra battery drain going on (even though it goes into deep sleep too according to CPU Spy), maybe about 1-2%/hr drain even in airplane mode.

Currently (pun intended) I'm undervolted to 700 mV w/ Interactive 245-1024 Mhz and have been 24 hrs since full charge and still 93% left (half of that was airplane mode), airplane mode has almost zero drain, and even with just cell radio on, it's less than 0.2%/hr I believe (screen on reports 70-80 mA, probably all due to the LCD backlight).

So can the next version allow undervolting to less than 650 mV or is that a hard limit with the chipset?
 
Back to my suspiscions of my 700 mV values... I just tried to monitor how much current it's drawing after fresh reboot (default voltage levels), and then after I decreased them to 700mV using IncrediControl & hit apply. Running 245-1024 Mhz Interactive governor, Before spike is default voltage, after spike is supposedly 700 mV.

screenshot1323638950975.png


Can anyone else verify this? Use Current Widget, run the Stability Test app for 10 minutes at regular voltage and undervolted. There should be a current draw difference between the two, but I'm not seeing it.

UPDATE: Actually now that I think about it, the voltage wouldn't show up in the current. Power = I * V, so the final power may still be lower (that requires a different kind of measurement). Is there even a voltage reading in Android?
 
Back to my suspiscions of my 700 mV values... I just tried to monitor how much current it's drawing after fresh reboot (default voltage levels), and then after I decreased them to 700mV using IncrediControl & hit apply. Running 245-1024 Mhz Interactive governor, Before spike is default voltage, after spike is supposedly 700 mV.

screenshot1323638950975.png


Can anyone else verify this? Use Current Widget, run the Stability Test app for 10 minutes at regular voltage and undervolted. There should be a current draw difference between the two, but I'm not seeing it.

UPDATE: Actually now that I think about it, the voltage wouldn't show up in the current. Power = I * V, so the final power may still be lower (that requires a different kind of measurement). Is there even a voltage reading in Android?

I've been looking for a way to measure and there are no apps at this time that I've found yet that measure the voltage at the CPU which is where the vdd level is, I think. All the voltage measurements info that I see are only at the battery which isn't accurate for this purpose.

However, I definitely see an effect when I change it too low by my phone locking up and rebooting. Looking at the regulator code though on some other 7x30 phones seems to indicate that the voltage min by default is 800 and if it goes below that, that code returns einvalu.

I'm doing testing now to see if there's any effect if I try lowering that. I did try 600 but I get reboots every time that I hit deep idle. So I'm raising that again.
 
I've been looking for a way to measure and there are no apps at this time that I've found yet that measure the voltage at the CPU which is where the vdd level is, I think. All the voltage measurements info that I see are only at the battery which isn't accurate for this purpose.

However, I definitely see an effect when I change it too low by my phone locking up and rebooting. Looking at the regulator code though on some other 7x30 phones seems to indicate that the voltage min by default is 800 and if it goes below that, that code returns einvalu.

I'm doing testing now to see if there's any effect if I try lowering that. I did try 600 but I get reboots every time that I hit deep idle. So I'm raising that again.

I guess I haven't reached the limit on my processor yet. Are you saying that in the code any value lower than 800 may just be set to 800? That might explain why I can even run 1024 Mhz at "650 mV" (it may just be 800 mV internally).
 
I guess I haven't reached the limit on my processor yet. Are you saying that in the code any value lower than 800 may just be set to 800? That might explain why I can even run 1024 Mhz at "650 mV" (it may just be 800 mV internally).

Yes. That's what it's looking like to me, unless I'm misreading the voltage regulator code.
 
Yes. That's what it's looking like to me, unless I'm misreading the voltage regulator code.

arch/arm/mach-msm/acpuclock-7x30.c

Code:
...
#define SEMC_ACPU_MIN_UV_MV 650U
#define SEMC_ACPU_MAX_UV_MV 1525U
...
void acpuclk_set_vdd(unsigned int khz, int vdd)
{
    int i;
    unsigned int new_vdd;
    vdd = vdd / V_STEP * V_STEP;
    mutex_lock(&drv_state.lock);
    for (i = 0; acpu_freq_tbl[i].acpu_clk_khz; i++)
    {
        if(acpu_freq_tbl[i].use_for_scaling==1)
        {
            if (khz == 0)
                new_vdd = min(max((acpu_freq_tbl[i].vdd_mv + vdd), SEMC_ACPU_MIN_UV_MV), SEMC_ACPU_MAX_UV_MV);
            else if (acpu_freq_tbl[i].acpu_clk_khz == khz)
                new_vdd = min(max((unsigned int)vdd, SEMC_ACPU_MIN_UV_MV), SEMC_ACPU_MAX_UV_MV);
            else continue;


            acpu_freq_tbl[i].vdd_mv = new_vdd;
            acpu_freq_tbl[i].vdd_raw = VDD_RAW(new_vdd);
        }
    }
    mutex_unlock(&drv_state.lock);
}
It looks like it would set whatever is defined as the lowest SEMC_ACPU_MIN_UV_MV (650), if lower than 650, it'll set to 650. Is this the right file? Where would the 800 value come from?
 
arch/arm/mach-msm/acpuclock-7x30.c

Code:
...
#define SEMC_ACPU_MIN_UV_MV 650U
#define SEMC_ACPU_MAX_UV_MV 1525U
...
void acpuclk_set_vdd(unsigned int khz, int vdd)
{
    int i;
    unsigned int new_vdd;
    vdd = vdd / V_STEP * V_STEP;
    mutex_lock(&drv_state.lock);
    for (i = 0; acpu_freq_tbl[i].acpu_clk_khz; i++)
    {
        if(acpu_freq_tbl[i].use_for_scaling==1)
        {
            if (khz == 0)
                new_vdd = min(max((acpu_freq_tbl[i].vdd_mv + vdd), SEMC_ACPU_MIN_UV_MV), SEMC_ACPU_MAX_UV_MV);
            else if (acpu_freq_tbl[i].acpu_clk_khz == khz)
                new_vdd = min(max((unsigned int)vdd, SEMC_ACPU_MIN_UV_MV), SEMC_ACPU_MAX_UV_MV);
            else continue;
 
 
            acpu_freq_tbl[i].vdd_mv = new_vdd;
            acpu_freq_tbl[i].vdd_raw = VDD_RAW(new_vdd);
        }
    }
    mutex_unlock(&drv_state.lock);
}
It looks like it would set whatever is defined as the lowest SEMC_ACPU_MIN_UV_MV (650), is this the right file? Where would the 800 value come from?

That's not it. Here's what I just found out today and am looking at:

Code:
/* Supported voltage values for regulators */
static const u16 VDCDC1_VSEL_table[] = {
 800, 825, 850, 875,
 900, 925, 950, 975,
 1000, 1025, 1050, 1075,
 1100, 1125, 1150, 1175,
 1200, 1225, 1250, 1275,
 1300, 1325, 1350, 1375,
 1400, 1425, 1450, 1475,
 1500, 1525, 1550, 1600,
};

From tps65023-regulator.c
 
That's not it. Here's what I just found out today and am looking at:

Code:
/* Supported voltage values for regulators */
static const u16 VDCDC1_VSEL_table[] = {
 800, 825, 850, 875,
 900, 925, 950, 975,
 1000, 1025, 1050, 1075,
 1100, 1125, 1150, 1175,
 1200, 1225, 1250, 1275,
 1300, 1325, 1350, 1375,
 1400, 1425, 1450, 1475,
 1500, 1525, 1550, 1600,
};
From tps65023-regulator.c

Ah... well I say add a few more values to match SEMC_ACPU_MIN_UV_MV. I want to see how low it can go on my phone :) Who knows maybe newer MT chips have better yields and can handle it.
 
As for your first swipe sometimes being ignored, it sounds like the phone/kernel is still in the process of waking up from sleep at those times and is just lagging.

BTW, I'm still noticing this, and not just on waking up. I'm not saying it's a specific issue to this kernel, could even be Moto's drivers. See my poll here:

http://androidforums.com/motorola-triumph/462062-do-you-have-touchscreen-issues.html

UPDATE: I have a workaround, basically zeroing out all the CM settings - Input - Haptic feedback tweaks.
 
I'm excited for the next update!! HAVS will rock! Mantera, will you post a voltage table like you did for the SVS as a guideline?
 
I'm excited for the next update!! HAVS will rock! Mantera, will you post a voltage table like you did for the SVS as a guideline?

Everyone's processor will be different. Just make sure you don't have critical data that isn't unsaved. Make a Nandroid backup and try to push the limits & test stability (undervolting is safer than overclocking/overvolting), once that's set write it down, it'll be your personal voltage table.
 
Everyone's processor will be different. Just make sure you don't have critical data that isn't unsaved. Make a Nandroid backup and try to push the limits & test stability (undervolting is safer than overclocking/overvolting), once that's set write it down, it'll be your personal voltage table.

Thanks, that makes sense.
Since I've only used SVS kernels I'm only used to setting a specific voltage for each frequency.
I understand HAVS has a "range" for each frequency and I'm not sure about how wide that range should be, since I have not experimented with undervolting in that way yet. I understand HAVS typically has a lower battery consumption so I look forward to trying it out.
 
I've been away from the forums for a while, so forgive my ignorance. What is Isaac's updated touchscreen driver that I've been reading about? Is that just the driver to get it to work with ICS or does it actually improve the touchscreen?
 
I have another set of noob like questions if anyone would like to take a poke.

First I just wanted to check that I understand the conversation above correctly in that if a voltage is selected lower than 800 such as 750 the Triumph will use 800 by default and never actually use the 750 value after it has been applied?

Second as most of this forums regulars probably are aware I am a huge fan of the Auto-killer app. The question here is that I have been looking around trying to find what it is exactly the apps settings under Advanced System Tweaks are actually doing.

Link to developers limited explanation of what these tweaks do.

AutoKiller Memory Optimizer - AndRS Studio

basically I am trying to figure out things like does the IO Scheduler Tweak change the IO scheduler or just tweak what is currently set and if any of these tweaks are already worked into this Kernel and can applying any of these tweaks mess with any of the Kernels customizations. I have had set the tweaks for IO Scheduler, Memory management, Battery and Scheduler and have noticed an increased in overall performance but would like knowing it’s not just all in my head. I do know the SD-card tweak increases the SD Cache from 256 to 2048 but I have already used an app to adjust the cache size and found it performed best running tests with an app called SD-tools set at 512 without any noticeable difference going any higher so the 2048 number seems a bit overboard. Anyhow I figured it couldn’t hurt to ask as I have found the advice from some of the regulars on this forum to be very reliable compared to what I read in other places.

Edit: Almost forgot about number 3. I have been using my current settings for over a month now and have found that my setCPU Temperature profiles are not necessary I would like to move away from the app and use the CM7 settings using smartass to eliminate the need for my screen off profile. The issue I’m having doing this is I have recently become a huge fan of Google music and find I have playback problems when my screen is off using smartass so have been using setCPU with ondemand and a max frequency of 368 as a screen off profile as anything under 368 seems to cause playback issues. Has anyone else had this issue? I could bump up my min frequency from 122 to the 368 frequency Google music seems to like without any playback issues but not ready to give up the savings in battery life, any ideas?
 
I've been away from the forums for a while, so forgive my ignorance. What is Isaac's updated touchscreen driver that I've been reading about? Is that just the driver to get it to work with ICS or does it actually improve the touchscreen?

I was curious about that too since I've had touchscreen ignoring actions once in a while (frequent enough to be annoying, but still responsive when it works). Here's Isaac's commits:

https://github.com/ikarosdev/triumph-kernel-msm7x30/commits/2.6.32.9-chaos-MIUI

I'm back to stock TG kernel to see if my touchscreen reliability goes up (So far no noticeable functional differences between before & after Isaac's changes, using Multitouch Visual Test app).

I have another set of noob like questions if anyone would like to take a poke.

First I just wanted to check that I understand the conversation above correctly in that if a voltage is selected lower than 800 such as 750 the Triumph will use 800 by default and never actually use the 750 value after it has been applied?

Yes, unless the lower voltage values are added into the regulator code in a future release.

Edit: Almost forgot about number 3. I have been using my current settings for over a month now and have found that my setCPU Temperature profiles are not necessary I would like to move away from the app and use the CM7 settings using smartass to eliminate the need for my screen off profile. The issue I’m having doing this is I have recently become a huge fan of Google music and find I have playback problems when my screen is off using smartass so have been using setCPU with ondemand and a max frequency of 368 as a screen off profile as anything under 368 seems to cause playback issues. Has anyone else had this issue? I could bump up my min frequency from 122 to the 368 frequency Google music seems to like without any playback issues but not ready to give up the savings in battery life, any ideas?
I recommend just simple Ondemand or Interactive for more of a responsive feel. They don't lock any frequencies, just uses high enough to be able to process whatever is needed in the background (use CPU Spy to check). When screen is off, it should be in deep sleep mode if there isn't anything going on anyway. Also the CPU running at around 500 Mhz draws about 180 mA current, at 1024 Mhz draws 200 mA current, 1.2 Ghz is 220 mA, 1.4 Ghz about 240 mA from some testing I've done. So you get the most "bang for the buck" at 1024 Mhz anyway.

Speaking of deep sleep. I encountered the "can't go into deep sleep while screen is off" bug again. As noticed last night when put the phone into airplane mode.

screenshot1324146783284.png


Notice the deep slope in airplane mode for about 8 hrs (deeper than idling with a cell signal earlier in the night). I did a 'cat /proc/kmsg > /sdcard/log.txt" & put screen to sleep then back on to try to capture the activity. The log is availble here: /proc/kmsg Pastebin.com

So with the touchscreen and deep sleep problem in the v1.5 kernel, I'm going back to TG's CM7 kernel to see if these issues don't exist there. I'll miss the undervolt and other tweaks in this kernel, but like I said, reliability matters more to me right now. I'll write an update post if I notice the same problems in TG's kernel.

UPDATE: Same touchscreen problem & kernel wakelock prevents deep sleep in TG's CM7 kernel, back on TheOC :)
 
Second as most of this forums regulars probably are aware I am a huge fan of the Auto-killer app. The question here is that I have been looking around trying to find what it is exactly the apps settings under Advanced System Tweaks are actually doing.

Link to developers limited explanation of what these tweaks do.

AutoKiller Memory Optimizer - AndRS Studio

basically I am trying to figure out things like does the IO Scheduler Tweak change the IO scheduler or just tweak what is currently set and if any of these tweaks are already worked into this Kernel and can applying any of these tweaks mess with any of the Kernels customizations. I have had set the tweaks for IO Scheduler, Memory management, Battery and Scheduler and have noticed an increased in overall performance but would like knowing it’s not just all in my head. I do know the SD-card tweak increases the SD Cache from 256 to 2048 but I have already used an app to adjust the cache size and found it performed best running tests with an app called SD-tools set at 512 without any noticeable difference going any higher so the 2048 number seems a bit overboard. Anyhow I figured it couldn’t hurt to ask as I have found the advice from some of the regulars on this forum to be very reliable compared to what I read in other places.

Some of the tweaks listed are already in the ROM or kernel:

Readahead: set to 1024 in kernel

IO Scheduler: You probably should be using noop, simple, or vr and not

CFS for best results since we don't have spinning hard disks in a phone.

Partitions: The rom already mounts all the partitions with noatime.

memory management: some of this is already in the v6 supercharger script that people have been posting about in the cm7 thread.

scheduler: not sure how the tweaks are doing this but I assume this only applies to cfq or bfq anyways.

battery: Not sure if the write flush timeouts this mentions is in the rom or battery, so no comment on this.

sleeper: This only applies if you're using the cfs i/o scheduler--which you probably shouldn't be.

The rest of the stuff are controlled in the ROM, i believe, so I'm not sure if they are implemented or not.
 
Ok, same touchscreen issues & kernel wakelock preventing deep sleep in TG's CM7 kernel.

Using "BetterBatteryStats" app, I see that the 3 kernel wakelocks are:

"mmc2"
2 hr 37 m 46 s (9466 s) (Cnt(c/wc/ec)3/0/0 13.2%

"mmc1"
2 hr 37 m 46 s (9466 s) (Cnt(c/wc/ec)3/0/0 13.2%

"mmc0"
2 hr 37 m 46 s (9466 s) (Cnt(c/wc/ec)3/0/0 13.2%

Anyone know what these could possibly point to?
 
Ok, same touchscreen issues & kernel wakelock preventing deep sleep in TG's CM7 kernel.

Using "BetterBatteryStats" app, I see that the 3 kernel wakelocks are:

"mmc2"
2 hr 37 m 46 s (9466 s) (Cnt(c/wc/ec)3/0/0 13.2%

"mmc1"
2 hr 37 m 46 s (9466 s) (Cnt(c/wc/ec)3/0/0 13.2%

"mmc0"
2 hr 37 m 46 s (9466 s) (Cnt(c/wc/ec)3/0/0 13.2%

Anyone know what these could possibly point to?

It looks like it's using battery by reading the partitions constantly.
 
Back
Top Bottom