* Issue on Linux 4.12-rc7 on iMX6 based board
@ 2017-06-28 15:32 gianluca
2017-06-28 15:34 ` Fwd: " gianluca
0 siblings, 1 reply; 12+ messages in thread
From: gianluca @ 2017-06-28 15:32 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]
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
--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212
[-- Attachment #2: sgtl5000-ek360.png --]
[-- Type: image/png, Size: 48066 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-28 15:32 Issue on Linux 4.12-rc7 on iMX6 based board gianluca @ 2017-06-28 15:34 ` gianluca 2017-06-29 11:37 ` Fabio Estevam 0 siblings, 1 reply; 12+ messages in thread From: gianluca @ 2017-06-28 15:34 UTC (permalink / raw) To: alsa-devel [-- Attachment #1: Type: text/plain, Size: 3022 bytes --] -------- 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 -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 [-- Attachment #2: sgtl5000-ek360.png8 --] [-- Type: image/png, Size: 12953 bytes --] [-- Attachment #3: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-28 15:34 ` Fwd: " gianluca @ 2017-06-29 11:37 ` Fabio Estevam 2017-06-29 13:39 ` gianluca 0 siblings, 1 reply; 12+ messages in thread From: Fabio Estevam @ 2017-06-29 11:37 UTC (permalink / raw) To: gianluca; +Cc: alsa-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-29 11:37 ` Fabio Estevam @ 2017-06-29 13:39 ` gianluca 2017-06-29 13:49 ` Fabio Estevam 0 siblings, 1 reply; 12+ messages in thread From: gianluca @ 2017-06-29 13:39 UTC (permalink / raw) To: alsa-devel; +Cc: Fabio Estevam 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, -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-29 13:39 ` gianluca @ 2017-06-29 13:49 ` Fabio Estevam 2017-06-29 14:24 ` gianluca 0 siblings, 1 reply; 12+ messages in thread From: Fabio Estevam @ 2017-06-29 13:49 UTC (permalink / raw) To: gianluca; +Cc: alsa-devel 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_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? They should be good. > How can I check or dump the SGTL5000 registers? cat /sys/kernel/debug/regmap/xxx ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-29 13:49 ` Fabio Estevam @ 2017-06-29 14:24 ` gianluca 2017-06-29 14:30 ` Fabio Estevam 2017-06-29 14:36 ` gianluca 0 siblings, 2 replies; 12+ messages in thread From: gianluca @ 2017-06-29 14:24 UTC (permalink / raw) To: Fabio Estevam; +Cc: alsa-devel 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_CLKO1 >>> 0x030b0 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_TXC >>> 0x130b0 >>> 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, -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-29 14:24 ` gianluca @ 2017-06-29 14:30 ` Fabio Estevam 2017-06-29 16:28 ` gianluca 2017-06-29 16:59 ` Fwd: Issue on Linux 4.12-rc7 on iMX6 based board gianluca 2017-06-29 14:36 ` gianluca 1 sibling, 2 replies; 12+ messages in thread From: Fabio Estevam @ 2017-06-29 14:30 UTC (permalink / raw) To: gianluca; +Cc: alsa-devel 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-29 14:30 ` Fabio Estevam @ 2017-06-29 16:28 ` gianluca 2017-07-03 9:36 ` gianluca 2017-06-29 16:59 ` Fwd: Issue on Linux 4.12-rc7 on iMX6 based board gianluca 1 sibling, 1 reply; 12+ messages in thread From: gianluca @ 2017-06-29 16:28 UTC (permalink / raw) To: Fabio Estevam; +Cc: alsa-devel 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, -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-29 16:28 ` gianluca @ 2017-07-03 9:36 ` gianluca 2017-07-03 11:08 ` Fwd: Issue on Linux 4.12-rc7 on iMX6 based board [SOLVED] gianluca 0 siblings, 1 reply; 12+ messages in thread From: gianluca @ 2017-07-03 9:36 UTC (permalink / raw) To: Fabio Estevam; +Cc: alsa-devel 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, -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board [SOLVED] 2017-07-03 9:36 ` gianluca @ 2017-07-03 11:08 ` gianluca 0 siblings, 0 replies; 12+ messages in thread From: gianluca @ 2017-07-03 11:08 UTC (permalink / raw) To: alsa-devel 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, -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-29 14:30 ` Fabio Estevam 2017-06-29 16:28 ` gianluca @ 2017-06-29 16:59 ` gianluca 1 sibling, 0 replies; 12+ messages in thread From: gianluca @ 2017-06-29 16:59 UTC (permalink / raw) To: Fabio Estevam; +Cc: alsa-devel 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, -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: Issue on Linux 4.12-rc7 on iMX6 based board 2017-06-29 14:24 ` gianluca 2017-06-29 14:30 ` Fabio Estevam @ 2017-06-29 14:36 ` gianluca 1 sibling, 0 replies; 12+ messages in thread From: gianluca @ 2017-06-29 14:36 UTC (permalink / raw) To: alsa-devel; +Cc: Fabio Estevam 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_CLKO1 >>>> 0x030b0 > > 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_TXC >>>> 0x130b0 >>>> 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 -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-07-03 11:08 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-28 15:32 Issue on Linux 4.12-rc7 on iMX6 based board gianluca 2017-06-28 15:34 ` Fwd: " gianluca 2017-06-29 11:37 ` Fabio Estevam 2017-06-29 13:39 ` gianluca 2017-06-29 13:49 ` Fabio Estevam 2017-06-29 14:24 ` gianluca 2017-06-29 14:30 ` Fabio Estevam 2017-06-29 16:28 ` gianluca 2017-07-03 9:36 ` gianluca 2017-07-03 11:08 ` Fwd: Issue on Linux 4.12-rc7 on iMX6 based board [SOLVED] gianluca 2017-06-29 16:59 ` Fwd: Issue on Linux 4.12-rc7 on iMX6 based board gianluca 2017-06-29 14:36 ` gianluca
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.