[alsa-devel] Please help in adding ams-delta support to ASoC

[Janusz Krzysztofik]

Hi Jarkko,

On Wed, 27 May 2009 08:59 Jarkko Nikula wrote:
> On Tue, 26 May 2009 15:17:23 +0200
> Janusz Krzysztofik <jkrzyszt at tis.icnet.pl> wrote:
>> -	.xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
>> -	    XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG,
>> +	.xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0),
>>
> XFIG is only difference (OMAP_MCBSP_WORD_8 = 0) -> transfer is aborted
> in case of unexpected frame sync.

I tried commenting out RFIG and XFIG bits settings in 
sound/soc/omap/omap-mcbsp.c - did not help.

>> -	.srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1),
>> +	.srgr1 = CLKGDV(0),
>>
> Width of frame sync signal set to 1 here -> DSP_B format because no
> data delay set.

That's what I have tried mostly.

>> -	.srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE *
>> 2 - 1),
>> +       .srgr2 = GSYNC,
>>
>> -	.pcr0 = CLKXP | CLKRP,  /* mcbsp: slave */
>>
> No CLKXM, CLKRM and FSGM set -> codec is providing the frame sync and
> bit-clock signals -> SND_SOC_DAIFMT_CBM_CFM.

This is my primary choice as well.

> CLKXP and CLKRP not set -> rising edge of bit clock drives the
> transitions. This with DSP_B indicates inverted bit clock so
> SND_SOC_DAIFMT_IB_NF.

I have given it a try this morning - no go.

> I wonder why the frame sync period (FWID) wasn't set in that original
> patch but probably McBSP is able to work without :-)

from linux-2.6.29/sound/soc/omap/omap-mcbsp.c:
         switch (mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
         case SND_SOC_DAIFMT_I2S:
                 regs->srgr2     |= FPER(wlen * 2 - 1);
                 regs->srgr1     |= FWID(wlen - 1);
                 break;
         case SND_SOC_DAIFMT_DSP_B:
                 regs->srgr2     |= FPER(wlen * channels - 1);
                 regs->srgr1     |= FWID(0);
                 break;
         }

So it looks like in case of SND_SOC_DAIFMT_DSP_B, FWID is not set, only 
FPER. However, in the original patch, FPER was not set either.

>> ... aplay 
>> and arecord wait forever, cat to/from /dev/dsp breaks with hardware 
>> error messgae. DMA interrput counters stay at 0. However, codec 
> 
> Looks like McBSP is not getting bit-clock and frame-sync signals from
> the codec. Do you have any way to measure is the codec sending those?

Well, I am not sure, but I'll try if nothing helps.

> Another possibility are the OMAP pins muxed for McBSP? I assume they
> are if the bootloader is still the same

I boot both kernels, working 2.6.16 and not working 2.6.30-rc5, with the 
same u-boot.bin.

 > but worth to find check was
> previous kernel doing any runtime remuxing for those pins with
> omap_cfg_reg calls.

I was not able to find anything relevant.

> ... OMAP1510 doesn't support DMA chaining so there are few
> cpu_is_omap1510() code snippets in sound/soc/omap/omap-pcm.c which I
> think I have only simulated using OMAP2420.

I hope DMA chaining is not an issue here. If I remove the DMA chaining 
workaround from the original patch, I get signle DMA interrupts, so that 
is better than none that I get with my patch.

Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html