TWL4030 using McBSP5 and not McBSP2?

GoogleGroups
1

Hi, I have been doing some research in DMA using the McBSP, Just to
validate this info:
Kernel used: Linux-2.6.29-rc5-omap1

sound/soc/omap/omap-mcbsp.c:

in: static int omap_mcbsp_dai_hw_params
The array omap24xx_dma_reqs fills with

#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
static const int omap24xx_dma_reqs[][2] = {
  { OMAP24XX_DMA_MCBSP1_TX, OMAP24XX_DMA_MCBSP1_RX },
  { OMAP24XX_DMA_MCBSP2_TX, OMAP24XX_DMA_MCBSP2_RX },
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
  { OMAP24XX_DMA_MCBSP3_TX, OMAP24XX_DMA_MCBSP3_RX },
  { OMAP24XX_DMA_MCBSP4_TX, OMAP24XX_DMA_MCBSP4_RX },
  { OMAP24XX_DMA_MCBSP5_TX, OMAP24XX_DMA_MCBSP5_RX },
#endif
};

which translates from arch/arm/plat-omap/include/dma.h to:

static const int omap24xx_dma_reqs[][2] = {
  { 31,32},
  { 33,34},
  { 17,18 },
  { 19,20 },
  { 21,22},
};

When debugging twl4030, the trigger used is 21(McBSP5) instead of the
value I expected, 33, from McBSP2. Is this suppose to be like this?

2

Ernesto Torres wrote:

static const int omap24xx_dma_reqs[2] = {
  { 31,32},
  { 33,34},
  { 17,18 },
  { 19,20 },
  { 21,22},
};

When debugging twl4030, the trigger used is 21(McBSP5) instead of the
value I expected, 33, from McBSP2. Is this suppose to be like this?

Agree - You are supposed to get 33d.
And you are sure you don't mix up decimal and hex? 0x21 = 33d :slight_smile:

Best regards
  Søren

3

This is from a linux-2.6.28-r26 tree
$ find . -name '*.h' -print | xargs grep -A 2 -B 2
OMAP24XX_DMA_MCBSP5_TX
./arch/arm/plat-omap/include/mach/dma.h-#define
OMAP24XX_DMA_MCBSP4_TX 19 /* S_DMA_18 */
./arch/arm/plat-omap/include/mach/dma.h-#define
OMAP24XX_DMA_MCBSP4_RX 20 /* S_DMA_19 */
./arch/arm/plat-omap/include/mach/dma.h:#define
OMAP24XX_DMA_MCBSP5_TX 21 /* S_DMA_20 */
./arch/arm/plat-omap/include/mach/dma.h-#define
OMAP24XX_DMA_MCBSP5_RX 22 /* S_DMA_21 */
./arch/arm/plat-omap/include/mach/dma.h-#define
OMAP24XX_DMA_SPI3_TX1 23 /* S_DMA_22 */
$

-Preston

4

Thanks, my mistake.
The problem was we had two sets of debugs, one hex and one dec.
We are having trouble using the dma and we are validating all the dma transfer path in search for a posible misplaced value that may be causing the problem.

Anyone has succeded in dma transfer? We are focusing on audio dma transfer via I2S