[alsa-devel] fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Caleb Crome]

On Thu, Oct 29, 2015 at 9:34 AM, Roberto Fichera <kernel at 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 at 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 at crome.org> wrote:
>>>>>> On Wed, Oct 28, 2015 at 9:53 PM, Nicolin Chen <nicoleotsuka at 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:
>>>>> 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

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.

-C