Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

What baseboard file are you using?

The devkit one configures MCASP for use by the ARM/linux. Could be a resource contention?

The board-da850-evm.c code is reserving EDMA channels such that the linux OS doesn't try to use them. It doesn't configure them for the DSP or anything else.

You should reserve (in your implementation) the EDMA channels in linux that you intend to use on the DSP. We did not do any reserving in the reference design because we didn't know what would be needed at the time.

-Mike

Hej Mike,

I'm using my own board and also my own baseboard-configuration.c which is based on your baseboard-industrialio.c. I removed everything related to SPI, McASP and USB - espacially the functions

baseboard_setup_spi();
baseboard_setup_mcasp();
baseboard_mtd_notify_add();
mityomapl138_usb_init(MUSB_OTG);

as I don't need them.

To forbid the use of edma-channels in linux I copied the edma-code of the board-da850-evm.c to the board-mityomapl138.c and added channel 0 and 1 (offset 0, number 2) to the reserved channels.

//
// The following EDMA channels/slots are not being used by drivers (for
// example: Timer, GPIO, UART events etc) on da850/omap-l138 EVM, hence
// they are being reserved for codecs on the DSP side.
//
static const s16 da850_dma0_rsv_chans[][2] = {
// (offset, number)
{ 0, 2}, { 8, 6}, {24, 4}, {30, 2}, {-1, -1}
};

static const s16 da850_dma0_rsv_slots[][2] = {
// (offset, number)
{ 0, 2}, { 8, 6}, {24, 4}, {30, 50}, {-1, -1}
};

static const s16 da850_dma1_rsv_chans[][2] = {
// (offset, number) { 0, 28}, {30, 2}, {-1, -1}
};

static const s16 da850_dma1_rsv_slots[][2] = {
// (offset, number) { 0, 28}, {30, 90}, {-1, -1}
};

static struct edma_rsv_info da850_edma_cc0_rsv = {
.rsv_chans = da850_dma0_rsv_chans,
.rsv_slots = da850_dma0_rsv_slots,
};

static struct edma_rsv_info da850_edma_cc1_rsv = {
.rsv_chans = da850_dma1_rsv_chans,
.rsv_slots = da850_dma1_rsv_slots,
};

static struct edma_rsv_info *da850_edma_rsv [2] = {
&da850_edma_cc0_rsv,
&da850_edma_cc1_rsv,
};

And at the beginning of the static void __init mityomapl138_init(void) I added the function call:

ret = da850_register_edma(da850_edma_rsv);

Is this the correct way to reserve edma-channels? Is there a way to verify that these channels are blocked for linux?

Benedikt

Found the reason. The DMA configuration was wrong.

Was the bug in the kernel or your application?

The bug was in the param-sets of the edma which were not set correctly in my application.

But now I have another issue with the edma:

I use linux on the ARM to configure external devices via I2C like DAC/ADCs and to communicate via ethernet. I use the DSP with the McASP to process audio data. The incomming data from the McASP is transferred to a buffer by the edma and, after processing the data, it is returned to the McASP by the edma.

I reserved CC_0-Channels 0 and 1 for the DSP in the board-configfile as mentioned above and I use only shadow-region 1 for the DSP while shadow-region 0 remains for the ARM. I route events 0 and 1 (McASP Rx + Tx) to queue 0 and everything else to queue 1 so that TC0 is doing all McASP-transfers and TC1 all others.

This works fine as long as linux does nothing. As soon as I access the MMC or SPI-interface from linux, for example a simple "ls", the transmitter-part of the edma stops. (linux root-fs is on a sd-card, MMCSD0 used)

Today I found a small sentence in the ti-wiki related to the edma-driver:

http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.22.00.02_Device_Driver_Features_and_Performance_Guide#EDMA_Driver

Under "Features Not Supported" is written:

"Reservation of resources (channels and PaRAMs) for usage from DSP is not supported."

This would mean, that the reservation in the linux kernel is nonsense as it is not applied anyway. Is this correct?! Are their possibilities to use the SPI-Flash and the MMCSD0-interface without the edma?

Benedikt

The reservation of resource may be non-sense, but the resources specific to device drivers (like McASP channel queues) will not be touched by the linux kernel if the drivers are not activated, so I suspect that is not the problem.

Instead, I am wondering if the issue is with the DMA mastering priority?

Take a look at the OMAP-L138 Technical Reference Manual, chapter 11.3 (Master Priority Control). Particularly table 11-2.

The ARM MMCSD driver uses, I believe DMAs in the EDMA4_0_TC0 (priority 0). If you are using a shadow region, perhaps you are using the EDMA3_t_TC0, which is priority 4, which will get held off by the SD card access.

You might try lowering the EDMA3_0_TC0/1 priorities or raising the EDMA3_1_TC0 priorities to at least make them equal, or make the one related to the McASP higher.

There is code in the MDK Core library (see tcDspSyscfg::SetMasterPriority()) that allows adjusting the priorities.

-Mike

Hej Mike,

I just checked the master priorities. I changed it to the following values:

0: EDMA3_0_TC0
1: DSP MDMA & CFG
2: EDMA3_0_TC1
3: ARM I & D
4-7: Everything else

I use EDMA3_0_TC0 for the McASP-transfers and EDMA3_0_TC1 for all other requests.

Unfortunatly the behavior is exactly the same.

Could it be that there are some McASP-drivers still active within linux even though I deselected sound-support with -menuconfig in the kernel? Which options should be deselected in order to avoid linux accessing anything related to the McASP? The strange thing is, that the Rx-EDMA-transfers are still active but no Tx-transfers are done.

Benedikt