iMX6 Solo AC97 configuration codec LM4549B

[rdk]

Hi,

I'm integrating the linux-imx 5.15 on a G15M-i.MX6 module from iWave that is equiped with an iMX6Solo. I'm having problem interfacing an AC97 codec (LM4549B) which is connected on AUD4_RXD, AUD4_TXFS, AUD4_TXD, AUD4_TXC and GPIO6_IO00 (for reset signal).

The problem is that when fsl-asoc-card driver tries to identifies the codec, it get 0x00 instead of the device id of the CODEC. The following trace can be seen in the dmesg:

fsl-asoc-card sound: AC'97 0 access is not valid [0x0], removing mixer.
ac97-codec ac97-codec.1: ASoC: error at snd_soc_component_probe on ac97-codec.1: -5

The ssi used is ssi2 which is routed to port 4 of the audmux.

I have review the differents drivers (fsl-asoc-card, imx-audmux, fsl-ssi, ...) to track the needed parameters from the device tree. 

/ {

    model = "iwg15m-imx6";

    sound {

        compatible = "fsl,imx-audio-ac97";

        model = "fsl,imx-audio-ac97";

        playback-only;

        audio-cpu = <&ssi2>;

        mux-int-port = <2>;

        mux-ext-port = <4>;

    };

};

&iomuxc {

    ac97 {

        pinctrl_ac97_running: ac97runninggrp {

            fsl,pins = <

                MX6QDL_PAD_SD2_DAT2__AUD4_TXD       0x110b0 /* TXD   */

                MX6QDL_PAD_SD2_DAT1__AUD4_TXFS      0x130b0 /* TXFS  */

                MX6QDL_PAD_SD2_DAT0__AUD4_RXD       0x130b0 /* RXD   */

                MX6QDL_PAD_SD2_DAT3__AUD4_TXC       0x130b0 /* TXC   */

                MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00   0x80000000 /* RESET */

            >;

        };

        pinctrl_ac97_warm_reset: ac97warmresetgrp {

            fsl,pins = <

                MX6QDL_PAD_SD2_DAT1__GPIO1_IO14     0x80000000 /* TXFS  */

                MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00   0x80000000 /* RESET */

            >;

        };

        pinctrl_ac97_reset: ac97resetgrp {

            fsl,pins = <

                MX6QDL_PAD_SD2_DAT1__GPIO1_IO14     0x80000000 /* TXFS  */    

                MX6QDL_PAD_SD2_DAT0__GPIO1_IO15     0x80000000 /* RXD */

                MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00   0x80000000 /* RESET */

            >;

        };

    };

};

&audmux {

    status = "okay";

};

&ssi2 {

    cell-index = <1>;

    fsl,mode = "ac97-slave";

    pinctrl-names = "default", "ac97-running", "ac97-reset", "ac97-warm-reset";

    pinctrl-0 = <&pinctrl_ac97_running>;

    pinctrl-1 = <&pinctrl_ac97_running>;

    pinctrl-2 = <&pinctrl_ac97_reset>;

    pinctrl-3 = <&pinctrl_ac97_warm_reset>;

    ac97-gpios = <&gpio1 14 0 &gpio1 15 0 &gpio6 0 0>;

    status = "okay";

};

The above device is mainly based on imx6qdl-udoo.dtsi and the analysis of the drivers.

I'm having trouble to find what I'm missing, could you please help ?

[JorgeCas]

Hello,

The LM4549B audio CODEC could not be supported in iWave's BSP. To use that CODEC in your system, may you need to add a third-party driver provided by manufacturer and configure your device tree.

Unfortunately, there is not a guide to port this specific CODEC to the BSP in our side. The references we have are the i.MX porting guide.

Here some debugging recommendations:

Check that CODEC voltages are according to manufacturer specifications.

Check that clocks are configured as expected.

When Linux starts, can you see the prompt of audio mapping-->ok?

Best regards.

[rdk]

Hello,

Thank you for response and appologize for my late response. 

From the source of sound/pci/ac97/ac97_codec.c (function snd_ac97_mixer()) it is the following code that is triggering the log trace:

ac97->id = snd_ac97_read(ac97, AC97_VENDOR_ID1) << 16;

 ac97->id |= snd_ac97_read(ac97, AC97_VENDOR_ID2);

  if (! (ac97->scaps & AC97_SCAP_DETECT_BY_VENDOR) &&

      (ac97->id == 0x00000000 || ac97->id == 0xffffffff)) {

           ac97_err(ac97,

               "AC'97 %d access is not valid [0x%x], removing mixer.\n",

             ac97->num, ac97->id);

             snd_ac97_free(ac97);

      return -EIO;

 }

Also from the log trace I can see that higher ac97_codec is using fsl-asoc-card which I believe uses the fsl-ssi driver to access the physical bus. 

So my question is why shall I implement a driver when the generic ac97_codec should be sufficient ?

Thanks in adavance,