Any good reason for the hard memory limit between DSP and ARM?

GoogleGroups
1

Hi,

One question which just hit me :slight_smile: Does anybody know if there is any good
reason why the memory is hard divided between ARM and DSP (using the MEM=xx
directive in the Linux cmdline?) In theory I think it should be possible to
do dynamic allocation from the same pool coordinating the allocation in
dsplink/dspbridge (is this i.e. supported in Syslink?).

Not 100% trivial I agree (but not impossible either I think), and it would
allow better memory utilization for people running mixed use cases instead
of always reserving xx MB for DSP usage, which are just wasted in case of no
DSP codec running?

Any good reason not to do some kind of dynamic allocation (except that it of
cause complicated things coding wise until it's stable and running :slight_smile: or is
it simply just an old left over from the way it was initially implemented?

Best regards - Hope somebody can clarify :slight_smile:
  Søren

2

dsplink has a fixed memory allocation and thus needs memory set aside
for the dsp and for buffers that are shared between arm and dsp (cmem)
dsplink uses the dsp mmu for a fixed, flat mapping and does not take
arm side user space mapping into account

dspbridge afaik uses the dsp mmu to dynamically map arm side buffers so
that they can also be used from the dsp (the same arm side pages are
mapped in the same order into dsp memory space)

dsplink runs on other MMU-less systems like DM64xx, so using the MMU
on OMAP3 would have made it non uniform wrt usage on other systems

dspbridge comes more or less from an all omap world and does not even
exist for other systems and was thus free to use the dsp mmu.

somebody from TI correct me where i am wrong :slight_smile:

3

see also:

http://linux.omap.com/pipermail/linux-omap-open-source/2007-May/009850.html

and

http://comments.gmane.org/gmane.linux.ports.arm.omap/40742