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
