AM5718: McASP module driver

Hi Krunal

I have gone through the thread that you suggested.

In my case ARM configured the codec(TLV320AIC3106) and DSP access the data through EDMA+McASP combination.

Since my platform is an SDR, Linux always running. Based on waveform, EDMA+McASP combination is switched between ARM and DSP.

can I make EDMA+McASP as a module driver and codec as platform driver.

I can switch the control of EDMA+McASP between processors(ARM(LINUX) and (DSP(SYSBIOS).

Regards
Satheesh Kumar S

Hello Satheesh,

can I make EDMA+McASP as a module driver and codec as platform driver

I am not sure what you mean by make as a module/platform driver. By default, the AIC codec is built as a module and loaded by the Kernel. The source code for the codec is under the directory <kernel_dir/sound/soc/codecs>. The McASP driver source code is located under the directory <kernel_dir/sound/soc/ti/davinci-mcasp.c> and it is built as part of the Kernel.

Regards,
Krunal

Hi krunal

Thanks for your reply

My requirement is to switch the audio data access using McASP and EDMA between processors(ARM and DSP) at runtime .

ARM(Linux) will configure the CODEC and data is to be accessed by ARM or DSP based on waveform applications.

I plan to remove McASP3 node from DTS file and make EDMA + McASP3 as a module driver and insert/remove the driver dynamically based on waveform application requirement. I am not planning to use any other McASP nodes in the system.

Is this method feasible and is it possible to access McASP + EDMA from DSP (TI RTOS) and ARM (Linux)? Access will be done either from ARM or DSP at a time.

If I remove McASP3 + EDMA, what happens to existing ALSA modules?

I am sorry if I am wrong.

Regards

Satheesh Kumar

Hi krunal

A gentle reminder

Regards

Satheesh Kumar S

Hello Satheesh,

If you disable McASP from the DT entry, Linux will not probe the McASP device. If the device is not probed, inserting the driver module will not initialize the McASP. Also, if McASP is not initialized, you will not be able to properly utilize the ALSA/gstreamer framework. I do not understand why you would need both the DSP and the ARM to capture samples from the McASP. A better option would be to have one core capture samples from the McASP and transfer samples to the other core. 

Regards,
Krunal 

Hi krunal

Thanks for the prompt reply.
We are developing platform software for SDR. Some waveforms may require DSP to perform source coding, while some other waveforms may not need any DSP operations to be performed on the audio data. So there is a requirement from our client, that in those waveforms which requires DSP to act on the audio data, DSP must directly fetch the data from the codec and in the waveforms which doesn't perform any DSP operations on the audio data GPP must be able to access the data. So the access to McASP3 and EDMA must be shared between GPP and DSP in run-time.

For this, I plan to disable McASP node from DT and plan to convert McASP3 and EDMA as a loadable module driver.

In our previous projects on SDR, we were accessing codec from GPP and if DSP operations were required, the data was sent to DSP, and the processed data is sent back to GPP. But our client is raising some concern about the possible latency in transfer of audio data due to Linux running in GPP. This is the main reason why we are thinking of alternative path.

Regards

Satheesh Kumar S.

Hello Sathessh,

If possible, could you please share the latency numbers and your desired performance criteria?

Regards,
Krunal 

Hello Satheesh,

If you are sending 512 bytes, please refer to the following article on IPC benchmarking: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#linux-benchmark-test-messageqbench

Please feel free to run the test MessageQBench, and specify your payload size. Generally speaking, the larger the payload, the longer the latency. We’ve posted benchmarks for payload size of 8 bytes here: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#ipc-average-round-trip-time

If larger than 512 bytes, please refer to the Big Data IPC example: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_examples_demos.html#big-data-ipc-example

The Big Data IPC example doesn’t have benchmarking capability out of the box, but please refer to the MessageQBench example to integrate it in.

Regards,
Krunal

Thanks krunal

Ok,what about the loadable module driver. is it feasible?. Whenever arm like to capture data,we insert the driver (mcasp+ Edma)using insmod . Whenever DSP like to capture data,we remove the module(mcasp3+ Edma) using rmmod and all configuration neeed for mcasp and Edma to work will be done in DSP.I am sorry if I am wrong

Regards

Satheesh Kumar

Hello Satheesh,

I am looking into the loadable module driver and I will get back to you within 48 hours.

Regards,
Krunal