SGTL5000 with external crystal, codec clock ok, sound is too fast

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SGTL5000 with external crystal, codec clock ok, sound is too fast

Jump to solution
2,952 Views
benoitmoffet
Contributor III


Hi,

I have a custom board with imx6dl cpu. We interfaced a SGTL5000 codec with fixed crystal sys_clk at 12.288MHz.

I used the standard imx-sgtl5000.c machine driver and created a fixed clock in the device tree to give to the codec.

clocks {

          audioclk: ext12Mz {

                  compatible = "fixed-clock";

                  clock-frequency = <12288000>;

reg=<0>;
          #clock-cells = <0>;

          };

        };

        sound {

                compatible = "fsl,imx-audio-sgtl5000";

                model = "imx6dl-custom-sgtl5000";

                cpu-dai = <&ssi1>;

                audio-codec = <&codec>;

                audio-routing =

"MIC_IN", "Mic Jack",
      "Mic Jack", "Mic Bias",
      "Headphone Jack", "HP_OUT",
      "Ext Spk", "LINE_OUT";

                mux-int-port = <1>;

                mux-ext-port = <4>;

        };

codec: sgtl5000 {
compatible = "fsl,sgtl5000";
clocks = <&audioclk>;
reg = <0x0a>;
VDDA-supply = <&reg_3p3v>;

                VDDIO-supply = <&reg_3p3v>;

};

&ssi1 {

  fsl,mode = "i2s-slave";

  status = "okay";

};

The sound is working but twice too fast and with some strange numeric noise.

I feel the system is playing stereo sound in a mono way so I hear left and right channel on a single channel...

Any thoughts?

Best regards,

Benoit

0 Kudos
1 Solution
1,878 Views
benoitmoffet
Contributor III

We managed to find the issue, it was a version issue between kernel and packages in the Q7 COM BSP we used. I started from scratch, without using the BSP from the COM manufacturer and it works really well now.

Thanks Igor.

Best regards,

Benoit

View solution in original post

0 Kudos
12 Replies
1,879 Views
benoitmoffet
Contributor III

We managed to find the issue, it was a version issue between kernel and packages in the Q7 COM BSP we used. I started from scratch, without using the BSP from the COM manufacturer and it works really well now.

Thanks Igor.

Best regards,

Benoit

0 Kudos
1,878 Views
igorpadykov
NXP Employee
NXP Employee

had you measured sgtl5000 clock (bit, frame) signals with oscilloscope,

do they have correct waveforms, frequency ?

Also if you record sound to file on that board and then play, will it have the same

too fast issue ?

0 Kudos
1,878 Views
benoitmoffet
Contributor III

The frame and bit clock are as expected 1.6Mhz and 48 kHz. .. it's the data

that seems to be invalid. If I do a speaker-test with sine at 1khz I get a

2 kHz sine on the scope.

My HW does not have a Mic...

Regards.

On Mar 17, 2016 10:50 PM, "igorpadykov" <admin@community.freescale.com>

0 Kudos
1,878 Views
igorpadykov
NXP Employee
NXP Employee

seems for some reason linux uses ssi settings for clock = 24000000.

What BSP are you using ? NXP does not use sgtl5000 on its releases,

recommended try boundary devices releases:

http://boundarydevices.com/audio-output-selection-under-linux-on-i-mx6/

Best regards

igor

0 Kudos
1,878 Views
benoitmoffet
Contributor III

That was my assumption, so I changed the oscillator to 24mhz. Same results.

On Mar 18, 2016 4:18 AM, "igorpadykov" <admin@community.freescale.com>

0 Kudos
1,878 Views
igorpadykov
NXP Employee
NXP Employee

Hi Benoit

seems clocks = <&audioclk>;  should be SSI's sys clock (SSI_CLK_ROOT)

on Figure 61-22. SSI Transmit Clock Generator Block Diagram

i.MX6DQ Reference Manual http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf

like clocks = <&clks 201>;  on example

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/boot/dts/imx6q-sabrelite.d...

Best regards

igor

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

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

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

0 Kudos
1,878 Views
benoitmoffet
Contributor III

We changed the oscillator to match references design to a 24MHz sys_clk and we get the same results with no surprise. Any new idea Igor?

0 Kudos
1,878 Views
igorpadykov
NXP Employee
NXP Employee

even clocks are generated externally it makes sense to check SSI_CLK_ROOT

as there are dependencies :

1.jpg

~igor

0 Kudos
1,878 Views
benoitmoffet
Contributor III

Hi Igor,

Our ratio is good...

Just to confirm, the codec is master, so it provides bit and frame clock and they are connected on TXC and TXFS pin of the cpu.

Here is what is in imx-sgtl5000.c in our kernel:

ret = imx_audmux_v2_configure_port(int_port,
IMX_AUDMUX_V2_PTCR_SYN |
IMX_AUDMUX_V2_PTCR_TFSEL(ext_port) |
IMX_AUDMUX_V2_PTCR_TCSEL(ext_port) |
IMX_AUDMUX_V2_PTCR_TFSDIR |
IMX_AUDMUX_V2_PTCR_TCLKDIR,
IMX_AUDMUX_V2_PDCR_RXDSEL(ext_port));

As far as I understand, the flags IMX_AUDMUX_V2_PTCR_TFSDIR and IMX_AUDMUX_V2_PTCR_TCLKDIR should not be present since we want them as an input right? But in the sabrelite reference design with sgtl5000 which is connected the same way as our custom board, they use the 2 flags...

Could you help me clarify this part?

Regards

0 Kudos
1,878 Views
benoitmoffet
Contributor III

Finally, they are output if seen from the internal port point of view, so I guess this is correct.

0 Kudos
1,878 Views
benoitmoffet
Contributor III

Hi Igor,

Even if the codec mclk is an external crystal?

Best regards,

Benoit

0 Kudos
1,878 Views
benoitmoffet
Contributor III

Just FYI, the codec is in master mode and ssi1 in slave mode, so the codec provides the bit and LR clocks.

Regards

0 Kudos