| Message ID | 1384878685-1515-3-git-send-email-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2013/11/19 Zhong Li <zql@glomationinc.com>: > When playing stereo sound on the Atmel at91sam9x5-ek board the left and > right channel would get swapped about 1 in 6 tries. Can you give a little more background ? : - What kernel ? - Command line to reproduce ? Richard.
> Can you give a little more background ? : > - What kernel ? > - Command line to reproduce ? > > Richard. One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board). We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc. The command to test the sound is just the simple aplay <sound-test-file>. The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing. Thanks
[added Nicolas Ferre and Bo Shen ] 2013/11/19 Zhong Li <zql@glomationinc.com>: >> Can you give a little more background ? : >> - What kernel ? >> - Command line to reproduce ? >> >> Richard. > > One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board). We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc. The command to test the sound is just the simple aplay <sound-test-file>. The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing. > > Thanks Ok, I reproduce the bug on g35-ek with a v3.11.7+(sam9x5 sound patches) kernel So, *sometimes*, the left and right channel are swapped. ( I found also the ratio 1 out of 6 (but once it has happened, it seems to be more often)) I tested that with the file given by Zhong Li, and with a file I created with audacity (440Hz only on right channel). I could see at the scope that the channels are swapped before the w8731 codec (the data on the TD line are sometime on the low edge of TF, instead of always being on the high edge (I2S mode)). There's, in both cases, a clock period (TK) between the rising/falling edge of TF and the 1st data bit on TD, so the mode is always I2S, and the channel data are swapped. I'll try to have a look (but I don't have much time right now) If someone could test that on a sam9g20 or a WM8904 based board, since they share the same DAI format, they may have the same problem. Thanks ! Richard
2013/11/20 Richard Genoud <richard.genoud@gmail.com>: > [added Nicolas Ferre and Bo Shen ] > > 2013/11/19 Zhong Li <zql@glomationinc.com>: >> >> One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board). We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc. The command to test the sound is just the simple aplay <sound-test-file>. The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing. >> >> Thanks > > Ok, I reproduce the bug on g35-ek with a v3.11.7+(sam9x5 sound patches) kernel > > So, *sometimes*, the left and right channel are swapped. ( I found > also the ratio 1 out of 6 (but once it has happened, it seems to be > more often)) > I tested that with the file given by Zhong Li, and with a file I > created with audacity (440Hz only on right channel). > I could see at the scope that the channels are swapped before the > w8731 codec (the data on the TD line are sometime on the low edge of > TF, instead of always being on the high edge (I2S mode)). > There's, in both cases, a clock period (TK) between the rising/falling > edge of TF and the 1st data bit on TD, so the mode is always I2S, and > the channel data are swapped. > > I'll try to have a look (but I don't have much time right now) > > If someone could test that on a sam9g20 or a WM8904 based board, since > they share the same DAI format, they may have the same problem. After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I don't understand how the right and left channel are synchronized. (which one will be on TF rising edge, and which one on TF falling edge ?) In the SSC_TCMR register, the start event is TF_FALLING when there only one channel (i.e. mono source always on left channel) With a stereo source, it's TF_EDGE (Detection of any edge on TF signal) ; so the samples are transferred on rising and falling edge. I didn't see anything in the SSC what could synchronize the first sample with a TF falling edge. Or I missed something ? Nicolas, Bo, any idea ? Richard.
> > After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I > don't understand how the right and left channel are synchronized. > (which one will be on TF rising edge, and which one on TF falling edge > ?) > In the SSC_TCMR register, the start event is TF_FALLING when there only > one channel (i.e. mono source always on left channel) With a stereo > source, it's TF_EDGE (Detection of any edge on TF > signal) ; so the samples are transferred on rising and falling edge. > I didn't see anything in the SSC what could synchronize the first > sample with a TF falling edge. > Or I missed something ? > The codec seems to be set to I2S mode based on the parameter name. And the FSOS field in the TFMR is set to be negative pulse. So it matches the I2S mode diagram (Figure 27 of WM8731 datasheet). The high to low on DACLRC (TF line aka PA25 pin) indicate start of the left channel data. Looks like the TF signal is automatically generated by the SSC controller according to the TFMR settings.
2013/11/20 Zhong Li <zql@glomationinc.com>: >> >> After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I >> don't understand how the right and left channel are synchronized. >> (which one will be on TF rising edge, and which one on TF falling edge >> ?) >> In the SSC_TCMR register, the start event is TF_FALLING when there only >> one channel (i.e. mono source always on left channel) With a stereo >> source, it's TF_EDGE (Detection of any edge on TF >> signal) ; so the samples are transferred on rising and falling edge. >> I didn't see anything in the SSC what could synchronize the first >> sample with a TF falling edge. >> Or I missed something ? >> > > > The codec seems to be set to I2S mode based on the parameter name. And the FSOS field in the TFMR is set to be negative pulse. So it matches the I2S mode diagram (Figure 27 of WM8731 datasheet). The high to low on DACLRC (TF line aka PA25 pin) indicate start of the left channel data. Looks like the TF signal is automatically generated by the SSC controller according to the TFMR settings. Yes, we use the I2S mode as in wm8731-figure27. But the WM8731 is in master mode (wm8731-figure3). So it provides BCLK (TK) and frame clock (DACLRC (TF)). That's set in sam9x5_wm8731.c : dai->dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM; DAIFMT_I2S : I2S mode obviously (wm8731 reg 7 bit 0:1 = 2) DAIFMT_NB_NF : clock frames phasing (wm8731 reg7 bit4=0, bit7=0 : Left channel when DAC is low and BCKL not inverted) DAIFMT_CBM_CFM : master mode (wm8731 reg7 bit6=1 ) And I think you read the wrong value for the FSOS field of TFMR register : in the I2S + CBM_CFM case, it's set to 0 because TF pin is an input for the SSC. So yes, the wm8731 generates the TK and TF signals and the SSC is configured to send 16bits data on every TF edge (SSC_START_EDGE_RF). The SSC_FSEDGE_POSITIVE flag will trigger the TXSYN interrupt on a TF positive edge. That's a way to get the sync between right/left channel I think : If we set SSC_FSEDGE_POSITIVE, and enable the TXSYN interrupt, at the first interrupt received we could start the DMA transfer (and disable the interrupt). The SSC will then send the 1st data (left data) on the next TF edge which will be a negative edge (left channel). Richard
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index f7644fe..e30ef67 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -299,7 +299,6 @@ struct omap_sdrc_params; extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0, struct omap_sdrc_params *sdrc_cs1); struct omap2_hsmmc_info; -extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers); extern void omap_reserve(void); struct omap_hwmod; diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 5791143..b39efd4 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -35,7 +35,6 @@ #include "iomap.h" #include "common.h" #include "mmc.h" -#include "hsmmc.h" #include "prminst44xx.h" #include "prcm_mpu44xx.h" #include "omap4-sar-layout.h" @@ -284,59 +283,3 @@ skip_errata_init: omap_wakeupgen_init(); irqchip_init(); } - -#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE) -static int omap4_twl6030_hsmmc_late_init(struct device *dev) -{ - int irq = 0; - struct platform_device *pdev = container_of(dev, - struct platform_device, dev); - struct omap_mmc_platform_data *pdata = dev->platform_data; - - /* Setting MMC1 Card detect Irq */ - if (pdev->id == 0) { - irq = twl6030_mmc_card_detect_config(); - if (irq < 0) { - dev_err(dev, "%s: Error card detect config(%d)\n", - __func__, irq); - return irq; - } - pdata->slots[0].card_detect_irq = irq; - pdata->slots[0].card_detect = twl6030_mmc_card_detect; - } - return 0; -} - -static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev) -{ - struct omap_mmc_platform_data *pdata; - - /* dev can be null if CONFIG_MMC_OMAP_HS is not set */ - if (!dev) { - pr_err("Failed %s\n", __func__); - return; - } - pdata = dev->platform_data; - pdata->init = omap4_twl6030_hsmmc_late_init; -} - -int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers) -{ - struct omap2_hsmmc_info *c; - - omap_hsmmc_init(controllers); - for (c = controllers; c->mmc; c++) { - /* pdev can be null if CONFIG_MMC_OMAP_HS is not set */ - if (!c->pdev) - continue; - omap4_twl6030_hsmmc_set_late_init(&c->pdev->dev); - } - - return 0; -} -#else -int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers) -{ - return 0; -} -#endif
This is no longer used, omap4 is device tree based now. Signed-off-by: Tony Lindgren <tony@atomide.com> --- arch/arm/mach-omap2/common.h | 1 - arch/arm/mach-omap2/omap4-common.c | 57 -------------------------------------- 2 files changed, 58 deletions(-)