Hi Jarkko,
On Wed, 27 May 2009 08:59 Jarkko Nikula wrote:
> On Tue, 26 May 2009 15:17:23 +0200
> Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
