--- Quote Start ---
Everything works, except I can't turn off park mode on the mSGDMA module without freezing Linux. I think that the DMAs really would benefit from a generic UIO kernel driver being available to handle things such as resets, etc. Waiting to hear back from Altera about the best method to reset a module in park mode.
--- Quote End ---
I am having similar problems in my ST to MM design for transferring video. I use the standard CVI module for generating data packets which are fed directly to a mSGDMA write only core. I connected the MM write master to a f2h_sdram bridge. Write address is just outside and above kernel space (dedicated lowest 512M to Linux). Writing data works just fine but oddly spaced though due to the endian reversal of the core. I'll work around that in my user-space program, no problem here.
I found that setting the descriptor length field did not guarantee stable transfer lengths at all. I simply assumed that I would get an interrupt after completion of a video frame transfer so I could stop the current and issue a new descriptor. But video is cut up in line based blocks that make very little sense to me. Closer inspection in SignalTap showed erratic address increments and early-done signals. Sometime a "done" condition coincided with a jump of 1000h in address space. First I thought this might be due to timing problems but TimeQuest reveals absolutely no problems.
For further investigation I whipped up a simple kernel module to catch the vsync interrupt of my sensor to start new descriptors at exactly the right time. It was then that I found that the EOP from CVI triggered an end of the current descriptor. After that (descriptor fifo essentially empty) the erratic behaviour started. So I figured a might be a good idea to start partial transfers and check the amount of bytes transferred the reponse port, while keeping the length field of the descriptor at max of 0xFFFFFFFF. The interrupt I wrote for the mSGDMA handler works allright but once an interrupt was triggered (outside park mode) the kernel hangs. I thought writing a zero to bit 9 of the CSR status register would be enough, but it's not. IRQ line remains active and drives the kernel to a panic state due to stack overflow. I am not seeing any interrupts in park mode so this might explain why derim is having problems... Once it's in park mode everything runs smooth but sync is lost.
Anyway, the question is: how do a clear the interrupt condition, or more likely, how do handle/clear events that lead to an interrupt?
Honored Contributor
