Actually, it's related to the DSP. When the DSP is busy (ie. during splash screen, playing videos, and MP3s (I guess)), it either starves the CPU, or shares vdd1 with it, and undervolts. If you're able to check the dmesg buffer, you can see DSP sync errors when it happens.
Here are my new values that appear to be stable while playing video:
Code:
20 20 25 30 35 38 43 45 48 51 54 56 60 65 72
Interestingly enough, the CPU enters sleep state during video playback, so the first voltage is critical. While it's otherwise stable with 15 as the first value, it locks almost immediately while playing video. It makes sense, I guess.
The main problem was voltage too low at 250 and 500mhz.
I don't think we can do better than this for ultra ultra low voltage.
Actually, it's related to the DSP. When the DSP is busy (ie. during splash screen, playing videos, and MP3s (I guess)), it either starves the CPU, or shares vdd1 with it, and undervolts. If you're able to check the dmesg buffer, you can see DSP sync errors when it happens.
Here are my new values that appear to be stable while playing video:
Code:
20 20 25 30 35 38 43 45 48 51 54 56 60 65 72
Interestingly enough, the CPU enters sleep state during video playback, so the first voltage is critical. While it's otherwise stable with 15 as the first value, it locks almost immediately while playing video. It makes sense, I guess.
The main problem was voltage too low at 250 and 500mhz.
I don't think we can do better than this for ultra ultra low voltage.
I suspect your analysis is incorrect. I am not sure that the MPU really ever enters a 0MHz mode. Certainly it does not do that by kernel setting this mode, so the voltage in the first line is really ignored. And even if it did enter 0MHz mode, the DSP gets the same voltage as the MPU, as you noted, so while the DSP is busy the voltage cannot be lowered. In addition, you need to recall that DSP and MPU frequencies are connected (this is a kernel issue, not necessarily a hardware issue), so if you need a high DSP frequency for decoding a video, the CPU will also be in a high frequency.
I suspect your analysis is incorrect. I am not sure that the MPU really ever enters a 0MHz mode. Certainly it does not do that by kernel setting this mode, so the voltage in the first line is really ignored. And even if it did enter 0MHz mode, the DSP gets the same voltage as the MPU, as you noted, so while the DSP is busy the voltage cannot be lowered. In addition, you need to recall that DSP and MPU frequencies are connected (this is a kernel issue, not necessarily a hardware issue), so if you need a high DSP frequency for decoding a video, the CPU will also be in a high frequency.
Looks like you're right about the first voltage; setting it to 0 has no effect. Maybe we should set it to this in all the various voltage configs so there's no confusion.
So I wonder .. if a given DSP rate is insufficient to run a codec, how does it signal to the host it needs to upclock?
There is a mechanism for that in the kernel, but it is using the original OPP tables, rather than our modified ones, and is thus probably not working very well.
This is frustrating. I'm trying to fix all the DSP rates to 500mhz, except when the main CPU is clocked at 250, to smooth video recording. It seems to be working, except that it means I have to bump all the voltages up considerably. I wish there were separate voltage selections.
I can confirm that disabling power-saving reduces latency from 50ms -> 5ms
but it increases the battery drain drastically.
I just tried this with the stock kernel and I get the same results.
With max. wifi powersaving 50ms, with medium or no powersaving ca. 5ms.
So this appears that it is not related to the kernel version.
Could you please try to confirm this with the stock kernel?
I just tried this with the stock kernel and I get the same results.
With max. wifi powersaving 50ms, with medium or no powersaving ca. 5ms.
So this appears that it is not related to the kernel version.
Could you please try to confirm this with the stock kernel?
I don't have the stock kernel anymore, but I had the same problem; it seem significantly better under 2.6.28.10. In fact it was so bad under the stock kernel I had to turn off powersaving to make ssh usable.
I asked the question over there, but I can ask you, too, titan... how would the dual boot affect your sweet, sweet kernel? Can the features happily co-exist?
