On 10/29/2015 05:39 PM, Caleb Crome wrote:
On Thu, Oct 29, 2015 at 9:34 AM, Roberto Fichera kernel@tekno-soft.it wrote:
On 10/29/2015 05:02 PM, Roberto Fichera wrote:
On 10/29/2015 04:54 PM, Caleb Crome wrote:
On Thu, Oct 29, 2015 at 8:37 AM, Roberto Fichera kernel@tekno-soft.it wrote:
On 10/29/2015 03:55 PM, Caleb Crome wrote:
On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome caleb@crome.org wrote: > On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen nicoleotsuka@gmail.com wrote: >> I am actually thinking about setting a watermark to a larger number. >> I forgot how the SDMA script handles this number. But if this burst >> size means the overall data count per transaction, it might indicate >> that each FIFO only gets half of the burst size due to dual FIFOs. >> >> Therefore, if setting watermark to 8, each FIFO has 7 (15 - 8) space >> left, the largest safe burst size could be 14 (7 * 2) actually. > Oh, does this depend on the data size? I'm using 16-bit data, so I > guess the bursts are measured in 2 byte units? Does this mean that > the burst size should be dynamically adjusted depending on word size > (I guess done in hw_params)? > >> Nicolin Okay, so wm=8 and maxburst=14 definitely does not work at all,. wm=8, maxburst=8 works okay, but still not perfect.
I just discovered some new information:
With wm=8 and maxburst=8 (which is my best setting so far), I just captured a problem at the very start of playing a file, and restarted enough times to capture it starting wrong:
Instead of the playback starting with
(hex numbers: my ramp file has first nibble as channel, second nibble as frame)
frame 0: 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0, f0 frame 1: 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1, f1
It started with:
frame 0: 00, 00, 10, 20, 30, 40, 50, 60, 70, 80, 90, a0, b0, c0, d0, e0 frame 1: f0, 01, 11, 21, 31, 41, 51, 61, 71, 81, 91, a1, b1, c1, d1, e1
So, the transfer started wrong right out of the gate -- with an extra sample inserted at the beginning. Again, my setup is:
- use scope to capture the TDM bus. Trigger on first data change
- aplay myramp.wav
- If okay, ctrl-c and goto 2.
- The capture below shows everything off by 1 sample.
The capture is here: https://drive.google.com/open?id=0B-KUa9Yf1o7iOXFtWXk2ZXdoUXc
This test definitely reveals that there is a startup issue. Now for the $64,000 question: what to do with this knowledge? I'm quite unfamiliar with how the DMA works at all.
I'm my case for example, I'm using a iMX6SX SoC, I've changed fsl_ssi.c to start the SSI clock generated internally by setting both RDMAE and TDMAE just once I'm pretty sure that everything has been setup (DMA and callback). Note that I'm not using alsa because, my target is to integrate SSI in TDM network mode with my DAHDI driver for VoIP app.
Back to the DMA question, in your case shouldn't be really a problem since all DMA stuff is handled by the linux audio framework.
Regarding my SSI problem, I was able to keep the DMA working for few second once before it get stopped and never retriggered. Currently I've 2 DMA channel one for TX and another for RX I've changed my DTS and update my fsl_ssi to handle new clocks, I guess only the CLK_SPBA has improved my situation. I've also tried to enable both RIE and TIE to service the ISR, with and without SSI DMA support, but this end with a full system freeze.
I got this system freeze too when enabling RIE and TIE because the interrupts TFE1IE, TFE0IE, TDE1IE, TDE0IE are *enabled* at reset. (Check ref manual 61.9.5). which I suspect was a livelock kind of situation where the ISR is just called infinitely often. After disabling those, then the system worked okay. Check out the previous patch I sent on the issue yesterday or the day before.
Ooohh!!! Forgot to check this!!! I'm now going to mask them!!!
Doesn't work for me! Still freeze the system! SIER=0x01d005f4
I thought the same but setting only RFF0, TFE0, RDMAE and TDMAE along the RIE and TIE still free the system.
You still have many per-frame interrupts enabled, which is still too many enabled. for example, you have RLSIE, TLSIE, RFSIE, TFSIE, etc. These all generate one interrupt per frame, and not necessarily at the same time, so you could be having 4 or more interrupts per frame. Be sure they're all zero except for the DMA enable and the specific ones you actually want enabled.
Yep! But I still think that the CPU should be able to handle all them.
-C _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel