On 10/31/2015 10:16 AM, Roberto Fichera wrote:
And here's Nicolin's reply: 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.
No! Currently is 1. Here the Freescale's v3.14.28 GA imx6sx.dtsi entry
ssi1: ssi@02028000 { compatible = "fsl,imx6sx-ssi", "fsl,imx21-ssi"; reg = <0x02028000 0x4000>; interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6SX_CLK_SSI1_IPG>, <&clks IMX6SX_CLK_SSI1>; clock-names = "ipg", "baud"; dmas = <&sdma 37 1 0>, <&sdma 38 1 0>; dma-names = "rx", "tx"; status = "disabled"; };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.
Sorry, maybe I've used a wrong sentence. All clocks to SLIC are currently ok, checked with a logical analyser and both are working as expected.
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.
Ok! I will do! Should I do within the SDMA isr or do you prefer another place?
Below there is both SSI and SDMA status as soon as SDMA stops operating, I've also moved all code to kernel v4.3 just published this morning:
root@voneus-domus-imx6sx:~# cat /proc/domus_ssi_stats SSI TDM Info: PLL clk=66000000 SSI baudclk=49152000 ssi_phy=0x02028000 irq=21 fifo_depth=8 tdm_frame_rate=8000 tdm_slots=32 (real 2) tdm_word_size=8 tdm_slots_enabled=00000000000000000000000000000011 clk_frequency=2048000 clock_running=yes DMA=yes Dual FIFO=no RX DMA frame count=33758 RX DMA addr=0x9edad000 RX DMA buffer len=16 TX DMA frame count=33758 TX DMA addr=0x9ed7f000 TX DMA buffer len=16
SSI Registers: ssi_scr=0x0000009f ssi_sier=0x00500004 ssi_stcr=0x000002e8 ssi_srcr=0x00000288 ssi_stccr=0x00007f0b ssi_srccr=0x00007f0b ssi_sfcsr=0x0088f088 ssi_stmsk=0xfffffffc ssi_srmsk=0xfffffffc
SSI SISR Register: rfrc=0 tfrc=0 cmdau=0 cmddu=0 rxt=0 rdr1=0 rdr0=0 tde1=0 tde0=0 roe1=0 roe0=0 tue1=0 tue0=0 tfs=0 rfs=0 tls=0 rls=0 rff1=0 rff0=0 tfe1=0 tfe0=0
SDMA RX channel: SDMA channel 4 status SDMA_H_STATSTOP=0x00000000 SDMA_H_START=0x00000000 SDMA_H_EVTOVR=0x00000001 SDMA_H_EVTPEND=0x0000001a SDMA_H_EVTERR=0x00000018 SDMA_H_DSPOVR=0xffffffff SDMA_H_HOSTOVR=0x00000000
SDMA TX channel: SDMA channel 3 status SDMA_H_STATSTOP=0x00000000 SDMA_H_START=0x00000000 SDMA_H_EVTOVR=0x00000001 SDMA_H_EVTPEND=0x0000001a SDMA_H_EVTERR=0x00000000 SDMA_H_DSPOVR=0xffffffff SDMA_H_HOSTOVR=0x00000000
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,
I will try this one.
I will go over this tomorrow morning.
or SDMA have missed the request signals from SSI.
This is my current thought. However since the SSI is not operating at so high rate and the Cabel's problem seems going to a solution then I think there is something else I'm missing.
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