Using the 128KB shared RAM on L138 from Linux User Space (cache coherency problem)

Or perhaps reconfigure the ARM in the linux kernel to not cache the shared memory area.

Any help please?

Many thanks,

Mads

Nobody knows if it is possible to remove dcache of the shared memory area in OMAPL138 in Linux kernel?

Please help,

Mads

Good stuff to know. Looks like that was a hard, lonely search for that one.  I am in the midst of coding up an ARM-DSP app using DSPLink. Is there an advantage to using the shared 128KB memory directly versus the DSPLink Pools? I am not too familiar with the DPSLink implementation. I got impression that DSPLink can use that shared memory. Any possiblility of conflict between direct access and DSPLink?

Hi Norman

Our DSPLink impl. uses the DDR memory for communication which is somewhat slower, but we do (currently) not have any "time" critical stuff that uses DSPLink.
I believe that you can configure DSPLink to use the shared memory if needed. 

We haven't yet measured the performance on the internal shared RAM vs. DDR, so I cannot really say what the performance gains are (besides the slower clock on DDR).
I do also not know what the read / write cycles are to the shared RAM.

There will not be any conflict with shared memory and DSPLink as long as you make sure they don't use the same memory area. So make sure DSPLink is configured properly on ARM and DSP.

I haven't gotten far enough to consider memory access times but that will definitely be factor later. I was thinking more from an architectural or programming perpective of direct vs DSPLink Pools. The DSPLink Pools, in theory, should take care of sharing memory for you without messing with "/dev/mem".  However, using DSPLink will probably cost me in  resource usage and reliability.  You wouldn't happen to know the DSPLink compile flag that controls use of the 128KB shared memory? I find the DSPLink build to be ridiculously complicated.

Well we wanted direct memory access for some specific algorithms, so we wouldn't need to go through any functions calls etc. which might slow us down.

But DSPLink which is what we use (although it has been replaced by SYS/Link, just like DSP/BIOS is now called SYS/BIOS) has some nice features which we definately are going to use.

On the DSP side you need to have your DSPLINK memory section configured correctly, so the location matches the ARM side (I am also fairly new to DSPLink).
On the ARM (Linux side) you need to edit a target specific file like CFG_OMAPL138GEM_SHMEM.c file to match the new location of DSPLink. This files is part of the DSPLink source for Linux and it requires you to recompile DSPLink for your target.
I haven't tried moving DSPLink so I am not completely certain that this is all that is needed.

I have also noticed two other things that you might like to know, though I am not 100% certain on this.

1. DSPLink uses SWIs on DSP which is of high priority and uses SWI_Disable/Enable causing all other SWIs to stall until it is done, if you have anything else that you really need to run of higher priority in SWIs, DSPLink can be configured to run in a task.

2. DSPLink is defauklt using HWI 4/5 which is also high priority, so if you have any HWIs implementation which is more critical, you will have to move DSPLink to other HWIs.

Have you checked out the DSP/Link FAQ, http://processors.wiki.ti.com/index.php/DSPLink_FAQs

/Mads

Thanks for the info and the link. The interrupt allocation may be the cause of hang problems I've been having with EDMA interrupts on the DSP side.

Hi Norman

Just saw your other post. I am not actually  sure this is the problem you are seeing.

I do not know the PSP SPI example you have mentioned, but I am wondering whether you are using the HWI Dispatcher?

I am new to all this. Not quite sure what is the HWI Dispatcher. I do have one of those mysterious TCF entries for HW_INT7 through HW_INT10. Eventually HW_INT8 maps to interrupt 1 that maps to the SPI event.