i.MX7Dual + SGTL5000 no data on SAI output

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX7Dual + SGTL5000 no data on SAI output

1,504 Views
Contributor II

Dear Support Team,

I have a problem with enabling sound on imx7d with sgtl5000 codec connected.
I've tried to follow recomendations from the latest i.MX Reference Manual available in Linux BSP (Chapter 7: Audio) but description of imx7 + sgtl5000 variant seems to be not present yet there.
I would be gratefull for supporting me with the issue.

My hardware setup is pretty much the same as for variant 1 (single audio codec) described here:
https://community.nxp.com/docs/DOC-334857
The only difference is that I2S_DOUT is not connected to SAI1_RX_DATA.

I'm using latest kernel from FSL BSP (https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fim...).


My kernel configuration is arch/arm/configs/imx_v7_defconfig + following flags added:

CONFIG_SND_SIMPLE_CARD = y

I'm using simple-card.c driver instead of imx-sgtl5000.c because the second one does not support SAI interfaces (it handles SSI only).

My device tree is configured as follows (done based on imx7s-warp.dts + MCLK frequency change from 24,000 MHz to 12,288 MHz):

/dts-v1/;

#include "imx7d.dtsi"

/ {
    model = "My device";
    compatible = "my device";

    sound {
        compatible = "simple-audio-card";
        simple-audio-card,name = "my_soundcard";
        simple-audio-card,format = "i2s";
        simple-audio-card,bitclock-master = <&dailink_master>;
        simple-audio-card,frame-master = <&dailink_master>;
        simple-audio-card,cpu {
            sound-dai = <&sai1>;
        };

        dailink_master: simple-audio-card,codec {
            sound-dai = <&audio_codec>;
            clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
        };
    };
};

&sdma {
    status = "okay";
};

&clks {
    assigned-clocks = <&clks IMX7D_PLL_AUDIO_POST_DIV>,
                                    <&clks IMX7D_AUDIO_MCLK_ROOT_SRC>,
                                    <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;

    assigned-clock-parents = <0>,
                                            <&clks IMX7D_PLL_AUDIO_POST_DIV>,
                                            <0>;

    assigned-clock-rates = <884736000>,
                                            <0>,
                                            <12288000>;
};

&iomuxc {
    pinctrl_i2c2: i2c2grp {
        fsl,pins = <
            MX7D_PAD_UART2_RX_DATA__I2C2_SCL 0x40000008
            MX7D_PAD_UART2_TX_DATA__I2C2_SDA 0x40000008
        >;
    };

    pinctrl_sai1: sai1grp {
        fsl,pins = <
            MX7D_PAD_SAI1_TX_BCLK__SAI1_TX_BCLK 0x0000001f
            MX7D_PAD_SAI1_TX_DATA__SAI1_TX_DATA0 0x00000030
            MX7D_PAD_SAI1_TX_SYNC__SAI1_TX_SYNC 0x0000001f
    >;
    };

    pinctrl_sai1mclk: sai1mclkgrp {
        fsl,pins = <
            MX7D_PAD_SAI1_MCLK__SAI1_MCLK 0x0000001f
        >;
    };
};

&i2c2 {
    clock-frequency = <100000>;
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_i2c2>;
    status = "okay";

    audio_codec: sgtl5000@0a {
        compatible = "fsl,sgtl5000";
        reg = <0x0a>;
    };
};

&sai1 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_sai1>;

    assigned-clocks = <&clks IMX7D_SAI1_ROOT_SRC>,
                                    <&clks IMX7D_SAI1_ROOT_CLK>;
    assigned-clock-parents = <&clks IMX7D_PLL_AUDIO_POST_DIV>;
    assigned-clock-rates = <0>, <12288000>;

    status = "okay";
};

&audio_codec {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_sai1mclk>;
    #sound-dai-cells = <0>;
    clocks = <&clks IMX7D_AUDIO_MCLK_ROOT_CLK>;
    VDDA-supply = <&vgen6_reg>;
    VDDIO-supply = <&sw2_reg>;
    VDDD-supply = <&sw2_reg>;
};

With setup described above link between soundcard and sai is created and the card is registered in the system:

# dmesg | grep sai
[ 4.743192] asoc-simple-card sound: sgtl5000 <-> 308a0000.sai mapping ok

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: imx7dgtl50 [imx7d-sgtl5000], device 0: 308a0000.sai-sgtl5000 sgtl5000-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

Playing wav using aplay gives following output:

# aplay /usr/share/sounds/alsa/Front_Right.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

Unfortunately I cannot hear any sound. I'm able to play audio from linear input of SGTL5000 so analog audio output works fine.

I examined SAI lines using scope and it seems valid audio data are not present on SAI1_TXD.

Yellow:  SAI1_TXD (48 kHz),
RED: SAI1_TXC (1,56 MHz),

BLUE: SAI1_TXFS (48 kHz)

13.2.204.2.png

Yellow: MCLK (12,288 MHz)

13.2.204.1.png

Could you please advise me what shall I check or what I've missed?

Kind regards,
Łukasz

Labels (2)
0 Kudos
10 Replies

51 Views
Contributor II

Hello,

I've solved the problem few weeks ago. To finalize this thread and for posterity solution if following:
Barebox does not setup access privileges for AIPS3 bridge in i.MX7 at all. Adding missing AIPS configuration makes SAI and DMA up and running.
I'm going to submit a patch for it in so called meantime.

Regards,
Łukasz

0 Kudos

51 Views
NXP TechSupport
NXP TechSupport

Hi Łukasz

sgtl5000 is supported on warp7 board and one can look at its settings:

linux-fslc/imx7s-warp.dts at 4.1-1.0.x-imx · WaRP7/linux-fslc · GitHub 

GitHub - WaRP7/linux-fslc: Linux kernel source tree 

https://www.element14.com/community/docs/DOC-79058 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

51 Views
Contributor II

Hello,

I've reconfigured my project to use kernel suggested by you (https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FWaRP7%2Flinux-fslc). Unfortunately the result remains same (still no data on SAI_TXD).

I started to analyse ASoC files and it occurred that after dummy direct writes to FSL_SAI_TDR0 register (using fsl_sai_trigger() function from fsl_sai.c driver) these dummy data are present on SAI_TXD. So my assumption is that sound data are not properly transferred from ALSA to SAI through DMA...
Which piece of configuration may be missing in that case?

DMA seems to be configured and started properly:

# dmesg | grep dma
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.318911] mxs-dma 33000000.dma-apbh: initialized
[ 0.443648] imx-sdma 30bd0000.sdma: no iram assigned, using external mem
[ 0.444040] imx-sdma 30bd0000.sdma: loaded firmware 4.2


Functions from imx-pcm-dma.c driver are triggered.
I've debugged imx_pcm_dma_complete function() and addr member of snd_dmaengine_dai_dma_data structure contains valid address of FSL_SAI_TDR0...

All hints are very welcomed.

Best regards,
Łukasz

0 Kudos

51 Views
NXP TechSupport
NXP TechSupport

strictly speaking warp7 is not supported by nxp, if sai works and able to output data,

one can try to port dts changes and use nxp bsps from codeaurora.org

linux-imx - i.MX Linux kernel 

Linux drivers are described in NXP linux documentation on

i.MX Software|NXP 

Best regards
igor

0 Kudos

51 Views
Contributor II

Kernel from official FSL BSP (4.9.88_2.0.0_ga) is the one I've started with. I've switched to Warp7 kernel just for tests and now I'm using 4.9.88_2.0.0_ga again + ported Device tree sound configuration for Warp7. For both kernels I've faced the same issue.

I've done some additional tests and it seems that SDMA does not work as expected.
- DMA memory is allocated properly (dma_addr, dma_area, dma_bytes),
- Sound data are put into allocated dma memory properly (I've compared memory content with wave hex data and these match),

- pcm_dmaengine.c driver prepares and submits dma transactions properly,
- imx-sdma.c driver is triggered by pcm_dmaengine.c (sdma_config(), smda_issue_pending(), sdma_start_desc(), sdma_tx_status() functions are called).
- for some reason sound data are not transferred from allocated dma_addr memory to FSL_SAI_TDR0 register.

On the other hand SDMA tested against dmatest module works fine on varous channesl (memory to memory transactions):

# ls -l /sys/class/dma | grep dma1chan10
lrwxrwxrwx 1 root root 0 Jul 12 2017 dma1chan10 -> ../../devices/soc0/soc/30800000.aips-bus/30bd0000.sdma/dma/dma1chan10
# modprobe dmatest channel=dma1chan10 timeout=2000 iterations=5 run=1
[ 1910.255335] dmatest: Started 1 threads using dma1chan10
[ 1910.276073] dmatest: dma1chan10-copy: summary 5 tests, 0 failures 293 iops 1409 KB/s (0)

Is it possible that BSP kernel does not include correct DMA firmware or not handles memory->SAI transactions for some reason?
Is any additional DMA configuration for SAI required?


Kind regards,
Łukasz

0 Kudos

51 Views
NXP TechSupport
NXP TechSupport

i.MX7D EVK has WM8960 codec on board, it works fine with NXP Demo Images

linux/arch/arm/boot/dts/imx7d-sdb-reva-wm8960.dts

imx7d-sdb-reva-wm8960.dts\dts\boot\arm\arch - linux-imx - i.MX Linux kernel 

Demo Images

https://www.nxp.com/webapp/Download?colCode=L4.9.88_2.0.0_MX6UL7D&appType=license&location=null&Pare... 

Best regards
igor

0 Kudos

51 Views
Contributor II

Thanks.
I should get IMX7D SABRE in upcoming days so I will be able to verify standard images and my images against it.


I did more debugging and sdma_tx_status function returns DMA_IN_PROGRESS only (no DMA_COMPLETE observed).

Moreover it seems that SAI FIFO pointers are not modified after aplay calls (no DMA transfer).

[ 85.781908] sdma: sdma_tx_status(chan.1, type.24, evid0.9, evid1.0)
[ 85.788178] sdma: sdma_tx_status ret=DMA_IN_PROGRESS

I've seen that you're quite experienced with sdma. At the moment this is the only thing which looks suspicious to me. Do you have any idea what can be cause of this strange DMA behavior?
Can it be somehow related to silicon revision (rev. C)?
Is there anything that can be examined before I get NXP dev board?


Best regards,
Łukasz

0 Kudos

51 Views
Contributor II

Hello again,

The SabreSD board is finaly on my desk. With the demo image SAI works perfectly on it.


I have not mentioned it before but I use barebox to boot the system.

After some investigation it occurred that SAI doesn't work when barebox is used as a bootloader and it works if u-boot is used instead (verified against u-boot from codeaurora v2017.03_4.9.88_2.0.0_ga , mainline u-boot v2018.09 and latest barebox v2018.10).

I've compared DCD tables, device trees and board related code. Unluckily any important/significant difference has not been noticed by me.

Could you please advise what may be added to u-boot (and missing in barebox at the same time) in this case?
Unfortunately switching to u-boot is not a solution that satisfy me...

Regards,
Łukasz

0 Kudos

51 Views
NXP TechSupport
NXP TechSupport

Hi Łukasz

u-boot may configure some clocks which may be used later for codec,

so one can check clock signals with oscilloscope.

Best regards
igor

0 Kudos

51 Views
Contributor II

Hi Igor,

Thank you for the reply and links.


Actually I've already used warp7 configuration both original and slightly modified (attached in initial question) but it does not work for unknown reason.


May I ask you to take a closer look on my configuration please? I hope you'll find something overlooked by me...


Thank you in advance and kind regards,
Łukasz

0 Kudos