[alsa-devel] Issue on Linux 4.12-rc7 on iMX6 based board
Hello list,
I have some issue using the sgtl5000 on two custom boards based with iMX6. One board has iMX6DL and the other has iMX6QP.
The issue is I have a (dramatically high) strange value on mixer settings (looks like a int32 limit or similar)
This is the output of amixer:
# amixer Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 0 [2147483647%] [-51.50dB] [on] Front Right: Playback 0 [2147483647%] [-51.50dB] [on] Simple mixer control 'Headphone Mux',0 Capabilities: enum Items: 'DAC' 'LINE_IN' Item0: 'DAC' Simple mixer control 'Headphone Playback ZC',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 192 Mono: Front Left: Playback 1 [2147483647%] Front Right: Playback 0 [2147483647%] Simple mixer control 'Lineout',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 18 [2147483647%] [-6.50dB] [on] Front Right: Playback 18 [2147483647%] [-6.50dB] [on] Simple mixer control 'Mic',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 3 Mono: 0 [2147483647%] [0.00dB] Simple mixer control 'Capture',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 15 Front Left: Capture 0 [2147483647%] Front Right: Capture 0 [2147483647%] Simple mixer control 'Capture Attenuate Switch (-6dB)',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'Capture Mux',0 Capabilities: enum Items: 'MIC_IN' 'LINE_IN' Item0: 'MIC_IN' Simple mixer control 'Capture ZC',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on]
In attachment there is a screenshot of alsamixer
All audio stuff are not hear at all.... :-(
After the output of the sgtl5000 I have a audio-booster and it is set at the maximum level. I have another board based on the iMX28, SGTL5000 and the same audio booster and everything is working good. So I can suppose something related the initialization of the codec.
Any help?
Best Regards, Gianluca Renzi
-------- Forwarded Message -------- Subject: Issue on Linux 4.12-rc7 on iMX6 based board Date: Wed, 28 Jun 2017 17:32:34 +0200 From: gianluca gianlucarenzi@eurekelettronica.it To: alsa-devel@alsa-project.org alsa-devel@alsa-project.org
Hello list,
I have some issue using the sgtl5000 on two custom boards based with iMX6. One board has iMX6DL and the other has iMX6QP.
The issue is I have a (dramatically high) strange value on mixer settings (looks like a int32 limit or similar)
This is the output of amixer:
# amixer Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 0 [2147483647%] [-51.50dB] [on] Front Right: Playback 0 [2147483647%] [-51.50dB] [on] Simple mixer control 'Headphone Mux',0 Capabilities: enum Items: 'DAC' 'LINE_IN' Item0: 'DAC' Simple mixer control 'Headphone Playback ZC',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 192 Mono: Front Left: Playback 1 [2147483647%] Front Right: Playback 0 [2147483647%] Simple mixer control 'Lineout',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 18 [2147483647%] [-6.50dB] [on] Front Right: Playback 18 [2147483647%] [-6.50dB] [on] Simple mixer control 'Mic',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 3 Mono: 0 [2147483647%] [0.00dB] Simple mixer control 'Capture',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 15 Front Left: Capture 0 [2147483647%] Front Right: Capture 0 [2147483647%] Simple mixer control 'Capture Attenuate Switch (-6dB)',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'Capture Mux',0 Capabilities: enum Items: 'MIC_IN' 'LINE_IN' Item0: 'MIC_IN' Simple mixer control 'Capture ZC',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on]
In attachment there is a screenshot of alsamixer
All audio stuff are not hear at all.... :-(
After the output of the sgtl5000 I have a audio-booster and it is set at the maximum level. I have another board based on the iMX28, SGTL5000 and the same audio booster and everything is working good. So I can suppose something related the initialization of the codec.
Any help?
Best Regards, Gianluca Renzi
Hi Gianluca,
On Wed, Jun 28, 2017 at 12:34 PM, gianluca gianlucarenzi@eurekelettronica.it wrote:
Hello list,
I have some issue using the sgtl5000 on two custom boards based with iMX6. One board has iMX6DL and the other has iMX6QP.
The issue is I have a (dramatically high) strange value on mixer settings (looks like a int32 limit or similar)
This is the output of amixer:
# amixer Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 0 [2147483647%] [-51.50dB] [on] Front Right: Playback 0 [2147483647%] [-51.50dB] [on]
Double check the codec hardware: is I2C communication working, are you able to dump the SGTL5000 registers, check the codec power supplies, MCLK, etc.
On 06/29/2017 01:37 PM, Fabio Estevam wrote:
Hi Gianluca,
On Wed, Jun 28, 2017 at 12:34 PM, gianluca gianlucarenzi@eurekelettronica.it wrote:
Hello list,
I have some issue using the sgtl5000 on two custom boards based with iMX6. One board has iMX6DL and the other has iMX6QP.
The issue is I have a (dramatically high) strange value on mixer settings (looks like a int32 limit or similar)
This is the output of amixer:
# amixer Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 0 [2147483647%] [-51.50dB] [on] Front Right: Playback 0 [2147483647%] [-51.50dB] [on]
Double check the codec hardware: is I2C communication working,are you able to dump the SGTL5000 registers,
The i2c communication is working:
# i2cdetect -y -a -r 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 00 -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- 10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: UU UU -- -- 54 -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
sgtl-5000 is 0xa address like specified in the device-tree:
&i2c1 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c1>; status = "okay";
sgtl5000: codec@0a { compatible = "fsl,sgtl5000"; reg = <0x0a>; clocks = <&clks IMX6QDL_CLK_CKO>; VDDA-supply = <®_3p3v>; VDDIO-supply = <®_3p3v>; VDDD-supply = <®_1p2v>; status = "okay"; };
I did not check the voltage supply yet, but during bootup the kernel is saying:
[ 0.620196] sgtl5000 0-000a: sgtl5000 revision 0x11
So I suppose (at least) the Codec is powered and the i2c lines are working correctly.
[ 0.650568] fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW [ 0.673984] imx-sgtl5000 sound: sgtl5000 <-> 2028000.ssi mapping ok
It looks like some basic initialization stuff and probing are working good...
[ 0.698683] ALSA device list: [ 0.698689] #0: imx6-ek360-sgtl5000
...and the device is added to ALSA device-list.
In the device-tree the sound node is so configured:
sound { compatible = "fsl,imx-audio-sgtl5000"; model = "imx6-ek360-sgtl5000"; ssi-controller = <&ssi1>; audio-codec = <&sgtl5000>; audio-routing = "MIC_IN", "Mic Jack", "Mic Jack", "Mic Bias", "Headphone Jack", "HP_OUT"; mux-int-port = <1>; mux-ext-port = <4>; micbias-resistor-k-ohms = <2>; micbias-voltage-m-volts = <3000>; status = "okay"; };
I do not know about the mux-int-port or mux-ext-port. The only thing I know is the hardware guy told me he routed the ssi (CLK and DAT) to:
AUD3_TXC_R (i2s_sclk) AUD3_TXD (i2s_din) AUD3_TXFS (i2s_lrclk) AUD3_RXD (i2s_dout) SYS_MCLK (GPIO_0_CLKO sys_mclk)
So I configured the pinmux for audio in the following way:
pinctrl_audmux: audmuxgrp { fsl,pins = < /* SGTL5000 sys_mclk */ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x030b0 MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0 MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0 MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0 MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0 >; };
Are the values correct for that?
I was looking at the device-tree for imx6qdl-nit6xlite.dtsi because they are using the same pinout as ours.
check the codec power supplies,
MCLK, etc.
How can I check or dump the SGTL5000 registers?
Regards,
On Thu, Jun 29, 2017 at 10:39 AM, gianluca gianlucarenzi@eurekelettronica.it wrote:
In the device-tree the sound node is so configured:
sound { compatible = "fsl,imx-audio-sgtl5000"; model = "imx6-ek360-sgtl5000"; ssi-controller = <&ssi1>; audio-codec = <&sgtl5000>; audio-routing = "MIC_IN", "Mic Jack", "Mic Jack", "Mic Bias", "Headphone Jack", "HP_OUT"; mux-int-port = <1>; mux-ext-port = <4>;
This should be mux-ext-port = <3>;
I do not know about the mux-int-port or mux-ext-port. The only thing I know is the hardware guy told me he routed the ssi (CLK and DAT) to:
AUD3_TXC_R (i2s_sclk) AUD3_TXD (i2s_din) AUD3_TXFS (i2s_lrclk) AUD3_RXD (i2s_dout) SYS_MCLK (GPIO_0_CLKO sys_mclk)
since you are using AUD3 pins.
So I configured the pinmux for audio in the following way:
pinctrl_audmux: audmuxgrp { fsl,pins = < /* SGTL5000 sys_mclk */ MX6QDL_PAD_GPIO_0__CCM_CLKO10x030b0 MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0 MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0 MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0 MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0 >; };
Are the values correct for that?
They should be good.
How can I check or dump the SGTL5000 registers?
cat /sys/kernel/debug/regmap/xxx
On 06/29/2017 03:49 PM, Fabio Estevam wrote:
On Thu, Jun 29, 2017 at 10:39 AM, gianluca gianlucarenzi@eurekelettronica.it wrote:
In the device-tree the sound node is so configured:
sound { compatible = "fsl,imx-audio-sgtl5000"; model = "imx6-ek360-sgtl5000"; ssi-controller = <&ssi1>; audio-codec = <&sgtl5000>; audio-routing = "MIC_IN", "Mic Jack", "Mic Jack", "Mic Bias", "Headphone Jack", "HP_OUT"; mux-int-port = <1>; mux-ext-port = <4>;This should be mux-ext-port = <3>;
I've already modified now.
I do not know about the mux-int-port or mux-ext-port. The only thing I know is the hardware guy told me he routed the ssi (CLK and DAT) to:
AUD3_TXC_R (i2s_sclk) AUD3_TXD (i2s_din) AUD3_TXFS (i2s_lrclk) AUD3_RXD (i2s_dout) SYS_MCLK (GPIO_0_CLKO sys_mclk)
since you are using AUD3 pins.
So, are they good?
My only concern is the value after the MSYS_CLK (GPIO_0_CCM_CLK01). It is 0x030b0. Is this correct for output clock signal?
So I configured the pinmux for audio in the following way:
pinctrl_audmux: audmuxgrp { fsl,pins = < /* SGTL5000 sys_mclk */ MX6QDL_PAD_GPIO_0__CCM_CLKO10x030b0
The remaining pins seems to be configured as a lot of boards in the current 4.12-rc7 kernel. So I can assume they are good.
MX6QDL_PAD_CSI0_DAT4__AUD3_TXC0x130b0 MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0 MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0 MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0 >; };
They should be good.
How can I check or dump the SGTL5000 registers?
cat /sys/kernel/debug/regmap/xxx
I am missing the regmap. Should I configure kernel with additional CONFIG_ ?
I started from the imxv6_imxv7_defconfig, then modified to have the correct drivers module as built-in or dynamic.
Maybe am I missing something else??? :-(
Regards,
On Thu, Jun 29, 2017 at 11:24 AM, gianluca gianlucarenzi@eurekelettronica.it wrote:
So, are they good?
If your hardware really uses these pins, then yes :-)
My only concern is the value after the MSYS_CLK (GPIO_0_CCM_CLK01). It is 0x030b0. Is this correct for output clock signal?
Most of the boards use 0x130b0. You should really check with a scope and see if the MCLK is getting to the codec. I suppose it is as the driver can read its ID register correctly.
I am missing the regmap. Should I configure kernel with additional CONFIG_ ?
mount -t debugfs none /sys/kernel/debug
I started from the imxv6_imxv7_defconfig, then modified to have the correct drivers module as built-in or dynamic.
imx_v6_v7_defconfig should give you working audio.
You should check in this scope if your getting SSI clock/data when playing audio.
On 06/29/2017 04:30 PM, Fabio Estevam wrote:
On Thu, Jun 29, 2017 at 11:24 AM, gianluca gianlucarenzi@eurekelettronica.it wrote:
So, are they good?
If your hardware really uses these pins, then yes :-)
Now looking at other boards where our hardware-guy took the inspiration (i.e. iMX6 Rex from Fedevel) the device-tree is the same as mine.
MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x030b0
0x130b0 or 0x030b0 the only difference is the PAD_CTL_HYS (1 << 16)
Maybe more strong to noise, but basically they are the same.
But I found an issue when playing data from aplay without specifing the device or specifying one:
# aplay /usr/share/sounds/alsa/Front_Center.wav Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
or
# aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Right.wav Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: set_params:1233: Sample format non available Available formats:
- S24_LE
Maybe some ALSA misconfigured????
This distro is a bootstrapped jessie Debian 8, so some configuration could be missing or not-so-good-configured.
# aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server default:CARD=imx6ek360sgtl50 imx6-ek360-sgtl5000, Default Audio Device sysdefault:CARD=imx6ek360sgtl50 imx6-ek360-sgtl5000, Default Audio Device dmix:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct sample mixing device dsnoop:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct sample snooping device hw:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct hardware device without any conversions plughw:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Hardware device with all software conversions
Anybody has never faced an issue like this?
Regards,
Now I did some great steps ahead! ;-)
I can assume there is some misconfigured alsa stuff in my debootstrapped armhf jessie distro!!!
First step: from Barebox bootloader I tried to move on/off all pins connected to the SGTL5000 from SoC iMX6. They are moving good, so I can assume _NO_HARDWARE_ issue.
Second step: burn a ubuntu armhf image (boundary-devices-jessie) to match up my system-boot (/etc/fstab and /etc/inittab), adding the /lib/modules/4.12-rc7/ directory and drivers, and add the uImage for 4.12-rc7 on the sdcard.
Third step: burn on the sdcard the Barebox bootloader instead of the (unrunningble) u-boot for another board (Nitrogen).
Fourth step: turn on my board with this sdcard.
Sound is working. The levels of the capabilities (PCM, MIC, DAC, ...) are settable and they are working fine.
I can play and I can record. The only thing is the driver can use only S24_LE as frequeny for recording but afterall everything is working as expected.
Now the biggest question:
WTF are working alsa or its configuration in a deboostrapped armhf distribution? Actually this distro was upgraded two times:
1- Wheezy armel 2- Wheezy armel + armhf 3- Wheezy armhf 4- Jessie armhf 5- apt get dist-upgrade...
Something in between was wrong with alsa. Any help or configuration file to fix this issue???
# aplay -L null Discard all samples (playback) or generate zero samples (capture) default:CARD=imx6ek360sgtl50 imx6-ek360-sgtl5000, Default Audio Device sysdefault:CARD=imx6ek360sgtl50 imx6-ek360-sgtl5000, Default Audio Device dmix:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct sample mixing device dsnoop:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct sample snooping device hw:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct hardware device without any conversions plughw:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Hardware device with all software conversions
# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: imx6ek360sgtl50 [imx6-ek360-sgtl5000], device 0: HiFi sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 root@nitrogen:~# arecord -l **** List of CAPTURE Hardware Devices **** card 0: imx6ek360sgtl50 [imx6-ek360-sgtl5000], device 0: HiFi sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
May I have a simple configuration file for this?
On 06/29/2017 06:28 PM, gianluca wrote:
On 06/29/2017 04:30 PM, Fabio Estevam wrote:
On Thu, Jun 29, 2017 at 11:24 AM, gianluca gianlucarenzi@eurekelettronica.it wrote:
So, are they good?
If your hardware really uses these pins, then yes :-)
Now looking at other boards where our hardware-guy took the inspiration (i.e. iMX6 Rex from Fedevel) the device-tree is the same as mine.
MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x030b0
0x130b0 or 0x030b0 the only difference is the PAD_CTL_HYS (1 << 16)
Maybe more strong to noise, but basically they are the same.
But I found an issue when playing data from aplay without specifing the device or specifying one:
# aplay /usr/share/sounds/alsa/Front_Center.wav Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
or
# aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Right.wav Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: set_params:1233: Sample format non available Available formats:
- S24_LE
Maybe some ALSA misconfigured????
This distro is a bootstrapped jessie Debian 8, so some configuration could be missing or not-so-good-configured.
Regards,
What did I do to fix this issue:
1- apt purge alsa-utils 2- apt install alsa-utils
Now everything is working as expected. Maybe some misconfigured stuff to have a (strangely enough) high value for property mixer and other stuff...
# amixer Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 63 [50%] [-20.00dB] [on] Front Right: Playback 63 [50%] [-20.00dB] [on] Simple mixer control 'Headphone Mux',0 Capabilities: enum Items: 'DAC' 'LINE_IN' Item0: 'DAC' Simple mixer control 'Headphone Playback ZC',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 192 Mono: Front Left: Playback 154 [80%] Front Right: Playback 154 [80%] Simple mixer control 'Lineout',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 18 [58%] [-6.50dB] [on] Front Right: Playback 18 [58%] [-6.50dB] [on] Simple mixer control 'Mic',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 3 Mono: 0 [0%] [0.00dB] Simple mixer control 'Capture',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 15 Front Left: Capture 12 [80%] Front Right: Capture 12 [80%] Simple mixer control 'Capture Attenuate Switch (-6dB)',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'Capture Mux',0 Capabilities: enum Items: 'MIC_IN' 'LINE_IN' Item0: 'MIC_IN' Simple mixer control 'Capture ZC',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] root@edelin:~#
...and everything is working good!
On 07/03/2017 11:36 AM, gianluca wrote:
Now I did some great steps ahead! ;-)
I can assume there is some misconfigured alsa stuff in my debootstrapped armhf jessie distro!!!
First step: from Barebox bootloader I tried to move on/off all pins connected to the SGTL5000 from SoC iMX6. They are moving good, so I can assume _NO_HARDWARE_ issue.
Second step: burn a ubuntu armhf image (boundary-devices-jessie) to match up my system-boot (/etc/fstab and /etc/inittab), adding the /lib/modules/4.12-rc7/ directory and drivers, and add the uImage for 4.12-rc7 on the sdcard.
Third step: burn on the sdcard the Barebox bootloader instead of the (unrunningble) u-boot for another board (Nitrogen).
Fourth step: turn on my board with this sdcard.
Sound is working. The levels of the capabilities (PCM, MIC, DAC, ...) are settable and they are working fine.
I can play and I can record. The only thing is the driver can use only S24_LE as frequeny for recording but afterall everything is working as expected.
Now the biggest question:
WTF are working alsa or its configuration in a deboostrapped armhf distribution? Actually this distro was upgraded two times:
1- Wheezy armel 2- Wheezy armel + armhf 3- Wheezy armhf 4- Jessie armhf 5- apt get dist-upgrade...
Something in between was wrong with alsa. Any help or configuration file to fix this issue???
# aplay -L null Discard all samples (playback) or generate zero samples (capture) default:CARD=imx6ek360sgtl50 imx6-ek360-sgtl5000, Default Audio Device sysdefault:CARD=imx6ek360sgtl50 imx6-ek360-sgtl5000, Default Audio Device dmix:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct sample mixing device dsnoop:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct sample snooping device hw:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Direct hardware device without any conversions plughw:CARD=imx6ek360sgtl50,DEV=0 imx6-ek360-sgtl5000, Hardware device with all software conversions
# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: imx6ek360sgtl50 [imx6-ek360-sgtl5000], device 0: HiFi sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 root@nitrogen:~# arecord -l **** List of CAPTURE Hardware Devices **** card 0: imx6ek360sgtl50 [imx6-ek360-sgtl5000], device 0: HiFi sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
May I have a simple configuration file for this?
On 06/29/2017 06:28 PM, gianluca wrote:
On 06/29/2017 04:30 PM, Fabio Estevam wrote:
On Thu, Jun 29, 2017 at 11:24 AM, gianluca gianlucarenzi@eurekelettronica.it wrote:
So, are they good?
If your hardware really uses these pins, then yes :-)
Now looking at other boards where our hardware-guy took the inspiration (i.e. iMX6 Rex from Fedevel) the device-tree is the same as mine.
MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x030b0
0x130b0 or 0x030b0 the only difference is the PAD_CTL_HYS (1 << 16)
Maybe more strong to noise, but basically they are the same.
But I found an issue when playing data from aplay without specifing the device or specifying one:
# aplay /usr/share/sounds/alsa/Front_Center.wav Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
or
# aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Right.wav Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: set_params:1233: Sample format non available Available formats:
- S24_LE
Maybe some ALSA misconfigured????
This distro is a bootstrapped jessie Debian 8, so some configuration could be missing or not-so-good-configured.
Regards,
On 06/29/2017 04:30 PM, Fabio Estevam wrote:
Most of the boards use 0x130b0. You should really check with a scope and see if the MCLK is getting to the codec. I suppose it is as the driver can read its ID register correctly.
I am missing the regmap. Should I configure kernel with additional CONFIG_ ?
mount -t debugfs none /sys/kernel/debug
Here we go!
root@edelin:/sys/kernel/debug/regmap/0-000a# cat registers 000: a011 002: 0060 004: 0008 006: 0080 00a: 0010 00e: 020c 010: fcfc 014: 015f 020: 0000 022: 4000 024: 0022 026: 0068 028: 01f1 02a: 0200 02c: 0322 02e: 0d0d 030: 7260 032: 5000 034: 0000 036: 0017 03a: 0000 03c: 0000 100: 0000 102: 0000 104: 0040 106: 051f 108: 0000 10a: 0040 10c: 0000 10e: 0000 110: 0000 116: 002f 118: 002f 11a: 002f 11c: 002f 11e: 002f 120: 8000 122: 0000 124: 0510 126: 1473 128: 0028 12a: 0050 12c: 0000 12e: 0000 130: 0000 132: 0000 134: 0000 136: 0000 138: 0000 13a: 0000
now access:
root@edelin:/sys/kernel/debug/regmap/0-000a# cat access 000: y y y n 002: y y n n 004: y y n n 006: y y n n 008: n y n n 00a: y y n n 00c: n y n n 00e: y y y n 010: y y n n 012: n y n n 014: y y n n 016: n y n n 018: n y n n 01a: n y n n 01c: n y n n 01e: n y n n 020: y y n n 022: y y n n 024: y y n n 026: y y n n 028: y y n n 02a: y y n n 02c: y y n n 02e: y y n n 030: y y n n 032: y y n n 034: y y n n 036: y y y n 038: n y n n 03a: y y n n 03c: y y n n 03e: n y n n 040: n y n n 042: n y n n 044: n y n n 046: n y n n 048: n y n n 04a: n y n n 04c: n y n n 04e: n y n n 050: n y n n 052: n y n n 054: n y n n 056: n y n n 058: n y n n 05a: n y n n 05c: n y n n 05e: n y n n 060: n y n n 062: n y n n 064: n y n n 066: n y n n 068: n y n n 06a: n y n n 06c: n y n n 06e: n y n n 070: n y n n 072: n y n n 074: n y n n 076: n y n n 078: n y n n 07a: n y n n 07c: n y n n 07e: n y n n 080: n y n n 082: n y n n 084: n y n n 086: n y n n 088: n y n n 08a: n y n n 08c: n y n n 08e: n y n n 090: n y n n 092: n y n n 094: n y n n 096: n y n n 098: n y n n 09a: n y n n 09c: n y n n 09e: n y n n 0a0: n y n n 0a2: n y n n 0a4: n y n n 0a6: n y n n 0a8: n y n n 0aa: n y n n 0ac: n y n n 0ae: n y n n 0b0: n y n n 0b2: n y n n 0b4: n y n n 0b6: n y n n 0b8: n y n n 0ba: n y n n 0bc: n y n n 0be: n y n n 0c0: n y n n 0c2: n y n n 0c4: n y n n 0c6: n y n n 0c8: n y n n 0ca: n y n n 0cc: n y n n 0ce: n y n n 0d0: n y n n 0d2: n y n n 0d4: n y n n 0d6: n y n n 0d8: n y n n 0da: n y n n 0dc: n y n n 0de: n y n n 0e0: n y n n 0e2: n y n n 0e4: n y n n 0e6: n y n n 0e8: n y n n 0ea: n y n n 0ec: n y n n 0ee: n y n n 0f0: n y n n 0f2: n y n n 0f4: n y n n 0f6: n y n n 0f8: n y n n 0fa: n y n n 0fc: n y n n 0fe: n y n n 100: y y n n 102: y y n n 104: y y n n 106: y y n n 108: y y n n 10a: y y n n 10c: y y n n 10e: y y n n 110: y y n n 112: n y n n 114: n y n n 116: y y n n 118: y y n n 11a: y y n n 11c: y y n n 11e: y y n n 120: y y n n 122: y y n n 124: y y n n 126: y y n n 128: y y n n 12a: y y n n 12c: y y n n 12e: y y n n 130: y y n n 132: y y n n 134: y y n n 136: y y n n 138: y y n n 13a: y y n n
cache-bypass
root@edelin:/sys/kernel/debug/regmap/0-000a# cat cache_bypass N
cache-dirty
root@edelin:/sys/kernel/debug/regmap/0-000a# cat cache_dirty N
cache-only
root@edelin:/sys/kernel/debug/regmap/0-000a# cat cache_only N
name
root@edelin:/sys/kernel/debug/regmap/0-000a# cat name sgtl5000
range
root@edelin:/sys/kernel/debug/regmap/0-000a# cat range 0-6 a-a e-10 14-14 20-36 3a-3c 100-110 116-13a
rbtree
root@edelin:/sys/kernel/debug/regmap/0-000a# cat rbtree 2-3c (30) 100-13a (30) 2 nodes, 60 registers, average 30 registers, used 192 bytes
and now the ssi node:
root@edelin:/sys/kernel/debug/regmap/2028000.ssi# ll total 0 -r-------- 1 root root 0 Jan 1 00:00 access -rw------- 1 root root 0 Jan 1 00:00 cache_bypass -r-------- 1 root root 0 Jan 1 00:00 cache_dirty -rw------- 1 root root 0 Jan 1 00:00 cache_only -r-------- 1 root root 0 Jan 1 00:00 name -r-------- 1 root root 0 Jan 1 00:00 range -r-------- 1 root root 0 Jan 1 00:00 registers
root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat name fsl-ssi-dai
root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat registers 00: 00000000 04: 00000000 10: 00001058 18: 00003003 1c: 0000020d 20: 0000020d 24: 00040100 28: 00040100 2c: 00880088 30: 00000000 34: 00000000 38: 00000000 48: 00000000 4c: 00000000 50: 00000000 54: 00000000 58: 00000000
root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat cache_bypass N
root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat cache_dirty N
root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat cache_only N
root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat range 0-4 10-10 18-38 48-58
root@edelin:/sys/kernel/debug/regmap/2028000.ssi# cat access 00: y y y n 04: y y y n 08: y n y y 0c: y n y y 10: y y n n 14: y y y y 18: y y n n 1c: y y n n 20: y y n n 24: y y n n 28: y y n n 2c: y y y n 30: y y n n 34: y y y n 38: y y y n 3c: y y y y 40: y y y y 44: y y y y 48: y y n n 4c: y y n n 50: y n y n 54: n y n n 58: n y n n
Now the pinmux
device 21d8000.audmux state default type MUX_GROUP (2) controlling device 20e0000.iomuxc group audmuxgrp function imx6qp-ek360
device 21d8000.audmux state default type CONFIGS_PIN (3) controlling device 20e0000.iomuxc pin MX6Q_PAD_CSI0_DAT7 config 000130b0
device 21d8000.audmux state default type CONFIGS_PIN (3) controlling device 20e0000.iomuxc pin MX6Q_PAD_CSI0_DAT4 config 000130b0
device 21d8000.audmux state default type CONFIGS_PIN (3) controlling device 20e0000.iomuxc pin MX6Q_PAD_CSI0_DAT5 config 000110b0
device 21d8000.audmux state default type CONFIGS_PIN (3) controlling device 20e0000.iomuxc pin MX6Q_PAD_CSI0_DAT6 config 000130b0
Pinctrl maps: device 20e0000.iomuxc state default type MUX_GROUP (2) controlling device 20e0000.iomuxc group hoggrp function imx6qp-ek360
device 20e0000.iomuxc state default type CONFIGS_PIN (3) controlling device 20e0000.iomuxc pin MX6Q_PAD_GPIO_0 config 000030b0
Now the Audio System On Chip (ASOC)
root@edelin:/sys/kernel/debug/asoc# ls codecs dais imx6-ek360-sgtl5000 platforms root@edelin:/sys/kernel/debug/asoc# cat codecs sgtl5000.0-000a snd-soc-dummy root@edelin:/sys/kernel/debug/asoc# cat dais 2034000.asrc 2028000.ssi sgtl5000 snd-soc-dummy-dai root@edelin:/sys/kernel/debug/asoc# cat platforms 2034000.asrc 2028000.ssi snd-soc-dummy
Any other value? :-/
You should check in this scope if your getting SSI clock/data when playing audio.
The biggest problem is to solder into the pins of the sgtl5000. I have a signal analyzer (Saleae) but it need some wires to get the job done.
I would like to solve the problem by software first. I cannot believe a hardware problem...
Regards,
On 06/29/2017 04:24 PM, gianluca wrote:
On 06/29/2017 03:49 PM, Fabio Estevam wrote:
On Thu, Jun 29, 2017 at 10:39 AM, gianluca gianlucarenzi@eurekelettronica.it wrote:
In the device-tree the sound node is so configured:
sound { compatible = "fsl,imx-audio-sgtl5000"; model = "imx6-ek360-sgtl5000"; ssi-controller = <&ssi1>; audio-codec = <&sgtl5000>; audio-routing = "MIC_IN", "Mic Jack", "Mic Jack", "Mic Bias", "Headphone Jack", "HP_OUT"; mux-int-port = <1>; mux-ext-port = <4>;This should be mux-ext-port = <3>;
I've already modified now.
I do not know about the mux-int-port or mux-ext-port. The only thing I know is the hardware guy told me he routed the ssi (CLK and DAT) to:
AUD3_TXC_R (i2s_sclk) AUD3_TXD (i2s_din) AUD3_TXFS (i2s_lrclk) AUD3_RXD (i2s_dout) SYS_MCLK (GPIO_0_CLKO sys_mclk)
since you are using AUD3 pins.
So, are they good?
My only concern is the value after the MSYS_CLK (GPIO_0_CCM_CLK01). It is 0x030b0. Is this correct for output clock signal?
So I configured the pinmux for audio in the following way:
pinctrl_audmux: audmuxgrp { fsl,pins = < /* SGTL5000 sys_mclk */ MX6QDL_PAD_GPIO_0__CCM_CLKO10x030b0
The remaining pins seems to be configured as a lot of boards in the current 4.12-rc7 kernel. So I can assume they are good.
MX6QDL_PAD_CSI0_DAT4__AUD3_TXC0x130b0 MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0 MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0 MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0 >; };
They should be good.
How can I check or dump the SGTL5000 registers?
cat /sys/kernel/debug/regmap/xxx
I am missing the regmap. Should I configure kernel with additional CONFIG_ ?
I started from the imxv6_imxv7_defconfig, then modified to have the correct drivers module as built-in or dynamic.
Maybe am I missing something else??? :-(
The funny thing is I can clearly hear the 'POP' of the speaker after some seconds the end of the audio stream...
# aplay /usr/share/sounds/alsa/Front_Right.wav
participants (2)
-
Fabio Estevam -
gianluca