TLV320ADC3140: NVIDIA Jetson (kernel 4.9) driver for TLV320ADCx140

David,

Looking at your changes, they seem OK. Let me check around with our Linux experts to see if they have any comments.

Best regards,
Pedro

Thanks Pedro,

As I'm using a pretty standard ALSA system, I don't imagine my setup is too different from what you guys are used to. Starting at the beginning, I note that in the dt-bindings for the tlv320adcx140 Linux driver, the reset gpio is set thus:

    #include <dt-bindings/gpio/gpio.h>
    i2c0 {
      #address-cells = <1>;
      #size-cells = <0>;
      codec: codec@4c {
        compatible = "ti,tlv320adc5140";
        reg = <0x4c>;
        ti,use-internal-areg;
        ti,mic-bias-source = <6>;
        reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
      };
    };

I have something similar, but expected the GPIO to be active low, which is what I need to drive SHDNz, right? In any case, I can see that adcx140_i2c_probe() is executing on system boot without error (apparently), but I'm not getting as far as adcx140_codec_probe(), which would be necessary to actually toggle the GPIO from low to high to get the codec out of shutdown. My understanding is that unless I can toggle SHDNz, the chip will ignore any i2c communications.

Right now, dmesg just says:

sound: ASoC: CODEC DAI tlv320adcx140 not registered

sound: sound_soc_register_card_failed (-517)

Have I misunderstood anything here? Have you got any pointers?

Cheers,

David.

Thanks again Pedro,

Have you any guidance on what my ALSA routing should look like? I'm just using four single-ended inputs, but the options in the driver look a bit daunting.

Cheers,

David.

David,

No problem, this Linux driver is capturing a lot of features of the device and the whole Linux driver development has a big learning curve. So we understand that it takes a while to get the hang of it.

Best regards,
Pedro

Hi Pedro,

I would appreciate some guidance with the routing (eventually), but maybe we should put that on hold as I grapple with another aspect of the TI driver. As I mentioned previously, when my system boots, I don't actually get any complaints from the adcx140_i2c_probe() function, which returns 0 as though everything is OK. That's as far as things get, however, as a null pointer is returned by devm_gpiod_get_optional() in the code below:

static int adcx140_i2c_probe(struct i2c_client *i2c,
			     const struct i2c_device_id *id)
{
	struct adcx140_priv *adcx140;
	int ret;

	adcx140 = devm_kzalloc(&i2c->dev, sizeof(*adcx140), GFP_KERNEL);
	if (!adcx140)
		return -ENOMEM;

	adcx140->gpio_reset = devm_gpiod_get_optional(adcx140->dev,
						      "reset", GPIOD_OUT_LOW);
	if (IS_ERR(adcx140->gpio_reset))
		dev_info(&i2c->dev, "Reset GPIO not defined\n");

	adcx140->supply_areg = devm_regulator_get_optional(adcx140->dev,
							   "areg");
	if (IS_ERR(adcx140->supply_areg)) {
		if (PTR_ERR(adcx140->supply_areg) == -EPROBE_DEFER)
			return -EPROBE_DEFER;
		else
			adcx140->supply_areg = NULL;
	} else {
		ret = regulator_enable(adcx140->supply_areg);
		if (ret) {
			dev_err(adcx140->dev, "Failed to enable areg\n");
			return ret;
		}
	}

	adcx140->regmap = devm_regmap_init_i2c(i2c, &adcx140_i2c_regmap);
	if (IS_ERR(adcx140->regmap)) {
		ret = PTR_ERR(adcx140->regmap);
		dev_err(&i2c->dev, "Failed to allocate register map: %d\n",
			ret);
		return ret;
	}
	adcx140->dev = &i2c->dev;
	i2c_set_clientdata(i2c, adcx140);

	return snd_soc_register_codec(&i2c->dev,
					       &soc_codec_driver_adcx140,
					       adcx140_dai_driver, 1);
}

Unfortunately, it appears that the IS_ERR macro is hiding the null return. What puzzles me is that devm_gpiod_get_optional() appears to be called on an empty (zeroed) piece of allocated memory. The adcx140 structure won't contain any data yet. I believe this is why my system can't find the gpio, rather than any peculiarities of the Jetson. I note that later on, adcx140->dev gets assigned a value. Am I missing something here?

Cheers,

David. 

David,

The code:

Hi Pedro,

I totally understand about the optional nature of both the reset gpio and regulator, but I'd doubt that either could work the way the code is currently. I have changed the adcx140_12c_probe() function to that below and can now configure my reset gpio correctly. adcx140->dev can't be used as an argument to devm_gpiod_get_optional() because it isn't initialized yet - just allocated. In my application, I am using a GPIO connected directly to the SHDNz pin.

static int adcx140_i2c_probe(struct i2c_client *i2c,
			     const struct i2c_device_id *id)
{
	struct adcx140_priv *adcx140;
	int ret;

	adcx140 = devm_kzalloc(&i2c->dev, sizeof(*adcx140), GFP_KERNEL);
	if (!adcx140)
		return -ENOMEM;

	adcx140->gpio_reset = devm_gpiod_get_optional(&i2c->dev,
						      "reset", GPIOD_OUT_LOW);

	if (adcx140->gpio_reset)
		dev_info(&i2c->dev, "Got reset GPIO %d OK\n", 
			desc_to_gpio(adcx140->gpio_reset));
	else
		dev_err(&i2c->dev, "Reset GPIO not defined!\n");

	adcx140->supply_areg = devm_regulator_get_optional(&i2c->dev,
							   "areg");

	if (IS_ERR(adcx140->supply_areg)) {
		if (PTR_ERR(adcx140->supply_areg) == -EPROBE_DEFER) {
			dev_err(&i2c->dev, "Probe deferred...\n");
			return -EPROBE_DEFER;
		} else
			adcx140->supply_areg = NULL;
	} else {
		ret = regulator_enable(adcx140->supply_areg);
		if (ret) {
			dev_err(&i2c->dev, "Failed to enable areg\n");
			return ret;
		}
	}

	adcx140->regmap = devm_regmap_init_i2c(i2c, &adcx140_i2c_regmap);
	if (IS_ERR(adcx140->regmap)) {
		ret = PTR_ERR(adcx140->regmap);
		dev_err(&i2c->dev, "Failed to allocate register map: %d\n",
			ret);
		return ret;
	}

	adcx140->dev = &i2c->dev;
	i2c_set_clientdata(i2c, adcx140);

	dev_info(adcx140->dev, "Calling snd_soc_register_codec():\n");

	ret = snd_soc_register_codec(&i2c->dev,
					       &soc_codec_driver_adcx140,
					       adcx140_dai_driver, 1);

	dev_info(adcx140->dev, "Return value = %d\n", ret);

	return ret;
}

So I'm through to the next problem, which I suspect involves routing (or my lack there of), so I'm hoping you can show me what the typical routing might look like for the 3140 in ALSA - which widgets are involved etc. This remains a bit of a black art to me.

Cheers,

David.

Hello again Pedro,

I think I now have the driver registered, and I can see the SHDNz go from low to high on boot, but the driver is producing the following errors:

tlv320adcx140 1-004c: Invalid DAI interface format
tlv320adcx140 1-004c: ASoC: Failed to set DAI format -22

I probably need a different bit format, fsync-width etc? My sound node looks like the following:

	tegra_sound: sound {
		compatible = "nvidia,tegra-audio-t186ref-mobile-rt565x";
		nvidia,model = "tegra-snd-t186ref-mobile-rt565x";
		nvidia,num-codec-link = <1>;
                nvidia,num-clk = <8>;
                nvidia,clk-rates = < 270950400  /* PLLA_x11025_RATE */
                             11289600   /* AUD_MCLK_x11025_RATE */
                             45158400   /* PLLA_OUT0_x11025_RATE */
                             45158400   /* AHUB_x11025_RATE */
                             245760000  /* PLLA_x8000_RATE */
                             12288000   /* AUD_MCLK_x8000_RATE */
                             49152000   /* PLLA_OUT0_x8000_RATE */
                             49152000 >;/* AHUB_x8000_RATE */
                clocks = <&tegra_car TEGRA186_CLK_PLLP_OUT0>,
                <&tegra_car TEGRA186_CLK_PLLA>,
                <&tegra_car TEGRA186_CLK_PLL_A_OUT0>,
                <&tegra_car TEGRA186_CLK_AHUB>,
                <&tegra_car TEGRA186_CLK_CLK_M>,
                <&tegra_car TEGRA186_CLK_AUD_MCLK>;
               clock-names = "pll_p_out1", "pll_a", "pll_a_out0", "ahub",
                        "clk_m", "extern1";

		assigned-clocks = <&tegra_car TEGRA186_CLK_PLL_A_OUT0>,
				  <&tegra_car TEGRA186_CLK_AHUB>,
				  <&tegra_car TEGRA186_CLK_AUD_MCLK>;
		assigned-clock-parents = <&tegra_car TEGRA186_CLK_PLLA>,
					 <&tegra_car TEGRA186_CLK_PLL_A_OUT0>,
					 <&tegra_car TEGRA186_CLK_PLL_A_OUT0>;
		resets = <&tegra_car TEGRA186_RESET_AUD_MCLK>;
		reset-names = "extern1_rst";

		status = "okay";
		nvidia,audio-routing =
		        "x CH1_ADC",		"x Mic",
			"x CH2_ADC",		"x Mic",
		        "x CH3_ADC",		"x Mic",
			"x CH4_ADC",		"x Mic";

		nvidia,xbar = <&tegra_axbar>;
		mclk-fs = <256>;

		rt565x_dai_link: nvidia,dai-link-1 {
			link-name = "tlv320adcx140-codec";
			cpu-dai = <&tegra_i2s1>;
			codec-dai = <&tlv320adcx140>;
			cpu-dai-name = "I2S1";
			codec-dai-name = "tlv320adcx140-codec";
			format = "dsp-a";
			fsync-width = <15>;
                        bitclock-slave;
                        frame-slave;
                        bitclock-noninversion;
                        frame-noninversion;
			bit-format = "s16_le";
			bclk_ratio = <1>;
			srate = <48000>;
			num-channel = <4>;
			ignore_suspend;
			name-prefix = "x";
			status = "okay";
		};

David,

The dts normally has these entries:

Hi Pedro,

OK - I changed my format from 'dsp-a' to 'dsp_a' in the sound block and the TI driver now registers and initialises without error. I see SHDNz go from low to high on system boot along with some i2c traffic. When I run 'arecord test.wav', I see MCLK from the TX2 become active at around 12.4 MHz, but nothing on FSYNC, BCLK or DOUT yet.

Obviously, I need to configure my audio routing, but I'd also like to hear your recommendation for the simplest hardware configuration I can use to start some recording. I currently have MCLK bridged through to GPIO1 on the 3140, but will it automatically detect this and configure the other clocks, or do I need to change some of the default register settings in the driver?

Cheers,

David.

David,

Glad to hear of the progress! The easiest routing for the audio serial interface is to let the TLV320ADCx140 PLL auto configure the clocks. Just by sending BCLK and FSYNC, the device will auto configure to the programmed sample rate. Just ensure that

BLCK >= FSYNC * word_length * #_channels

Then use alsamixer to setup the input channels and volume.

On boot-up, you should see the sound card and its pin mapping being registered, like this:

asoc-simple-card sound: tlv320adcx140-codec <-> 48038000.mcasp mapping ok

arecord -l should show the ALSA device list

Best regards,
Pedro