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

[Nicolin Chen]

On Fri, Oct 30, 2015 at 12:42:53PM +0100, Roberto Fichera wrote:


>         /*
>          * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
>          * don't use FIFO 1.  We program the transmit water to signal a
>          * DMA transfer if there are only two (or fewer) elements left
>          * in the FIFO. 
>          */

> SSI clock calculated and then enabled. Both TX and RX DMA channel are requested in the probe() function as below.
> and the corresponding TX and RX SDMA event in DTS are using the default from imx6sx.dtsi:

Since you are using single FIFO configuration, which SDMA script
are you using? This should reflects in the Device Tree. As far as
I learned, FSL 3.14 is using number 22 for SSIs which is the one
for Dual FIFO Mode.

> At this time I should see the DMA callbacks called every burst_size words. This behaviour
> doesn't really happen as I wish because I can see from a proc file that such callbacks
> are called from 1 to 20000 times and then anymore. This is also confirmed by the fact that
> the interrupt 34 (sdma) doesn't increase anymore but matches my internal counters collected
> within my callbacks. Here is what I can inspect from the data I have collected:

Just for clarification, the behaviour doesn't happen as you wish
is just the DMA stopped? I remember you also mentioned bit clock
has stopped as you can check the clock status from the Codec chip.

> SSI Registers:
>         ssi_sfcsr=0x0088f088

At this point you have data in RxFIFO and get empty in TxFIFO, so
the DMA requests from both side should be issued. If the DMA stops
as you described, you must check those two channels from the SDMA
side by dumping SDMAARM_STOP_STAT, SDMAARM_HSTART, SDMAARM_EVTOVR,
SDMAARM_EVTPEND, SDMAARM_EVTERR, SDMAARM_DSPOVR and SDMAARM_HOSTOVR
registers.

Overall, I don't see an obvious defect from you SSI side, but you
may also try to toggle TDMAE and RDMAE at the point that callback
stops -- re-raise the DMA requests by disabling and enabling TDMAE
and RDMAE again and see if it works. I think either something did
intervene register controls of SDMA or SSI, or SDMA have missed the
request signals from SSI.