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 linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
