Weird EMIFA read and DMA problem

Hi Szymon

Can you clarify where your McASP buffers are located on device memory? Similarly where are the bytes read from 0x6000 0000 getting stored on the device memory?

Regards
Mukul

Hi

I forced the DSP compiler to store my McASP buffers in the DSP L2 RAM (from 0x11800000) for performance reasons. In the morning I'll check if moving those buffers around helps. The bytes read from 0x60000000 are not stored anywhere by the Linux kernel module, but just checked by some of my system's logic.

Regards
Szymon

Thanks for the update. I wonder if there is a way for you to create some sort of local variable within your kernel module to read into from 0x6000 0000 to ensure that it works properly and it does not break your audio buffers.

If your source/destination for EDMA to/from McASP and your reads to EMIFA have no "common" memory buffers or access paths, then it is unlikely a system interconnect issue.

Regards

Mukul

Hi

If I read the address from a macro or place it in a local variable in Linux makes no difference. Also, placing McASP buffers in RAM does not help. I wonder if there is some common bus shared between EMIFA and EDMA? High EMIFA usage might stall and starve EDMA and McASP...

Regards
Szymon

Hi

If I assume that your EMIFA accesses are initiated by ARM (read from EMIFA and write to mDDR/DDR2) and EDMA accesses are read/write from McASP and read/write to IRAM( assume L2 or Shared RAM), then there should not be any "common bus" shared between these sets of accesses. Please refer to the attached diagram, highlight the access path for these accesses using the system interconnect diagram.

So I am still hoping that something else is causing the issue. Following additional clarifications might help

1) You mention "system logic" for accesses done to EMIFA reads, is it worth elaborating a bit more on this. Are you sure that logic is working fine?

2) What is your audio/PCM data rates

3) For EMIFA reads, assuming 120 reads per seconds (120 Hz?), how many bytes do you read back on every such interrupt? If you were to put some wait loop between every byte read during an access does that reduce the McASP overrun/underrun issue?

4) You mention that it is the "reads" from EMIFA that make it fail. Would it be possible for you to see if writing to EMIFA also causes similar issues on McASP.

Let me know if you have any questions on the attached diagram

Regards

Mukul

Another possible debug suggestion that came up during some internal discussions was, if you have the OMAPL138 EVM with the UI card (that has the NOR flash).

NOR flash is connected on CS2 on the EVM and you can try accessing it from Linux to make sure your custom card or the ioremap code you have written is not causing anything.

Hello again

I have some new input on the problem. But first to answer your question: I'm using a fully custom built board, and things EMIFA-wise are connected correctly.

One things seems to have cured the situation (at least for now). Right up until now my DMA transfers looked like this:

For McASP TX - when the serializers demanded data, I used two channels to service them. First one (numbered 1 - triggered by AXEVT) just sorted the data, and stored them in some temporary buffer in DSP's L2 RAM. The second transfer chained to the first one moved the data from the temporary buffer to McASP DMA address.

For McASP RX - when the serializers told me they had data, I also used two channels to service them. First one (numbered 0 - triggered by AREVT) moved the data to a temporary buffer, the second one chained to the first sorted them in a fashion desired by my system.

I started writing my code while I was't that much familliar with EDMA. Now I was able to combine the sorting and moving transfers into one with little effort. It resulted in twice lower EDMA utilization.

As you can see the EDMAs utilization, in conjunction with EMIFA reads, has a direct impact on how the situation develops. Should it be that way? My fear is when I start adding more peripherals to EMIFA the problem will return.

McASP is clocked by a 2048 kHz signal. I have 6 PCMs for transimt and 6 for receive, each having 32 8-bit slots.

Regards
Szymon

Hi Szymon

Just so I have a better understanding of your data flow and current and old scheme, please correct me if I am wrong

Old Scenario

McASP TX

Transmit DMA channel: SRC: L2 DST: McASP

Sorting DMA channel: SRC : L2 , DST: L2(?)

McASP RX

Receive DMA Channel: SRC: McASP DST: L2

Sorting DMA Channel: SRC: L2 , DST:L2(?)

Current Scenario

McASP TX

Transmit DMA channel: SRC: L2 DST: McASP

No additional sorting?

McASP RX

Receive DMA Channel: SRC: McASP DST: L2

No additional sorting?

Is the above correct? What EDMA Q's are being used in both scenarios? I am assuming what you are saying is that in the current scenario you managed to use only 2 channels instead of 4 and eliminated the L2 to L2 sorting transfers, and that fixes the issue?

Please clarify

Regards

Mukul

Hi

All the above is correct. I'm using two EDMA channels now - number 0 and number 1 (they are connected to McASP AREVT and AXEXT in OMAP-L138). Linking is used to reload the transfers with new PaRAM sets.

Regards
Szymon

Hi

Any new leads on what might be going on?

Regards
Szymon

Szymon

Based on the above data flow for the McASP based EDMA traffic and ARM issuing reads to EMIFA , there is no common points in the accesses , and these should really be orthogonal/independent and not impact each other directly (my attached pdf still holds good for data flow routes for those accesses).

So I feel we are missing some "indirect" dependency between these 2 access scenarios , which is likely causing your McASP failures (things like ARM/DSP interaction if any while ARM is accessing EMIFA vs DSP is processing PCM data , and if they have any timing/synchronizing effects based on your application, your EMIFA CS system logic etc?)

Regards

Mukul