AnsweredAssumed Answered

MC13783 codec driver problem on 3.X (or later)community Linux version

Question asked by edison xu on Apr 14, 2016
Latest reply on May 17, 2016 by OtavioSalvador

HI Community,

     I'm working on kernel upgrading for FSL 2.6.22 to new community version 3.12 for our customized IMX27 board, and met some problem when porting the MC13783 audio device driver. The hardware schematic for audio part is the same as IMX27 ADS, in which MC13783 audio is connect to IMX27 with two SSI (SSI1/SS2). In the FSL 2.6.22 BSP, the design is the same as the hardware schematic, the alsa driver use SS1 / SS2 as codec and DAC respectively. However, after I works on the 3.12 kernel, if I assign two difference SSI port for MC13783 codec as below

  /* MC13783 */

    static struct mc13xxx_codec_platform_data mx27_ads_codec = {

        .dac_ssi_port = MC13783_SSI2_PORT,

        .adc_ssi_port = MC13783_SSI1_PORT,



     From the latest mc13783 audio driver it will be bind to asynchronized MC13783 DAI for separated routing for AD/DA (mc13783.c), one called mc13783-hifi-playback and the other called mc13783-hifi-capture, but DAI bind will be certainly unsuccessful because on the mc13783 sound soc driver (imx-mc13783.c),  the dai_link name is "mc13783_hifi", so looks like the bind can only be successfully if we use synchronized mode (AD/DA use the same SSI port rather than different ports). That seems to be a big difference between community version and FSL version. My question:

1. Has someone used the asynchronized DAI in their design with community kernel version? Is it  works or tested (I cannot find any reference for mc13783-hifi-playback/mc13783-hifi-capture in the kernel source code)?

2. Can I use synchronized DAI (force ADC/DAC use same SSI) instead of Asynchronized DAI on the community version to make audio works without hardware change? (Unfortunately I have done some experiments but seems not work).


Thanks in advance.