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

[dragosstoica]

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,

[ThomasBandelier]

VladanJovanovicFabioEstevam,MT any feedback on this would be appreciate. Thanks in advance !

Thomas

[sinanakman]

Hi Thomas

I don't know how much this will help you but sometimes

ago I took a SabreSD board (not Sabre Auto Fabio mentions)

and tested the spdif input. As this board doesn't have a spdif

port I used the OTG pins and muxed it accordingly. I used

the recent mainline Linux kernel at that time (3.18) and

had no problem recording a CD from an inexpensive (Phillips)

DVD player. I recorded using arecord command as you did.

The recording and playing back had no problem in that experiment.

If you prefer you can perhaps set up a sabresd platform

(if you find mx6sabre auto that Fabio suggested too

expensive) with a recent mainline kernel  and measure

the signals as you did on your board to compare.

Unfortunately I don't have that set up any more but

if can't solve this problem for some time I can see if

I would be able to  have some time to put this together

again.

Regards

Sinan Akman

[fabio_estevam]

Hi Thomas,

Sorry for the delay.

mx6sabre auto boards are capable of doing SPDIF input. Are you able to have access to this board and have a try  for comparison?

Regards,

Fabio Estevam

[ThomasBandelier]

Hi Fabio,

we wil llook into this possibility. Apparently you want to isolate a HW issue: based on the data provided by @dragosstoica, what could be a lead for a HW issue that would explain this clock behaviour? Is voltage level correct for example ?

Thanks

Thomas

[fabio_estevam]

Hi Thomas,

Yes, that's the idea.

Please check the mx6qsabreauto SPDIF input circuitry for comparison. The schematics are available at freescale.com.

Regards,

Fabio Estevam