No data output on I2S

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

No data output on I2S

Jump to solution
1,214 Views
travisr
Contributor II

I have setup a machine driver and device tree to connect the in-tree Maxim 98357a codec driver to SSI1 via the AUD3 external port (see attached files) on a Boundary Devices Nitrogen6x SOM V2, starting with the Boundary Devices 4.9.x kernel and the machine driver in the thread here. The card is successfully registered, but when I use speaker-test or aplay I can see that the TXD signal is constant low even though the TXC and TXFS signals are toggling at the expected rates. Here's where I currently stand:

  1. The aplay and speaker-test apps enter a 'hung' state after starting playback and when I send SIGINT (CTRL-C) they indicate that the pcm_write system call was interrupted.
  2. By adding prints to fsl_ssi.c, I can see that the start of playback correctly results in a call to fsl_ssi_config, where the code reports that there are a few entries in the FIFO before setting the TE bit in SCR (as confirmed by a readback of the register).
  3. I'm not sure whether FIQ mode is fully supported, but when I try it (by setting fsl,fiq-stream-filter in the device tree) the aplay and speaker-test calls result in same phenomenon with the TXD, TXC and TXFS signals, and the application reports a continual string of 'underrun' messages instead of getting hung up.

So it currently appears that the SSI simply isn't pulling from the FIFOs into the shift register. This obviously would prevent data from appearing on TXD and would be consistent with the DMA buffer filling up and causing the pcm_write call to block. I would expect overrun instead of underruns with FIQ mode, but I haven't explored that in detail. Regardless, it isn't clear to me what could cause this situation to arise. As noted, the TE bit is definitely being set in SCR.

Please advise if you see anything amiss or have any suggestions on additional ideas to review. Thanks in advance.

Labels (1)
Tags (2)
0 Kudos
1 Solution
1,027 Views
travisr
Contributor II

Found the problem. The sample machine driver that I had used as my starting point was setting TDM mask bits to zero to indicate the active slot, as is defined by the SSIx_STMSK register. However, since then the fsl_ssi.c module was updated to invert the mask value so that it is consistent with the spec for snd_soc_dai_set_tdm_slot. Once I changed the mask to indicate the active slots with ones, everything worked as expected. The updated imx-max98357a.c file is attached for future reference.

View solution in original post

0 Kudos
2 Replies
1,028 Views
travisr
Contributor II

Found the problem. The sample machine driver that I had used as my starting point was setting TDM mask bits to zero to indicate the active slot, as is defined by the SSIx_STMSK register. However, since then the fsl_ssi.c module was updated to invert the mask value so that it is consistent with the spec for snd_soc_dai_set_tdm_slot. Once I changed the mask to indicate the active slots with ones, everything worked as expected. The updated imx-max98357a.c file is attached for future reference.

0 Kudos
1,027 Views
igorpadykov
NXP Employee
NXP Employee

Hi Travis

also one can try with simple tests described in sect.7.1.5 Unit Test

sect.7.1 Advanced Linux Sound Architecture (ALSA) System on a
Chip (ASoC) Sound attached Linux Manual. Drivers are described in 

Figure 7-1. ALSA SoC Software Architecture, Table 7-1.

Probably one can try unchanged configuration with sgtl5000 and compare

ssi registers with working case.

linux-imx6/imx6qdl-nitrogen6_som2.dtsi at boundary-imx_4.9.x_2.0.0_ga · boundarydevices/linux-imx6 ·... 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos