Re: Frequencies scaling with OS2008
Klaus.K Pedersen (Nokia-M/Helsinki) wrote: On Wed, 2008-01-02 at 13:30 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: On Mon, 2007-12-31 at 17:37 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? Mixing is still happening on DSP. I see so DSP is running fully but there is no dynamic task loaded so the multimedia requirements are low and it can run at 400/133, right? So what you are seeing is that the DSP task policy is active even though there are no dynamic dsp task loaded? Just an update/explanation. I was not fuly aware of how it works. The most important difference here that I missed previously is the term 'dynamic dsp task'. I was not aware that there are also 'static' dsp tasks. They look same from userspace but are linked statically to dsp bios (?) and the clock policy ignores them (on purpose). So the pcm0/pcm1 dsp tasks are static but pcm2 is dynamic. Therefore uncompressed audio output via pcm0/1 leaves the clock at 400 but same output via pcm2 drops clock to 330. So maybe this is a bug and I should report it in bugzilla? Maybe Real audio should use pcm0 or 1 or pcm2 should not be dynamic task? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Wed, 2008-01-09 at 11:19 +0100, ext Frantisek Dufka wrote: [...] Just an update/explanation. I was not fuly aware of how it works. The most important difference here that I missed previously is the term 'dynamic dsp task'. I was not aware that there are also 'static' dsp tasks. They look same from userspace but are linked statically to dsp bios (?) and the clock policy ignores them (on purpose). Yes. The idea is that when the DSP have to do real work it will load a task to do it. The advanced and unknown tasks are loaded at runtime as dynamic tasks. So lacking a better way to predict the load of the DSP we are using the number of these dynamic tasks to determine if the DSP require the DSP_HI operation point (and thereby locking the ARM to 330MHz). So the pcm0/pcm1 dsp tasks are static but pcm2 is dynamic. Therefore uncompressed audio output via pcm0/1 leaves the clock at 400 but same output via pcm2 drops clock to 330. So maybe this is a bug and I should report it in bugzilla? Maybe Real audio should use pcm0 or 1 or pcm2 should not be dynamic task? True, all pcm tasks should be static. Please report it. BR, Klaus Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Wed, 2008-01-02 at 13:30 +0100, ext Frantisek Dufka wrote:
Igor Stoppa wrote:
On Mon, 2007-12-31 at 17:37 +0100, ext Frantisek Dufka wrote:
Igor Stoppa wrote:
Having the audio path open, but no dsp tack loaded (arm audio) sets the
clock to 400MHz.
Interesting, so, umm, there is way to play audio from ARM side directly?
Mixing is still happening on DSP.
I see so DSP is running fully but there is no dynamic task loaded so the
multimedia requirements are low and it can run at 400/133, right?
So what you are seeing is that the DSP task policy is active even
though there are no dynamic dsp task loaded?
I guess that you are running with your own kernel, build from
http://repository.maemo.org/pool/chinook/free/source/k/kernel-source-rx-34 ?
As discussed in other threads -- this kernel is not really state of the
art :-(
Please try to see weather applying the attached patch(*) solve your
problem.
BR, Klaus
* The patch have been extracted from the kernel that shipped in OS2008.
--- a/arch/arm/plat-omap/dsp/task.c 2008-01-03 12:30:53.0 +0200
+++ b/arch/arm/plat-omap/dsp/task.c 2007-11-23 22:33:52.0 +0200
@@ -260,6 +260,9 @@
/* Expected to hold state_sem in caller function */
static void set_taskdev_state(struct taskdev *dev, long state)
{
+ if (dev-state == state)
+ return;
+
pr_debug(omapdsp: devstate: CHANGE %s[%d]:\%s\-\%s\\n,
dev-name,
(dev-task ? dev-task-tid : -1),
@@ -272,16 +275,18 @@
if ((dev-task) is_dynamic_task(dev-task-tid)) {
int temp = num_dynamic_task;
- if (dev-state == TASKDEV_ST_ATTACHED)
+ if (dev-state TASKDEV_ST_ATTACHED)
num_dynamic_task++;
- else if (dev-last_state == TASKDEV_ST_ATTACHED)
+ else if (dev-last_state TASKDEV_ST_ATTACHED)
num_dynamic_task--;
+ else
+ return;
- BUG_ON((num_dynamic_task 0) ||
- (num_dynamic_task = TASKDEV_MAX));
+ BUG_ON(num_dynamic_task 0);
+ BUG_ON(num_static_task + num_dynamic_task = TASKDEV_MAX);
/* Change only if there's any dynamic task or not */
- if (!(temp*num_dynamic_task))
+ if (!(temp * num_dynamic_task))
dvfs_op_policy_update(DSP_DYNAMIC_TASK_CHANGED,
num_dynamic_task);
}
@@ -559,6 +564,8 @@
devheap = heap;
taskheap = heap + devheapsz;
+ num_dynamic_task = 0;
+
num_static_task = n;
for (i = 0; i n; i++) {
struct taskdev *dev = devheap[i];
@@ -1320,7 +1327,6 @@
struct dsptask *task;
size_t len = vma-vm_end - vma-vm_start;
- BUG_ON(!(dev-state TASKDEV_ST_ATTACHED));
task = dev-task;
omap_mmu_exmap_unuse(dsp_mmu, task-map_base, len);
}
@@ -1955,7 +1961,9 @@
dev-fops.write = NULL;
dev-wsz = 0;
- pr_info(omapdsp: taskdev %s disabled.\n, dev-name);
+ pr_info(omapdsp: taskdev %s disabled(%d)\n, dev-name,
+ num_dynamic_task);
+
dev-task = NULL;
}
@@ -2047,9 +2055,13 @@
goto free_out;
dsp_task_init(task);
- pr_info(omapdsp: taskdev %s enabled.\n, dev-name);
+
set_taskdev_state(dev, TASKDEV_ST_ATTACHED);
+ pr_info(omapdsp: taskdev %s enabled(%d)\n, dev-name,
+ num_dynamic_task);
+
wake_up_interruptible_all(dev-state_wait_q);
+
return 0;
free_out:
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Klaus.K Pedersen (Nokia-M/Helsinki) wrote: So what you are seeing is that the DSP task policy is active even though there are no dynamic dsp task loaded? No, not exactly. First thing - I did not know there is a way to output audio without loading dynamic dsp tasks (named pcm and possibly also pcm2 and 3). I guess this is new feature in OS2008 and with the frequency scaling complictions it looks like this feature is a solution to many performance problems (like videos in flash player) and is generally useful. Also it makes the pcm dsp tasks (i.e. tasks playing just uncompressed audio) obsolete and worse choice because of lowered arm clock when they start. So what I see instead is that gstreamer framework probably uses those pcm dsp tasks (instead of the new way) so when you are playing music in Real audio format (like the BBC radio preinstalled in the firmware) the audio is decompressed on CPU but pcm2 task is started and frequency drops to 330. And so in fact when listening to internet radio you are penalized twice with real audio - frequency drops and audio is decoded on cpu so user experince with microb is degraded. It is slightly better with MP3 audio but still it is unexpected penalty which did not happen with N800/OS2007 and 770 too. On those systems playing mp3 on background came virtually for free. Also that is why I asked why there are pcm dsp tasks at all in OS2008? Or if they are there for better mixing than the logic which reduces clock from 400/133 to 330/220 should be more clever and kick in only when it is really needed. The switch (and audio click) is there anyway if you are first playing music in something SDL based (ScummVM) and then start audio via gstreamer (internet radio). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Mon, 2007-12-31 at 17:37 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? Mixing is still happening on DSP. What I tried is to play BBC radio in home screen applet which activated only pcm2 task and arm clock dropped from 400 to 330. That lead me to conclusion that there is no way to output audio with arm clock at 400Mhz. Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? flash-based audio is decoded on arm (last.fm, ...) Indeed there is something in arch/arm/mach-omap2/board-n800-audio.c arch/arm/mach-omap2/board-n800-dsp.c that looks like there is a way to (partly?) power up dsp, do not run any task and send audio from arm side? As for the policy I had a look at arch/arm/mach-omap2/board-n800-dvfs.c and there are four states defined OP_0 to OP_3 and two additional ones OP_DSP_H (H=high?) and OP_CPU_H as aliases to OP_1 (330/220) and OP_0 (400/133). So one could probably redefine OP_DSP_H to different OP_X to try running dsp at different clock and see which dsp tasks are not fast enough. The multimedia requirements are very strict and comprise some almost-unrealistic cases of multiple streams being decoded and mixed. That's where the extra horsepower is needed. Being apparently impossible to have a continuous dma from the dsp sram to the hw codec practically prevents doing DVFS while the DSP is doing anything. Therefore the only OP which somehow catches all the possible cases over time (i'm talking about a user who is doing more than just mp3 playuback, but might start browsing and so on) is 330/220. Also I wonder what happens when I set DSP_CLK_KHZ in OP_0 state to 266000, can I damage the hardware or will the DSP just crash (leaving rest of the system relatively OK)? Depending on many conditions, it might or might not work, however as long as you don't crank up the voltage, there is no risk of damaging the silicon. HOWEVER (!) corruption in the DSP execution path might lead to unpredictable results, including bricking the unit (to that point that cold flashing is required). Overclocking the DSP only should not so easily cause damage but it's not really a black and white situation. Also you might have to play with the synchronizer. Some comments would be nice there like e.g. which clocks in the table are tied together or which combinations (dsp vs mpu vs other) are allowed. You can refer to the omap2 specific clock framework: it has all the dependencies, basically it replicates the clock tree. BTW, are you forbidden to put any meaningful comments about the hardware there? If yes then how come you are allowed to publish the code itself? The comment i got from TI when i asked is that we are not allowed ot do copy paste of the TRM into the code. Anything else is ok since it is our interpretation of what the TRM says. But having worked on these things for a while it's hard ot tell the difference between what is obvious and what is not. What exactly would is missing? I see no point in replicating the clock dependencies. Is there something else that you think should be added? -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Igor Stoppa wrote: On Mon, 2007-12-31 at 17:37 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? Mixing is still happening on DSP. I see so DSP is running fully but there is no dynamic task loaded so the multimedia requirements are low and it can run at 400/133, right? So whan playing audio like this (using SDL and esd) and starting internet radio later I should hear som pops and clicks when freauecny changes to 330/220? Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? flash-based audio is decoded on arm (last.fm, ...) So is (or should be) Real audio but still CPU drops to 330 (OP_DSP_H). So it is perhaps more about different frameworks used, gstreamer uses pcm dsp tasks (and thus lowers arm core to 330) but things not implemented via dynamic dsp tasks (SDL, esd, flash plugin) use the OP_CPU_H state. The multimedia requirements are very strict and comprise some almost-unrealistic cases of multiple streams being decoded and mixed. That's where the extra horsepower is needed. So perhaps we can introduce another state or swith between OP_DSP_H and OP_CPU_H depending of which exact dynamic tasks are started on DSP. And only when almost unrealistic thin happens (like decoding mp3 and starting decoder and encoder tasks for VOIP/Skype) switch to OP_DSP_H. This would solve use case of listen to mp3 music while surfing the web (and wanting microb to rut at 400Mhz) Also I wonder what happens when I set DSP_CLK_KHZ in OP_0 state to 266000, can I damage the hardware or will the DSP just crash (leaving rest of the system relatively OK)? HOWEVER (!) corruption in the DSP execution path might lead to unpredictable results, including bricking the unit (to that point that cold flashing is required). Overclocking the DSP only should not so easily cause damage but it's not really a black and white situation. Also you might have to play with the synchronizer. Cold flashing because of unstable DSP? Hmm that's bad. That reminds me that there is no guide for cold flashing. It this supposed to work via the released linux flasher binary and firmware and perhaps serial pins next to battery? Or is it more complex procedure not posible to do with tools available to public. What is DSP synchronizer? Tried google but found nothing tha made sense in this context. The comment i got from TI when i asked is that we are not allowed ot do copy paste of the TRM into the code. Anything else is ok since it is our interpretation of what the TRM says. Sounds good :-) What exactly would is missing? I see no point in replicating the clock dependencies. Is there something else that you think should be added? Perhaps not if it is somewhere in the clock architecture code. I only had a feeling that the kernel code which originated from Nokia has less or no comments when compared to other linux code and was thinking about reasons why it is so. Examples are/were retu/tahvo drivers and video driver for the epson chip. But maybe that's just my feeling caused by my general inexperience and lack of other documentation. In such case any hints in the code helps. As for OMAP2 it is bad there is no documentation at TI site. Having same set of manuals like they have for 5910 and 5912 boards would be nice. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Wed, 2008-01-02 at 13:30 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: On Mon, 2007-12-31 at 17:37 +0100, ext Frantisek Dufka wrote: Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? Mixing is still happening on DSP. I see so DSP is running fully but there is no dynamic task loaded so the multimedia requirements are low and it can run at 400/133, right? So whan playing audio like this (using SDL and esd) and starting internet radio later I should hear som pops and clicks when freauecny changes to 330/220? If you have a ARM based sound that is being played when the (first) DSP task is loaded, yes, you should hear a click - one - but it's a fairly uncommon case. The typical case is that the interaction sound is played, then the system is for a while @400 MHz but the loading of the task brings it down to 330 MHz Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? flash-based audio is decoded on arm (last.fm, ...) So is (or should be) Real audio but still CPU drops to 330 (OP_DSP_H). If there are no dsp tasks loaded, then the constraint on the fixed OP is not active. So it is perhaps more about different frameworks used, gstreamer uses pcm dsp tasks (and thus lowers arm core to 330) but things not implemented via dynamic dsp tasks (SDL, esd, flash plugin) use the OP_CPU_H state. Right. And the OP is not changed while the sound is played. You can refer to board-n800-dvfs.c The multimedia requirements are very strict and comprise some almost-unrealistic cases of multiple streams being decoded and mixed. That's where the extra horsepower is needed. So perhaps we can introduce another state or swith between OP_DSP_H and OP_CPU_H depending of which exact dynamic tasks are started on DSP. And only when almost unrealistic thin happens (like decoding mp3 and starting decoder and encoder tasks for VOIP/Skype) switch to OP_DSP_H. This would solve use case of listen to mp3 music while surfing the web (and wanting microb to rut at 400Mhz) Yes, but never the less you have the constraint of keeping low (0) the number of op changes wile audio is active, since they will be perceived as clicks. Also I wonder what happens when I set DSP_CLK_KHZ in OP_0 state to 266000, can I damage the hardware or will the DSP just crash (leaving rest of the system relatively OK)? HOWEVER (!) corruption in the DSP execution path might lead to unpredictable results, including bricking the unit (to that point that cold flashing is required). Overclocking the DSP only should not so easily cause damage but it's not really a black and white situation. Also you might have to play with the synchronizer. Cold flashing because of unstable DSP? Hmm that's bad. Whatever uncontroled code is executed, it can nuke the data/controls written on the onenand bus and there is no _phisical_ protection for the bootloader, meaning that the whole chip content can be randomly trashed. That reminds me that there is no guide for cold flashing. It this supposed to work via the released linux flasher binary and firmware and perhaps serial pins next to battery? That is the connector, yes, you need level shifters, but i think there is on the net some instruction on how to build one. Or is it more complex procedure not posible to do with tools available to public. I don't remember if the public flasher tool provides support for cold flashing but it shouldn't be much different from USB flashing, from the flasher point of view. What is DSP synchronizer? Tried google but found nothing tha made sense in this context. It takes care of the possible difference between DSP_IF and L3 clock, iirc, anyway it's already included in the parameters that describe one OP, check the already mentioned board-n800-dvfs.c and dvfs.c The comment i got from TI when i asked is that we are not allowed ot do copy paste of the TRM into the code. Anything else is ok since it is our interpretation of what the TRM says. Sounds good :-) What exactly would is missing? I see no point in replicating the clock dependencies. Is there something else that you think should be added? Perhaps not if it is somewhere in the clock architecture code. I only had a feeling that the kernel code which originated from Nokia has less or no comments when compared to other linux code and was thinking about reasons why it is so. Examples are/were retu/tahvo drivers and video driver for the epson chip. Retu tahvo are nokia asics and the security through obscurity is intentional, albeit i agree that it is ridiculous since somebody with enough motivation can
Re: Frequencies scaling with OS2008
As ARM core is quite fast in N8x0, probably it would make sense to try keeping DSP out of the way whenever possible (restrict it to 133MHz only, keep DSP tasks which are fast enough to run at this frequency, port all the other DSP tasks to ARM)? That is unless improvements to support more intelligent DSP clock frequency selection are still possible. But for those interested in C55x development, Nokia 770 is still a very interesting device as it runs DSP at full speed. It would be interesting to see whether the mp3 task (for example) can decode in real time when the DSP is run at 133MHz or are your audio/video sync problems because it's running too slowly? This would remove some load from the CPU and allow us to use the DSP for something. I've done a quick test, and although one can't use gstreamer to decode two mp3 files at the same time (presumably as the dsp task doesn't support being loaded more than once due to the shared memory buffers), it's possible to decode AAC and MP3 at the same time without any glitches (though as they are mixed it does make listening a bit hard ;) The loadinfo file in the sysfs doesn't appear to do anything useful (always produces 0.00% as the load) so I don't have any load figures to go with the test. Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Hi, On Sun, 2007-12-30 at 17:16 +0100, ext Krischan Keitsch wrote: Hi, I read an interesting thread about overclocking the n800 [1]. Based on that I started experimenting with the n800 running OS2008. The OS scales the cpu frequency nicely from 165MHz up to 400MHz. The current cpu scaling can be checked with cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq So far so good. I noticed that during playback of mp3 files the cpu is scaled to 330MHz. Stressing the cpu during mp3 playback will not change the scaling - the cpu will not scale up to 400MHz. According to a presentation Nokia Internet Tablet Power Managemen [2] the dsp runs at 220MHz when the cpu is set to 330MHz. (This is the default setting in OS2007, by the way.) I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? The issues are: - doing dvfs while ther is audio playback will generate audible ticks because of problems with the dsp dma - the dsp is always set to support even the weirdest cases, therefore there is a lot of spare DSP horsepower that could be cut off if you knew that your mpu load is not going to change too much and it will be low Practically speaking: if you remove the constraint of fixed [EMAIL PROTECTED] [EMAIL PROTECTED] when there is a dsp task active, you might end up in a situation where you are listening to MP3 @ low OMAP clock, then start the browser, therefore causing the OMAP clock to change rapidly and get lots of garbage on the audio out. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On 30 December 2007, Frantisek Dufka wrote: Krischan Keitsch wrote: I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? Well, yes it looks a bit simplistic now. Even if you play audio decoded by ARM cpu (ogg, real audio) it seems to lock ARM core to 330 and dsp to 220Mhz. I suppose it is because you need pcm dsp task running for audio output and any active dsp task locks it to 220Mhz (and thus cpu to 330). I wonder if it is just simple implementation that can be tuned in next firmwares or there is some fundamental problem (like changing dsp clock of already running dsp task may break it so it is hardcoded to 220). ARM cpu frequency is apparently not locked at 330MHz when using pcm dsp task. That's why it is faster to do MP3 decoding on ARM core with the current OS2008 firmware. Extra 70MHz of ARM core frequency are more than enough to handle MP3 and there are even some resources left to speed up video decoding. It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Also it is interesting to know what is the difference in power consumption between 400/166 and 330/220 modes? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Mon, 2007-12-31 at 12:40 +0200, ext Siarhei Siamashka wrote: On 30 December 2007, Frantisek Dufka wrote: Krischan Keitsch wrote: I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? Well, yes it looks a bit simplistic now. Even if you play audio decoded by ARM cpu (ogg, real audio) it seems to lock ARM core to 330 and dsp to 220Mhz. I suppose it is because you need pcm dsp task running for audio output and any active dsp task locks it to 220Mhz (and thus cpu to 330). I wonder if it is just simple implementation that can be tuned in next firmwares or there is some fundamental problem (like changing dsp clock of already running dsp task may break it so it is hardcoded to 220). ARM cpu frequency is apparently not locked at 330MHz when using pcm dsp task. That's why it is faster to do MP3 decoding on ARM core with the current OS2008 firmware. Extra 70MHz of ARM core frequency are more than enough to handle MP3 and there are even some resources left to speed up video decoding. It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Also it is interesting to know what is the difference in power consumption between 400/166 and 330/220 modes? Sadly, because of DSP sw issues, little power saving is possible when the DSP is running (ARM can still go to idle and most of the processor can have its clock gated, but it's not possible to reach OMAP retention). It would be nice to have the DSP able to sleep between frames; the time taken to decode an mp3 frame is significantly shorter than the related playback. However the voltage used @330MHz is the same used @400MHz and the associated DSP clock is actually lower, therefore it _might_ be that the power consumption is the same or lower. If anybody has time and the means to measure it (*), it would certainly be interesting to do a comparison. * a clock is enough if one is sufficiently patient: fully charge the battery and measure how many hours of playback can be achieved in each mode before the battery goes flat this requires _exclusive_ utilization of the system by the player, therefore one has to give up doing anything while the test is ongoing Also, note that for the test to be reliable, it should be executed on a freshly flashed unit with stock sw (apart from the modified kernel) and no extras whatsoever -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Would this be possible then? What knocks the CPU speed down when the DSP is used (or rather when a music file is played)? The media player presumably? Assuming it is the media player that makes the change, I presume that mplayer should run at 400MHz all the time? Sadly, because of DSP sw issues, little power saving is possible when the DSP is running (ARM can still go to idle and most of the processor can have its clock gated, but it's not possible to reach OMAP retention). It would be nice to have the DSP able to sleep between frames; the time taken to decode an mp3 frame is significantly shorter than the related playback. Presumably the background IDL thread implements power saving functions and is present in the dsp kernel? What actually prevents the DSP from sleeping between frames? If the mp3 task is written using semaphores around the data transfer/notification functions, shouldn't the task yield to the background thread after it has decoded a frame and DMA'd it to the audio codec hardware? Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On Mon, 2007-12-31 at 12:52 +, ext Simon Pickering wrote: It is interesting if it is possible to lock ARM/DSP frequency at 400/166 instead of 330/220 when playing video. That would probably improve built-in player performance on some heavy bitrate/resolution videos. Would this be possible then? What knocks the CPU speed down when the DSP is used (or rather when a music file is played)? A dsp task loaded changes the cpufreq policy, so that the only allowed frequency for ARM is 330 Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. The media player presumably? Assuming it is the media player that makes the change, I presume that mplayer should run at 400MHz all the time? If mplayer is not using any dsp codec, it should already be in such case. Sadly, because of DSP sw issues, little power saving is possible when the DSP is running (ARM can still go to idle and most of the processor can have its clock gated, but it's not possible to reach OMAP retention). It would be nice to have the DSP able to sleep between frames; the time taken to decode an mp3 frame is significantly shorter than the related playback. Presumably the background IDL thread implements power saving functions and is present in the dsp kernel? What actually prevents the DSP from sleeping between frames? Far from optimal design. In other word there has not been enough commitment to push the sw envelope so that it could actually leverage what the hw can do. The current architecture met the (relatively relaxed) time requirement that were set and therefore it didn't receive any further improvement. If the mp3 task is written using semaphores around the data transfer/notification functions, shouldn't the task yield to the background thread after it has decoded a frame and DMA'd it to the audio codec hardware? The mixer is still running and it has a significant timeout, iirc. Also, 'm not so sure that the tasks are actually behaving so nicely. I'm not really into audio, but if you try to decode some mp3 that requires a lot of dsp time vs one that requires very little (silence?), I'm almost certain that there will be no sigificant difference in terms of power consumption. It should be easy to verify with a large enough SD and some mp3 handcrafting skills (several copy paste of the right type of data should be enough). -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? What I tried is to play BBC radio in home screen applet which activated only pcm2 task and arm clock dropped from 400 to 330. That lead me to conclusion that there is no way to output audio with arm clock at 400Mhz. Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? Indeed there is something in arch/arm/mach-omap2/board-n800-audio.c arch/arm/mach-omap2/board-n800-dsp.c that looks like there is a way to (partly?) power up dsp, do not run any task and send audio from arm side? As for the policy I had a look at arch/arm/mach-omap2/board-n800-dvfs.c and there are four states defined OP_0 to OP_3 and two additional ones OP_DSP_H (H=high?) and OP_CPU_H as aliases to OP_1 (330/220) and OP_0 (400/133). So one could probably redefine OP_DSP_H to different OP_X to try running dsp at different clock and see which dsp tasks are not fast enough. Also I wonder what happens when I set DSP_CLK_KHZ in OP_0 state to 266000, can I damage the hardware or will the DSP just crash (leaving rest of the system relatively OK)? Some comments would be nice there like e.g. which clocks in the table are tied together or which combinations (dsp vs mpu vs other) are allowed. BTW, are you forbidden to put any meaningful comments about the hardware there? If yes then how come you are allowed to publish the code itself? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
On 31 December 2007, Frantisek Dufka wrote: Igor Stoppa wrote: Having the audio path open, but no dsp tack loaded (arm audio) sets the clock to 400MHz. Interesting, so, umm, there is way to play audio from ARM side directly? What I tried is to play BBC radio in home screen applet which activated only pcm2 task and arm clock dropped from 400 to 330. That lead me to conclusion that there is no way to output audio with arm clock at 400Mhz. Why there are pcm tasks (used when streaming internet radio) if we could output audio from arm side without limiting ARM clock? Siarhei apparently used a way to output audio without activating DSP from mplayer, how? I did not do anything special. ARM clock frequency just remains at 400MHz when using esd or sdl for audio output. I did some benchmarks and it became clear that it is now faster not to touch dsp mp3 task and just do all the decoding on ARM core. In addition, my hack which used dspmp3sink from MPlayer, now has problems with audio/video synchronization in OS2008. So looks like it is a good time to drop it. Using DSP for MP3 audio was a useful trick on Nokia 770 and OS2006, but right now everything is reversed for N800/N810 and OS2008. Anyway, my guess also was that pcm dsp task is used in osso-esd, maybe it makes sense to check its sources more thoroughfully. Looks like we will have a lot of new discoveries with OS2008 :) As ARM core is quite fast in N8x0, probably it would make sense to try keeping DSP out of the way whenever possible (restrict it to 133MHz only, keep DSP tasks which are fast enough to run at this frequency, port all the other DSP tasks to ARM)? That is unless improvements to support more intelligent DSP clock frequency selection are still possible. But for those interested in C55x development, Nokia 770 is still a very interesting device as it runs DSP at full speed. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Krischan Keitsch wrote: So far so good. I noticed that during playback of mp3 files the cpu is scaled to 330MHz. Stressing the cpu during mp3 playback will not change the Seems that it's also 330MHz with ogg playback even though oggs are decoded on the ARM side and according to the top it takes 20% of the cpu. -- Tuomas signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Am Sonntag, 30. Dezember 2007 schrieben Sie: Krischan Keitsch wrote: So far so good. I noticed that during playback of mp3 files the cpu is scaled to 330MHz. Stressing the cpu during mp3 playback will not change the Seems that it's also 330MHz with ogg playback even though oggs are decoded on the ARM side and according to the top it takes 20% of the cpu. And mplayer takes 400MHz for video and ogg playback. It shouldn't use 400MHz for ogg when 5% cpu is used. Room for optimization? Krischan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frequencies scaling with OS2008
Krischan Keitsch wrote: I was wondering if the device really needs to run at 300MHz (220MHz dsp) for mp3 playback? Is the max dsp power needed for such a task? Or would 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower dsp scaling save even more battery? Well, yes it looks a bit simplistic now. Even if you play audio decoded by ARM cpu (ogg, real audio) it seems to lock ARM core to 330 and dsp to 220Mhz. I suppose it is because you need pcm dsp task running for audio output and any active dsp task locks it to 220Mhz (and thus cpu to 330). I wonder if it is just simple implementation that can be tuned in next firmwares or there is some fundamental problem (like changing dsp clock of already running dsp task may break it so it is hardcoded to 220). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
