SGTL5000 bring up & audio routing questions

I am working on rewriting a BSP to use the stock kernel. I have everything else on the board working except the audio, so recompiling just for that is something I really, really want to avoid.
Im aware of this thread, and in fact am using the same carrier board, but reimplementing their patches to make it cleaner.

The carrier I am using has a SGTL5000 audio codec on board with its mclk driven from the mclk output on the xavier. I’ve gotten it working to the point of having no errors in dmesg and I get mic input support, however I still am not getting line out. I believe it is due to the nvidia,audio-routing parameter, but I cant find any documentation on how this field works or what the X, Y, and Zs mean.

I’ve spent a few days working on this trying to get it to work. changing the link name to ‘fe-pi-audio-z-v2’ does not work as this codec is missing some of the clock initialization stuff in tegra_machine_driver_mobile.c so it errors out. I went back to using the standard rt565x-playback link name and it seems like it has correctly initialized the codec since the line in works.

Any help related to the audio routing would be appreciated. I want to avoid having to modify kernel code if at all possible.

Here is my dt code:

/* Support for SGTL5000 audio CODEC */
i2c@c250000 {
	/* delete old codec and its pointer */
	/delete-node/ rt5658;
	/delete-node/ rt5659.7-001a@1a;

	sgtl5000: sgtl5000.7-000a@0a {
		compatible = "fsl,sgtl5000";
		reg = <0x0a>;
		clocks = <&bpmp_clks TEGRA194_CLK_AUD_MCLK>;
		clock-names = "extern1";
		VDDA-supply = <&p2822_vdd_1v8_cvb>;
		VDDIO-supply = <&p2822_vdd_1v8_cvb>;
		VDDD-supply = <&p2822_vdd_1v8_cvb>;
		status = "okay";

tegra_sound: sound {
	nvidia,audio-routing =
			"x Headphone",		"x HP_OUT",
			"x MIC_IN",		"x Mic",
			"x ADC",		"x Mic Bias",
			"x LINE_IN",		"x Line In",
			"x Line Out",		"x LINE_OUT";
	nvidia,dai-link-1 {
		link-name = "rt565x-playback";
		codec-dai = <&sgtl5000>;
		codec-dai-name = "sgtl5000";


If you are referring to the ‘x’ prefix for the codec routes (eg ‘x Line Out’) then these are just used to idenfity the codec instance. For example, all Jetson platforms have multiple I2S interfaces and so can support multiple codecs. If we are using more than one codec then we need a way to identify which route is associated with which codec. Under the ‘dai-link’ nodes you will see a property ‘name-prefix’ which indicates the prefix being used for that particular codec.

With regard to your problem, the routing looks correct and this is what we have for the legacy fe-pi module that features the sgtl5000 codec. I recall that the default volume controls for the Line Out were too low and so take a look at the various volume controls for the codec and try increasing the volume to see if this helps. I believe that there are a couple different volume controls, ‘x PCM Playback Volume’ and ‘x Lineout Playback Volume’.


Thank you so much for that! The Line out was indeed turned completely off.
Using fe-pi-audio still doesnt work, but leaving it at rt565x-playback does.
I used amixer sset 'x Lineout' on and it worked.
For future reference and other people looking at this thread,
amixer sset 'x Capture Mux' LINE_IN will allow you to use the line in port too.

It would be nice if Nvidia would add a ‘generic’ codec to tegra_machine_driver_mobile.c that has enough of its parameters controllable through the DT that it can spit out i2s at a desired rate. Looking at the fe-pi-audio code, it seems to ignore most of the parameters in the DT and hard codes clock rates.


This is all dependent upon who is driving the MCLK for the sgtl5000. The fe-pi module has an on-board oscillator that drives the MCLK at a fixed 12.288 MHz. Hence the device-tree for the fe-pi modules defines a fixed-rate clock for the MCLK. In this case, we configure the sgtl5000 codec as the I2S master and it drives the I2S bit clock and frame clock. Now if you are using the Tegra AUD_MCLK to drive the sgtl5000 MCLK and Tegra is the I2S master, then yes it will not work in the same way and this is expected. That said, yes I am sure we could probably improve things to help with the integration of some of these simpler codecs.

Glad to hear it is working (pun intended).