I am using imx-audio-card which uses sai1 snd-soc-dummy-dai-0
I have an external SoC connected to iMX8MP module via I2S, there's no exposed codec for me to use, hence why I'm using a dummy codec.
I can view them in aplay -L which will show:
hw:CARD=imxaudiocard,DEV=0
imx-audio-card, sai1 snd-soc-dummy-dai-0
Direct hardware device without any conversions
plughw:CARD=imxaudiocard,DEV=0
imx-audio-card, sai1 snd-soc-dummy-dai-0
Hardware device with all software conversions
default:CARD=imxaudiocard
imx-audio-card, sai1 snd-soc-dummy-dai-0
Default Audio Device
sysdefault:CARD=imxaudiocard
imx-audio-card, sai1 snd-soc-dummy-dai-0
Default Audio Device
dmix:CARD=imxaudiocard,DEV=0
imx-audio-card, sai1 snd-soc-dummy-dai-0
Direct sample mixing device
I can play audio via this and it works.
aplay -D default:CARD=imxaudiocard music.wav
Similar results in the code snippet above using arecord -L. I'm able to record using:
arecord -D default:CARD=imxaudiocard -r 32000 -c 2 -d 20 -f S24_3LE test.wav
However, the test.wav comes out blank; I cannot seem to record sounds. FYI - there's no amixer controls, so I can't seem to set to CAPTURE.
Any idea how I can accept the audio in via I2S when I can already playback the audio out via I2S?
解決済! 解決策の投稿を見る。
SOLVED!
On the development board, the module was physically connected to the codec. We needed to break the lines to stop the voltage leakage.
So disabling the codec in the device tree wasn’t sufficient, hardware work was needed to be done.
Thank you @Manuel_Salas and @jamesbone - I definitely learned a lot in this journey that I would not have learned otherwise. Thanks again!
You can test with an oscilloscope, the clock signal when it is in the record mode, if the clock it is not setup then in the Device tree you can change it.
the pcm_write it is function in the alsa driver, you can get the Kernel Log using Dmesg command, let me share a link on how to
https://www.linuxfoundation.org/blog/blog/classic-sysadmin-viewing-linux-logs-from-the-command-line
Hello James,
The dmesg command is not available and it is not in /var/log either.
I did some more testing, so here's the scenario,
Any ideas?
Hello @jamesbone
Our setup is as such:
External SoC --> Level shifter (3.3V to 1.8V) --> imx8mp
We have the oscilloscope probed at the RX line of the imx8mp (SAI1_RX_DATA00). This is what we see:
The highest voltage never reaches 1.8V, and the high seems to be at 0.85V, which is too low and never gets registered as high in the imx8mp RX line.
If we unplug the RX line from the imx8mp while everything is intact, the oscilloscope jumps up above 1.8V, as shown:
The oscilloscope is reading what is coming from the SoC via level shifter.
My question is, why is connecting the imx8mp RX line pulling the voltage down such that the high doesn't trigger as 1 in the input, thus producing complete silence in the eyes of imx8mp?
Hello @freshmango90
It seems that you have enabled pull-down on the RX pin on i.MX8MP.
Could you please share your device tree related to the the SAI configuration? If possible, share the schematic and part number of the level shifter.
Best regards,
Salas.
&{/} {
sound_i2s_card {
status = "okay";
compatible = "fsl,imx-audio-card";
model = "imx-audio-card";
pri-dai-link {
link-name = "sai1";
format = "i2s";
cpu {
sound-dai = <&sai1>;
};
};
};
};
&sai1 {
status = "okay";
pinctrl-0 = <&pinctrl_sai1_bclk_lrclk_dout_din>;
pinctrl-names = "default";
};
&iomuxc {
pinctrl_sai1_bclk_lrclk_dout_din: my_sai_grp {
fsl,pins =
<MX8MP_IOMUXC_SAI5_MCLK__AUDIOMIX_SAI1_TX_BCLK 0x1d6>, /* SODIMM 30 */
<MX8MP_IOMUXC_SAI5_RXD1__AUDIOMIX_SAI1_TX_SYNC 0x1d6>, /* SODIMM 32 */
<MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI1_TX_DATA00 0x96>, /* SODIMM 34 */
<MX8MP_IOMUXC_SAI1_RXD0__AUDIOMIX_SAI1_RX_DATA00 0x1d0>; /* SODIMM 36 */
};
};
I have RX line to be 1d0 because I wanted to reduce the output drive strength to keep it as an input.
Here is the level shifter datasheet. This device does use pull-up resistors.
Our schematic is the same as the one shown in 9.2 Typical application with the only difference with OE being connected to 1.8V to always enable the level shifter.
Hello @freshmango90
I can confirm that the TXS0102 has internal pull-ups resistors of 10K, so, you can disable the pull ups from i.MX8MP.
Also, the TXS0102 is Open drain, so, you must disable Open Drain from i.MX8MP.
Please try it.
Best regards,
Salas.
Hello @Manuel_Salas ,
I appreciate your insight, and we've went ahead and checked with the manual on the register (section 8.2.4.232 in the IMX8MPRM, or here's the snippet)
So this would mean that Bit 5 (open drain field) should be 0 and Bit 6 (pull up/down config field) should be 1. That means 0x1d6. It is what I currently have.
I've also played around with the settings, and tried with 0x0d6, 0x0d0, 0x096 and these do not solve the issue. The signal is still too low.
I'm at a loss, not sure what to do.
I wanted to know if there's any issue with the pin 36, so we've made that as a TX line as such:
<MX8MP_IOMUXC_SAI1_RXD0__AUDIOMIX_SAI1_TX_DATA01 0x1d6>; /* SODIMM 36 */
And it is behaving the same with as if it's the RX line (pulls lower when connected)
So maybe something is wrong with the imx8mp module, and I have an extra one, so I replace the module. Same issue. So...
So we thought maybe the pin 36 has some hardware issue or corruption, so I wanted to use another RX line, which is in pin 220 using this line:
<MX8MP_IOMUXC_SAI1_RXD1__AUDIOMIX_SAI1_RX_DATA01 0x1d6>; /* SODIMM 220 */
Suddenly, the audio card is not available, so I cannot send/receive signals to test if it pulls high/low. aplay -L does not show this, nor is it in /proc/asound/cards. I've also tried disabling one pinctrl as it uses pin 220 as such:
&pinctrl_gpio7{
status = "disabled";
};
SOLVED!
On the development board, the module was physically connected to the codec. We needed to break the lines to stop the voltage leakage.
So disabling the codec in the device tree wasn’t sufficient, hardware work was needed to be done.
Thank you @Manuel_Salas and @jamesbone - I definitely learned a lot in this journey that I would not have learned otherwise. Thanks again!
Since you are using a Dummy Codec, the issue would be the setup of MAster / Slave mode.
pcm_write return EIO error, that means I/O is not setup. And master mode can wok but slave mode not.
Can they check if bit clock is generated with your Dummy and slave mode? Check if any message from kernel log.
Hello @freshmango90
I hope you are doing very well.
Could you please share what codec are you using? BSP version also.
If possible, your device tree related to the codec.
Sometimes it happens when there is a connection between an i.MX and device like "MAX98357A" that is not a "codec", those are Digital amplifiers and eventually there are issues.
Best regards,
Salas.
Could you please share what codec are you using? BSP version also.
No codec - hence the dummy one. I just have the audio streaming coming directly from I2S with no I2C line.
BSP - not sure how to get this... I did uname -r though, and got: 5.15.148-6.8.1+git.1cbf48124747
If possible, your device tree related to the codec.
As for the device tree - I don't have that on hand, but it would create a new node to use fsl,imx-audio-card
Sometimes it happens when there is a connection between an i.MX and device like "MAX98357A" that is not a "codec", those are Digital amplifiers and eventually there are issues.
As for your comment about digital amplifiers, could you elaborate on that?