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

Reply via email to