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

[Caleb Crome]

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.
>
> Another thing I'm looking is the sdma events (37 and 38) which are reported by the reference
> manual to
>
> 37 -> SSI1 Receive 0 DMA request
> 38 -> SSI1 Transmit 0 DMA request
>
> along that there are also
>
> 35 -> SSI1 Receive 1 DMA request
> 36 -> SSI1 Transmit 1 DMA request
>
> I don't know actually how the two events types will behaves from the SDMA point of view.

The 35 and 36 are for Dual fifo mode only, and no current system (with
fsl_ssi.c anyway) uses dual fifo mode.  How do I know?  Because the
it's definitely broken in the fsl_ssi.c.  I was just about to report
that bug.

hint:  fsl_ssi.c:  if (ssi_private->use_dma && !ret && dmas[3] ==
IMX_DMATYPE_SSI_DUAL) {
should read  if (ssi_private->use_dma && !ret && dmas[4] ==
IMX_DMATYPE_SSI_DUAL) {

>
> I'm also considering to make plain new audio driver to at least try to use something which
> is supposed to work fine with SSI.

Yeah, maybe that's the easiest way to go just to get operational.
Start with just the bare minimum ssi driver so you know all the
registers are locked into place the way you like.

-caleb