[alsa-devel] imx-ssi.c & SND_SOC_DAIFMT_I2S
Hi Sascha,
while trying to get a TI TLV320AIC23B codec configured as I2S master to work with an i.MX27 using the latest git kernel, I noticed there may be a problem in the slave I2S setting in imx-ssi.c
Please find two captures of the I2S bus signals : - http://eukrea.com/tmp/initial_i2s.png : this is not an I2S signal, both left & right are sent while Frame Sync is high (so I only get mono output) - http://eukrea.com/tmp/i2s_slave.png : when I set I2S_MODE to 0x2 in SCR register (scr |= SSI_SCR_NET | 0x40; at line 101 of imx-ssi.c), thus setting the SSI in "I2S slave mode", I get a real I2S signal as shown on this capture.
I understand the actual I2S configuration may work with the Freescale's PMIC but this chipset may not be fully I2S compliant and I think that the actual setting prevent real I2S codecs from being used with the i.MX.
Am I wrong here ? Shouldn't we use the I2S slave mode of the SSI instead of what is done actually ?
Thanks and best regards, Eric
Hi Eric,
On Wed, May 26, 2010 at 11:34:08AM +0200, Eric Bénard wrote:
Hi Sascha,
while trying to get a TI TLV320AIC23B codec configured as I2S master to work with an i.MX27 using the latest git kernel, I noticed there may be a problem in the slave I2S setting in imx-ssi.c
Please find two captures of the I2S bus signals :
- http://eukrea.com/tmp/initial_i2s.png : this is not an I2S signal,
both left & right are sent while Frame Sync is high (so I only get mono output)
- http://eukrea.com/tmp/i2s_slave.png : when I set I2S_MODE to 0x2 in
SCR register (scr |= SSI_SCR_NET | 0x40; at line 101 of imx-ssi.c), thus setting the SSI in "I2S slave mode", I get a real I2S signal as shown on this capture.
I understand the actual I2S configuration may work with the Freescale's PMIC but this chipset may not be fully I2S compliant and I think that the actual setting prevent real I2S codecs from being used with the i.MX.
Am I wrong here ? Shouldn't we use the I2S slave mode of the SSI instead of what is done actually ?
I just had a look at the oscilloscope. For me it seems to make no difference whether I use I2S mode or what is done in current driver. Both look like your second picture. So we can change it if there are no other objections.
Sascha
Hi Sascha,
Le 26/05/2010 12:37, Sascha Hauer a écrit :
I just had a look at the oscilloscope. For me it seems to make no difference whether I use I2S mode or what is done in current driver. Both look like your second picture.
strange, here that's not the case, if I don't add this, I get the first picture (left & right data on the same frame half period).
One thing : I'm using i.MX27's SSI port 4 which may be "special" as it can be host or device port, do you think this could make a difference vs your configuration ?
Eric
On Wed, May 26, 2010 at 11:34:08AM +0200, Eric B?nard wrote:
while trying to get a TI TLV320AIC23B codec configured as I2S master to work with an i.MX27 using the latest git kernel, I noticed there may be a problem in the slave I2S setting in imx-ssi.c
Please find two captures of the I2S bus signals :
- http://eukrea.com/tmp/initial_i2s.png : this is not an I2S signal,
both left & right are sent while Frame Sync is high (so I only get mono output)
- http://eukrea.com/tmp/i2s_slave.png : when I set I2S_MODE to 0x2 in
SCR register (scr |= SSI_SCR_NET | 0x40; at line 101 of imx-ssi.c), thus setting the SSI in "I2S slave mode", I get a real I2S signal as shown on this capture.
What are these captures actually of? The current mainline driver does not support master mode so whatever you're capturing won't have been generated by the i.MX. If you've implemented master mode it'd be nice to post the patch for this...
Am I wrong here ? Shouldn't we use the I2S slave mode of the SSI instead of what is done actually ?
If I remember correctly the I2S slave mode isn't exactly I2S compliant either and is actually just setting up similar settings to override other registers. I could be wrong, or this could have changed in later i.MXs.
Most of the generic serial ports with an I2S mode aren't actually doing proper I2S but are rather configuring things that look close to it - it's common for them to not be able to tolerate extra BCLKs, for example.
Hi Mark,
Le 27/05/2010 02:56, Mark Brown a écrit :
On Wed, May 26, 2010 at 11:34:08AM +0200, Eric B?nard wrote:
while trying to get a TI TLV320AIC23B codec configured as I2S master to work with an i.MX27 using the latest git kernel, I noticed there may be a problem in the slave I2S setting in imx-ssi.c
Please find two captures of the I2S bus signals :
- http://eukrea.com/tmp/initial_i2s.png : this is not an I2S signal,
both left& right are sent while Frame Sync is high (so I only get mono output)
- http://eukrea.com/tmp/i2s_slave.png : when I set I2S_MODE to 0x2 in
SCR register (scr |= SSI_SCR_NET | 0x40; at line 101 of imx-ssi.c), thus setting the SSI in "I2S slave mode", I get a real I2S signal as shown on this capture.
What are these captures actually of? The current mainline driver does not support master mode so whatever you're capturing won't have been generated by the i.MX. If you've implemented master mode it'd be nice to post the patch for this...
the TLV320 is master thus generates clock and framesync the i.MX's SSI is slave thus send data (when playing sound) synchronized on framesync and clock provided by the TLV320.
The problem on the first capture is that the SSI send the data for both channels on one half of the framesync's period => codec outputs sound on only one channel.
By setting the mode to I2S_SLAVE, the SSI send the data the way the codec expect it : one channel when framesync is high and one channel when framesync is low.
Am I wrong here ? Shouldn't we use the I2S slave mode of the SSI instead of what is done actually ?
If I remember correctly the I2S slave mode isn't exactly I2S compliant either and is actually just setting up similar settings to override other registers. I could be wrong, or this could have changed in later i.MXs.
this is what is written in the comment, but in the iMX manual (at least 25 & 27), there is an I2S_SLAVE mode which seems to set more things than what is actually done in the driver as when I enable this, I get a perfect sound of both channels (and recording also works fine).
Eric
On Thu, May 27, 2010 at 03:15:51AM +0200, Eric Bénard wrote:
The problem on the first capture is that the SSI send the data for both channels on one half of the framesync's period => codec outputs sound on only one channel.
By setting the mode to I2S_SLAVE, the SSI send the data the way the codec expect it : one channel when framesync is high and one channel when framesync is low.
Right, this is the thing I was saying about being unable to tolerate extra BCLKs when in I2S mode. In general with these generic serial ports you're much better off using one of the DSP modes, it's what they naturally implement.
If I remember correctly the I2S slave mode isn't exactly I2S compliant either and is actually just setting up similar settings to override other registers. I could be wrong, or this could have changed in later i.MXs.
this is what is written in the comment, but in the iMX manual (at least 25 & 27), there is an I2S_SLAVE mode which seems to set more things than what is actually done in the driver as when I enable this, I get a perfect sound of both channels (and recording also works fine).
That register is present in later i.MX CPUs too, the issue is if it actually does what is expected robustly.
Hi Eric,
I am using the same Devices i.mx27 ssi as a slave and tlv320aic33 as a master.
I am getting the bit clock and word clock but I am not getting the data when I play using aplay command and it is giving the underrun error.
I am using the linux-2.6.32 kernel
I am giving here the register dump.
mx27# aplay test_file.wav dump @ imx_ssi_startup STX0 0 STX1 0 scr 0 sisr 3003 stcr 200 srcr 200 stccr 40000 srccr 40000 sfcsr 440044 stmsk 0 srmsk 0 sier 3003 Playing WAVE 'test_file.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo dump @ imx_ssi_prepare STX0 0 STX1 0 scr 50 sisr 3003 stcr 289 srcr 289 stccr 4e000 srccr 4e000 sfcsr 440044 stmsk 0 srmsk 0 sier 783503 dump @ dma_new_period STX0 0 STX1 0 scr 50 sisr 3003 stcr 289 srcr 289 stccr 4e000 srccr 4e000 sfcsr 440044 stmsk 0 srmsk 0 sier 783503 dump @ dma_new_period STX0 0 STX1 0 scr 50 sisr 3003 stcr 289 srcr 289 stccr 4e000 srccr 4e000 sfcsr 440044 stmsk 0 srmsk 0 sier 783503 dump @ imx_ssi_trigger STX0 0 STX1 0 scr 53 sisr 3001 stcr 289 srcr 289 stccr 4e000 srccr 4e000 sfcsr 440044 stmsk 0 srmsk 0 sier 783503 dump @ audio_dma_irq STX0 0 STX1 0 scr 53 sisr 3001 stcr 289 srcr 289 stccr 4e000 srccr 4e000 sfcsr 440044 stmsk 0 srmsk 0 sier 783503 dump @ imx_ssi_trigger STX0 0 STX1 0 scr 51 sisr 3001 stcr 289 srcr 289 stccr 4e000 srccr 4e000 sfcsr 440044 stmsk 0 srmsk 0 sier 783503 underrun!!! (at least 2.738 ms long) underrun!!! (at least 2.329 ms long) underrun!!! (at least 9.367 ms long) underrun!!! (at least 8.608 ms long) underrun!!! (at least 5.143 ms long) underrun!!! (at least 9.898 ms long) underrun!!! (at least 10.871 ms long) underrun!!! (at least 2.419 ms long) underrun!!! (at least 7.744 ms long) underrun!!! (at least 1.232 ms long) underrun!!! (at least 9.252 ms long) underrun!!! (at least 11.574 ms long) underrun!!! (at least 0.977 ms long) underrun!!! (at least 2.145 ms long) underrun!!! (at least 0.123 ms long) underrun!!! (at least 0.246 ms long) underrun!!! (at least 9.592 ms long) underrun!!! (at least 5.880 ms long) underrun!!! (at least 10.787 ms long) underrun!!! (at least 10.750 ms long) underrun!!! (at least 1.000 ms long) underrun!!! (at least 2.313 ms long) underrun!!! (at least 7.890 ms long) underrun!!! (at least 10.555 ms long) underrun!!! (at least 8.590 ms long) underrun!!! (at least 8.882 ms long) underrun!!! (at least 8.340 ms long) underrun!!! (at least 10.537 ms long) underrun!!! (at least 11.060 ms long) underrun!!! (at least 8.724 ms long) underrun!!! (at least 2.152 ms long) underrun!!! (at least 8.223 ms long) underrun!!! (at least 11.946 ms long) underrun!!! (at least 5.138 ms long) underrun!!! (at least 20.275 ms long) underrun!!! (at least 13.806 ms long) underrun!!! (at least 0.882 ms long) underrun!!! (at least 5.893 ms long) underrun!!! (at least 6.395 ms long) underrun!!! (at least 5.790 ms long) underrun!!! (at least 11.237 ms long) underrun!!! (at least 9.248 ms long) underrun!!! (at least 7.412 ms long) underrun!!! (at least 9.083 ms long) underrun!!! (at least 0.182 ms long) underrun!!! (at least 3.309 ms long) underrun!!! (at least 9.153 ms long) underrun!!! (at least 9.418 ms long) underrun!!! (at least 8.878 ms long) underrun!!! (at least 6.878 ms long) underrun!!! (at least 9.293 ms long) underrun!!! (at least 8.395 ms long) underrun!!! (at least 9.006 ms long) underrun!!! (at least 9.996 ms long) underrun!!! (at least 0.635 ms long) underrun!!! (at least 10.810 ms long) underrun!!! (at least 10.753 ms long) underrun!!! (at least 1.756 ms long) underrun!!! (at least 1.574 ms long) imx_dma_free: trying to free free channel 8 mx27#
Please send me the configuration [if any changes] from i.mx ssi slave and tlv320aic33.
Thanks & Regards, Anil.
Hi Anil,
Le 23/06/2010 12:15, anilkumar a écrit :
Please send me the configuration [if any changes] from i.mx ssi slave and tlv320aic33.
I'm using TLV320AI23 and not the 33 so I don't know the necessary changes for your codec but this look like you could start from eukrea-tlv320.c and update it for tlv320aic33.
Eric
participants (4)
-
anilkumar -
Eric Bénard -
Mark Brown -
Sascha Hauer