| Message ID | 1305122135-27938-1-git-send-email-premi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, May 11, 2011 at 07:25:35PM +0530, Sanjeev Premi wrote: > Current checks for cpu type were too restrictive leading > to failures for other silicons in same family. > > The problem was found while testing audio playback on > AM37x and AM35x processors. But should exist on OMAP36xx > as well. Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 11 May 2011 16:55:35 Premi, Sanjeev wrote: > Current checks for cpu type were too restrictive leading > to failures for other silicons in same family. > > The problem was found while testing audio playback on > AM37x and AM35x processors. But should exist on OMAP36xx > as well. > > Signed-off-by: Sanjeev Premi <premi@ti.com> > cc: Mark Brown <broonie@opensource.wolfsonmicro.com> > cc: Liam Girdwood <lrg@ti.com> > cc: Jarkko Nikula <jhnikula@gmail.com> > --- Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 11 May 2011 19:25:35 +0530 Sanjeev Premi <premi@ti.com> wrote: > Current checks for cpu type were too restrictive leading > to failures for other silicons in same family. > > The problem was found while testing audio playback on > AM37x and AM35x processors. But should exist on OMAP36xx > as well. > > Signed-off-by: Sanjeev Premi <premi@ti.com> > cc: Mark Brown <broonie@opensource.wolfsonmicro.com> > cc: Liam Girdwood <lrg@ti.com> > cc: Jarkko Nikula <jhnikula@gmail.com> > --- Acked-by: Jarkko Nikula <jhnikula@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/11/11 06:55, Sanjeev Premi wrote: > Current checks for cpu type were too restrictive leading > to failures for other silicons in same family. > > The problem was found while testing audio playback on > AM37x and AM35x processors. But should exist on OMAP36xx > as well. > > Signed-off-by: Sanjeev Premi <premi@ti.com> > cc: Mark Brown <broonie@opensource.wolfsonmicro.com> > cc: Liam Girdwood <lrg@ti.com> > cc: Jarkko Nikula <jhnikula@gmail.com> > --- > > Changes in v4: > Reposting after validating that patch still applies cleanly on > linux-omap master [46966f1] > > Changed the subject as suggested by Jarkko. Since the subject > has changed, i have omitted v4. > > Changes in v3:: > None. Reposting[1] after subscribing to alsa-devel list > > Changes in v2: > 1) Added one more check to the changes. > 2) Updated commit message to use plurals. > > Hi, I removed all but the linux-omap list for my question. I am trying to get the beagleboardxm to work with an external codec. I am trying to use a mcbsp1 via the trainer board where it level shifts to 5 volts. I have applied this patch (I am on 2.6.39rc4), but still no joy. I have a small analyzer attached to the I/O pins and important things like the bit clock does not wiggle. First a side question. In the arch/arm/mach-omap2/Kconfig when I select BEAGLE, it selects OMAP_PACKAGE_CBB - but my bbxm system reference manual says "The BeagleBoard-xM processor is the DM3730CBP 1GHz version" which to me implies the proper package selection should be OMAP_PACKAGE_CBP. The platform file mux34xx.c has different tables for them, but I cant quickly tell the difference. Does this matter for mcbspx? Here is a console dump where I try to aplay a file: [ 1565.773712] omap_mcbsp_dai_startup: omap-mcbsp-dai.0 bus_id=0 active 0 [ 1565.781829] omap_pcm_open: ret 1 [ 1565.785491] asoc: HiFi <-> omap-mcbsp-dai.0 info: [ 1565.790527] asoc: rate mask 0x7fe [ 1565.794006] asoc: min ch 1 max ch 2 [ 1565.797760] asoc: min rate 8000 max rate 96000 [ 1565.826721] bbxm_hw_params: codec_dai=dfbbb9c0 clk 12288000 [ 1565.832702] bbxm_hw_params 2: codec_dai=dfbbb9c0 clk 12288000 [ 1565.838867] omap_mcbsp_dai_set_dai_fmt: configured 0 [ 1565.844146] bbxm_hw_params 3: codec_dai=dfbbb9c0 clk 12288000 [ 1565.850219] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0 [ 1565.857299] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0 [ 1565.864379] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 2048000 [ 1565.877319] max98095 4-0010: read 2a => 10 [ 1565.884277] max98095 4-0010: read 27 => 1 [ 1565.891143] max98095 4-0010: read 2a => 10 [ 1565.898956] max98095 4-0010: read 2e => 0 [ 1565.903198] omap_mcbsp_dai_hw_params: format 1 [ 1565.907958] omap_mcbsp_dai_hw_params: stream Audio Playback [ 1565.913909] omap_mcbsp_dai_hw_params: framesize 32 in_freq=2048000 div=8 rate=8000 [ 1565.921936] omap-mcbsp omap-mcbsp.1: Configuring McBSP1 phys_base: 0x48074000 [ 1565.929565] omap_pcm_hw_params: ret 0 [ 1565.934722] omap_pcm_prepare: dma_data bf00d4a0 [ 1565.945831] max98095 4-0010: read 91 => 0 [ 1565.950347] max98095 4-0010: write 91 = 3 [ 1565.958618] max98095 4-0010: read 91 => 3 [ 1565.963195] max98095 4-0010: write 91 = c3 [ 1565.972351] snd_pcm_lib_write1: state 2 size 1000 [ 1565.977691] snd_pcm_lib_write1: offset 0 [ 1565.981842] snd_pcm_update_state: stream=0 avail=3000 buffer_size=4000 twake=0 tsleep=1 [ 1565.992706] snd_pcm_lib_write1: state 2 size 1000 [ 1565.997985] snd_pcm_lib_write1: offset 0 [ 1566.002227] snd_pcm_update_state: stream=0 avail=2000 buffer_size=4000 twake=0 tsleep=1 [ 1566.011810] snd_pcm_lib_write1: state 2 size 1000 [ 1566.017120] snd_pcm_lib_write1: offset 0 [ 1566.021270] snd_pcm_update_state: stream=0 avail=1000 buffer_size=4000 twake=0 tsleep=1 [ 1566.033050] snd_pcm_lib_write1: state 2 size 1000 [ 1566.038360] snd_pcm_lib_write1: offset 0 [ 1566.042510] snd_pcm_pre_start: state 3 [ 1566.046447] snd_pcm_do_start: state 3 [ 1566.050292] omap_pcm_trigger: cmd 1 [ 1566.053955] omap_start_dma: lch 0 [ 1566.057891] omap-mcbsp omap-mcbsp.1: **** McBSP1 regs **** [ 1566.063629] omap-mcbsp omap-mcbsp.1: DRR2: 0x0000 [ 1566.068664] omap-mcbsp omap-mcbsp.1: DRR1: 0x0000 [ 1566.073699] omap-mcbsp omap-mcbsp.1: DXR2: 0x0000 [ 1566.078735] omap-mcbsp omap-mcbsp.1: DXR1: 0x0000 [ 1566.083740] omap-mcbsp omap-mcbsp.1: SPCR2: 0x02f5 [ 1566.088775] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030 [ 1566.093811] omap-mcbsp omap-mcbsp.1: RCR2: 0x8041 [ 1566.098846] omap-mcbsp omap-mcbsp.1: RCR1: 0x0040 [ 1566.103851] omap-mcbsp omap-mcbsp.1: XCR2: 0x8041 [ 1566.108886] omap-mcbsp omap-mcbsp.1: XCR1: 0x0040 [ 1566.113922] omap-mcbsp omap-mcbsp.1: SRGR2: 0x101f [ 1566.118927] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f07 [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0: 0x0f0f [ 1566.128997] omap-mcbsp omap-mcbsp.1: *********************** [ 1566.134918] snd_pcm_post_start: state 3 [ 1566.138977] snd_pcm_update_state: stream=0 avail=0 buffer_size=4000 twake=0 tsleep=1 [ 1566.148681] snd_pcm_lib_write1: state 3 size 1000 [ 1566.153625] omap_pcm_pointer: offset 64 [ 1566.157653] snd_pcm_update_hw_ptr0: old_hw_ptr=0 pos=64 in_int=0 [ 1566.163970] snd_pcm_update_hw_ptr0: stream=0 new_hw_ptr=64 silence_size=0 [ 1566.171081] snd_pcm_update_state: stream=0 avail=64 buffer_size=4000 twake=1000 tsleep=1 [ 1566.180145] snd_pcm_lib_write1: offset 0 [ 1566.184295] snd_pcm_lib_write1: state 3 size 936 [ 1566.189147] omap_pcm_pointer: offset 64 [ 1566.193176] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0 [ 1576.194274] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA or IRQ trouble?) [ 1576.304199] snd_pcm_lib_write1: state 3 size 936 [ 1576.309051] omap_pcm_pointer: offset 64 [ 1576.313079] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0 [ 1586.319274] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA or IRQ trouble?) [ 1586.337554] omap_pcm_trigger: cmd 0 [ 1591.342651] pop wq checking: HiFi Playback status: inactive waiting: yes [ 1591.351898] max98095 4-0010: read 91 => c3 [ 1591.356231] max98095 4-0010: write 91 = 3 [ 1591.362030] max98095 4-0010: read 91 => 3 [ 1591.366424] max98095 4-0010: write 91 = 0 [ 1591.373229] max98095 4-0010: read 90 => c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Steve Calfee [stevecalfee@gmail.com] > Sent: Wednesday, May 11, 2011 11:46 PM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org; Girdwood, Liam > Subject: Re: [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type > [snip]...[snip] > > Hi, > > I removed all but the linux-omap list for my question. [sp] Using a separate thread for this issues would have gotten more eyes! > > I am trying to get the beagleboardxm to work with an external codec. I > am trying to use a mcbsp1 via the trainer board where it level shifts to > 5 volts. I have applied this patch (I am on 2.6.39rc4), but still no > joy. I have a small analyzer attached to the I/O pins and important > things like the bit clock does not wiggle. > > First a side question. In the arch/arm/mach-omap2/Kconfig when I select > BEAGLE, it selects OMAP_PACKAGE_CBB - but my bbxm system reference > manual says "The BeagleBoard-xM processor is the DM3730CBP 1GHz version" > which to me implies the proper package selection should be > OMAP_PACKAGE_CBP. The platform file mux34xx.c has different tables for > them, but I cant quickly tell the difference. Does this matter for mcbspx? [sp] Check this page to find the differences: http://processors.wiki.ti.com/index.php/OMAP35x_To_AM37x_Hardware_Migration_Guide ~sanjeev [snip]...[snip] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/11/11 11:16, Steve Calfee wrote: New title, more appropriate to the topic. I was replying to the fix posted by Sanjeev fixing a/sound/soc/omap/omap-mcbsp.c I am pretty near the cutting edge kernel, trying to use the latest alsa changes. I cannot get bbxm to talk to an external codec via mcbsp1. Has anyone been able to use mcbsp1 on a recent linux-next. More below. > Hi, > > I removed all but the linux-omap list for my question. > > I am trying to get the beagleboardxm to work with an external codec. I > am trying to use a mcbsp1 via the trainer board where it level shifts to > 5 volts. I have applied this patch (I am on 2.6.39rc4), but still no > joy. I have a small analyzer attached to the I/O pins and important > things like the bit clock does not wiggle. > > First a side question. In the arch/arm/mach-omap2/Kconfig when I select > BEAGLE, it selects OMAP_PACKAGE_CBB - but my bbxm system reference > manual says "The BeagleBoard-xM processor is the DM3730CBP 1GHz version" > which to me implies the proper package selection should be > OMAP_PACKAGE_CBP. The platform file mux34xx.c has different tables for > them, but I cant quickly tell the difference. Does this matter for mcbspx? > Sanjeev pointed me to: Check this page to find the differences: http://processors.wiki.ti.com/index.php/OMAP35x_To_AM37x_Hardware_Migration_Guide Where it appears TI has some new chip naming scheme and maybe the bbxm is a am3730? In any case it doesn't seem that mcbsp is affected by the package change. > Here is a console dump where I try to aplay a file: > [ 1565.773712] omap_mcbsp_dai_startup: omap-mcbsp-dai.0 bus_id=0 active 0 > [ 1565.781829] omap_pcm_open: ret 1 > [ 1565.785491] asoc: HiFi <-> omap-mcbsp-dai.0 info: > [ 1565.790527] asoc: rate mask 0x7fe > [ 1565.794006] asoc: min ch 1 max ch 2 > [ 1565.797760] asoc: min rate 8000 max rate 96000 > [ 1565.826721] bbxm_hw_params: codec_dai=dfbbb9c0 clk 12288000 > [ 1565.832702] bbxm_hw_params 2: codec_dai=dfbbb9c0 clk 12288000 > [ 1565.838867] omap_mcbsp_dai_set_dai_fmt: configured 0 > [ 1565.844146] bbxm_hw_params 3: codec_dai=dfbbb9c0 clk 12288000 > [ 1565.850219] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0 > [ 1565.857299] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0 > [ 1565.864379] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 > in_freq 2048000 > [ 1565.877319] max98095 4-0010: read 2a => 10 > [ 1565.884277] max98095 4-0010: read 27 => 1 > [ 1565.891143] max98095 4-0010: read 2a => 10 > [ 1565.898956] max98095 4-0010: read 2e => 0 > [ 1565.903198] omap_mcbsp_dai_hw_params: format 1 > [ 1565.907958] omap_mcbsp_dai_hw_params: stream Audio Playback > [ 1565.913909] omap_mcbsp_dai_hw_params: framesize 32 in_freq=2048000 > div=8 rate=8000 > [ 1565.921936] omap-mcbsp omap-mcbsp.1: Configuring McBSP1 phys_base: > 0x48074000 > [ 1565.929565] omap_pcm_hw_params: ret 0 > [ 1565.934722] omap_pcm_prepare: dma_data bf00d4a0 > [ 1565.945831] max98095 4-0010: read 91 => 0 > [ 1565.950347] max98095 4-0010: write 91 = 3 > [ 1565.958618] max98095 4-0010: read 91 => 3 > [ 1565.963195] max98095 4-0010: write 91 = c3 > [ 1565.972351] snd_pcm_lib_write1: state 2 size 1000 > [ 1565.977691] snd_pcm_lib_write1: offset 0 > [ 1565.981842] snd_pcm_update_state: stream=0 avail=3000 > buffer_size=4000 twake=0 tsleep=1 > [ 1565.992706] snd_pcm_lib_write1: state 2 size 1000 > [ 1565.997985] snd_pcm_lib_write1: offset 0 > [ 1566.002227] snd_pcm_update_state: stream=0 avail=2000 > buffer_size=4000 twake=0 tsleep=1 > [ 1566.011810] snd_pcm_lib_write1: state 2 size 1000 > [ 1566.017120] snd_pcm_lib_write1: offset 0 > [ 1566.021270] snd_pcm_update_state: stream=0 avail=1000 > buffer_size=4000 twake=0 tsleep=1 > [ 1566.033050] snd_pcm_lib_write1: state 2 size 1000 > [ 1566.038360] snd_pcm_lib_write1: offset 0 > [ 1566.042510] snd_pcm_pre_start: state 3 > [ 1566.046447] snd_pcm_do_start: state 3 > [ 1566.050292] omap_pcm_trigger: cmd 1 > [ 1566.053955] omap_start_dma: lch 0 > [ 1566.057891] omap-mcbsp omap-mcbsp.1: **** McBSP1 regs **** > [ 1566.063629] omap-mcbsp omap-mcbsp.1: DRR2: 0x0000 > [ 1566.068664] omap-mcbsp omap-mcbsp.1: DRR1: 0x0000 > [ 1566.073699] omap-mcbsp omap-mcbsp.1: DXR2: 0x0000 > [ 1566.078735] omap-mcbsp omap-mcbsp.1: DXR1: 0x0000 > [ 1566.083740] omap-mcbsp omap-mcbsp.1: SPCR2: 0x02f5 > [ 1566.088775] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030 > [ 1566.093811] omap-mcbsp omap-mcbsp.1: RCR2: 0x8041 > [ 1566.098846] omap-mcbsp omap-mcbsp.1: RCR1: 0x0040 > [ 1566.103851] omap-mcbsp omap-mcbsp.1: XCR2: 0x8041 > [ 1566.108886] omap-mcbsp omap-mcbsp.1: XCR1: 0x0040 > [ 1566.113922] omap-mcbsp omap-mcbsp.1: SRGR2: 0x101f > [ 1566.118927] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f07 > [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0: 0x0f0f > [ 1566.128997] omap-mcbsp omap-mcbsp.1: *********************** > [ 1566.134918] snd_pcm_post_start: state 3 > [ 1566.138977] snd_pcm_update_state: stream=0 avail=0 buffer_size=4000 > twake=0 tsleep=1 > [ 1566.148681] snd_pcm_lib_write1: state 3 size 1000 > [ 1566.153625] omap_pcm_pointer: offset 64 > [ 1566.157653] snd_pcm_update_hw_ptr0: old_hw_ptr=0 pos=64 in_int=0 > [ 1566.163970] snd_pcm_update_hw_ptr0: stream=0 new_hw_ptr=64 silence_size=0 > [ 1566.171081] snd_pcm_update_state: stream=0 avail=64 buffer_size=4000 > twake=1000 tsleep=1 > [ 1566.180145] snd_pcm_lib_write1: offset 0 > [ 1566.184295] snd_pcm_lib_write1: state 3 size 936 > [ 1566.189147] omap_pcm_pointer: offset 64 > [ 1566.193176] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0 > [ 1576.194274] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA > or IRQ trouble?) > [ 1576.304199] snd_pcm_lib_write1: state 3 size 936 > [ 1576.309051] omap_pcm_pointer: offset 64 > [ 1576.313079] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0 > [ 1586.319274] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA > or IRQ trouble?) > [ 1586.337554] omap_pcm_trigger: cmd 0 > [ 1591.342651] pop wq checking: HiFi Playback status: inactive waiting: yes > [ 1591.351898] max98095 4-0010: read 91 => c3 > [ 1591.356231] max98095 4-0010: write 91 = 3 > [ 1591.362030] max98095 4-0010: read 91 => 3 > [ 1591.366424] max98095 4-0010: write 91 = 0 > [ 1591.373229] max98095 4-0010: read 90 => c Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 11 May 2011 14:31:46 -0700 Steve Calfee <stevecalfee@gmail.com> wrote: > On 05/11/11 11:16, Steve Calfee wrote: > New title, more appropriate to the topic. > > I was replying to the fix posted by Sanjeev fixing > a/sound/soc/omap/omap-mcbsp.c > > I am pretty near the cutting edge kernel, trying to use the latest alsa > changes. I cannot get bbxm to talk to an external codec via mcbsp1. > > Has anyone been able to use mcbsp1 on a recent linux-next. > This sounds like that those expansion connector pins are not muxed to mcbsp1 but e.g. to gpio by the bootloader. Are you able to see clock activity on CLKX if you enable CONFIG_OMAP_MUX=y and add following lines to board_mux table in arch/arm/mach-omap2/board-omap3beagle.c? Of course for this you need to use omap as a master and codec as a slave. One example for this is sound/soc/omap/omap3pandora.c. static struct omap_board_mux board_mux[] __initdata = { + OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), + OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), + OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), + OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), + { .reg_offset = OMAP_MUX_TERMINATOR },
On Thursday 12 May 2011 09:25:55 Jarkko Nikula wrote: > Of course for this you need to use omap as a master and codec as a > slave. One example for this is sound/soc/omap/omap3pandora.c. > > static struct omap_board_mux board_mux[] __initdata = { > + OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), > + OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), > + OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), > + OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), > + I think the CLKX, FSX need to be input, since the config suggests,t that McBSP1 is the slave port: > [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0: 0x0f0f
On 05/12/11 04:01, Peter Ujfalusi wrote: > On Thursday 12 May 2011 09:25:55 Jarkko Nikula wrote: >> Of course for this you need to use omap as a master and codec as a >> slave. One example for this is sound/soc/omap/omap3pandora.c. >> >> static struct omap_board_mux board_mux[] __initdata = { >> + OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), >> + OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), >> + OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), >> + OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), >> + > > I think the CLKX, FSX need to be input, since the config suggests,t that > McBSP1 is the slave port: > >> [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0: 0x0f0f > Hi, thanks for trying to help. I already tried that, but it still did not xmit. Now I wonder about master/slave. I thought that the omap is set up as a master. I looked at PCR0 docs in the tech ref manual and I get: 11 FSXM Transmit Frame-Synchronization Mode RW 0x0 0x0: Frame-synchronization signal derived from an external source 0x1: Frame synchronization is determined by the SRG frame-synchronization mode bit FSGM in SRGR2. 10 FSRM Receive Frame-Synchronization Mode RW 0x0 0x0: Frame-Synchronization pulses generated by an external device. FSR is an input pin. 0x1: Frame synchronization generated internally by SRG. FSR is an output pin except when GSYNC=1 in SRGR. Etc. Since it is set to 0xF0F, doesn't this set it as master? Also, spelunking the kernel sources, I cannot seem to find the source for mcbsp_data->regs -- do you know where it gets set initially? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 12 May 2011 21:43:20 Steve Calfee wrote: > Since it is set to 0xF0F, doesn't this set it as master? Sorry, that is correct, McBSP is configured as msater. > Also, spelunking the kernel sources, I cannot seem to find the source > for mcbsp_data->regs -- do you know where it gets set initially? They configured within sound/soc/omap/omap-pcm.c Have you configured the clk source, and divider correctly for McBSP port from the machine driver (with snd_soc_dai_set_sysclk)?
On 11/05/11 14:55, Premi, Sanjeev wrote: > Current checks for cpu type were too restrictive leading > to failures for other silicons in same family. > > The problem was found while testing audio playback on > AM37x and AM35x processors. But should exist on OMAP36xx > as well. > > Signed-off-by: Sanjeev Premi <premi@ti.com> > cc: Mark Brown <broonie@opensource.wolfsonmicro.com> > cc: Liam Girdwood <lrg@ti.com> > cc: Jarkko Nikula <jhnikula@gmail.com> > --- > > Changes in v4: > Reposting after validating that patch still applies cleanly on > linux-omap master [46966f1] > > Changed the subject as suggested by Jarkko. Since the subject > has changed, i have omitted v4. > > Changes in v3:: > None. Reposting[1] after subscribing to alsa-devel list > > Changes in v2: > 1) Added one more check to the changes. > 2) Updated commit message to use plurals. > > > Applied. Thanks Liam -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 12, 2011 at 10:59 PM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote: > On Thursday 12 May 2011 21:43:20 Steve Calfee wrote: >> Since it is set to 0xF0F, doesn't this set it as master? > > Sorry, that is correct, McBSP is configured as msater. > >> Also, spelunking the kernel sources, I cannot seem to find the source >> for mcbsp_data->regs -- do you know where it gets set initially? > > They configured within sound/soc/omap/omap-pcm.c > > Have you configured the clk source, and divider correctly for McBSP port from > the machine driver (with snd_soc_dai_set_sysclk)? > Hi, Thanks for the suggestions. I think I have it correct. I was able to load the original sound/soc/beagleboard.c and the codec/twl4030 and play a wav file. I have been copying that to try and get my new codec driver to work. One immediate difference is that the system sets up the twl4030 as the master i2s device on the bus. So I changed my codec over to do that too. Now the mcbsp register dump matches the working setup. I put in a few debug statements. It appears that my DMA never gets started. I know it can work with a different machine and codec driver, but not mine. I don't see any explicit DMA init, but that must be the problem. Any more ideas? Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 14 May 2011 05:47:33 Steve Calfee wrote: > I put in a few debug statements. It appears that my DMA never gets > started. I know it can work with a different machine and codec driver, > but not mine. I don't see any explicit DMA init, but that must be the > problem. Any more ideas? You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called? Could you post the output of dmesg related to ASoC? Does the connection between the CPU and codec DAI correct? Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, omap_mcbsp_dai_trigger got called)?
On 05/16/11 01:54, Peter Ujfalusi wrote: > On Saturday 14 May 2011 05:47:33 Steve Calfee wrote: >> I put in a few debug statements. It appears that my DMA never gets >> started. I know it can work with a different machine and codec driver, >> but not mine. I don't see any explicit DMA init, but that must be the >> problem. Any more ideas? > > You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called? > Could you post the output of dmesg related to ASoC? Does the connection > between the CPU and codec DAI correct? > Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, > omap_mcbsp_dai_trigger got called)? > No, they get called. I just don't get the clock on the bclk pin. I think I have the mcbsp1 set up correctly - I explictly set the MUX: static struct omap_board_mux board_mux[] __initdata = { #if 1 /* McBSP 1 */ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), #endif { .reg_offset = OMAP_MUX_TERMINATOR }, }; And elsewhere I set the mcbsp to use a 4 pin interface: /* configure mcbsp1 to just use 4 pins */ ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0, SND_SOC_CLOCK_IN); if (ret < 0) { printk(KERN_ERR "can't set CPU system clock OMAP_MCBSP_CLKR_SRC_CLKX\n"); //return ret; } ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0, SND_SOC_CLOCK_IN); if (ret < 0) { printk(KERN_ERR "can't set CPU system clock OMAP_MCBSP_FSR_SRC_FSX\n"); //return ret; } Here is some hopefully relevant console output. Note that where I added debug printk's I also printed the __func__. # cat /proc/asound/cards 0 [bbxm ]: - bbxm bbxm # lsmod Module Size Used by Not tainted snd_soc_max98095 26314 1 snd_soc_omap3beaglexm 4818 0 snd_soc_omap_mcbsp 7148 1 gpio_i2cmux 1699 0 i2c_mux 1408 1 gpio_i2cmux # aplay /newmail2.wav [ 262.129882] omap_mcbsp_dai_startup: omap-mcbsp-dai.0 bus_id=0 active 0 [ 262.137847] omap-mcbsp omap-mcbsp.1: omap_mcbsp_request: tx_irq_completion t=59 r=60 [ 262.146972] omap_mcbsp_dai_startup: rules omap-mcbsp-dai.0 bus_id=0 active 0 [ 262.155090] omap_pcm_open: ret 1 [ 262.158752] asoc: HiFi <-> omap-mcbsp-dai.0 info: [ 262.163757] asoc: rate mask 0x7fe [ 262.167327] asoc: min ch 1 max ch 2 [ 262.170989] asoc: min rate 8000 max rate 96000 Playing WAVE '/newmail2.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo [ 262.188537] bbxm_hw_params: codec_dai=dfbb9ac0 clk 12288000 [ 262.194519] bbxm_hw_params 2: codec_dai=dfbb9ac0 clk 12288000 [ 262.200683] omap_mcbsp_dai_set_dai_fmt: configured 0 [ 262.205932] bbxm_hw_params 3: codec_dai=dfbb9ac0 clk 12288000 [ 262.212036] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5f8 in_freq 0 [ 262.219116] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5f8 in_freq 0 [ 262.227752] max98095 4-0010: read 2a => 90 [ 262.234832] max98095 4-0010: read 27 => 1 [ 262.240875] max98095 4-0010: read 2a => 90 [ 262.245300] max98095 4-0010: write 28 = 7 [ 262.252044] max98095 4-0010: write 29 = 8f [ 262.261779] max98095 4-0010: read 2e => 0 [ 262.266265] omap_mcbsp_dai_hw_params: format 1 [ 262.270996] omap_mcbsp_dai_hw_params: stream Audio Playback [ 262.276977] omap-mcbsp omap-mcbsp.1: Configuring McBSP1 phys_base: 0x48074000 [ 262.284606] omap_pcm_hw_params: ret 0 [ 262.290008] omap_pcm_prepare: dma_data bf00d4e0 [ 262.298980] max98095 4-0010: read 91 => 0 [ 262.303558] max98095 4-0010: write 91 = 3 [ 262.311798] max98095 4-0010: read 91 => 3 [ 262.316345] max98095 4-0010: write 91 = c3 [ 262.326690] snd_pcm_lib_write1: state 2 size 1000 [ 262.332031] snd_pcm_lib_write1: offset 0 [ 262.336181] snd_pcm_update_state: stream=0 avail=3000 buffer_size=4000 twake=0 tsleep=1 [ 262.345825] snd_pcm_lib_write1: state 2 size 1000 [ 262.351165] snd_pcm_lib_write1: offset 0 [ 262.355346] snd_pcm_update_state: stream=0 avail=2000 buffer_size=4000 twake=0 tsleep=1 [ 262.364929] snd_pcm_lib_write1: state 2 size 1000 [ 262.370269] snd_pcm_lib_write1: offset 0 [ 262.374420] snd_pcm_update_state: stream=0 avail=1000 buffer_size=4000 twake=0 tsleep=1 [ 262.383972] snd_pcm_lib_write1: state 2 size 1000 [ 262.389312] snd_pcm_lib_write1: offset 0 [ 262.393463] snd_pcm_pre_start: state 3 [ 262.397399] snd_pcm_do_start: state 3 [ 262.401245] omap_pcm_trigger: cmd 1 [ 262.404907] omap_start_dma: lch 0 [ 262.408843] omap-mcbsp omap-mcbsp.1: **** McBSP1 regs **** [ 262.414581] omap-mcbsp omap-mcbsp.1: DRR2: 0x0000 [ 262.419616] omap-mcbsp omap-mcbsp.1: DRR1: 0x0000 [ 262.424652] omap-mcbsp omap-mcbsp.1: DXR2: 0x0000 [ 262.429656] omap-mcbsp omap-mcbsp.1: DXR1: 0x0000 [ 262.434692] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0235 [ 262.439727] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030 [ 262.444763] omap-mcbsp omap-mcbsp.1: RCR2: 0x8041 [ 262.449768] omap-mcbsp omap-mcbsp.1: RCR1: 0x0040 [ 262.454803] omap-mcbsp omap-mcbsp.1: XCR2: 0x8041 [ 262.459838] omap-mcbsp omap-mcbsp.1: XCR1: 0x0040 [ 262.464843] omap-mcbsp omap-mcbsp.1: SRGR2: 0x001f [ 262.469879] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f00 [ 262.474914] omap-mcbsp omap-mcbsp.1: PCR0: 0x000f [ 262.479919] omap-mcbsp omap-mcbsp.1: *********************** [ 262.485870] snd_pcm_post_start: state 3 [ 262.489898] snd_pcm_update_state: stream=0 avail=0 buffer_size=4000 twake=0 tsleep=1 [ 262.500854] snd_pcm_lib_write1: state 3 size 1000 [ 262.505828] omap_pcm_pointer: offset 64 [ 262.509857] snd_pcm_update_hw_ptr0: old_hw_ptr=0 pos=64 in_int=0 [ 262.516143] snd_pcm_update_hw_ptr0: stream=0 new_hw_ptr=64 silence_size=0 [ 262.523284] snd_pcm_update_state: stream=0 avail=64 buffer_size=4000 twake=1000 tsleep=1 [ 262.532226] snd_pcm_lib_write1: offset 0 [ 262.536407] snd_pcm_lib_write1: state 3 size 936 [ 262.541259] omap_pcm_pointer: offset 64 [ 262.545288] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0 [ 272.549896] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA or IRQ trouble?) [ 272.659851] snd_pcm_lib_write1: state 3 size 936 [ 272.664703] omap_pcm_pointer: offset 64 [ 272.668731] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0 [ 282.674957] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA or IRQ trouble?) aplay: pcm_write[ 282.686767] omap_pcm_trigger: cmd 0 :1682: write error: Input/output error # [ 287.706268] pop wq checking: HiFi Playback status: inactive waiting: yes [ 287.715148] max98095 4-0010: read 91 => c3 [ 287.719726] max98095 4-0010: write 91 = 3 [ 287.725585] max98095 4-0010: read 91 => 3 [ 287.729980] max98095 4-0010: write 91 = 0 [ 287.736785] max98095 4-0010: read 90 => c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi On Mon, 16 May 2011 11:07:40 -0700 Steve Calfee <stevecalfee@gmail.com> wrote: > On 05/16/11 01:54, Peter Ujfalusi wrote: > > On Saturday 14 May 2011 05:47:33 Steve Calfee wrote: > >> I put in a few debug statements. It appears that my DMA never gets > >> started. I know it can work with a different machine and codec driver, > >> but not mine. I don't see any explicit DMA init, but that must be the > >> problem. Any more ideas? > > > > You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called? > > Could you post the output of dmesg related to ASoC? Does the connection > > between the CPU and codec DAI correct? > > Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, > > omap_mcbsp_dai_trigger got called)? > > > No, they get called. I just don't get the clock on the bclk pin. > > I think I have the mcbsp1 set up correctly - I explictly set the MUX: > > static struct omap_board_mux board_mux[] __initdata = { > #if 1 > /* McBSP 1 */ > OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), > OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), > OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), > OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), > #endif > { .reg_offset = OMAP_MUX_TERMINATOR }, > }; > Did you try to run OMAP as an I2S master like what omap3pandora.c is doing? Missing clock in codec master configuration suggests that reason is in codec side and reversed roles during development makes easier to hunt it further as then OMAP can play data out independently of is the codec correctly configured or not. You could run OMAP as a master by specifying SND_SOC_DAIFMT_CBS_CFS as a DAI format for both codec and OMAP and by setting McBSP to use internal 96 MHz clock as a master clock. Something like below might work for testing purposes: snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK, 96000000, SND_SOC_CLOCK_IN); snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, 62); /* 96M / 48k*32 */
Hi,
On Monday 16 May 2011 21:07:40 Steve Calfee wrote:
> No, they get called. I just don't get the clock on the bclk pin.
OK.
Could you try to disconnect the CLKX, and FSX lines from OMAP, and see that
you have the clocks on the codec side?
If in this way you still can not see the clocks, than your codec (max98095 ?)
is not generating the clocks.
Could you also post from your machine driver how you configure the formats for
cpu/codec DAI (snd_soc_dai_set_fmt call)?
While the clock lines are not physically connected, you can try to configure
either side to generate the correct clocks on the lines. When you see that,
you can connect them together, and see (hear) if it works.
On 05/17/11 03:42, Peter Ujfalusi wrote: > Hi, > > On Monday 16 May 2011 21:07:40 Steve Calfee wrote: >> No, they get called. I just don't get the clock on the bclk pin. > > OK. > Could you try to disconnect the CLKX, and FSX lines from OMAP, and see that > you have the clocks on the codec side? > If in this way you still can not see the clocks, than your codec (max98095 ?) > is not generating the clocks. > Could you also post from your machine driver how you configure the formats for > cpu/codec DAI (snd_soc_dai_set_fmt call)? > > While the clock lines are not physically connected, you can try to configure > either side to generate the correct clocks on the lines. When you see that, > you can connect them together, and see (hear) if it works. > Hi, Good suggestion. After switching to my codec as master, I could see the clocks. But one problem was the beagleboardxm trainer has level shifters, but they are one directional, and not correct for my use. So I reconnected to the expansion port pins (and re-did the voltage requirement of the codec to 1.8 volts). Now I get some sound. One problem remains and is a mystery to me. My omap setup with the max98095 codec is identical to the on board twl4030 device. The twl4030 works find, but my codec only plays one channel. I hooked up a logic analyzer and discovered that my codec sends 32 bit clocks per fsx or what we call lrclk. The twl4030 sends 16 bit clocks per lrclk. I think that more than 16 bits is supposed to be ok and someone here said some of the high end audio test equipment only sends 64 bitclock per lrclock and that seems to be within the standard. I think the I2S protocol says data bits are aligned with the lrclk, so what should be happening is the omap slave should send 16 bits of audio followed by 16 bits of null, then the lrclk switches and it should send the other channel of audio followed by null. The data being sent by the omap is actually 32 bits in the first lrclk phase, comprising the left 16 bits and the right 16 bits. The second lrclk phase gets null sent for all 32 bits. My 32 bits has the same data (from the same .wav file) that was sent to the twl4030 as two 16 bit channels. Here is the mcbsp register dump (the same from both twl4030 and max98095 runs). [ 54.391174] omap_pcm_trigger: cmd 1 [ 54.395111] omap_start_dma: lch 0 [ 54.399047] omap-mcbsp omap-mcbsp.1: **** McBSP1 regs **** [ 54.404815] omap-mcbsp omap-mcbsp.1: DRR2: 0x2000100 [ 54.410125] omap-mcbsp omap-mcbsp.1: DRR1: 0x0000 [ 54.415130] omap-mcbsp omap-mcbsp.1: DXR2: 0x0000 [ 54.420166] omap-mcbsp omap-mcbsp.1: DXR1: 0x0000 [ 54.425201] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0235 [ 54.430206] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030 [ 54.435241] omap-mcbsp omap-mcbsp.1: RCR2: 0x8041 [ 54.440277] omap-mcbsp omap-mcbsp.1: RCR1: 0x0040 [ 54.445281] omap-mcbsp omap-mcbsp.1: XCR2: 0x8041 [ 54.450317] omap-mcbsp omap-mcbsp.1: XCR1: 0x0040 [ 54.455352] omap-mcbsp omap-mcbsp.1: SRGR2: 0x001f [ 54.460388] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f00 [ 54.465393] omap-mcbsp omap-mcbsp.1: PCR0: 0x000f [ 54.470428] omap-mcbsp omap-mcbsp.1: *********************** [ 54.476379] snd_pcm_post_start: state 3 My codec cannot be set to use only 16 bits per phase. Is there a way to setup the omap so that data is sent to both channels? As you can see above the xphase bit is one saying dual channels. Is this a dma setup problem? Thanks for your help. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/16/11 23:37, Jarkko Nikula wrote: > Hi > > On Mon, 16 May 2011 11:07:40 -0700 > Steve Calfee <stevecalfee@gmail.com> wrote: > >> On 05/16/11 01:54, Peter Ujfalusi wrote: >>> On Saturday 14 May 2011 05:47:33 Steve Calfee wrote: >>>> I put in a few debug statements. It appears that my DMA never gets >>>> started. I know it can work with a different machine and codec driver, >>>> but not mine. I don't see any explicit DMA init, but that must be the >>>> problem. Any more ideas? >>> >>> You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called? >>> Could you post the output of dmesg related to ASoC? Does the connection >>> between the CPU and codec DAI correct? >>> Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, >>> omap_mcbsp_dai_trigger got called)? >>> >> No, they get called. I just don't get the clock on the bclk pin. >> >> I think I have the mcbsp1 set up correctly - I explictly set the MUX: >> >> static struct omap_board_mux board_mux[] __initdata = { >> #if 1 >> /* McBSP 1 */ >> OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), >> OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), >> OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), >> OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), >> #endif >> { .reg_offset = OMAP_MUX_TERMINATOR }, >> }; >> > Did you try to run OMAP as an I2S master like what omap3pandora.c is > doing? > > Missing clock in codec master configuration suggests that reason > is in codec side and reversed roles during development makes easier to > hunt it further as then OMAP can play data out independently of is the > codec correctly configured or not. > > You could run OMAP as a master by specifying SND_SOC_DAIFMT_CBS_CFS > as a DAI format for both codec and OMAP and by setting McBSP to use > internal 96 MHz clock as a master clock. Something like below might work > for testing purposes: > > snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK, > 96000000, SND_SOC_CLOCK_IN); > > snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, > 62); /* 96M / 48k*32 */ > Hi, The hunt for clock continues. I redid my board-omap3beaglexm.c to as closely match what board-omap3pandora.c is doing as I can. Like pandora, I don't explicitly set the mux pin directions, I guess mcbsp master is the default. I also tried to get as close as I could to the soc/omap/omap3pandora.c machine driver with my omap3beaglexm.c machine driver. Specifically in the *_hw_params init routines. But when I start things up (even with the codec disconnected from the bclk line), I don't get any movement on the CLK and fsx. And of course the dma doesn't send anything. Thanks for the suggestion. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thursday 19 May 2011 03:30:51 Steve Calfee wrote: > On 05/17/11 03:42, Peter Ujfalusi wrote: > Good suggestion. After switching to my codec as master, I could see the > clocks. But one problem was the beagleboardxm trainer has level > shifters, but they are one directional, and not correct for my use. So I > reconnected to the expansion port pins (and re-did the voltage > requirement of the codec to 1.8 volts). Now I get some sound. Great, we are getting closer. ... > My codec cannot be set to use only 16 bits per phase. Is there a way to > setup the omap so that data is sent to both channels? As you can see > above the xphase bit is one saying dual channels. Is this a dma setup > problem? I can not find datasheet for the max98095... So you can not configure the codec to use 2x16 number of bit clocks. when it is configured to receive/send 16bit stereo samples? Is this the case (that the codec all the time have 32 clock cycles per channel)? If this is the case, than it is kind of tricky to get around this, but you can try the following (warning: hack): In the codec driver: create/add a startup callback function for the dais (snd_soc_dai_ops): static int max98095_startup(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { snd_pcm_hw_constraint_msbits(substream->runtime, 0, 32, 16); return 0; } Modify the MAX98095_FORMATS to only support S32_LE (remove the other formats for now) In the hw_params calls handle the S32_LE in a same way as you handle the S16_LE. To explain what we are doing: Configure the codec to support only S32_LE format, but tell ALSA, that out of the 32 bit only the first 16bit is valid. So the driver will be opened with S32_LE mode, but only the first 16 bits will have audio data: 0-15: Left audio 16-31: zero (padding on left channel) 32-47: Right audio 48-63: zero (padding on right channel) Use aplay -Dplughw:0,0 -v <some sample> to play audio, and see, if the HW has been opened with S32_LE. You should have full stereo sound now. I have CC-d the author of the wm98095 codec driver, hi might be able to help you with the codec setup...
On 05/19/11 04:28, Peter Ujfalusi wrote: ... > >> My codec cannot be set to use only 16 bits per phase. Is there a way to >> setup the omap so that data is sent to both channels? As you can see >> above the xphase bit is one saying dual channels. Is this a dma setup >> problem? > > I can not find datasheet for the max98095... > So you can not configure the codec to use 2x16 number of bit clocks. when it > is configured to receive/send 16bit stereo samples? Correct, I can set bit clock to 64*lrclk, 48*lrclk, 128*lrclk, 17*lrclk, and 18*lrclk. The audio folks here think that it is normal to send more than required bit clocks, data is sent first so just ignore the rest. It would appear that the mcbsp doesn't really use the lrclk (I think called FSX), it just uses a positive transition to start the bit shifting for all the requested bits. The falling edge does not start the right channel, the shifter keeps going until all requested l/r counts have been sent. Or maybe something in the mcbsp has not been set up correctly? > Is this the case (that the codec all the time have 32 clock cycles per > channel)? > > If this is the case, than it is kind of tricky to get around this, but you can > try the following (warning: hack): > > In the codec driver: > create/add a startup callback function for the dais (snd_soc_dai_ops): > > static int max98095_startup(struct snd_pcm_substream *substream, > struct snd_soc_dai *dai) > { > snd_pcm_hw_constraint_msbits(substream->runtime, 0, 32, 16); > > return 0; > } > > Modify the MAX98095_FORMATS to only support S32_LE (remove the other formats > for now) > > In the hw_params calls handle the S32_LE in a same way as you handle the > S16_LE. > > To explain what we are doing: > Configure the codec to support only S32_LE format, but tell ALSA, that out of > the 32 bit only the first 16bit is valid. > So the driver will be opened with S32_LE mode, but only the first 16 bits will > have audio data: > 0-15: Left audio > 16-31: zero (padding on left channel) > 32-47: Right audio > 48-63: zero (padding on right channel) > > Use aplay -Dplughw:0,0 -v <some sample> to play audio, and see, if the HW has > been opened with S32_LE. > > You should have full stereo sound now. > I do, thanks. I am truly amazed that I was able to follow your instructions and get it to work first time. You must really know your alsa machine implementation. The problem is that now I cannot run 44.1Khz audio, I get underruns. I am guessing that software is expanding the samples from 16 bits to 32? Without your hack 44.1Khz audio works fine (but only audible in the first channel). > I have CC-d the author of the wm98095 codec driver, hi might be able to help > you with the codec setup... > I talk to Peter every day. He brought up the codec, I am trying to use the Beagleboardxm as a generic Linux platform for new codec bringups and for following kernel and alsa cutting edge software. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/18/11 18:06, Steve Calfee wrote: > On 05/16/11 23:37, Jarkko Nikula wrote: >>> >> Did you try to run OMAP as an I2S master like what omap3pandora.c is >> doing? >> >> Missing clock in codec master configuration suggests that reason >> is in codec side and reversed roles during development makes easier to >> hunt it further as then OMAP can play data out independently of is the >> codec correctly configured or not. >> >> You could run OMAP as a master by specifying SND_SOC_DAIFMT_CBS_CFS >> as a DAI format for both codec and OMAP and by setting McBSP to use >> internal 96 MHz clock as a master clock. Something like below might work >> for testing purposes: >> >> snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK, >> 96000000, SND_SOC_CLOCK_IN); >> >> snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, >> 62); /* 96M / 48k*32 */ >> > Hi, > > The hunt for clock continues. I redid my board-omap3beaglexm.c to as > closely match what board-omap3pandora.c is doing as I can. Like pandora, > I don't explicitly set the mux pin directions, I guess mcbsp master is > the default. > > I also tried to get as close as I could to the soc/omap/omap3pandora.c > machine driver with my omap3beaglexm.c machine driver. Specifically in > the *_hw_params init routines. > > But when I start things up (even with the codec disconnected from the > bclk line), I don't get any movement on the CLK and fsx. And of course > the dma doesn't send anything. > I have gotten mcbsp1 to work as a slave (sort-of) with Peter's help. I havent been able to get it to clock as a master. So now I try with mcbsp3, still no luck. More missing mcbsp bit clock. I am trying on mcbsp3. I am trying to get master mode working. Here is the register dump from the console (I have some debug printouts on). [ 30.039978] snd_pcm_do_start: state 3 [ 30.043823] omap_pcm_trigger: cmd 1 [ 30.047760] omap_start_dma: lch 0 [ 30.051696] omap-mcbsp omap-mcbsp.3: **** McBSP3 regs **** [ 30.057464] omap-mcbsp omap-mcbsp.3: DRR2: 0x2820d81 [ 30.062774] omap-mcbsp omap-mcbsp.3: DRR1: 0x0000 [ 30.067779] omap-mcbsp omap-mcbsp.3: DXR2: 0x0000 [ 30.072814] omap-mcbsp omap-mcbsp.3: DXR1: 0x0000 [ 30.077850] omap-mcbsp omap-mcbsp.3: SPCR2: 0x02f5 [ 30.082885] omap-mcbsp omap-mcbsp.3: SPCR1: 0x0030 [ 30.087890] omap-mcbsp omap-mcbsp.3: RCR2: 0x80a1 [ 30.092926] omap-mcbsp omap-mcbsp.3: RCR1: 0x00a0 [ 30.097961] omap-mcbsp omap-mcbsp.3: XCR2: 0x80a1 [ 30.102966] omap-mcbsp omap-mcbsp.3: XCR1: 0x00a0 [ 30.108001] omap-mcbsp omap-mcbsp.3: SRGR2: 0x10c0 [ 30.113037] omap-mcbsp omap-mcbsp.3: SRGR1: 0x5f3d [ 30.118041] omap-mcbsp omap-mcbsp.3: PCR0: 0x0f0f [ 30.123077] omap-mcbsp omap-mcbsp.3: *********************** My BSP sets up the mux for mcbsp3: #ifdef CONFIG_OMAP_MUX static struct omap_board_mux board_mux[] __initdata = { #if 1 /* McBSP 1 slave */ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), #else /* McBSP 1 master */ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), #endif /* McBSP 3 master */ OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), OMAP3_MUX(MCBSP3_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), OMAP3_MUX(MCBSP3_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT), { .reg_offset = OMAP_MUX_TERMINATOR }, }; #endif And with the mcbsp 4 pins not connected to anything but the scope, I don't see any bitclock movement. I think others used u-boot to setup the mcbspx, but has anyone successfully used linux to set up the pins? Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 19 May 2011 17:58:56 -0700 Steve Calfee <stevecalfee@gmail.com> wrote: > > I also tried to get as close as I could to the soc/omap/omap3pandora.c > > machine driver with my omap3beaglexm.c machine driver. Specifically in > > the *_hw_params init routines. > > > > But when I start things up (even with the codec disconnected from the > > bclk line), I don't get any movement on the CLK and fsx. And of course > > the dma doesn't send anything. > > > > I have gotten mcbsp1 to work as a slave (sort-of) with Peter's help. I > havent been able to get it to clock as a master. So now I try with > mcbsp3, still no luck. > This very likely sounds that in master mode the master clock to McBSP is missing if there is no DMA running. Did you try to use internal 96 MHz from my example or did you try to use external CLKS what Pandora is using? That CLKS setup in Pandora requires that there is a clock coming to McBSP CLKS pin. But as you got codec slave mode working it seems that pin multiplexing is ok so there is no need to try with master mode. In problematic cases the master mode is a good start since then only McBSP clock setup and pin multiplexing can affect if there are no clock and data signals visible. > And with the mcbsp 4 pins not connected to anything but the scope, I > don't see any bitclock movement. I think others used u-boot to setup the > mcbspx, but has anyone successfully used linux to set up the pins? > Yep, in a couple omap boards. Remember that for kernel based multiplexing the CONFIG_OMAP_MUX=y must be set.
On Friday 20 May 2011 02:58:30 Steve Calfee wrote: > On 05/19/11 04:28, Peter Ujfalusi wrote: > Correct, I can set bit clock to 64*lrclk, 48*lrclk, 128*lrclk, 17*lrclk, > and 18*lrclk. Strange, that there is no option for 32*lrclk. > The audio folks here think that it is normal to send more > than required bit clocks, data is sent first so just ignore the rest. Yes, it is allowed. The rest should be ignored. But I'm afraid, OMAP McBSP can not handle this in a way you (and me) wanted to. > It would appear that the mcbsp doesn't really use the lrclk (I think > called FSX), it just uses a positive transition to start the bit > shifting for all the requested bits. The falling edge does not start the > right channel, the shifter keeps going until all requested l/r counts > have been sent. Yeah, McBSP only cares about the start condition, it does not care about the right channel FSX transition. This is the reason it is not possible to handle the scenario you are aiming for. At start condition, it just start to send the data stream (frame1 followed by frame2 in dual-phase mode - in single phase mode it can send up to 128 frames). Having said that, there might be a way to actually work this around with McBSP's multichannel mode. Configuring it for 4 slots, and only shift data for slot 0, and 2 in case of your setup (16bit data within 32 bitclocks). It is a long shot, I can not promise that I can take a look right away, but if you have time.... ;) > > You should have full stereo sound now. > > I do, thanks. Cool :D > I am truly amazed that I was able to follow your > instructions and get it to work first time. You must really know your > alsa machine implementation. Thanks, I try. > The problem is that now I cannot run 44.1Khz audio, I get underruns. I > am guessing that software is expanding the samples from 16 bits to 32? > Without your hack 44.1Khz audio works fine (but only audible in the > first channel). Hmm. I have used similar mode with twl4030, and tlv320dac33 (S32_LE with 24msbits) without issues with underrun. Let's see. Can you check /sys/devices/platform/omap-mcbsp.X/dma_op_mode, max_tx_thres for your McBSP port? I would suggest to switch the dma_op_mode to threshold mode in any port. When you play audio try to use bigger periods, something like 10ms: aplay -Dplughw:0,0 --period-time=10000 -v <your sample> Replace the -Dplughw:0,0 to point to the wm98095 PCM. Could you post the output of aplay? > I talk to Peter every day. He brought up the codec, I am trying to use > the Beagleboardxm as a generic Linux platform for new codec bringups and > for following kernel and alsa cutting edge software. Make sense..
Hi, On Friday 20 May 2011 09:29:11 Jarkko Nikula wrote: > This very likely sounds that in master mode the master clock to McBSP is > missing if there is no DMA running. If the clock setup is correct for McBSP, than it runs the clocks, and shifts out data. > Did you try to use internal 96 MHz > from my example or did you try to use external CLKS what Pandora is > using? That CLKS setup in Pandora requires that there is a clock coming > to McBSP CLKS pin. Really good point. PRCM/CORE (depending on the McBSP port) 96M_FCLK must be used here.
On 05/19/11 23:29, Jarkko Nikula wrote: > On Thu, 19 May 2011 17:58:56 -0700 > Steve Calfee <stevecalfee@gmail.com> wrote: > ... >> > This very likely sounds that in master mode the master clock to McBSP is > missing if there is no DMA running. Did you try to use internal 96 MHz > from my example or did you try to use external CLKS what Pandora is > using? That CLKS setup in Pandora requires that there is a clock coming > to McBSP CLKS pin. > > But as you got codec slave mode working it seems that pin multiplexing > is ok so there is no need to try with master mode. In problematic cases > the master mode is a good start since then only McBSP clock setup and > pin multiplexing can affect if there are no clock and data signals > visible. > OK, you called this correctly. Apparently the beagle does not by default have a clock on the clks pin. When I correctly followed your suggestion and changed to the internal 96,000,000 clock I do get transitions on the mcbsp1 clk and fsx pins. The problem is 96M is pretty big. the only divisor I see is 8 bits, your suggested division (else where of 62) only brings the bit clock rate to about 15Mhz. the frame clock did get set very near the 8Khz for the sample playback. So about 1900 bit clocks are sent per frame. This would be ok, but since the mcbsp does not respect the l/r clock (FSX) for shifting out data, I am back to getting audio on only one ear. I was hoping that in master mode I could configure the mcbsp to only send 16 bit clocks per frame. It looks like the clocks are not that configurable. The external clks pin is supposed to be connect to an external TPS65950 chip which divides down the source 26Mhz clock by 256. I'll have to investigate why I was not seeing that clock. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 2175f09..a88a0bf 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -146,7 +146,7 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, * 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) * 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) */ - if (cpu_is_omap343x() || cpu_is_omap44xx()) { + if (cpu_is_omap34xx() || cpu_is_omap44xx()) { /* * Rule for the buffer size. We should not allow * smaller buffer than the FIFO size to avoid underruns @@ -258,7 +258,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, default: return -EINVAL; } - if (cpu_is_omap343x()) { + if (cpu_is_omap34xx()) { dma_data->set_threshold = omap_mcbsp_set_threshold; /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */ if (omap_mcbsp_get_dma_op_mode(bus_id) ==
Current checks for cpu type were too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi <premi@ti.com> cc: Mark Brown <broonie@opensource.wolfsonmicro.com> cc: Liam Girdwood <lrg@ti.com> cc: Jarkko Nikula <jhnikula@gmail.com> --- Changes in v4: Reposting after validating that patch still applies cleanly on linux-omap master [46966f1] Changed the subject as suggested by Jarkko. Since the subject has changed, i have omitted v4. Changes in v3:: None. Reposting[1] after subscribing to alsa-devel list Changes in v2: 1) Added one more check to the changes. 2) Updated commit message to use plurals. [1] http://marc.info/?l=linux-omap&m=130026430110592&w=2 sound/soc/omap/omap-mcbsp.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)