i.MX6 S/PDIF transmitter choosing inappropriate PLL under Linux

[inovonicsjeremy]

On a custom host board for a Variscite SoM we're attempting to use the S/PDIF transmitter for an application requiring a fairly high degree of clock precision. Notably the default configuration for the S/PDIF transmitter clock under Linux (using the linux-fslc tree) is to source the SPDIF0 clock from PLL3 PFD3, leaving it as the closest candidate when the S/PDIF transmitter driver selects a clock source. It is however, not accurate enough for our purposes, being off by fractions of a percent, rather the dozen PPM or so we need.

From what I could dig up, the use of that PFD for the SPDIF0 clock rather than the audio PLL is hard-coded into the clock driver, however changing it to the post-divided audio PLL output did not result in it being selected, rather the clock source chosen at the last mux (SPDIF_STC's TxClk_Source) was now the divided ipu_clk rather than tx_clk (SPDIF0_CLK_ROOT). I believe this was because of a failure to correctly set the intermediary dividers, as the combination of defaults for the other dividers and the range of PLL4 is outside of the divider range for only the S/PDIF transmitter divider.

My question then is how would I go about configuring the clock system under Linux to allow those intermediary dividers (ANALOG_PLL_AUDIO's POST_DIV_ SELECT, MISC2's AUDIO_DIV_LSB/_MSB, and CDCDR's SPDIF0_CLK_PRED and SPDIF0_CLK_PODF) to factor in to clock selection such that PLL4 with its fractional divider can be used to output S/PDIF with the precision we need? I have acquired accurate frequencies under Linux by manually poking registers via /dev/mem from userspace, however that's obviously highly undesirable.

Thanks,

-Jeremy

[inovonicsjeremy · Accepted solution]

The solution to this it seems was to write a completely custom spdif_clk_set_rate function, and walk the tree of dividers to get a handle to each, as well as PLL4 itself. This is of course, something I would have had to do anyway with the Freescale BSP, regardless of the board in question.

[igorpadykov]

Hi Jeremy

I am not aware how spdif is supported by variscite, but you can

test it with Freescale BSP L3.14.28_1.0.0_iMX6QDLS_BUNDLE

on freescale reference boards. Note, limited number of frequencies supported:

SABRE-SD supports 16 bit and 24 bit stereo playback from 32 KHz to 48 KHz sample rate

SABRE-AI supports 24 bit stereo record from 16 KHz to 96 KHz.

For details and testing procedure one can refer to attached Linux Manual

Chapter 32 The Sony/Philips Digital Interface (S/PDIF) Driver

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[inovonicsjeremy]

Hi Igor,

Variscite pins out the S/PDIF out port, and that's good enough to make this a Freescale issue. I am in fact able to drive S/PDIF output, however it is not accurate enough as per the details provided in my original post.

Thanks,

-Jeremy

[igorpadykov]

Hi Jeremy

I would suggest to post it to Variscite

forum, as it  uses own BSP which may not support spdif

Best regards

igor

[inovonicsjeremy]

Hi Igor,

S/PDIF works. I am outputting S/PDIF data. The only Variscite software I am using is the device-tree file, which does include the working S/PDIF device. Beyond the device-tree file itself, the kernel being used is the Freescale linux-fslc tree.

Please do not mark the question "assumed answered" without addressing the question, which relates to clock routing as handled by the Freescale code that controls the Freescale hardware, not the BSP.

Thanks,

-Jeremy

[igorpadykov]

Hi Jeremy

please try with Freescale BSP L3.14.28_1.0.0_iMX6QDLS_BUNDLE

(not community linux-fslc) on freescale reference board.

Difference between Freescale BSP and Community BSP is described below

https://community.freescale.com/message/402940#402940

Best regards

igor

[inovonicsjeremy]

Hi Igor,

While your suggestion to buy more hardware and ignore the convenience provided by device-tree files altogether is tempting, I believe the simple fact that the Freescale BSP's S/PDIF Tx driver still merely makes a call to clk_set_rate on a clock node proves such testing unnecessary. In fact, use of PLL4 by the Freescale BSP seems to be relegated to audio codecs, making its use at all under said BSP for the S/PDIF transmitter even less trivial than the Community BSP.

If I have misread the Freescale BSP and there is in fact code relevant to my question there, a reference to file and line number would be much appreciated.

Thanks,

-Jeremy