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 certainly figure out by himself how they work. But this is the mandate and you have to push Quim to make pressure on the opening of the specs. > 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. Yes, I agree, omap linux development is a sort of closed club since i don't know of anybody doing extended omap work without TRM. -- 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
