On 10/28/2015 03:24 PM, Caleb Crome wrote:
On Wed, Oct 28, 2015 at 7:05 AM, Roberto Fichera kernel@tekno-soft.it wrote:
On 10/28/2015 02:59 PM, Caleb Crome wrote:
On Wed, Oct 28, 2015 at 1:11 AM, Roberto Fichera kernel@tekno-soft.it wrote:
On 10/27/2015 07:57 PM, Fabio Estevam wrote:
[Adding Roberto in the thread as he is also trying to get SSI TDM support/
Thanks Fabio,
I'm also having the same issue but employing SSI in TDM master mode against a SLIC Si32178 using its PCM mode. PCLK is at 2048KHz, FSYNC is 8KHz slot length is 32 bits (SSI wants this since when in master mode) but valid data set to be 8bits in the SSI register.
My Current situation is that I've a custom fsl_ssi.c driver to control the SSI in TDM master mode both PCLK and FSYNC works perfectly fine, the SLIC has a register that I can check via SPI for such purpose, I can see the clocking status from its side. The main problem I've is exactly the same Caleb is having, after a certain amount of SDMA transfers, roughly 1000 or so, everything stops without any apparent reason.
My problem is that the channels randomly slip a slot and all words end up in the wrong slot. I suspect this is a DMA issue, but I really haven't diagnosed it yet. I don't get a full stop on the data.
Ah! Ok!
FYI, I'm using a very recent 4.3 kernel from linus's repo, but 4.2 behaved the same.
Can you please post the code you are using to setup the SSI, what PCLK and FSYNC rates?
My codec is generating the clocks and the MX6 is in slave mode. PCLK (I assume that's the bit clock or BCLK in my workld) is 12.288MHz,
Yes! I meant BCLK.
and the FSYNC is 48kHz. 16 channels/frame, 16 bits/channel.
Ok! In my case it's BCLK at 2048KHz and FSYNC 8KHz, 8 slots at 8bits
I hardly changed the SSI driver at all. It's goofy now for sure because I force it to 16 slots/frame no matter what, so beware. Other than that, I also set the STCCR for 16 channels and set channels_max to 16.
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 37c5cd4..73778c2 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -749,7 +749,10 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream, CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK, channels == 1 ? 0 : i2smode); }
- ssi_private->i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET;
- regmap_update_bits(regs, CCSR_SSI_SCR,
CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK,ssi_private->i2s_mode);@@ -863,6 +866,15 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev, return -EINVAL; } scr |= ssi_private->i2s_mode;
// Set to 16 slots/frame
regmap_update_bits(regs, CCSR_SSI_STCCR,
CCSR_SSI_SxCCR_DC_MASK,CCSR_SSI_SxCCR_DC(16));regmap_update_bits(regs, CCSR_SSI_SRCCR,
CCSR_SSI_SxCCR_DC_MASK,CCSR_SSI_SxCCR_DC(16));/* DAI clock inversion */ switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
@@ -1084,14 +1099,14 @@ static struct snd_soc_dai_driver fsl_ssi_dai_template = { .playback = { .stream_name = "CPU-Playback", .channels_min = 1,
.channels_max = 2,
.channels_max = 16, .rates = FSLSSI_I2S_RATES, .formats = FSLSSI_I2S_FORMATS,
.channels_max = 2,
.channels_max = 16, .rates = FSLSSI_I2S_RATES, .formats = FSLSSI_I2S_FORMATS,There are other changes I've tried, including watermark changes (check out the alsa-dev archives on this thread for what I did before). This morning I am about to try the watermark changes suggested by Nicolin Chen.
Did you have your own DMA handling?
Nope, I don't really know how to do that. I'm relying on the built in sdma driver (drivers/dma/imx-sdma.c) + fsl pcm (sound/soc/fsl/imx-pcm-dma.c) and my modified fsl_ssi.c driver.
In case you need to increase the SSI clock, have a look at CLK_SSI1_PODF within arch/arm/mach-imx/clk-imx6*.c depending by your SoC, in this file you can change the max clock rate supported by the given SSI clock.
Have you tried to set the SSI in I2S_MODE_SLAVE BTW?
-Caleb
-Caleb
On Tue, Oct 27, 2015 at 2:45 PM, Fabio Estevam festevam@gmail.com wrote:
On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome caleb@crome.org wrote: > On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam festevam@gmail.com wrote: >> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome caleb@crome.org wrote: >> >>>> Could you please try it without using the external SDMA firmware? >>> I do need *some* SDMA firmware, correct? The firmware that I'm using >>> ends up in /lib/firmware/imx/sdma/sdma-imx6q.bin and is md5sum >>> 5d4584134cc4cba62e1be2f382cd6f3a. >> SSI can operate with the ROM SDMA firmware. >> >> I would like to know if this issue also happens if you don't pass the >> external firmware and use the internal ROM SDMA firmware instead. > Ah, good to know. Do I just remove reference in the .dtsi file? > Remove the file from the filesystem? I'll do both to be doubly sure > :-) Just remove it from the rootfs. Then you will see a message from the kernel saying that no external SDMA firmware could be found and that the internal one is going to be used.
>> Also, could you try bumping the SSI and SDMA clock rates at the maximum? > Any idea how I do that? I guess it's in the .dtsi file perhaps? I'll > poke around. You can try to call clk_set_rate() with the maximum allowed frequency inside the ssi driver. I don't recall on top of my head what is this value though.
Regards,
Fabio Estevam
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
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel