Device tree configuration for SGTL5000 audio codec

Hello,

I’m working with a Colibri iMX6ULL 512MB Wi-Fi / Bluetooth | V1.1A installed on to a custom carrier board. We’re using the following setup:

  • Hardware: Colibri iMX6ULL 512MB WB IT V1.1A
  • Software version: Toradex Embedded Linux Console Demo v2.8b6, release 2019-12-10.
  • Kernel version: 4.9.166 (from git branch Colibri-iMX6ULL_LXDE-Image_2.8b6.184-20190401)
  • I had trouble getting yocto to compile, so I just downloaded and compiled the kernel using colibri-imx6ull_defconfig and added the drivers for the SGTL5000, as shown in the diff attached to this post.

The board has an SGTL5000 codec connected to SAI3, as shown below:

[upload|dwCdUhpxyDcUN+G/40dzAfFsAaM=]

[upload|7pHtV3M/XJoaPQA1kKmUbnBTCOc=]

I’ve been trying to configure the SAI3 port so that in addition to providing sound output to the codec chip, I want it to provide SYS_MCLK as well. I’ve been trying to modify the device tree to achieve this, using some of the existing examples as a reference, but unfortunately, I haven’t been able to get any output on MCLK. If we provide the SGTL5000 with an external MCLK, the SGTL5000 can be probed over the I2C lines just fine, but we get the following error in dmesg:

[    2.105996] sgtl5000 0-000a: sgtl5000 revision 0x11
[    2.117718] sgtl5000 0-000a: Using internal LDO instead of VDDD: check ER1
[    2.166052] imx-sgtl5000 sound: ASoC: CPU DAI (null) not registered
[    2.176372] imx-sgtl5000 sound: snd_soc_register_card failed (-517)
[    2.452564] imx-sgtl5000 sound: ASoC: CPU DAI (null) not registered
[    2.460539] imx-sgtl5000 sound: snd_soc_register_card failed (-517)
[    2.958312] imx-sgtl5000 sound: ASoC: CPU DAI (null) not registered
[    2.968292] imx-sgtl5000 sound: snd_soc_register_card failed (-517)
[    3.130565] imx-sgtl5000 sound: ASoC: CPU DAI (null) not registered
[    3.138826] imx-sgtl5000 sound: snd_soc_register_card failed (-517)

Here’s the device tree I’m using:

/dts-v1/;

#include "imx6ull-colibri.dtsi"
#include "imx6ull-colibri-eval-v3.dtsi"

/ {
	model = "Precept Health MedManager";
	compatible = "toradex,colibri_imx6ull-wifi-eval", "fsl,imx6ull";

	clocks {
		mclk: mclk {
			compatible = "fixed-clock";
			#clock-cells = <0>;
			clock-frequency = <12288000>;
		};
	};

	sound {
		compatible = "fsl,imx-audio-sgtl5000";
		model = "imx-audio-sgtl5000";
		ssi-controller = <&sai3>;
		asrc-controller = <&asrc>;
		codec-master;
		cpu-dai = <&sai3>;
		audio-codec = <&sgtl5000>;
		audio-routing =
			"Line Out Jack", "LINE_OUT";
		mux-int-port = <1>;
		mux-ext-port = <3>;
	};
};

/delete-node/ &mcp251x0;
/delete-node/ &atmel_mxt_ts;
/delete-node/ &touch;

&spidev0 {
	status = "okay";
};

&i2c1 {
	sgtl5000: codec@a {
		compatible = "fsl,sgtl5000";
		reg = <0xa>;
		clocks = <&mclk>;
		micbias-resistor-k-ohms = <2>;
		micbias-voltage-m-volts = <2250>;
		VDDA-supply = <&reg_module_3v3>;
		VDDIO-supply = <&reg_module_3v3>;

		status = "okay";
		/*#sound-dai-cells = <0>;*/
	};
};

&pinctrl_lcdif_dat {
	fsl,pins = <>;
};

&pinctrl_lcdif_ctrl {
	fsl,pins = <>;
};

&pinctrl_pwm7 {
	fsl,pins = <>;
};

&pinctrl_hog_4 {
	fsl,pins = <>;
};

&pinctrl_hog_2 {
	fsl,pins = <>;
};

&iomuxc {
	imx6ull-colibri {
		pinctrl_sai3: sai3grp {
			fsl,pins = <
				MX6UL_PAD_LCD_DATA13__SAI3_TX_BCLK 0x17088
				MX6UL_PAD_LCD_ENABLE__SAI3_TX_SYNC 0x17088
				MX6UL_PAD_LCD_DATA15__SAI3_TX_DATA 0x11088
				MX6UL_PAD_LCD_DATA14__SAI3_RX_DATA 0x11088
				MX6UL_PAD_LCD_DATA09__SAI3_MCLK 0x17088
			>;
		};

		pinctrl_htrc: htrcgrp {
			fsl,pins = <
				MX6UL_PAD_ENET1_TX_CLK__GPIO2_IO06 0x74
				MX6UL_PAD_CSI_DATA07__GPIO4_IO28	0x74
				MX6UL_PAD_CSI_DATA04__GPIO4_IO25	0x74
			>;
		};
	};
};

&sai3 {
	#sound-dai-cells = <0>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_sai3>;
	assigned-clocks = <&clks IMX6UL_CLK_SAI3_SEL>,
			  <&clks IMX6UL_CLK_SAI3>;
	assigned-clock-parents = <&clks IMX6UL_CLK_PLL4_AUDIO_DIV>;
	assigned-clock-rates = <0>, <12288000>;
	fsl,sai-mclk-direction-output;
	status = "okay";
};

I’ve attached the dmesg log output here.
The output of clk_summary can be found here.

Can anyone help us identify what’s wrong here? Thanks,

Hi @amrbekhit and Welcome to the Toradex Community!

Could you provide the version of the hardware and software of your module?
Regarding the device-tree changes, which kernel branch are you using?

Could you share the changes you have done in kernel branch ( git diff ) ?

Thanks and best regards,
Jaski

Hi @jaski.tx. I’ve updated the question to include the necessary information. Please let me know if there’s anything missing.

Dear @amrbekhit , just a quick check but did you disable the LCD pins that are enabled by default in the device tree for those pins?

For instance, X1_48 I believe to be enabled as LCDIF.DATA(9) to which you correctly set to MX6UL_PAD_LCD_DATA09__SAI3_MCLK but not sure if you have disabled the default definition.

One of the DTSI you are using ( imx6ull-colibri-eval-v3.dtsi ), has the following definition which I’m not sure you have changed.

https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/imx6ull-colibri.dtsi?h=toradex_4.9-2.3.x-imx-next#n422
https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/imx6ull-colibri.dtsi?h=toradex_4.9-2.3.x-imx-next#n184
https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi?h=toradex_4.9-2.3.x-imx-next#n171

Kindly let us know.

Kind regards,
Alvaro.

@alvaro.tx Thanks for your response.

I had disabled the default definitions using the following lines in the dts (the kernel complains of a pin conflict otherwise):

 &pinctrl_lcdif_dat {
     fsl,pins = <>;
 };
 
 &pinctrl_lcdif_ctrl {
     fsl,pins = <>;
 };

I hadn’t disabled lcdif. I’ve just tried to do that as follows:

&lcdif {
		status = "disabled";
};

Unfortunately, I’m still getting the same errors. I also tried removing those nodes completely using:

/delete-node/ &lcdif;
/delete-node/ &pinctrl_lcdif_dat;
/delete-node/ &pinctrl_lcdif_ctrl;

Still getting the same result.

Hi @amrbekhit

You can also set the nodes to disabled ( status = “disabled”) instead on deleting them.

Where did you set the delete-node property?

Could you share the dmesg log in a text file?
Thanks

Best regards,
Jaski

@jaski.tx

If you have a look at the full dts file in the forum post, I have a couple of /delete-node/ lines. I added the lcd /delete-node/ entries there.

I’ve attached the dmesg file to the original post.

Also would it be possible for a moderator to approve this post please? Other members of the company would like to view the forum post.

Thanks @amrbekhit, let us check and we will get back to you.

Noted, I’ve just informed our IT moderation team to approve this post. Hopefully it can be done shortly. Thanks for your patience.

Hi @amrbekhit ,

What frequency do you want to configure for SAI3_MCLK?
Could you please attach the output of /sys/kernel/debug/clk/clk_summary .

Hi @deven.tx
We’re trying to generate a 12.288MHz clock (see the DTS file line 105).
I’ve attached clk_summary to the original post.

Hi @amrbekhit ,

From clk_summery I can see that you are getting 12.288MHz clock at SAI3_MCLK.
Could you please confirm the same at MX6UL_PAD_LCD_DATA09__SAI3_MCLK pin using an oscilloscope.

@deven.tx I’ll ask our hardware guy to check again - we weren’t able to measure a clock on the scope. Potentially we might have a hardware issue.

In any case, the MCLK issue is somewhat secondary, because when we apply an external clock, the SGTL becomes visible on the I2C bus, but despite that, it is not being registered as an audio card. Could we have a look at that issue please?

@amrbekhit ,
Could you please confirm the SGTL5000 is detecting successfully by i2c or not.
You can use the “i2cdetect -y 0” command. Please attach the output here.

Could you also try by connecting,
I2S_DIN → SAI3_TX_DATA,
I2S_DOUT → SAI3_RX_DATA

@deven.tx The chip is detected via I2C - please see the output of dmesg in the orignal post.

I’ll pass on your suggestion of swapping I2S_DIN/I2S_DOUT to our hardware team and get back to you.

Hi @amrbekhit: Did the swapping or I2S_DIN vs I2S_DOUT help to fix the issue?

Best regards,
Jaski

@jaski.tx we did swap the pins (that was indeed a mistake in the layout), but unfortunately we’re still getting the same errors as the ones in my original post.

Hi @amrbekhit , thanks for the update. Noted. Can you please confirm that the clock is actually generated from the expected pin with the given changes? We will also check ourselves.

@alvaro.tx Thanks for your response and for your help so far. Can we put the clock issue to one side and see if we can try and solve the snd_soc_register_card failed (-517) error please? For the time being, we’ve bypassed the clock issue by soldering a fixed oscillator to the SGTL, which has allowed us to view it via I2C. As you can see from dmesg, it has been detected, but it seems that there is a problem with the SAI3 device. I’d be grateful if we could focus on solving that please.