On 10/29/2015 05:39 PM, Caleb Crome wrote: > On Thu, Oct 29, 2015 at 9:34 AM, Roberto Fichera <kernel@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote: >>>>> On 10/29/2015 03:55 PM, Caleb Crome wrote: >>>>>> On Thu, Oct 29, 2015 at 6:44 AM, Caleb Crome <caleb@xxxxxxxxx> wrote: >>>>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka@xxxxxxxxx> 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: >>>>>> 1) use scope to capture the TDM bus. Trigger on first data change >>>>>> 2) aplay myramp.wav >>>>>> 3) If okay, ctrl-c and goto 2. >>>>>> 4) 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@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
