AnsweredAssumed Answered

i.MX6Q S/PDIF RX clock detection (voltage level issue?)

Question asked by dragosstoica on Feb 4, 2015
Latest reply on Mar 9, 2015 by Fabio Estevam
Branched to a new discussion

Hi all,

 

We have a platform based on  i.MX6Q, and we try to record the S/PDIF audio from the DVD unit. However, the recording is very noisy and with interruptions.

I use this command:

root@android:/ # alsa_arecord -Dhw:0,0 -f S24_LE  -c 2 -r 44100 /system/spdif_rec_10.wav
Recording WAVE '/system/spdif_rec_10.wav' : Signed 24 bit Little Endian, Rate 44100 Hz, Stereo
overrun!!! (at least 355.589 ms long)
overrun!!! (at least 1216.716 ms long)
overrun!!! (at least 278.374 ms long)
overrun!!! (at least 112.048 ms long)

 

This is how we configured the S/PDIF in the board file:

static struct mxc_spdif_platform_data mxc_spdif_data = {
       .spdif_tx       = 0,    /* disable tx */
       .spdif_rx       = 1,    /* enable rx */
       .spdif_rx_clk   = 0,    /* rx clk from spdif stream */
       .spdif_clk      = NULL, /* spdif bus clk */
};

    mxc_spdif_data.spdif_core_clk = clk_get_sys("mxc_spdif.0", NULL);
    clk_put(mxc_spdif_data.spdif_core_clk);
    imx6q_add_spdif(&mxc_spdif_data);
    imx6q_add_spdif_dai();
    imx6q_add_spdif_audio_device();

 

We captured SPDIF_SR_CLK (pad GPIO_8) and we see many interruptions of the clock signal. Please see the captures (la_capture_1.png and la_capture_2.png)

It looks like the RX clock is not detected properly from the input bitstream.. Do you know what could cause this problem?


We also investigated the S/PDIF signal level (DS1ED142105694_5.bmp  ch1: S/PDIF, ch2: SR_CLK). Is this voltage level correct?

 

We tried with a different S/PDIF source and a different signal level, but no data could be recorded at all (DS1ED142105694_13.bmp)

We also confirmed that the DVD signal is correct (with a different s/pdif receiver)

 

These are the S/PDIF-related registers:

root@android:/ # [  246.700982] SCR: 0x00140600
[  246.703795] SIE: 0x0010c7ec
[  246.706598] SRPC: 0x00000058
[  246.709488] FreqMeas: 0x0008adde
[  246.712728] reg 0x00 = 0x140600
[  246.715879] reg 0x04 = 0x000000
[  246.719030] reg 0x08 = 0x000058
[  246.722181] reg 0x0c = 0x10c7ec
[  246.725333] reg 0x10 = 0x93c613
[  246.728484] reg 0x14 = 0x000000
[  246.731635] reg 0x18 = 0x000000
[  246.734786] reg 0x1c = 0x208000
[  246.737937] reg 0x20 = 0x000000
[  246.741088] reg 0x24 = 0x808080
[  246.744239] reg 0x28 = 0x000000
[  246.747390] reg 0x2c = 0x000000
[  246.750540] reg 0x30 = 0x000000
[  246.753691] reg 0x34 = 0x000000
[  246.756841] reg 0x38 = 0x000000
[  246.759993] reg 0x44 = 0x0af5f1
[  246.763144] reg 0x50 = 0x020f00
[  246.766484] SPDIF interrupt parity bit error
[  246.770766] SPDIF interrupt symbol error
[  246.774698] SPDIF Rx dpll locked
[  248.948596] SIS: 0x00830012
[  248.951407] SRPC: 0x00000058
[  248.954298] FreqMeas: 0x000af2b7
[  249.313858] SCR: 0x00140200
[  249.316671] SIE: 0x0010c7ec
[  249.319475] SRPC: 0x00000058
[  249.322365] FreqMeas: 0x000af2b6
[  249.325604] reg 0x00 = 0x140200

 

We use the L3.0.35 BSP (JB4.2.2_1.0.0-GA).

 

Though, after applying two patches that changes the bus clock for s/pdif to "ipg" (ENGR00267442 and ENGR00315426) from linux-3.0.101-imx_4.1.1, we can see a difference..
The RX clock detection still fails but with less/smaller interruptions.

Please see d3_to_imx_spdif_without_patches_1.png and d3_to_imx_spdif_with_patches_1.png

 

Thank you,


Outcomes