Compiling custom kernels for P1.1 (with fiasco-gen) - Page 26 - maemo.org

Active Topics

Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 7 hrs, 3 mins ago
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 11 hrs ago
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 23 hrs ago
n770 youtube video (0)
to General by nmdv - 5 days, 23 hrs ago
more...

Page 26 of 34

Thread Tools

titan	2010-04-18 , 22:23
Posts: 946 \| Thanked: 1,650 times \| Joined on Oct 2009 @ Germany	#251

Originally Posted by nightfire

I'm curious if this voltage map is stable for anyone else. Been 24 hours and no lockups, oopses, segv's, or anything.

rebooted while playing mp3s...

Quote & Reply |

nightfire	2010-04-18 , 22:43
Posts: 310 \| Thanked: 383 times \| Joined on Jan 2010	#252

Originally Posted by titan

rebooted while playing mp3s...

Yeah, I just noticed this too.

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.

Last edited by nightfire; 2010-04-18 at 22:50.

Quote & Reply |

The Following 2 Users Say Thank You to nightfire For This Useful Post:
cproc, titan

Matan	2010-04-18 , 23:04
Posts: 1,224 \| Thanked: 1,763 times \| Joined on Jul 2007	#253

Originally Posted by nightfire

Yeah, I just noticed this too.

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.

__________________
My repository

"N900 community support for the MeeGo-Harmattan" Is the new "Mer is Fremantle for N810".

No more Nokia devices for me.

Quote & Reply |

The Following User Says Thank You to Matan For This Useful Post:
cproc

nightfire	2010-04-18 , 23:11
Posts: 310 \| Thanked: 383 times \| Joined on Jan 2010	#254

Originally Posted by Matan

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?

Quote & Reply |

Matan	2010-04-18 , 23:37
Posts: 1,224 \| Thanked: 1,763 times \| Joined on Jul 2007	#255

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.

See in drivers/dsp/bridge/rmgr/drv_interface.c

__________________
My repository

"N900 community support for the MeeGo-Harmattan" Is the new "Mer is Fremantle for N810".

No more Nokia devices for me.

Quote & Reply |

The Following User Says Thank You to Matan For This Useful Post:
S0urcerr0r

nightfire	2010-04-19 , 00:32
Posts: 310 \| Thanked: 383 times \| Joined on Jan 2010	#256

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.

Quote & Reply |

titan	2010-04-21 , 15:34
Posts: 946 \| Thanked: 1,650 times \| Joined on Oct 2009 @ Germany	#257

Originally Posted by titan

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?

Quote & Reply |

nightfire	2010-04-21 , 15:40
Posts: 310 \| Thanked: 383 times \| Joined on Jan 2010	#258

Originally Posted by titan

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.

With your kernel I've reenabled powersaving.

Quote & Reply |

titan	2010-04-22 , 15:32
Posts: 946 \| Thanked: 1,650 times \| Joined on Oct 2009 @ Germany	#259

interesting news from the MeeGo kernel upgrade to 2.6.33
http://lists.meego.com/pipermail/mee...il/001792.html

Quote & Reply |

twoboxen	2010-04-22 , 15:52
Posts: 258 \| Thanked: 138 times \| Joined on Oct 2009 @ St. Louis, MO, USA	#260

Originally Posted by titan

interesting news from the MeeGo kernel upgrade to 2.6.33
http://lists.meego.com/pipermail/mee...il/001792.html

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?