[maemo-developers] ARM MMU questions

From: Frantisek Dufka dufkaf at seznam.cz
Date: Mon Oct 29 16:47:14 EET 2007
Simon Pickering wrote:

> Of course, I'd just not realised that the name of the memory section 
> was used to perform the framebuffer sharing. I had expected to have to 
> make an explicit call to the DSP memory ioctl to do this.

I don't know for sure, it was just a guess that could explain why it 
behaves differently.

>>> Another thing I need to look at is whether I can share some large shared
>>> memory regions on the 770 at higher addresses in the DSP memory map (to
>>> be used by mplayer to avoid memcpy operations on frames).
>> Well that would be nice but most probably you need continuous physical
>> (not virtual) memory for this so the frame can be used as real video
>> memory = transferable via DMA to external video chip.
> 
> This is probably not such a big issue - the idea here is to share some 
> memory buffers between mplayer and the DSP so mplayer can fill them 
> (and then use them to calculate the next frames, etc.) and the DSP can 
> be told to display the data in one of these buffers (after it performs 
> colourspace conversion and scaling). There will be some memcpys on the 
> DSP side (from shared memory to framebuffer), but hopefully this will 
> be fast enough as the DSP does not have to do anything else.

Oh, I see. I was thinking about zero copy mechanism, this makes it one 
copy on DSP side which may be almost free and nicely kills one or more 
birds with one stone. Now I think I understand the idea :-) - mplayer 
produces more frames in advance to some dynamic memory, dsp does 
colourspace conversion and copy to real video ram one frame at a time.
So there is no need to have continuous physical memory and still mplayer 
can decode frames in advantage with zero copy on arm side. Looks like 
win for 770 :-)

Frantisek

More information about the maemo-developers mailing list