02-22-2012 04:40 PM
155 12345 ...
tools
  1. mmarz's Avatar
    Thanks for the info!

    I think every kernel/ROM dev (me included) has to relearn these same lessons re: frequency and voltage scaling. This post sums up the situation pretty well:



    Nevertheless people keep clocking down to 122 and rediscovering that it doesn't work.

    People need to read up on the MSM7600 chipset and realize this is an older (when I pulled the datasheet it, was (c) 2006) SoC design, that is a phone-specific cpu from Qualcomm, and some of the things that are possible with the general-purpose ARM cpus that are in most higher-end devices are not with the MSM7627, because stuff like voltage levels is hardwired in (and we can't just port some HAVS patch HTC wrote for a different chipset). Or, put another way, some things are "possible" (i.e. clocking from 480 or 245 down to 122) but there's no benefit and/or bad side effects.

    The good news is that there are some easy wins, like overclocking, disabling features, enabling JIT or reducing the wifi poll interval to save battery.

    I have gone through, built and tested 10x the number of kernel config changes, CFLAGS (fpu-related) and patchsets that I have actually wound up putting into this kernel, and with almost all of it there was either no testable improvement or (usually) a regression of some kind. LG has done a really solid job on the kernel (especially where it really matters for performance, in the cpu-specific MSM arch sections) which I'm sure comes from years of working with this chipset.

    And the community has been hacking on it for a long time, too.
    Does this mean that there are only two voltage levels to choose from 3 or 7? Does this also mean that after 600 MHz, the "choice" is made for you and you cannot force the CPU to level 3 voltage with 806 MHz? Or is the problem that at 806 MHz, the cpu is not stable at the level 3 voltage?

    From empirical testing, I found the most efficient CPU clock scaling is your max speed being set one step below the most stable speed for your phone, and the min speed being set to either 600 MHz or the same speed as the max and not scaling at all. What you just wrote explains why this is the case.

    Great work btw. This info should be stickied or wiki'ed. You know you are going to be getting an undervolt request every week otherwise.
    04-18-2011 12:26 PM
  2. drezliok's Avatar
    This would be great if someone could make it into a flashable zip...
    It took 15 minutes to get the commands and push the file. Don't fear the keyboard.
    04-18-2011 12:33 PM
  3. jmel's Avatar
    Yes lets make everything super easy and flashable so, oh I dunno, it takes no knowledge of how or where to put things via root navigation or adb push commands.
    That's right, because then noobs won't mess it up and flood the forums. Sigh...

    What is the point of your post again???

    I've used adb, and have no issues. I'm just making a suggestion.
    04-18-2011 12:52 PM
  4. picasticks's Avatar
    That's right, because then noobs won't mess it up and flood the forums. Sigh...

    What is the point of your post again???

    I've used adb, and have no issues. I'm just making a suggestion.
    Don't worry, I will just be including this file in the next release of the kernel's zip file, so it will automagically restore everybody's original key map.

    At this point looks like I will be putting that out later today or tomorrow.
    jmel likes this.
    04-18-2011 12:59 PM
  5. mmarz's Avatar
    Don't worry, I will just be including this file in the next release of the kernel's zip file, so it will automagically restore everybody's original key map.

    At this point looks like I will be putting that out later today or tomorrow.
    Can I request it being placed as a separate zip and not included with the kernel? I have my own key map, and I don't want to replace it every time I test your kernel. Just a suggestion.
    04-18-2011 01:12 PM
  6. picasticks's Avatar
    Does this mean that there are only two voltage levels to choose from 3 or 7? Does this also mean that after 600 MHz, the "choice" is made for you and you cannot force the CPU to level 3 voltage with 806 MHz? Or is the problem that at 806 MHz, the cpu is not stable at the level 3 voltage?

    From empirical testing, I found the most efficient CPU clock scaling is your max speed being set one step below the most stable speed for your phone, and the min speed being set to either 600 MHz or the same speed as the max and not scaling at all. What you just wrote explains why this is the case.

    Great work btw. This info should be stickied or wiki'ed. You know you are going to be getting an undervolt request every week otherwise.
    Well, I am not the original source of that post, for which drellisdee gets the credit (not to mention doing all the original LS670 hacking work last year ... I haven't read far enough into the Optimus One to know who got all that started).

    The way I read it is that yes, you're one voltage level for 245-480 and another (the max) at 600 Mhz or higher. I know zefie found the same thing as you when he did all his OC testing in Nov/Dec, that one freq below max worked the best. Personally I have found the same, my phone breaks at 864, and gets max benchmarks at 825.

    I already posted a datasheet link and some of this general info about the 7600 chipset onto an S thread that had gone way deep into to the topic of HD video recording ("we just need some dev to step up and make this, it can't be hard!") without any actual knowledge of anything. It was pretty funny, actually. People seriously wondering why their Corolla wouldn't be able to fly if they just stapled on some cardboard wings.
    04-18-2011 01:17 PM
  7. mmarz's Avatar
    I already posted a datasheet link and some of this general info about the 7600 chipset onto an S thread that had gone way deep into to the topic of HD video recording ("we just need some dev to step up and make this, it can't be hard!") without any actual knowledge of anything. It was pretty funny, actually. People seriously wondering why their Corolla wouldn't be able to fly if they just stapled on some cardboard wings.
    I'm sure you can combine HD video recording with your weekend project to port Adobe Flash to android. Can't be that hard
    04-18-2011 01:25 PM
  8. picasticks's Avatar
    Can I request it being placed as a separate zip and not included with the kernel? I have my own key map, and I don't want to replace it every time I test your kernel. Just a suggestion.
    Yeah, I knew there would be people like you! (see a couple of days ago on the thread, me and obijohn talking about this).

    I agree in principle that it is bad for me to be clobbering people's keymaps. I also think it's pretty ironic considering (AFAIK) my kernel is the only V kernel circulating actually built from the V source, with the correct button map (rather than incomplete ports of S kernels) ... but everybody who has flashed something to swap their button map now flashes my kernel and thinks something is wrong.

    For right now I think I will include the file because it will fix the issue and only negatively affect a small minority (right now, well, you ... welcome to the minority!), who are probably also smart enough to work around it. Sorry. I would hope that people will fix the other kernel(s) and I can pull this "feature" out at some point.

    For sure if I put this in and then everyone says "why are you clobbering my custom keymap!?!?!?!" I will take it back out again.

    A better fix would be to just patch the keymap, I don't know if I could run patch or a sed script or similar, but honestly I don't want to make it that complex and have it possibly break for people. The range of commands you can run in the update.zip is very limited because the filesystems aren't mounted, so you basically have to include binaries for every command you want to run.

    The "right" fix would be to have an sh script check for the bad keymap, if found then run patch, and then depending on the exit code either exit on success or default to clobbering the file only as a last resort. If somebody wants to make that, it would probably only take a couple hours and it would I think be a great addition to the AnyKernel framework which is used by the entire Android community.

    I don't want to get into it (it would be a side project of a side project for a phone I don't own, of a side project of a hobby at that point), but if it's possible/easy to just to a check and not clobber if the keymap is already correct, I might do that.
    04-18-2011 02:20 PM
  9. obijohn's Avatar
    EDIT: oops, posted in he wrong thread.
    04-18-2011 03:36 PM
  10. Eollie's Avatar
    That's right, because then noobs won't mess it up and flood the forums. Sigh...

    What is the point of your post again???

    I've used adb, and have no issues. I'm just making a suggestion.
    My point is STOP making everything one click and where brain dead people can do it.

    Ask any dev if they like one clicks or would rather people actually have knowledge of basic commands. THAT is your answer.
    04-18-2011 03:37 PM
  11. mmarz's Avatar
    Or make a backup of the keymap file you are replacing.

    run_program("/system/bin/mv", "/system/usr/keylayout/thunder_keypad.kl", "/system/usr/keylayout/thunder_keypad.bak")

    then continue.
    04-18-2011 03:40 PM
  12. LeslieAnn's Avatar
    I was worried about that too, the "Screenstate scaling", because of the testing I did that showed underclocking hurting performance. You can find the original script mark used here: [INITSCRIPT] screenstate_scaling - switch CPU freq governor on screen state change - xda-developers

    But it was dropped from Rodimus in the later releases. I'm not sure if it is an accidental omission or it was left out on purpose because the change log does not state when it was removed. Either way, it shouldn't be an issue with the latest Rodimus.
    It was probably dropped because of this:
    Don't use this with SetCPU!
    picasticks likes this.
    04-18-2011 04:09 PM
  13. picasticks's Avatar
    Or make a backup of the keymap file you are replacing.

    run_program("/system/bin/mv", "/system/usr/keylayout/thunder_keypad.kl", "/system/usr/keylayout/thunder_keypad.bak")

    then continue.
    OK, it turned out that busybox (in my recovery at least) had a reasonable grep, so I went halfway and put a check in so that it only restores the original file if it finds a swapped button mapping for the Menu key (that maps it to Home).

    i.e. if it finds key 139 mapped to Home, it restores original. Otherwise, it does nothing.

    So, please test this out and verify that it leaves your thunder_keypad.kl alone (back up first).

    If your recovery shell does not have egrep, it should just do nothing.

    People with reversed keymaps (i.e. remnant of some ROM with the V Xionia port with the swapped keymap hack), please try this and let me know if it reverts you back to the correct keys.

    Also, this version includes the ext2-4 drivers as modules, so it's identical to 06-a. (The other 10 or so changes I tested for 07 I wound up reverting.)

    picasticks-07a.zip

    NOTE: There was a tiny bug in 07 (the above link is 07a) affecting users of CWMA recovery where the update script does not restore the keymap (i.e. it always leaves the keymap file alone). Big props to LeslieAnn for finding the bug and working with me to trace it. If you are the 1 other person who downloaded 07 before we fixed it, please download 07a. The kernel builds of 07 and 07a are identical.
    04-18-2011 08:48 PM
  14. samusishere1's Avatar
    I'm running the kernel on rodimus rom and it woks great but the only problem I noticed is the contrast (things that are white or bright colors) are brighter then normal. How do I fix this.?
    04-19-2011 07:20 PM
  15. picasticks's Avatar
    I'm running the kernel on rodimus rom and it woks great but the only problem I noticed is the contrast (things that are white or bright colors) are brighter then normal. How do I fix this.?
    Settings / Display / Brightness?

    Otherwise, there's nothing in the kernel that is tuning the display. It's using the identical LCD display driver as the one in LG's kernel. It's possible that Xionia (the kernel Rodimus uses) was using the other display driver (I can check this) and that could possibly explain a difference. What version Rodimus?
    04-19-2011 07:38 PM
  16. samusishere1's Avatar
    1.2.3
    04-19-2011 08:08 PM
  17. jmel's Avatar
    I'm running the kernel on rodimus rom and it woks great but the only problem I noticed is the contrast (things that are white or bright colors) are brighter then normal. How do I fix this.?
    I am using rodimus rom and noticed the same thing.
    04-19-2011 10:01 PM
  18. prime0025's Avatar
    I am running RodimusROM 1.2.3 with picasticks-07a and everything is fine.
    04-19-2011 10:08 PM
  19. jmel's Avatar
    It might seem like it is fine, but the issue is there. It is most noticeable to me in facebook for android (not flow).
    04-19-2011 10:27 PM
  20. picasticks's Avatar
    1.2.3
    OK, I downloaded Rodimus 1.2.3 and pulled the kernel config. Both kernels are using the FB_MSM_MDDI_NOVATEK_HVGA driver (which is correct; LS670 uses the HITACHI driver). So, that's not it.

    Since you're coming from Xionia, my advice would be to look closer there for the bug, if there is one -- this kernel doesn't go anywhere near any of the display config and is identical to the LG kernel in that area.

    Settings/Display/Brightness gives you a pretty wide range of adjustment. Always better to have to turn the brightness down than the other way around.

    p.s. I looked again and that kernel is a really old build of zefie's from mid-December for the Optimus S -- it is probably not worth investigating it further. Zefie has made a ton of changes and fixes since then.
    04-19-2011 10:35 PM
  21. samusishere1's Avatar
    Well right. But its still the same when I go to that part of the setings and change brightness. but it also looks the same way when I use any xionia kernel higher then 005. I'm still new to this and a bit connfussed
    04-19-2011 10:42 PM
  22. jmel's Avatar
    OK, I downloaded Rodimus 1.2.3 and pulled the kernel config. Both kernels are using the FB_MSM_MDDI_NOVATEK_HVGA driver (which is correct; LS670 uses the HITACHI driver). So, that's not it.

    Since you're coming from Xionia, my advice would be to look closer there for the bug, if there is one -- this kernel doesn't go anywhere near any of the display config and is identical to the LG kernel in that area.

    Settings/Display/Brightness gives you a pretty wide range of adjustment. Always better to have to turn the brightness down than the other way around.

    p.s. I looked again and that kernel is a really old build of zefie's from mid-December for the Optimus S -- it is probably not worth investigating it further. Zefie has made a ton of changes and fixes since then.
    If I had to call it something, I'd say it looks like a gamma setting is 'a bit off'...

    I've never noticed this with other kernels/roms. I've used rodimus, stock, and stock + xionia.

    Most devs are using xionia 5 because of a number of issues that have come up with later versions. I think this is due to the other ones being ported from the optimus s, and not the v...
    04-19-2011 11:02 PM
  23. picasticks's Avatar
    Well I did go to setting and adjust that but it still looks the same. And any other kernel higher then 005 looks the same also
    OK, well now you've got me a little confused as to what's going on. BTW my kernel versions and zefie's for Xionia have nothing to do with each other. His 005 is from last December, mine is from two weeks ago.

    If you use Xionia higher than a certain number, he changes to the HITACHI LCD driver (Optimus S) so that might explain the problems on an Optimus V (which uses the NOVATEK driver that the S used to). I don't know when that is (it could be 006 when he updates to VC baseband for the S, it could be 013 when he mentions the LCD in his changelog) and would have to download and pull the config from every Xionia to find out. But, that could explain a problem. (Or it might not if the Hitachi driver also works on the V.)

    So, are you saying that with picasticks-07, you go to the Brightness control and when you slide it with your finger the brightness doesn't change? (if so please go to Settings/About Phone and double-check the kernel version)

    All I can tell you is there's nothing in my kernel that changes anything related to the graphics display. It's all the same as the kernel that came on your phone.
    04-19-2011 11:03 PM
  24. jmel's Avatar
    The brightness changes, but it looks like the gamma is set too high. Changing the brightness does not change the gamma. It seems obvious to me that there is something in the rodimus rom similar to the button swap that is being enabled/changed/whatever to make it work better with the xionia kernel. At least to me anyway...
    04-19-2011 11:16 PM
  25. picasticks's Avatar
    If I had to call it something, I'd say it looks like a gamma setting is 'a bit off'...

    I've never noticed this with other kernels/roms. I've used rodimus, stock, and stock + xionia.

    Most devs are using xionia 5 because of a number of issues that have come up with later versions. I think this is due to the other ones being ported from the optimus s, and not the v...
    How drastic is it? Is it too contrasty (no shadow detail, brights burned out) or not enough? Is it adjustable to a reasonable level with the Brightness control?

    I'm sure you aren't imagining things, all I can tell you is that it isn't the kernel. The Android/Linux kernel selects the framebuffer video driver, that's all. Something like adjusting the gamma is in userland, it's not hardcoded into a device driver. For Android that means in a .prop file or init script, it's all configurable at runtime.

    Xionia 005 is the last version that works with the V9 baseband for the S ... which I assume must be the same as the V since everybody's running it here. Since then, the S had two updates, VC and VD. VC introduced a bug so it was pretty quickly followed with VD. The stock S video driver also changed (whether it was first in VC or VD I don't remember).

    I would be curious what Settings / About phone says your Baseband and SW versions are, actually. i.e. mine are LS670MVD_60401001 and LS670ZVD.

    p.s. another thought ... I am going to diff the actual driver code.
    04-19-2011 11:17 PM
155 12345 ...

Tags for this Thread

LINK TO POST COPIED TO CLIPBOARD