I'm using DM355 to a wireless video project.
To connect the wireless module, I use a FPGA connected between them served as a connector. The DM355 use EMIF interface fo connect to FPGA.
For receive side, when enough data comes, the FPGA will give a pulse through to DM355. And then DM355 use EDMA to read data from FPGA to DDR memory.
At the beginning, I use "the pulse given by FPGA" as a GPIO interrupt. That is to say, when "pulse" comes, the DM355 enters a interrupt, configure the EDMA parameter and start EDMA. Then when EDMA completes, it enters a interrupt again, exchanges another working buffer(ping-pong). So, for receiving one packet, two interrupts will happen.
When I transmit a SD video, it is working very well. But when I transmit a HD video, the image output from receive side(VGA output from THS8200) is not very good, something like jumping up and down. My understanding is that, there's too many interrupts causing the interrupt used by VPBE is not served in time and is delayed.
So I decide to change to another way. I use "this pulse" to trigger EDMA directly. In DM355, GPIO 6 is a trigger event of channel 38. So when "pulse" comes, the data will be read by EDMA automaticly. And when EDMA completes, it wil enter the interrupt. In this way, just one interrupt on packets.
I have already completed this driver and write a simple application just transmitting a big file to test the communcation. Then I compare the file received and the original file, it is the same. It's good. But when I use this driver to receive the real-time video and play it. The problem comes. The phenomenon is the following:
1. The "Vdec_process fucntion" is halting.
2. Before calling "Vdec_process function", the gpio-trigger-edma is working very well. After calling it, the EDMA interrupt never comes.
But when I use the same driver and the same user-land application on DM365(just very few modifcation), everything is OK on DM365, which confused me. What happen on DM355?
3. At that time, I can use "telnet" command to login into DM355 board and do some other things. So the kernel is not hang.
In my understanding, the below may cause this problem:
1. The DMA channel is conflicted. Maybe channel 38 is also used by hardware codec. Since when I use the the first way, I use "davinci_request_dma" the get the DMA channel and the channel num is 0. The channel number between these two ways are not the same.
2. The EDMA is using the bus too frequency and hardware codec can not get the bus in time. So there may be some priority settings to solve this problem.
Maybe I'm wrong. So please give me some help or tips to solve this problem. Thanks very much.
Best Regards
Richard LIU