TLV320AIC32x4 evaluation board with TX2

Hi Igal,

I am not sure if this is %100 needed. With regard to your comment in #218, I believe that this is all related to the same problem.

Regards
Jon

Jon, hi,

I have removed it and yet I am getting the same error:

amixer: Mixer hw:1 load error: Input/Output error

Regards, Igal

Hi Igal,

So this was working before you added capture support, right? Can you undo your recent changes to where you had playback working and figure out which change introduces the problem?

Regards
Jon

Jon, hi,

I did nothing for the capture issue besides changing the control name per your proposal, and I have already revised it back.

Regards, Igal.

Hi Igal,

But playback no longer works, right? If so please keep digging.

Regards,
Jon

Jon, hi,

I have tried to apply the following command which is part of the pltest.sh script:

amixer -c tegrasndt186ref cset name=‘z Auto-mute Switch’ 0

The error received is amixer: Cannot read the given element from control hw:1
I see this switch in the CODEC driver.

What do you think might be the cause for this error?

Regards, Igal

Hi Igal,

I am sorry, but I don’t know. There must be something that has changed in the kernel to cause this.

Regards,
Jon

Jon, hi,

who might know how to solve this kind of error?

Regards, Igal

Hi Igal,

This was working before and this has just stopped working recently, correct?

Therefore, there must have been a change that has been made that has introduced this problem. The only way to resolve this is to review all the changes that have been made. Alternatively, if you remove all the changes or start with a fresh installation, then ‘amixer -c 1’ should work and if you then replay your changes on top, you should be able to track down where this error was introduced.

Regards,
Jon

Jon, hi,

I understand that something went wrong in the kernel. And I understand that the command amixer -c tegrasndt186ref cset name=‘z Auto-mute Switch’ 0 where the audio CODEC is involved the the CODEC is to blame. but how the command amixer -c tegrasndt186ref sset ‘ADMAIF1 Mux’ ‘I2S1’ can be related to anything we changed?

Regards, Igal

Hi Igal,

If there is one bad mixer control, then none of the others will work.

Regards,
Jon

Jon hi,

I found the reason for the problem. TI have explained to me that the audio CODEC maintains pages. These pages are selected by access a register ‘0’ on each page. While the driver code maintains the pages in a different way it assumes that there are only two pages and the registers of page 1 are starting on address 128. This means that if one wants to access register ‘1’ on page ‘1’ he needs to access register 129.

With respect to TI request I have set the value of the offset definition (AIC32X4_PAGE1) value to 0 (in the header file) this way I can access a register without the offset but only by changing to the requested page via register ‘0’ access.

The failure I guess happen because amixer could not access some of the controls which are on page 1.
There is something very basic that I don’t understand with the driver:

  1. accessing each page as the data sheet dictates: first write to register ‘0’ the destination page and then access any register in the selected page, or
  2. add an offset of 128 x N to access a selected register on a page.

Regards, Igal

Jon, hi,

I have found the source for the noise: the MCLK which is not utilized for clocking the CODEC was the source.

I have a small question regarding the configuration from terminal.

I can find the following dapm that was defined in the CODEC “z Right ADC” I grepped it:

sudo grep -rlw -e "Right ADC" /sys/kernel/debug/asoc/tegra-snd-t186ref-mobile-rt565x/

the result was

/sys/kernel/debug/asoc/tegra-snd-t186ref-mobile-rt565x/codec:tlv320aic32x4.1-0018/dapm/z Capture
/sys/kernel/debug/asoc/tegra-snd-t186ref-mobile-rt565x/codec:tlv320aic32x4.1-0018/dapm/z Right ADC
/sys/kernel/debug/asoc/tegra-snd-t186ref-mobile-rt565x/codec:tlv320aic32x4.1-0018/dapm/z Right Input Mixer

But when I tried to modify it from within the amixer:

amixer -c tegrasndt186ref cget name='z Right ADC'

I got

amixer: Cannot find the given element from control hw:1

Please advise.

Regards, Igal

Hi Igal,

Good news on sorting out the noise.

DAPM widgets are not mixer controls and so there will not be a mixer control for a DAPM widget such as ‘z Right ADC’.

If you …

$ amixer -c tegrasndt186ref | grep "z "

… you will see all the mixer controls for the codec. The mixer controls are defined in the structure ‘aic32x4_snd_controls’.

Regards,
Jon

John, hi,

So where from can I control snd_soc_dapm_widget(s)?

BTW, I have successfully accomplished encoding audio by the CODEC. So I am ready to close this topic :)

Regards, Igal

Hi Igal,

Typically, the DAPM widgets are controlled either by the audio path (ie. to enable ADC/DACs when the path is enabled) or via a mixer kcontrol that is linked to the DAPM widget (see “LOL Output Mixer” which is controlled via the switches defined by hpr_output_mixer_controls).

However, I am not sure what you are trying to control and so it is difficult to answer specifically. The best thing to do is figure out what register you are trying to configure and see if any mixer control exposes this.

You can always add new controls to the driver if there is some feature you need to control that is not exposed by the driver. However, before doing so you may wish to discuss with TI as maybe there is another way to accomplish what you are trying to do with the existing driver.

Regards,
Jon

Hi, John,
Internally in the CODEC driver this dapm is mapped to bits which enable/disable the Left and Right ADC so I thought to enable it during the amixer configurations as I did with other configuration related “registers”.

Is it the correct approach?

Regards, Igal.

John, hi,

Could you replay to message #237?

Regards, Igal

Hi Igal,

Sorry I have been out of the office. With regard to comment #238, as I mentioned in comment #237, this should be able when the audio path itself is enabled and so you should not need to enable this explicitly.

I still do not know why you are trying to enable this manually, because if you have capture working then this means it must be enabled, right? You should see that if you trace the DAPM power events.

Regards,
Jon

Jon, hi,

I was thinking the same that somehow eventually these registers will be set:

SND_SOC_DAPM_ADC("Left ADC", "Capture", AIC32X4_ADCSETUP, 7, 0),
SND_SOC_DAPM_ADC("Right ADC", "Capture", AIC32X4_ADCSETUP, 6, 0),

that is, bits 6 and 7 in register AIC32X4_ADCSETUP will be set by the ALSA framework internally.
But they were not set and I had to add code setting these bits in the CODEC driver, otherwise encoding does not get any data once I start the arecord.

Regards, Igal.