AnsweredAssumed Answered

Vybrid audio (sgtl5000)

Question asked by Petr Kubiznak on Jan 14, 2014
Latest reply on Jan 14, 2014 by Bill Pringlemeir

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?

Outcomes