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
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:
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.