Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Roberto Fichera <kernel@tekno-soft.it>]

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:
>>>> 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

>
>>> 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.
> Ah! Thanks! The reference manual is really clear to explain it :-D !
>
>> 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) {
> Yep! I know such piece of code.
>
>>> 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
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>