No Audio Capture on SSI3, IMX6Q

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

No Audio Capture on SSI3, IMX6Q

Jump to solution
2,048 Views
pasamuel
Contributor III


On a IMX6Q-based platform, we are switching from Android Jelly Bean to Marshmallow. The board has a toshiba mipi chip (tc35874) for HDMI video and audio capture. After porting to Marshmallow, the video works fine but the audio capture does not. It's not a hardware issue as the audio capture was working on Jelly Bean. We also probed the audio data, bit and work clock lines from the Toshiba chip and verified that it's sending data/clock signals. The SSI3 and AUDMUX registers seems to be configured  similar to what it was on Jelly Bean. The audio driver properly registers with the kernel and ALSA enumerates the sound card ( Card 2).

SSI -> codec mapping is also successful:

imx-tc358749 sound-hdmi-input: tc358749-hifi <-> 2030000.ssi mapping ok


However, when attempting to capture audio data using tinycap utility, no audio data is captured :


tinycap /sdcard/Music/hdmi_test.wav -D 2 -d 0 -r 48000 -c 2
Capturing sample: 2 ch, 48000 hz, 16 bit
Captured 0 frames

Below is a snippet of the device tree config

        sound-hdmi-input {
                compatible = "fsl,imx-var-som-tc358749", "fsl,tc358749-audio";
                cpu-dai = <&ssi3>;
                model = "tc358749-audio";
                mux-int-port = <7>;
                mux-ext-port = <4>;
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_audmux_tc358749>;
                status = "okay";
        };

               pinctrl_audmux_tc358749: audmux_tc358749 {
                        fsl,pins = <
                                 MX6QDL_PAD_DISP0_DAT19__AUD4_RXC  0x130b0
                                 MX6QDL_PAD_DISP0_DAT23__AUD4_RXD  0x130b0
                                 MX6QDL_PAD_DISP0_DAT18__AUD4_RXFS 0x130b0
                        >;
               };

&ssi3 {
       fsl,mode = "i2s-slave";
       status = "okay";
};

Registers 0x203_0008, 0x203_000C ( SSI Receive Data Register (SSI3_SRX0/SRX1)) read 0, showing that no data is received.

Is there some thing else that needs to be configured for data capture?

The one oddity that is different from Jelly Bean is register 0x203_0018 ( SSI3_SIER). On JB, the value is 0x0040_0000 but on MM, the value is 0x140,3457 which doesn't seem to make sense but it may or may not be relevant to the problem.

Any help diagnosing the problem is appreciated.

Thanks,

--Sam

Labels (1)
0 Kudos
1 Solution
1,504 Views
pasamuel
Contributor III

Hi Igor,

I think I found the problem.

Register SSI3_SRMSK ( Receive Time Slot Mask Register) was being set-up incorrectly which prevented capture. Even though the sound driver calls are exactly the same in Marshmallow ( 4.1 kernel) and Jelly Bean (3.0.35), for some reason the default value of that register was being changed.

Manually setting that register to the default value kicks off the capture which I was able to playback.

I'm not sure why the difference in 4.1 kernel but I'm still looking into that. 

Thanks for your help.

--Sam

View solution in original post

0 Kudos
11 Replies
1,504 Views
igorpadykov
NXP Employee
NXP Employee

Hi Sam

one can check ssi clocks (ssi3_clk_root) outputting it on CLKO pin and using

CCM_CCOSR register. Check audmux configurations with ones on other boards:

imx6qdl-sabrelite.dtsi, imx6qdl-sabresd.dtsi
http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/tree/arch/arm/boot/dts?id=rel_imx_4.1.15_2.0...

Test in linux (with same kernel as Marshmallow) using attached Linux Manual

Chapter 28 Advanced Linux Sound Architecture (ALSA) System on a Chip (ASoC) Sound Driver

Other module settings which may affect sound - sdma and asrc, they are used in nxp bsps described on

i.MX 6 / i.MX 7 Series Software and Development Tool|NXP 

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

0 Kudos
1,504 Views
pasamuel
Contributor III

Hi Igor,

Thanks for your quick response. The device tree configuration was checked against imx6q-nitrogen and sabrelite/auto. But I will re-verify just to be sure. 

Meanwhile, with respect to the ssi clock check, is this to force the ssi clock on CLK0? Shouldn't this already be taken when calling pcm/dai interfaces for capture? I'm trying to understand what's the purpose of the ssi check. Is this something that ought to have been taken care of by the audio driver but isn't?

Thanks,

--Sam

0 Kudos
1,504 Views
igorpadykov
NXP Employee
NXP Employee

Hi Sam

this just for verifying that ssi module receives proper ccm clock (audio driver may use and not use CLK0, depending on board).

For example Sabre SD (spf-27392 schematic) uses GPIO_0_CLKO to provide MCLK on WM8962 codec.

For sabrelite, imx6qdl-nitrogen6x.dtsi check     imx6q-nitrogen6x {     /* SGTL5000 sys_mclk */
                MX6QDL_PAD_GPIO_0__CCM_CLKO1

for read/write registers one can use memtool in unit tests

imx-test
www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-test-5.7.tar.gz

Best regards
igor

0 Kudos
1,504 Views
pasamuel
Contributor III

Hi Igor,

This chip doesn't need the clock like WM8962 codec which we also have on our reference board. On a working Jelly Bean device, the CLK0 is not configured for this chip as well. 

To the best of our knowledge, using sabre and nitrogen board device tree as reference, the chip seems to be configured properly. ALSA registers the sound card and we can open the device for capture. However, no frames are captured. IMX6 SSI receive registers are showing no data even though the toshiba part is sending data.

  Is there anything else that needs to be configured for SSI3? Jelly Bean did have option for specifying DMA but I assume this is an automatic configuration in Marshmallow. 

static struct imx_ssi_platform_data mx6_precor_tc_ssi_pdata = {
.flags = IMX_SSI_DMA | IMX_SSI_SYN,
};

I've compared register values with SSI3 and AUDMUX registers to a working device. I'm not seeing any big difference that would explain why IMX6 doesn't capture audio. 

Thanks,

--Sam

0 Kudos
1,504 Views
igorpadykov
NXP Employee
NXP Employee

Hi Sam

had you checked ssi clock (ssi3_clk_root), is it eanbled,

without it ssi will not receive frames nor set any ready bits.

Best regards
igor

0 Kudos
1,504 Views
pasamuel
Contributor III

Hi Igor,

Are you referring to CCM_CCOSR register? I set it manually from command line using devregs tool but still no capture.

#devregs 0x20C_4060 0x1140101

In Jelly Bean board config, we had this config but no explicit call to enable ssi3 clock :

static struct mxc_audio_platform_data tc_audio_data = {
    .ssi_num = 2,
    .src_port = 7,
    .ext_port = 4,
    .hp_gpio = -1,
};

imx6q_add_imx_ssi(2, &mx6_precor_tc_ssi_pdata);

Is there a  explicit way to enable SSI3 clock root in 4.1 kernel device tree?

Thanks,

--Sam

0 Kudos
1,504 Views
igorpadykov
NXP Employee
NXP Employee

Hi Sam

 

yes, I suggested to check ssi clock (ssi3_clk_root), is it eanbled,

if yes you will see it on CLKO pin.

Measure frequency and compare with working board.

In general one can printf all ssi, ccm registers (related to ssi)

of working and not working boards and compare them.

Best regards
igor

0 Kudos
1,504 Views
pasamuel
Contributor III

Hi Igor,

Sorry for the delay in following up because of the holidays.

We checked the SSI3 clock on CLKO pin for both a working device ( with Jelly Bean) and non-working device with Marshmallow. SSI3 clock is active on Jelly Bean device but not on Marshmallow.

What's the proper way to enable the SSI3 clock? The device tree is similar to Nitrogen board dts.  I assumed that once enabled in device tree that the clock would be enabled automatically. In Marshmallow, should the SSI3 clock be explicitly enabled at the driver level? Appreciate your feedback.

Thanks,

--Sam

0 Kudos
1,504 Views
igorpadykov
NXP Employee
NXP Employee

Hi Sam

 

ssi3_clk_root may be gated in CCM_CCGR5 and it
should be enabled with dts file settings (no need explicitly be enabled at driver level).
One can check (and try to rebuild from scratch all image), if correct name processor was
used for build (and dts file names). As there are many i.MX6: Q, QP, Solo, DL - they may have
minute differencies in dts files.

 

Best regards
igor

0 Kudos
1,504 Views
pasamuel
Contributor III

Hi Igor,

I checked register CCM_CCGR5 when attempting to capture audio data using the tinycap utility. The reg value is 0xFC000F3 => SSI3 clock is enabled.

So I believe the device tree is enabling the SSI3 clock. Although we're not able to see this on the CLKO pin output.

Toshiba part is sending bit, word and data clock.

Are there any other registers to I can check?

Thanks,

--Sam

0 Kudos
1,505 Views
pasamuel
Contributor III

Hi Igor,

I think I found the problem.

Register SSI3_SRMSK ( Receive Time Slot Mask Register) was being set-up incorrectly which prevented capture. Even though the sound driver calls are exactly the same in Marshmallow ( 4.1 kernel) and Jelly Bean (3.0.35), for some reason the default value of that register was being changed.

Manually setting that register to the default value kicks off the capture which I was able to playback.

I'm not sure why the difference in 4.1 kernel but I'm still looking into that. 

Thanks for your help.

--Sam

0 Kudos