Vybrid audio (sgtl5000)

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

Vybrid audio (sgtl5000)

2,193 Views
kubiznak_petr
Contributor V

Hi everyone,

I am experiencing several issues while patching the Timesys Linux to work with sgtl5000 audio on our custom board (base schema and module schema) with Vybrid VF6.

Firstly, can someone please explain me the clocking mechanism? I reached a functional audio with the following configuration:

  • PTB18 (attached to sgtl5000's SYS_MCLK) configured for output of CKO1 (0x00400062)
  • CCM_CCOSR configured to output 24MHz clock on CKO1 (0x000A0439)

Hence the SYS_MCLK signal of sgtl5000 receives 24MHz clock, nothing more. And it works, which surprises me. I was convinced the MCU also needs to receive the clock back as the EXT_AUDIO_MCLK. That's why we have PTA12 connected to PTB18, I expected to configure PTA12 to EXT_AUDIO_MCLK (mux 2), but it is not needed (current value 0x00000060). Also the IOMUXC_CCM_AUD_EXT_CLK_SELECT_INPUT register is left untouched (value 0x00000000). I would expect the current configuration to not work. Can someone please explain me where I am wrong?

Secondly, audio works correctly only when the second core is not running. When the second core is started using mqxboot, both cores start to collide on DMA. Originally it used to crash immediately, causing a kernel panic (NULL pointer dereference in ISR) because in function mcf_edma_isr() (at drivers/dma/mvf_edma.c) noone cared about the situation when no channel is found in the loop at lines 196:201. I added the following check right after the loop:

     if (channel == -1) {
          ERR("Invalid channel %d. addr=0x%p, irq=%d, dev_id=%p, intr=0x%08X",
               channel, addr, irq, dev_id, intr);
          return result;
     }

Now when I start a playback, error messages

drivers/dma/mvf_edma.c:mcf_edma_isr: Invalid channel -1. addr=0xf2038000, irq=40, dev_id=8a000000, intr=0x00000000

get produced periodically. The M4 core probably clears the interrupt flags before the kernel processes them. That does not obviously happen in all cases as the playback continues, just erroneously (1 block is played several times before a new one is delivered). Does the Tower behave the same way? If not, can someone (Timesys?) please suggest what else to do to fix it on our custom board?

Labels (3)
0 Kudos
3 Replies

990 Views
billpringlemeir
Contributor V

Xiubo Li  and Alison Wang (of Freescale) have added an SGTL5000 driver to the mainline linux.

It maybe helpful to you.  The clock infrastructure in the mainline is much easier to use.  TimeSys is also getting ready to release a more current version which should have the same clocking infrastructure.

As per the SYS_MCLK, it does not have to be the same as you observe.  This is a clock to the synchronous logic on the codec.  There is more synchronous logic on the Vybrid audio which needs a clock.  However, the SSI protocol itself can be synchronous and it also has a clock.  The other clocks over sample the bit lines in case of noise, shift/accumulate for the DAC, etc.  The main four lines (FS,TX,RX,CLK) are pretty much independent of the other two clocks.  For convenience,they can be the same.  Ie, using the same clock for SYS_MCLK on the SGTL5000 codec and the Vybrid Audio gives you more clock sources for other things.  If the Vybrid is the master, then the EXT_AUDIO_MCLK is what is the origin of the SSI CLK.  If the SGTL is the master then, SYS_MCLK will be the origin.  However, each side can have un-correlated clocks that control the module logic.  Some codec have an internal PLL for this purpose.  Often they include the option for an external source as this clock can affect the audio performance; it is a time base for all the digital logic on the chip.

As per the DMA/interrupt issue with the M4, this is probably dependent on both the Linux and MQX versions and configuration.  There is nothing to prevent hardware collision between the two CPUs; Ie, accessing SOC peripheral simultaneously.  With the mainline and the device tree, you can get lists of what pins/modules are used by Linux in sysfs.  You have to hunt through the MQX source/configuration to find the other M4 side.  People with a Tower Board also need the TWR-AUDIO-SGTL daughter board to test this (as well as your configurations).

990 Views
kubiznak_petr
Contributor V

Dear Bill,

thank you for helpful reply.

I am using Linux 3.0.15-ts-armv7l (i.e. ~1 month old version) and MQX 4.0.2, configuration might surely play a role, but that is not the most important part now. I would just like to know whether generally audio playback on Timesys Linux is tested to work on Tower while running a program on the second core. If so, I will be seeking for the right configuration then, but honestly I wouldn't be surprised if noone tested it yet. I already spent 4 days with this and do not want to spend more before I know the problem is just in my configuration.

You seem to have an overview of the mainline Linux - don't you know how much it is ready for use on Vybrid, let's say on Tower?

0 Kudos

990 Views
billpringlemeir
Contributor V

The mainline Linux can work on a Tower board with the mainline u-boot.  Vicent posted a HOWTO, here on the Vybrid forum.  The general procedure for the main line Linux kernel build is,

  • select imx defconfig file.
  • make ARCH=arm
  • move vf610-twr.dtb and zImage to a tftp directory.

On u-boot,

  tftp 0x81000000 vf610-twr.dtb; fdt addr 0x81000000; tftp 0x82000000 zImage; bootz 0x82000000 - 0x81000000

The u-boot in the HOWTO above gives these variable names like fdtaddr, fdtimage.  Where 'fdt' means flattened device tree.  I just was pointing out that the Tower board has no SGTL5000 codec on board by default.  TimeSys, etc need the extra daughter board to test this.  It may have been tested at some point, but a change/regression to something could easily slip in as it is not a default configuration.  Sorry, if my information was not helpful, I have been working on NAND flash issues for over a month.  So four days seems small. :smileylaugh:

NOTE: I am not sure if the mainline Linux supports the MMC.  I am using NAND flash and an initramfs for my file system.

Update: The latest ~3.15 Linux supports Vybrid MMC on the Tower boards.