Please help in adding ams-delta support to ASoC

Hi,

I am trying to add sound support for ams-delta omap machine, yet without much success.

Three years ago, Mark Underwood created an omap-alsa compatible driver that basically worked[1]. It was derieved from similiar driver for aic23 codec found on omap osk machine. It looks like Mark has never managed to finish his work. It's not clear for me if he has found that getting a working fullduplex sound is technically impossible on a voice modem codec, shared among modem and cpu, controlable only from modem side afaik, but I have decided to give it a try.

Since Mark's initial work, omap-alsa framework has been depreciated in favour of soc-omap. API changes are so significant that Mark's code is rather not useable directly any more. However, I am trying to use it as a starting point, by comparing it against it's prototype osk/aic23 code.

Following Mark, I am trying to derieve the new ams-delta sound driver from current asoc driver for omap osk9512. For codec part, I decided to base my work on much more simple ad73311 rather that tlv320aic23.

Comparing Mark's code agaist it's osk/aic23 prototype, I can see the folowing significant changes:
1. rate tables/bitmaps found in hw_constraint_rates, snd_omap_alsa_playback and snd_omap_alsa_capture structures limited to 8kHz, 2. hardware related code found in codec_configure_dev(), codec_clock_on() and codec_clock_off() callback functions replaced with ams-delta hardware specific code that switches the codec DAI pins from modem chip to mcbsp cpu interface and back,
3. codec_set_samplerate() and all mixer related functions replaced with stubs.
4. the following McBSP register settings changes:

(quoted diff) +0 -1

-	.xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |

I have found points 1. to 3. rather trivial to implement in new framework. Regarding point 4., it looks like detailed register settings are now done inside omap-mcbsp.c, based on machine specified format, so I have to find out what format should be specified for ams-delta. Please correct me if I am missing something.

There was one more modification in Mark's code, addressing dma chaining problem on omap15xx hardware, but as far as I could see, the problem was already solved in the asoc omap framework.

Initially, I based my work on ompenembedded provided linux-omap.git revision 90e758af52ba803cba233fabee81176d99589f09. The results were rather poor - total system hangup after first device access, with no single message. So I have switched to linux-2.6.30-rc5 and now I can safely access the device, however it does not work as expected. aplay and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae.
DMA interrput counters stay at 0.

However, codec
switching that I do from machine->ops->startup/shutdown seems working, as modem stops producing any sounds while the alsa device is in use and gets back thereafter.

First of all, I'd like to make sure if my problem is related to my code only. As I am new in these areas, I would like to ask you if the omap asoc framework is stable enough to relay on.

If yes, could you please
look at my dirty code (attached) an give me some hints? I can provide you with more information if necessary.

Regards,
Janusz

safely access the device, however it does not work as expected. aplay and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae. DMA interrput counters stay at 0. However, codec

First of all, I'd like to make sure if my problem is related to my code only. As I am new in these areas, I would like to ask you if the omap asoc framework is stable enough to relay on. If yes, could you please look at my dirty code (attached) an give me some hints? I can provide you with more information if necessary.

single message. So I have switched to linux-2.6.30-rc5 and now I can safely access the device, however it does not work as expected. aplay and arecord wait forever, cat to/from /dev/dsp breaks with hardware

First of all, I'd like to make sure if my problem is related to my code only. As I am new in these areas, I would like to ask you if the omap asoc framework is stable enough to relay on. If yes, could you please

sound/soc/codecs/cx20442.c +4 -0

+static int cx20442_soc_probe(struct platform_device *pdev)
+{
+	struct snd_soc_device *socdev = platform_get_drvdata(pdev);
+	struct snd_soc_codec *codec;

+/*

+ * File:         sound/soc/codec/cx20442.h
+ * Based on:     sound/soc/codec/ad73311.h
+ * Author:       Cliff Cai <[email protected]>

+ *
+ * Created: Thur Sep 25, 2008
+ * Description: definitions for cx20442 registers
+ *
+ *
+ * Modified:
+ * Copyright 2006 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/

Quoted 9 lines · On Tuesday 26 May 2009 16:17:23 ext Janusz Krzysztofik wrote:

4. the following McBSP register settings changes:

(quoted diff) +2 -3

-	.xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
-	    XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG,
+	.xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0),
 
-	.srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1),
+	.srgr1 = CLKGDV(0),

Review

Quoted 4 lines

(quoted diff) +1 -2

-	.srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1),
+       .srgr2 = GSYNC,
 
-	.pcr0 = CLKXP | CLKRP,  /* mcbsp: slave */

Since I don't have the original osk/aic23 thing, this does not mean to much... Just a bit confusing.

The configuration suggest slave McBSP with NB_IF
polarity, dual phase format, 16 bit words, 16*2 long frames, the FS pulse is probably a pulse... Suggesting kind of DSP mode, but with not so correct configuration, which happens to be working.

Quoted 4 lines

... aplay
and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae.
DMA interrput counters stay at 0.

This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec.

Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct.

Review

Quoted 4 lines · On Tue, 26 May 2009 15:17:23 +0200 Janusz Krzysztofik <[email protected]>…

(quoted diff) +1 -2

-	.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.

Review

Quoted 3 lines

(quoted diff) +1 -1

-	.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.

Review

Quoted 6 lines

(quoted diff) +0 -1

-	.srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE *

2 - 1),

(quoted diff) +1 -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.

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

Quoted 3 lines

... 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?

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

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

... 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.

Review

Quoted 4 lines · On Tue, 26 May 2009 15:17:23 +0200 Janusz Krzysztofik <[email protected]>…

(quoted diff) +1 -2

-	.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.

Review

Quoted 3 lines

(quoted diff) +1 -1

-	.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.

Review

Quoted 6 lines

(quoted diff) +0 -1

-	.srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE *

2 - 1),

(quoted diff) +1 -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.

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

Quoted 1 line

... 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?

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

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

... 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.

Quoted 2 lines · Janusz Krzysztofik

... aplay
and arecord wait forever, cat to/from /dev/dsp breaks with hardware

Do they really wait for ever or do they eventually time out? The default for both programs is to give up after 10 seconds if there's no DMA happening.

... A few comments below.

sound/soc/codecs/cx20442.c line 25

Quoted 5 lines

sound/soc/codecs/cx20442.c +5 -0

+#include <sound/ac97_codec.h>
+#include <sound/initval.h>
+#include <sound/soc.h>
+
+#include "cx20442.h"

Shouldn't need ac97_codec.h if it's not an AC97 CODEC.

Quoted 10 lines

sound/soc/codecs/cx20442.c +10 -0

+static int cx20442_soc_probe(struct platform_device *pdev)
+{
+	struct snd_soc_device *socdev = platform_get_drvdata(pdev);
+	struct snd_soc_codec *codec;
+	int ret = 0;
+
+	codec = kzalloc(sizeof(struct snd_soc_codec), GFP_KERNEL);
+	if (codec == NULL)
+		return -ENOMEM;
+	mutex_init(&codec->mutex);

sound/soc/codecs/cx20442.c line 57

Quoted 4 lines

sound/soc/codecs/cx20442.c +4 -0

+	codec->name = "CX20442";
+	codec->owner = THIS_MODULE;
+	codec->dai = &cx20442_dai;
+	codec->num_dai = 1;

It'd be nice to switch this over to registering the CODEC as a platform device rather than using the old style ASoC probing - see something line WM8731 for a relatively simple example.

sound/soc/codecs/cx20442.c line 116

Quoted 2 lines

sound/soc/codecs/cx20442.c +2 -0

+MODULE_DESCRIPTION("ASoC cx20442 driver");
+MODULE_AUTHOR("Cliff Cai ");

You possibly want to update this one :)

Basically, the CODEC driver looks fine from an ASoC point of view.

Quoted 4 lines

+/*

+ * File:         sound/soc/codec/cx20442.h
+ * Based on:     sound/soc/codec/ad73311.h
+ * Author:       Cliff Cai <[email protected]>

Quoted 9 lines

+ *
+ * Created: Thur Sep 25, 2008
+ * Description: definitions for cx20442 registers
+ *
+ *
+ * Modified:
+ * Copyright 2006 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/

These comments have cut'n'paste issues too, and the register definitions should all be removed.

Quoted 8 lines

sound/soc/omap/ams-delta.c +8 -0

+static int ams_delta_startup(struct snd_pcm_substream *substream)
+{
+	ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, 0);
+	return clk_enable(cx20442_mclk);
+}
+
+static void ams_delta_shutdown(struct snd_pcm_substream *substream)
+{

sound/soc/omap/ams-delta.c line 53

Quoted 1 line

sound/soc/omap/ams-delta.c +1 -0

+	clk_disable(cx20442_mclk);

Possibly not an issue with this device but you might want to move the MCLK handling to your machine set_bias_level() function. That will mean that your MCLK will be left running for a while after audio stops, ensuring that the DAC has had time to clock out the final sample. Without that sometimes you can end up causing an audible artefact when starting the next playback.

Quoted 6 lines

Quoted 6 lines

(quoted diff) +0 -1

-	.srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE

* 2 - 1),

(quoted diff) +1 -1

+       .srgr2 = GSYNC,
 
-	.pcr0 = CLKXP | CLKRP,  /* mcbsp: slave */

Quoted 2 lines

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.

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.

Quoted 6 lines

Quoted 6 lines

(quoted diff) +0 -1

-	.srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE

* 2 - 1),

(quoted diff) +1 -1

+       .srgr2 = GSYNC,
 
-	.pcr0 = CLKXP | CLKRP,  /* mcbsp: slave */

Quoted 2 lines

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.

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.

This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec.

Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct.

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?

Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls.

This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec.

Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct.

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?

Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls.

So I am going to restart with checking if the original patch still works with the latest kernel version supporting omap-alsa.

Looks like McBSP is not getting bit-clock and frame-sync signals from the codec. ...
Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls.

This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec.
Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct.

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.

It would be nice to get
this working since it would be the first OMAP5910 == OMAP1510 based machine driver.

So I am going to restart with checking if the original patch still works with the latest kernel version supporting omap-alsa.

Looks like McBSP is not getting bit-clock and frame-sync signals from the codec. ...
Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls.

This means that the McBSP module is not transmitting/receiving any data.
Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec. Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct.

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.

It would be nice to get
this working since it would be the first OMAP5910 == OMAP1510 based machine driver.

The original patch ported to linux-omap-2.6.27, the last omap release with omap-alsa support, gives me a working sound driver on ams-delta.

To make the original driver work stable, I had to patch the omap-alsa framework to restore the original way that lack of dma chaining problem had been solved in the original patch (see below), so maybe there is a similiar issue in the currect ASoC McBSP framework?

My asoc based patch is also very generic and contains no more that the same two ams_delta_latch2_write() hardware related operations, called from inside snd_soc_dai_link.ops.startup() and snd_soc_dai_link.ops.shutdown() callback functions:

My conclusuions so far:

1. If the new OMAP McBSP ASoC framework provides all the functionality of the depreciated OMAP Alsa under a different API, the only reason of my driver not working I can imagine is that I have put these two lines of hardware related code in wrong places. If this is the case, could someone please point me into the right direction?

2. Maybe the original ams-delta sound driver should not in theory work as is? Maybe Mark Underwood was just lucky enough to get it working without any real hardware setup?

3. Otherwise, there must be a significant difference in (alsa) MsBSP handling code that I am not able to identify and resolve myself. I can only say that I have seen much more mcbsp_...() stuff in the old omap-alsa framework than in the current one. The differece can be significant for OMAP15XX, or OMAP5910, or even ams-delta only.

4. Base (not alsa related) McBSP framework did not change since 2.6.16 (the original patch base) up to 2.6.27 in a way that could break the original patch. If my problem was related to base McBSP handling, changes should be looked for after 2.6.27, if any.

Quoted 3 lines · Jarkko Nikula

It would be nice to get
this working since it would be the first OMAP5910 == OMAP1510 based machine driver.

I am personally interested in this, as I have bought two E3's recently in hope I can make use of them as IP phones. But for now, I have no idea what else I could try. I have noticed that Andrew de Quincey is going to fix sound on Nokia 770, maybe he finds something related.

The original patch ported to linux-omap-2.6.27, the last omap release with omap-alsa support, gives me a working sound driver on ams-delta.

To make the original driver work stable, I had to patch the omap-alsa framework to restore the original way that lack of dma chaining problem had been solved in the original patch (see below), so maybe there is a similiar issue in the currect ASoC McBSP framework?

My asoc based patch is also very generic and contains no more that the same two ams_delta_latch2_write() hardware related operations, called from inside snd_soc_dai_link.ops.startup() and snd_soc_dai_link.ops.shutdown() callback functions:

My conclusuions so far:

1. If the new OMAP McBSP ASoC framework provides all the functionality of the depreciated OMAP Alsa under a different API, the only reason of my driver not working I can imagine is that I have put these two lines of hardware related code in wrong places. If this is the case, could someone please point me into the right direction?

2. Maybe the original ams-delta sound driver should not in theory work as is? Maybe Mark Underwood was just lucky enough to get it working without any real hardware setup?

3. Otherwise, there must be a significant difference in (alsa) MsBSP handling code that I am not able to identify and resolve myself. I can only say that I have seen much more mcbsp_...() stuff in the old omap-alsa framework than in the current one. The differece can be significant for OMAP15XX, or OMAP5910, or even ams-delta only.

4. Base (not alsa related) McBSP framework did not change since 2.6.16 (the original patch base) up to 2.6.27 in a way that could break the original patch. If my problem was related to base McBSP handling, changes should be looked for after 2.6.27, if any.

Quoted 3 lines · Jarkko Nikula

It would be nice to get
this working since it would be the first OMAP5910 == OMAP1510 based machine driver.

I am personally interested in this, as I have bought two E3's recently in hope I can make use of them as IP phones. But for now, I have no idea what else I could try. I have noticed that Andrew de Quincey is going to fix sound on Nokia 770, maybe he finds something related.

Hi Peter,

Quoted 10 lines · On Wuesday 27 May 2009 07:57 Peter Ujfalusi wrote:

Quoted 9 lines · On Tuesday 26 May 2009 16:17:23 ext Janusz Krzysztofik wrote:

4. the following McBSP register settings changes:

(quoted diff) +2 -3

-	.xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
-	    XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG,
+	.xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0),
 
-	.srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1),
+	.srgr1 = CLKGDV(0),

Quoted 7 lines

Review

Quoted 4 lines

(quoted diff) +1 -2

-	.srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1),
+       .srgr2 = GSYNC,
 
-	.pcr0 = CLKXP | CLKRP,  /* mcbsp: slave */

Since I don't have the original osk/aic23 thing, this does not mean to much... Just a bit confusing.

OK, once again then.

original omap-alsa mcbsp register settings for osk board, as found in linux-2.6.16/arch/arm/mach-omap1/board-osk.c:
-----
#define DEFAULT_BITPERSAMPLE 16

static struct omap_mcbsp_reg_cfg mcbsp_regs = {
         .spcr2 = FREE | FRST | GRST | XRST | XINTM(3),
         .spcr1 = RINTM(3) | RRST,
         .rcr2 = RPHASE | RFRLEN2(OMAP_MCBSP_WORD_8) |
             RWDLEN2(OMAP_MCBSP_WORD_16) | RDATDLY(0),
         .rcr1 = RFRLEN1(OMAP_MCBSP_WORD_8) | RWDLEN1(OMAP_MCBSP_WORD_16),
         .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) |
             XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG,
         .xcr1 = XFRLEN1(OMAP_MCBSP_WORD_8) | XWDLEN1(OMAP_MCBSP_WORD_16),
         .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1),
         .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 -

1), /*.pcr0 = FSXM | FSRM | CLKXM | CLKRM | CLKXP | CLKRP,*/ /* mcbsp:
master */
.pcr0 = CLKXP | CLKRP, /* mcbsp: slave */
};
-----
the same for ams-delta, as found in Mark Underwood patch:
-----

static struct omap_mcbsp_reg_cfg mcbsp_regs = {
         .spcr2 = FREE | XRST | GRST | XINTM(3) | FRST,
         .spcr1 =  RINTM(3) | RRST,
         .rcr2 =  RPHASE | RWDLEN2(OMAP_MCBSP_WORD_16) | RFRLEN2(0),
         .rcr1 = RWDLEN1(OMAP_MCBSP_WORD_16) | RFRLEN1(0),
         .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0),
         .xcr1 =  XWDLEN1(OMAP_MCBSP_WORD_16) | XFRLEN1(0),
         .srgr1 = CLKGDV(0),
         .srgr2 = GSYNC,
};

-----
currnet soc-audio mcbsp config for osk, as found in linux-2.6.29/sound/soc/omap/osk5912.c:
-----
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM);
-----
Using exactly the same does not work on my ams-delta.

Quoted 5 lines

The configuration suggest slave McBSP with NB_IF

polarity, dual phase format, 16 bit words, 16*2 long frames, the FS pulse is probably a pulse... Suggesting kind of DSP mode, but with not so correct configuration, which happens to be working.

So I will try the following then:
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_IF | SND_SOC_DAIFMT_CBM_CFM);
and this:
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_NB_IF | SND_SOC_DAIFMT_CBM_CFM);
and give you a feedback.

Quoted 8 lines

Quoted 4 lines

... aplay
and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae.
DMA interrput counters stay at 0.

This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec.

Do you mean trying with codec as slave and McBSP as master, like this?
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_IF | SND_SOC_DAIFMT_CBS_CFS);
I'll give it a try as well.

Quoted 2 lines

Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct.

Do you mean mux setup? Reading OMAP5910 Data Manual I found only 2 relevant signals, MCBSP1.FSX and MCBSP1.DX, that could be swapped from pin H15 to H18 and vice versa. However, there is no pin configuration entry for neither, both in 2.6.16 and 2.6.29 arch/arm/mach-omap1/mux.c, so I assume default setup should just work.

I keep on digging.

Thanks,
Janusz
_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

On Mon, 01 Jun 2009 14:41:59 +0200

Quoted 2 lines · Janusz Krzysztofik

The original patch ported to linux-omap-2.6.27, the last omap release with omap-alsa support, gives me a working sound driver on ams-delta.

Ok, good to know.

Quoted 4 lines

To make the original driver work stable, I had to patch the omap-alsa framework to restore the original way that lack of dma chaining problem had been solved in the original patch (see below), so maybe there is a similiar issue in the currect ASoC McBSP framework?

Is the older implementation working at commit d8376cc482b241701f7606c81ad578b90853e175 in linux-omap, i.e. last commit before their removal?

What I see at quick look from the older implementation that it is doing somewhat similar way the DMA transfer and workaround for 1510 than current ASoC except that now the DMA parameters are not reprogrammed between the restarted transfers. I don't know if 1510 requires it?

Quoted 5 lines

My asoc based patch is also very generic and contains no more that the same two ams_delta_latch2_write() hardware related operations, called from inside snd_soc_dai_link.ops.startup() and snd_soc_dai_link.ops.shutdown() callback functions:

One thing worth to try would be try to use exactly same McBSP registers for omap_mcbsp_config in omap_mcbsp_dai_hw_params than used before for ams delta.

Sorry, have to cut my answer now here. I'll get back tomorrow.

On Mon, 01 Jun 2009 14:41:59 +0200

Quoted 2 lines · Janusz Krzysztofik

The original patch ported to linux-omap-2.6.27, the last omap release with omap-alsa support, gives me a working sound driver on ams-delta.

Ok, good to know.

Quoted 4 lines

To make the original driver work stable, I had to patch the omap-alsa framework to restore the original way that lack of dma chaining problem had been solved in the original patch (see below), so maybe there is a similiar issue in the currect ASoC McBSP framework?

Is the older implementation working at commit d8376cc482b241701f7606c81ad578b90853e175 in linux-omap, i.e. last commit before their removal?

What I see at quick look from the older implementation that it is doing somewhat similar way the DMA transfer and workaround for 1510 than current ASoC except that now the DMA parameters are not reprogrammed between the restarted transfers. I don't know if 1510 requires it?

Quoted 5 lines

My asoc based patch is also very generic and contains no more that the same two ams_delta_latch2_write() hardware related operations, called from inside snd_soc_dai_link.ops.startup() and snd_soc_dai_link.ops.shutdown() callback functions:

One thing worth to try would be try to use exactly same McBSP registers for omap_mcbsp_config in omap_mcbsp_dai_hw_params than used before for ams delta.

Sorry, have to cut my answer now here. I'll get back tomorrow.

What I see at quick look from the older implementation that it is doing somewhat similar way the DMA transfer and workaround for 1510 than current ASoC except that now the DMA parameters are not reprogrammed between the restarted transfers. I don't know if 1510 requires it?

Quoted 7 lines

1. If the new OMAP McBSP ASoC framework provides all the functionality of the depreciated OMAP Alsa under a different API, the only reason of my driver not working I can imagine is that I have put these two lines of hardware related code in wrong places. If this is the case, could someone please point me into the right direction?

Quoted 7 lines

3. Otherwise, there must be a significant difference in (alsa) MsBSP handling code that I am not able to identify and resolve myself. I can only say that I have seen much more mcbsp_...() stuff in the old omap-alsa framework than in the current one. The differece can be significant for OMAP15XX, or OMAP5910, or even ams-delta only.

Quoted 6 lines

I am personally interested in this, as I have bought two E3's recently in hope I can make use of them as IP phones. But for now, I have no idea what else I could try. I have noticed that Andrew de Quincey is going to fix sound on Nokia 770, maybe he finds something related.

Quoted 10 lines · Janusz Krzysztofik

(quoted diff) +10 -0

+static int cx20442_soc_probe(struct platform_device *pdev)
+{
+	struct snd_soc_device *socdev = platform_get_drvdata(pdev);
+	struct snd_soc_codec *codec;
+	int ret = 0;
+
+	codec = kzalloc(sizeof(struct snd_soc_codec), GFP_KERNEL);
+	if (codec == NULL)
+		return -ENOMEM;
+	mutex_init(&codec->mutex);

Review

Quoted 4 lines

(quoted diff) +4 -0

+	codec->name = "CX20442";
+	codec->owner = THIS_MODULE;
+	codec->dai = &cx20442_dai;
+	codec->num_dai = 1;

It'd be nice to switch this over to registering the CODEC as a platform device rather than using the old style ASoC probing - see something line WM8731 for a relatively simple example.

I have choosen to register the codec device with platform_device_register_simple("cx20442-codec", ...) invoked form asoc machine driver, is this ok?

Is the older implementation working at commit d8376cc482b241701f7606c81ad578b90853e175 in linux-omap, i.e. last commit before their removal?

Is the older implementation working at commit d8376cc482b241701f7606c81ad578b90853e175 in linux-omap, i.e. last commit before their removal?

Quoted 10 lines · On Wednesday 27 May 2009 16:07:23 ext Janusz Krzysztofik wrote:

static struct omap_mcbsp_reg_cfg mcbsp_regs = {
         .spcr2 = FREE | XRST | GRST | XINTM(3) | FRST,
         .spcr1 =  RINTM(3) | RRST,
         .rcr2 =  RPHASE | RWDLEN2(OMAP_MCBSP_WORD_16) | RFRLEN2(0),
         .rcr1 = RWDLEN1(OMAP_MCBSP_WORD_16) | RFRLEN1(0),
         .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0),
         .xcr1 =  XWDLEN1(OMAP_MCBSP_WORD_16) | XFRLEN1(0),
         .srgr1 = CLKGDV(0),
         .srgr2 = GSYNC,
};

I wonder has this been working at all???
FPER is not configured in srgr2 (actually it is 0, which means that the frame period is 1...)
FWID is not configured in srgr1 (it is 0, which means the FS is a pulse, length is 1)
Since CLKXP, CLKRP is 0, it suggests inverted bitclock.
FSXP, FSRP is 0, so it must have normal FS polarity in DSP mode, or inverted polarity in I2S mode???
Data delay is 0 for rx and tx.

In all, I think this is a missconfigured DSP_B mode with inverted bitclock. Can you try this:
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_CBM_CFM);

Quoted 11 lines

So I will try the following then:
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_IF | SND_SOC_DAIFMT_CBM_CFM);
and this:
err = snd_soc_dai_set_fmt(cpu_dai,
SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_NB_IF | SND_SOC_DAIFMT_CBM_CFM);
and give you a feedback.

On Mon, 1 Jun 2009 21:04:13 +0300
Jarkko Nikula <[email protected]> wrote:

Hmm, I forgot one major difference. Older implementation was transferring the buffer by transferring periods by own DMA transfers while ASoC implementation is transferring the whole buffer by single transfer but letting DMA to generate interrupts at period boundaries but this should be supported by the 1510 as well.

I just tried non-chained transfer, i.e. restarting DMA after buffer is transferred in omap-pcm.c by using N810 and 2420 and it worked as I was recalling. This was simulating 1510 by adding (1
|| cpu_is_omap1510) or (0 && !cpu_is_omap1510()) where 1510 was tested.

But there is no DMA stop workaround before restarting like the original ams delta patch has.

Quoted 3 lines

Quoted 3 lines

the only reason of my driver not working I can imagine is that I have put these two lines of hardware related code in wrong places.

I don't think there is anything in a wrong place. It would help a lot if we would know for sure is the MCLK from OMAP to codec and McBSP FS and bit clocks from the codec really working since that is the first requirement for working transfer. Luckily we know that the HW is working :-)

At least one difference is that omap-mcbsp.c is constructing McBSP register bits itself while older implementation was passing raw register configuration from the board files. Probably you could try to hack omap_mcbsp_dai_hw_params and pass the same register settings there to see are there some missing bit in omap-mcbsp.c.

I am not sure if this is of any importance, but with the old working code, playing /dev/urandom to /dev/dsp I get only 3-4 DMA interrupts per second, while doing the same on a x86_64 via82cxxx results in 40-50 device interrupts per second.

I did not find any documentation on the codec itself, only on its "master" modem chip cx81801. Regarding modem<->codec interface, there were only pins with breif description specified for both chips, nothing more, as this interface was probably not intended for access from outside. From the codec side, it looks like this:

- Sleep (SLEEP); input
- Master Clock (M_CLKIN); input
- Serial Clock (M_SCK); output
- Control (M_CNTRLSIN); input
- Serial Frame Sync (M_STROBE); output
- Serial Transmit Data (M_TXSIN); input
- Serial Receive Data (M_RXOUT); output
- Reset (POR); input

However, I can't tell which lines are switched from modem to mcbsp and which are kept connected to the modem chip all the time. Anyway, it looks like we can be sure that both bit clock and frame sync should come from codec to mcbsp. It is not clear for me if MCLK is really used by the codec, or it is possible that it gets its master clock from an other, modem related source, and if this does really matter.

Quoted 5 lines

At least one difference is that omap-mcbsp.c is constructing McBSP register bits itself while older implementation was passing raw register configuration from the board files. Probably you could try to hack omap_mcbsp_dai_hw_params and pass the same register settings there to see are there some missing bit in omap-mcbsp.c.

OK, I'll see if I know how to do this.

I am not sure if this is of any importance, but with the old working code, playing /dev/urandom to /dev/dsp I get only 3-4 DMA interrupts per second, while doing the same on a x86_64 via82cxxx results in 40-50 device interrupts per second.

I did not find any documentation on the codec itself, only on its "master" modem chip cx81801. Regarding modem<->codec interface, there were only pins with breif description specified for both chips, nothing more, as this interface was probably not intended for access from outside. From the codec side, it looks like this:

- Sleep (SLEEP); input
- Master Clock (M_CLKIN); input
- Serial Clock (M_SCK); output
- Control (M_CNTRLSIN); input
- Serial Frame Sync (M_STROBE); output
- Serial Transmit Data (M_TXSIN); input
- Serial Receive Data (M_RXOUT); output
- Reset (POR); input

However, I can't tell which lines are switched from modem to mcbsp and which are kept connected to the modem chip all the time. Anyway, it looks like we can be sure that both bit clock and frame sync should come from codec to mcbsp. It is not clear for me if MCLK is really used by the codec, or it is possible that it gets its master clock from an other, modem related source, and if this does really matter.

Quoted 5 lines

At least one difference is that omap-mcbsp.c is constructing McBSP register bits itself while older implementation was passing raw register configuration from the board files. Probably you could try to hack omap_mcbsp_dai_hw_params and pass the same register settings there to see are there some missing bit in omap-mcbsp.c.

OK, I'll see if I know how to do this.

Hi Jarkko,

Quoted 3 lines · Jarkko Nikula

Is the older implementation working at commit d8376cc482b241701f7606c81ad578b90853e175 in linux-omap, i.e. last commit before their removal?

I have managed to check with that revision this morning and yes, the driver is working.

I'll try you other suggestions as soon as I get back home.

Hi Jarkko,

Quoted 3 lines · Jarkko Nikula

Is the older implementation working at commit d8376cc482b241701f7606c81ad578b90853e175 in linux-omap, i.e. last commit before their removal?

I have managed to check with that revision this morning and yes, the driver is working.

I'll try you other suggestions as soon as I get back home.

Quoted 4 lines

It is not clear for me if MCLK
is really used by the codec, or it is possible that it gets its master clock from an other, modem related source, and if this does really matter.

Hmm. Are there any possibility that ams_delta_latch2_write requires working MCLK for latch change?

Probably you could use also older implementation to find out is the MCLK required for codec by commenting out vc_mclk control.

Just hack the same "static struct omap_mcbsp_reg_cfg mcbsp_regs = { ..." in omap-mcbsp.c and pass that structure instead of &mcbsp_data->regs to omap_mcbsp_config in omap_mcbsp_dai_hw_params.

Looking at the code at commit: d8376cc482b241701f7606c81ad578b90853e175 on l-o the comment about the need for the call the omap_stop_dma puzzled me.

Can you try something like this:

sound/soc/omap/omap-pcm.c +2 -0

index 6454e15..2df1792 100644
@@ -67,6 +67,7 @@ static void omap_pcm_dma_irq(int ch, u16 stat, void
 *data) spin_lock_irqsave(&prtd->lock, flags);
                if (prtd->period_index >= 0) {
                        if (++prtd->period_index == runtime->periods) {
+                               omap_stop_dma(prtd->dma_ch);
                                prtd->period_index = 0;
                                omap_start_dma(prtd->dma_ch);
                        }

@@ -191,6 +192,7 @@ static int omap_pcm_trigger(struct snd_pcm_substream
 *substream, int cmd)
        case SNDRV_PCM_TRIGGER_START:
        case SNDRV_PCM_TRIGGER_RESUME:
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+               omap_stop_dma(prtd->dma_ch);
                prtd->period_index = 0;
                omap_start_dma(prtd->dma_ch);

                break;

Looking at the code at commit: d8376cc482b241701f7606c81ad578b90853e175 on l-o the comment about the need for the call the omap_stop_dma puzzled me.

Can you try something like this:

sound/soc/omap/omap-pcm.c +2 -0

index 6454e15..2df1792 100644
@@ -67,6 +67,7 @@ static void omap_pcm_dma_irq(int ch, u16 stat, void
 *data) spin_lock_irqsave(&prtd->lock, flags);
                if (prtd->period_index >= 0) {
                        if (++prtd->period_index == runtime->periods) {
+                               omap_stop_dma(prtd->dma_ch);
                                prtd->period_index = 0;
                                omap_start_dma(prtd->dma_ch);
                        }

@@ -191,6 +192,7 @@ static int omap_pcm_trigger(struct snd_pcm_substream
 *substream, int cmd)
        case SNDRV_PCM_TRIGGER_START:
        case SNDRV_PCM_TRIGGER_RESUME:
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+               omap_stop_dma(prtd->dma_ch);
                prtd->period_index = 0;
                omap_start_dma(prtd->dma_ch);

                break;

Thanks! The origial driver with commented out clk_enable(vc_clk) and clk_disable(vc_clk) still works for me, so MCLK is not required! If I only knew what to do with this finding...

Quoted 3 lines

Just hack the same "static struct omap_mcbsp_reg_cfg mcbsp_regs = { ..." in omap-mcbsp.c and pass that structure instead of &mcbsp_data->regs to omap_mcbsp_config in omap_mcbsp_dai_hw_params.

Done. Did not help. Again, I really don't know how to make use of this finding except for looking in a different place.

Thanks! The origial driver with commented out clk_enable(vc_clk) and clk_disable(vc_clk) still works for me, so MCLK is not required! If I only knew what to do with this finding...

Quoted 3 lines

Just hack the same "static struct omap_mcbsp_reg_cfg mcbsp_regs = { ..." in omap-mcbsp.c and pass that structure instead of &mcbsp_data->regs to omap_mcbsp_config in omap_mcbsp_dai_hw_params.

Done. Did not help. Again, I really don't know how to make use of this finding except for looking in a different place.

Optimize out one needless clock :-)

Ok, so looks that McBSP settings have nothing to do.

While I don't believe that call order has something to do on 1510 versus other omaps, it's easy to try by changing call order in arch/arm/plat-omap/dma.c: omap_set_dma_params.

Of course you could try to also copy transfer setup from audio_set_dma_params_play into omap_pcm_prepare... That should make the DMA setup same than older implementation.

Hopefully these speculations would help you to find out at least one DMA interrupt.

Optimize out one needless clock :-)

Ok, so looks that McBSP settings have nothing to do.

While I don't believe that call order has something to do on 1510 versus other omaps, it's easy to try by changing call order in arch/arm/plat-omap/dma.c: omap_set_dma_params.

Of course you could try to also copy transfer setup from audio_set_dma_params_play into omap_pcm_prepare... That should make the DMA setup same than older implementation.

Hopefully these speculations would help you to find out at least one DMA interrupt.

On the codec frame sync output, I can see ~10kHz symmetric square wave (filled by 50%), the same on modem frame sync input, mcbsp1 status unknown. This shape suggests I2S protocol, not DSP_B as we deduced from the original driver code.

Anyway, we still have at least two potential reasons for my driver not
working: wrong mcbsp clocks setup or broken mcbsp dma handling. My last idea was to create a generic test driver that would not use any external clocks, ie configured with OMAP_MCBSP_SYSCLK_CLK and SND_SOC_DAIFMT_CBS_CFS, right? That way, it should just work without any hardware support except for mcbsp and maybe we could then definitelly verify if current mcbsp and dma code works on omap1510 or not. Trying to select a template driver to base the test driver on, I felt into these troubles with more and more questions coming on mind. If you think my idea is worth of trying, could you please look at this and give me some hints?

Quoted 4 lines

On the codec frame sync output, I can see ~10kHz symmetric square wave (filled by 50%), the same on modem frame sync input, mcbsp1 status unknown. This shape suggests I2S protocol, not DSP_B as we deduced from the original driver code.

Not that this seems like an unreasonable conclusion but it's worth pointing out that the DSP modes only require the leading edge of the frame clock and that the falling edge can occur at any point before the next rising edge is due.

Quoted 8 lines

... My last
idea was to create a generic test driver that would not use any external clocks, ie configured with OMAP_MCBSP_SYSCLK_CLK and SND_SOC_DAIFMT_CBS_CFS, right? That way, it should just work without any hardware support except for mcbsp and maybe we could then definitelly verify if current mcbsp and dma code works on omap1510 or not. Trying to select a template driver to base the test driver on, I felt into these troubles with more and more questions coming on mind...

That approach is one I use all the time in driver development - isolate the device as much as possible and confirm that it can at least interoperate with itself.

Is it possible that the codec speeks I2S, with 8-bit word, 1 word per frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can read in modem documentation, this should rather be one 8-bit channel at 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope be matched against any format that mcbsp can be set with current code?

I'm still far from understanding mcbsp, but I wonder what happens if the bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this is the cause of dma interrupts not being generated?

Reviewing the code of different asoc omap drivers and mcbsp documentation again and again, several questions comes on mind, like:

1. What is the default setting for mcbsp master clock source? Assuming that default register bit values are 0, OMAP_MCBSP_SYSCLK_CLKS_EXT would be default for omap1, and there would be no default for others. Sources other than OMAP_MCBSP_SYSCLK_CLKS_EXT or OMAP_MCBSP_SYSCLK_CLKS_FCLK require setting of CLKSM and/or SCLKME to 1, and both OMAP_MCBSP_SYSCLK_CLKS_EXT and OMAP_MCBSP_SYSCLK_CLKS_FCLK require additional omap_ctrl_writel() calls on omap2 and higher. Am I missing anything?

2. Why omap asoc drivers, except for omap3pandora, do not call snd_soc_dai_set_sysclk(cpu_dai, ...)? Does it mean that osk9512 uses default OMAP_MCBSP_SYSCLK_CLKS_EXT? What does it mean for others without default?

Anyway, we still have at least two potential reasons for my driver not working: wrong mcbsp clocks setup or broken mcbsp dma handling. My last idea was to create a generic test driver that would not use any external clocks, ie configured with OMAP_MCBSP_SYSCLK_CLK and SND_SOC_DAIFMT_CBS_CFS, right? That way, it should just work without any hardware support except for mcbsp and maybe we could then definitelly verify if current mcbsp and dma code works on omap1510 or not. Trying to select a template driver to base the test driver on, I felt into these troubles with more and more questions coming on mind. If you think my idea is worth of trying, could you please look at this and give me some hints?

Reviewing the code of different asoc omap drivers and mcbsp documentation again and again, several questions comes on mind, like:

1. What is the default setting for mcbsp master clock source? Assuming that default register bit values are 0, OMAP_MCBSP_SYSCLK_CLKS_EXT would be default for omap1, and there would be no default for others. Sources other than OMAP_MCBSP_SYSCLK_CLKS_EXT or OMAP_MCBSP_SYSCLK_CLKS_FCLK require setting of CLKSM and/or SCLKME to 1, and both OMAP_MCBSP_SYSCLK_CLKS_EXT and OMAP_MCBSP_SYSCLK_CLKS_FCLK require additional omap_ctrl_writel() calls on omap2 and higher. Am I missing anything?

2. Why omap asoc drivers, except for omap3pandora, do not call snd_soc_dai_set_sysclk(cpu_dai, ...)? Does it mean that osk9512 uses default OMAP_MCBSP_SYSCLK_CLKS_EXT? What does it mean for others without default?

Anyway, we still have at least two potential reasons for my driver not working: wrong mcbsp clocks setup or broken mcbsp dma handling. My last idea was to create a generic test driver that would not use any external clocks, ie configured with OMAP_MCBSP_SYSCLK_CLK and SND_SOC_DAIFMT_CBS_CFS, right? That way, it should just work without any hardware support except for mcbsp and maybe we could then definitelly verify if current mcbsp and dma code works on omap1510 or not. Trying to select a template driver to base the test driver on, I felt into these troubles with more and more questions coming on mind. If you think my idea is worth of trying, could you please look at this and give me some hints?

I'm not sure how that could happen, but I was wrong with some of those figures. After looking at the scope several more times I can only confirm that master clock really runs at 2MHz (0,5µs period). Frame sync is rather closer to 8kHz (~125µs period) than previously estimated 10kHz, with the same symmetric (50% fill) shape as before. But bit clock is very different from what I have seen before. It runs at 2MHz in 9µs long packets (18 periods), those are repeated every half period of frame sync (~62µs / 16kHz), ie every frame sync edge, both rising and falling. There is also a signal present on codec data output: 4µs long packets (8 bits each?) every ~62µs (16 kHz).

Is it possible that the codec speeks I2S, with 8-bit word, 1 word per frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can read in modem documentation, this should rather be one 8-bit channel at 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope be matched against any format that mcbsp can be set with current code?

I'm still far from understanding mcbsp, but I wonder what happens if the bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this is the cause of dma interrupts not being generated?

Quoted 7 lines · On Sat, 6 Jun 2009 00:28:00 +0200 Janusz Krzysztofik <[email protected]>…

My last idea was to create a generic test driver that would not use any external clocks, ie configured with OMAP_MCBSP_SYSCLK_CLK and SND_SOC_DAIFMT_CBS_CFS, right? That way, it should just work without any hardware support except for mcbsp and maybe we could then definitelly verify if current mcbsp and dma code works on omap1510 or not.

This could be a bit risky and can damage your HW since both OMAP and codec are then driving the bit-clock and FS signals but you could try to configure McBSP as a master and use the internal clock source as its input.

Basically it goes with current driver by passing SND_SOC_DAIFMT_CBS_CFS to snd_soc_dai_set_fmt(cpu_dai, ...) and by setting SRG source clock and divider:

snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLK, ...); snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, divider);

Quoted 7 lines · On Sat, 6 Jun 2009 00:28:00 +0200 Janusz Krzysztofik <[email protected]>…

My last idea was to create a generic test driver that would not use any external clocks, ie configured with OMAP_MCBSP_SYSCLK_CLK and SND_SOC_DAIFMT_CBS_CFS, right? That way, it should just work without any hardware support except for mcbsp and maybe we could then definitelly verify if current mcbsp and dma code works on omap1510 or not.

This could be a bit risky and can damage your HW since both OMAP and codec are then driving the bit-clock and FS signals but you could try to configure McBSP as a master and use the internal clock source as its input.

Basically it goes with current driver by passing SND_SOC_DAIFMT_CBS_CFS to snd_soc_dai_set_fmt(cpu_dai, ...) and by setting SRG source clock and divider:

snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLK, ...); snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, divider);

I'm kind of bad at visualizing things, is it possible to put somewhere the screenshoot of the scope showing at least one sample?

I have been looking for clues around the net, and it seams that the codec in question has stereo 16 bit format.

sound/soc/omap/omap-pcm.c +4 -0

@@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct snd_pcm_substream 
 *substream, int cmd)
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
                prtd->period_index = 0;
                omap_start_dma(prtd->dma_ch);
+               printk("omap_pcm_trigger START: DMA pointer at 0x%08x\n",
+                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
                break;
 
        case SNDRV_PCM_TRIGGER_STOP:
        case SNDRV_PCM_TRIGGER_SUSPEND:
        case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+               printk("omap_pcm_trigger STOP: DMA pointer at 0x%08x\n",
+                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
                prtd->period_index = -1;
                omap_stop_dma(prtd->dma_ch);

                break;

Than start a playback, and stop it with CTRL+C, see if the two pointers are different...

2) I would I think try to port the 2.6.28 pure ALSA version to the head of l- o, with minimal (only the needed) changes and see if it is still working.

Quoted 2 lines · Peter Ujfalusi

I'm kind of bad at visualizing things, is it possible to put somewhere the screenshoot of the scope showing at least one sample?

Good idea. I'll take some screenshots for future reference and let you know when available.

Quoted 2 lines

I have been looking for clues around the net, and it seams that the codec in question has stereo 16 bit format.

From the very minimal mcbsp setup I get best audio experience with
(using original omap-alsa based driver - see below), it looks like the codec speeks DSP (single phase), 16-bit mono @8kHz on output, but 8-bit stereo @8kHz on input. Capturing one channel only (the first one) I can't hear myself speaking, so audio from the microphone must be sent over the second input channel.

(quoted diff) +8 -0

+static struct omap_mcbsp_reg_cfg mcbsp_regs = {
+       .spcr2 = FREE | XINTM(3) | XRST,
+       .spcr1 = RINTM(3) | RRST,
+       .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
+       .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
+};
 
 
+static snd_pcm_hardware_t vc_snd_omap_alsa_playback = {
+       .info = (SNDRV_PCM_INFO_INTERLEAVED |

SNDRV_PCM_INFO_BLOCK_TRANSFER |

(quoted diff) +18 -0

+                SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
+       .formats = (SNDRV_PCM_FMTBIT_S16_LE),
+       .rates = (SNDRV_PCM_RATE_8000 |
+                 SNDRV_PCM_RATE_KNOT),
+       .rate_min = 8000,
+       .rate_max = 8000,
+       .channels_min = 1,
+       .channels_max = 1,
+       .buffer_bytes_max = 128 * 1024,
+       .period_bytes_min = 32,
+       .period_bytes_max = 8 * 1024,
+       .periods_min = 16,
+       .periods_max = 255,
+       .fifo_size = 0,
+};
+
+static snd_pcm_hardware_t vc_snd_omap_alsa_capture = {
+       .info = (SNDRV_PCM_INFO_INTERLEAVED |

SNDRV_PCM_INFO_BLOCK_TRANSFER |

(quoted diff) +15 -0

+                SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
+       .formats = (SNDRV_PCM_FMTBIT_U8),
+       .rates = (SNDRV_PCM_RATE_8000 |
+                 SNDRV_PCM_RATE_KNOT),
+       .rate_min = 8000,
+       .rate_max = 8000,
+       .channels_min = 2,
+       .channels_max = 2,
+       .buffer_bytes_max = 128 * 1024,
+       .period_bytes_min = 32,
+       .period_bytes_max = 8 * 1024,
+       .periods_min = 16,
+       .periods_max = 255,
+       .fifo_size = 0,
+};

For other combinations of single/dual phase, sample size, mono/stereo, sound I get is much more distorted. Playing with polarisation and delays for getting still better experience remains on my todo list.

BTW, I can't see any way of specifying a similiar mcbsp setup in new omap asoc framework.

--------------

Quoted 21 lines

sound/soc/omap/omap-pcm.c +4 -0

@@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct
 snd_pcm_substream *substream, int cmd)
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
                prtd->period_index = 0;
                omap_start_dma(prtd->dma_ch);
+               printk("omap_pcm_trigger START: DMA pointer at 0x%08x\n",
+                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
                break;
 
        case SNDRV_PCM_TRIGGER_STOP:
        case SNDRV_PCM_TRIGGER_SUSPEND:
        case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+               printk("omap_pcm_trigger STOP: DMA pointer at 0x%08x\n",
+                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
                prtd->period_index = -1;
                omap_stop_dma(prtd->dma_ch);

                break;

Quoted 2 lines

Than start a playback, and stop it with CTRL+C, see if the two pointers are different...

Both playback and capture start with their own but always the same value (something like 0x1101a0d0 for playback, 0xe101a0d0 for capture), and always stop with this value unchanged.

Quoted 4 lines

2) I would I think try to port the 2.6.28 pure ALSA version to the head of l- o, with minimal (only the needed) changes and see if it is still working.

Trying to use the new driver on the last l-o revision supporting both omap-alsa and omap asoc, I got a broken system that hanged up completely at sound device first access. The same for earlier and later l-o revisions I have ever tried, unlike mainline that at least does not hang. From all that I would conclude that porting the old driver could be just waste of time, as the problem is probably omap asoc related, not just omap, probably existed from the start of omap asoc life, and could be solved on any l-o or mainline revision, including those eariler l-o that supported both frameworks. But I can be wrong, of course.

Quoted 7 lines

(quoted diff) +6 -0

+static struct omap_mcbsp_reg_cfg mcbsp_regs = {
+       .spcr2 = FREE | XINTM(3) | XRST,
+       .spcr1 = RINTM(3) | RRST,
+       .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
+       .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
+};

Quoted 2 lines

BTW, I can't see any way of specifying a similiar mcbsp setup in new omap asoc framework.

Yeah, 8 bit is not supported - in fact only 16 bit is supported - with ASoC on OMAP.

But you should be able to use the playback with the current ASoC.

arch/arm/plat-omap/dma.c +2 -0

@@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int
 data_type, int elem_count,
                ccr &= ~(1 << 5);
                if (sync_mode == OMAP_DMA_SYNC_FRAME)
                        ccr |= 1 << 5;
+               if (dma_trigger)
+                       ccr |= dma_trigger & 0x1f;
                dma_write(ccr, CCR(lch));
 

                ccr = dma_read(CCR2(lch));

I would expected that by just copying (I know that there are other things involved) the old ALSA arm directory to the latest kernel and compiling it should be working... It seams I was wrong.

Quoted 7 lines

(quoted diff) +6 -0

+static struct omap_mcbsp_reg_cfg mcbsp_regs = {
+       .spcr2 = FREE | XINTM(3) | XRST,
+       .spcr1 = RINTM(3) | RRST,
+       .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
+       .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
+};

Quoted 2 lines

BTW, I can't see any way of specifying a similiar mcbsp setup in new omap asoc framework.

Yeah, 8 bit is not supported - in fact only 16 bit is supported - with ASoC on OMAP.

But you should be able to use the playback with the current ASoC.

arch/arm/plat-omap/dma.c +2 -0

@@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int
 data_type, int elem_count,
                ccr &= ~(1 << 5);
                if (sync_mode == OMAP_DMA_SYNC_FRAME)
                        ccr |= 1 << 5;
+               if (dma_trigger)
+                       ccr |= dma_trigger & 0x1f;
                dma_write(ccr, CCR(lch));
 

                ccr = dma_read(CCR2(lch));

I would expected that by just copying (I know that there are other things involved) the old ALSA arm directory to the latest kernel and compiling it should be working... It seams I was wrong.

Not only this. AFAICS, there is no way of specifying single phase stereo (with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)). Isn't this required for correct DSP_A/DSP_B support?

Quoted 2 lines

But you should be able to use the playback with the current ASoC.

Definitelly yes. I am aware that the above limitations have nothing to do with the main problem, as with current mcbsp code I should always be able to get some kind of noise at least using one of supported formats, as far as clocking is set up correctly.

Quoted 11 lines

arch/arm/plat-omap/dma.c +2 -0

@@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int
 data_type, int elem_count,
                ccr &= ~(1 << 5);
                if (sync_mode == OMAP_DMA_SYNC_FRAME)
                        ccr |= 1 << 5;
+               if (dma_trigger)
+                       ccr |= dma_trigger & 0x1f;
                dma_write(ccr, CCR(lch));
 

Quoted 1 line

                ccr = dma_read(CCR2(lch));

Applied, sorry, did not help (with capture, unlike playback, set up for internal clocking for as much device isolation as possible).

Quoted 4 lines

I would expected that by just copying (I know that there are other things involved) the old ALSA arm directory to the latest kernel and compiling it should be working... It seams I was wrong.

Anyway, if you find porting one or another framework, back or forward, helpfull in any way, just let me know, I can try.

Thanks,
Janusz

Not only this. AFAICS, there is no way of specifying single phase stereo (with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)). Isn't this required for correct DSP_A/DSP_B support?

Quoted 2 lines

But you should be able to use the playback with the current ASoC.

Definitelly yes. I am aware that the above limitations have nothing to do with the main problem, as with current mcbsp code I should always be able to get some kind of noise at least using one of supported formats, as far as clocking is set up correctly.

Quoted 11 lines

arch/arm/plat-omap/dma.c +2 -0

@@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int
 data_type, int elem_count,
                ccr &= ~(1 << 5);
                if (sync_mode == OMAP_DMA_SYNC_FRAME)
                        ccr |= 1 << 5;
+               if (dma_trigger)
+                       ccr |= dma_trigger & 0x1f;
                dma_write(ccr, CCR(lch));
 

Quoted 1 line

                ccr = dma_read(CCR2(lch));

Applied, sorry, did not help (with capture, unlike playback, set up for internal clocking for as much device isolation as possible).

Quoted 4 lines

I would expected that by just copying (I know that there are other things involved) the old ALSA arm directory to the latest kernel and compiling it should be working... It seams I was wrong.

Anyway, if you find porting one or another framework, back or forward, helpfull in any way, just let me know, I can try.

Thanks,
Janusz

Quoted 3 lines · On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote:

Not only this. AFAICS, there is no way of specifying single phase stereo (with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)). Isn't this required for correct DSP_A/DSP_B support?

Sure it is possible:

	format = mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK;
	wpf = channels = params_channels(params);
	switch (channels) {
	case 2:
		if (format == SND_SOC_DAIFMT_I2S) {
			/* Use dual-phase frames */
			regs->rcr2	|= RPHASE;
			regs->xcr2	|= XPHASE;
			/* Set 1 word per (McBSP) frame for phase1 and phase2 */
			wpf--;
			regs->rcr2	|= RFRLEN2(wpf - 1);
			regs->xcr2	|= XFRLEN2(wpf - 1);
		}
	case 1:
	case 4:
		/* Set word per (McBSP) frame for phase1 */
		regs->rcr1	|= RFRLEN1(wpf - 1);
		regs->xcr1	|= XFRLEN1(wpf - 1);
		break;
	default:
		/* Unsupported number of channels */
		return -EINVAL;
	}

wpf = channels == 2, format is not I2S --> RFRLEN1(wpf - 1), XFRLEN1(wpf - 1), RFRLEN1(2 - 1), XFRLEN1(2 - 1)

Quoted 3 lines · On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote:

Not only this. AFAICS, there is no way of specifying single phase stereo (with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)). Isn't this required for correct DSP_A/DSP_B support?

Sure it is possible:

	format = mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK;
	wpf = channels = params_channels(params);
	switch (channels) {
	case 2:
		if (format == SND_SOC_DAIFMT_I2S) {
			/* Use dual-phase frames */
			regs->rcr2	|= RPHASE;
			regs->xcr2	|= XPHASE;
			/* Set 1 word per (McBSP) frame for phase1 and phase2 */
			wpf--;
			regs->rcr2	|= RFRLEN2(wpf - 1);
			regs->xcr2	|= XFRLEN2(wpf - 1);
		}
	case 1:
	case 4:
		/* Set word per (McBSP) frame for phase1 */
		regs->rcr1	|= RFRLEN1(wpf - 1);
		regs->xcr1	|= XFRLEN1(wpf - 1);
		break;
	default:
		/* Unsupported number of channels */
		return -EINVAL;
	}

wpf = channels == 2, format is not I2S --> RFRLEN1(wpf - 1), XFRLEN1(wpf - 1), RFRLEN1(2 - 1), XFRLEN1(2 - 1)

Quoted 2 lines · Peter Ujfalusi

I'm kind of bad at visualizing things, is it possible to put somewhere the screenshoot of the scope showing at least one sample?

Good idea. I'll take some screenshots for future reference and let you know when available.

Quoted 1 line · Peter Ujfalusi

I'm kind of bad at visualizing things, is it possible to put somewhere the screenshoot of the scope showing at least one sample?

Good idea. I'll take some screenshots for future reference and let you know when available.

Just out of curiosity, can you try this one as well:

sound/soc/omap/omap-mcbsp.c +1 -0

@@ -191,6 +191,7 @@ static int omap_mcbsp_dai_trigger(struct
 snd_pcm_substream *substream, int cmd,
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
                if (!mcbsp_data->active++)
                        omap_mcbsp_start(mcbsp_data->bus_id);
+               omap_mcbsp_pollwrite(mcbsp_data->bus_id, 0xdb55);
                break;
 

basically write 0xdb55 to the DXR1 register (0xdb55 is 1101101101010101) With this, if McBSP is operating correctly you should be seeing this pattern going to the codec.

If it does, than we have some problems with the
McBSP/DMA cooperation, if this pattern is not seen on the bus, than the McBSP is not shifting data out for some reason.

Just out of curiosity, can you try this one as well:

sound/soc/omap/omap-mcbsp.c +1 -0

@@ -191,6 +191,7 @@ static int omap_mcbsp_dai_trigger(struct
 snd_pcm_substream *substream, int cmd,
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
                if (!mcbsp_data->active++)
                        omap_mcbsp_start(mcbsp_data->bus_id);
+               omap_mcbsp_pollwrite(mcbsp_data->bus_id, 0xdb55);
                break;
 

basically write 0xdb55 to the DXR1 register (0xdb55 is 1101101101010101) With this, if McBSP is operating correctly you should be seeing this pattern going to the codec.

If it does, than we have some problems with the
McBSP/DMA cooperation, if this pattern is not seen on the bus, than the McBSP is not shifting data out for some reason.

Important or not, I have to fine down my provious reports on what works and what does not:

- original patch applied with other ams-delta related patches on linux-omap-2.6.16, as it was designed for:
- playback: works, with both aplay and >/dev/dsp,
- capture: works with </dev/dsp, gives null output with arecord

- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.

Important or not, I have to fine down my provious reports on what works and what does not:

- original patch applied with other ams-delta related patches on linux-omap-2.6.16, as it was designed for:
- playback: works, with both aplay and >/dev/dsp,
- capture: works with </dev/dsp, gives null output with arecord

- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.

Quoted 4 lines

- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.

Not that I would see it as a real progress, but to clarify things: I have managed to solve this particular problem with capture by patching sound/arm/omap/omap-alsa.c (call omap_get_dma_dst_pos() instead of omap_get_dma_src_pos() from audio_get_dma_pos() in case of (stream_id == SNDRV_PCM_STREAM_CAPTURE)). The original code stopped working after changes introduced to omap_get_dma_src_pos() with this
patch: http://marc.info/?l=linux-omap&m=121280267705523.

Quoted 4 lines

- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.

Not that I would see it as a real progress, but to clarify things: I have managed to solve this particular problem with capture by patching sound/arm/omap/omap-alsa.c (call omap_get_dma_dst_pos() instead of omap_get_dma_src_pos() from audio_get_dma_pos() in case of (stream_id == SNDRV_PCM_STREAM_CAPTURE)). The original code stopped working after changes introduced to omap_get_dma_src_pos() with this
patch: http://marc.info/?l=linux-omap&m=121280267705523.

Quoted 4 lines · On Mon, 15 Jun 2009 15:22:34 +0200 Janusz Krzysztofik <[email protected]>…

Quoted 4 lines

- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.

Quoted 8 lines

Not that I would see it as a real progress, but to clarify things: I have managed to solve this particular problem with capture by patching sound/arm/omap/omap-alsa.c (call omap_get_dma_dst_pos() instead of omap_get_dma_src_pos() from audio_get_dma_pos() in case of (stream_id == SNDRV_PCM_STREAM_CAPTURE)). The original code stopped working after changes introduced to omap_get_dma_src_pos() with this
patch: http://marc.info/?l=linux-omap&m=121280267705523.

Nice step forward. From quick look of the patch I see that patch is changing how the source and destination positions are read for omap1.

While I don't have idea can this explain the ceased DMA in 1510 but will the playback in original code work again if you change line "offset = dma_read (CPC(lch));" to "offset = dma_read(CSSA_L(lch));" in omap_get_dma_src_pos? Or read both CSSA_L and CSSA_U at once like code before?

Quoted 11 lines · On Mon, 15 Jun 2009 15:22:34 +0200 Janusz Krzysztofik <[email protected]>…

Quoted 4 lines

- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.

Not that I would see it as a real progress, but to clarify things: I have managed to solve this particular problem with capture by patching sound/arm/omap/omap-alsa.c (call omap_get_dma_dst_pos()
instead of omap_get_dma_src_pos() from audio_get_dma_pos() in case of
(stream_id == SNDRV_PCM_STREAM_CAPTURE)). The original code stopped
working after changes introduced to omap_get_dma_src_pos() with this
patch: http://marc.info/?l=linux-omap&m=121280267705523.

Nice step forward. From quick look of the patch I see that patch is changing how the source and destination positions are read for omap1.

While I don't have idea can this explain the ceased DMA in 1510 but will the playback in original code work again if you change line "offset = dma_read (CPC(lch));" to "offset = dma_read(CSSA_L(lch));" in omap_get_dma_src_pos? Or read both CSSA_L and CSSA_U at once like code before?

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.

I can confirm that the old driver can set up mcbsp in a way that keeps it shifting the contents of its input register, loaded with a pattern using omap_mcbsp_pollwrite() as Peter suggested, even if I break dma by commenting out all omap_start_dma() invocations. I have verified this by detecting averaged voltage level changes on the codec input pin with a simple multimeter (I still have not get access to a scope back).

Using the new driver, I am not able to detect similiar voltage changes, whatever I do to get the mcbsp sending data to the codec over its serial output. I have modified omap-mcbsp code with a hacked in probe hook that initializes mcbsp at boot time exactly as the old driver does it - no results.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.

I can confirm that the old driver can set up mcbsp in a way that keeps it shifting the contents of its input register, loaded with a pattern using omap_mcbsp_pollwrite() as Peter suggested, even if I break dma by commenting out all omap_start_dma() invocations. I have verified this by detecting averaged voltage level changes on the codec input pin with a simple multimeter (I still have not get access to a scope back).

Using the new driver, I am not able to detect similiar voltage changes, whatever I do to get the mcbsp sending data to the codec over its serial output. I have modified omap-mcbsp code with a hacked in probe hook that initializes mcbsp at boot time exactly as the old driver does it - no results.

Quoted 11 lines · On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote:

Quoted 2 lines · Janusz Krzysztofik

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on.

Hmmm, this is quite unexpected.
Can you access to mcbsp2 or 3 registers, or only the mcbsp1 registers are not accessible?
One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510).
I have to check it further what this actually means...

Quoted 2 lines · Janusz Krzysztofik

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on.

Thanks,
Janusz

Quoted 2 lines · Janusz Krzysztofik

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on.

Thanks,
Janusz

Quoted 11 lines · On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote:

Quoted 2 lines · Janusz Krzysztofik

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on.

Hmmm, this is quite unexpected.
Can you access to mcbsp2 or 3 registers, or only the mcbsp1 registers are not accessible?
One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510).
I have to check it further what this actually means...

Quoted 20 lines · Tony Lindgren

Quoted 18 lines · Peter Ujfalusi

Quoted 10 lines · On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote:

Quoted 2 lines · Janusz Krzysztofik

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on.

Hmmm, this is quite unexpected.
Can you access to mcbsp2 or 3 registers, or only the mcbsp1 registers are not accessible?
One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510).
I have to check it further what this actually means...

Quoted 4 lines

Hmmm, do you have the DSP code compiled (and loaded)?

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all. For several weeks I was trying to do what was impossible :/. But fortunatelly, I have learned a lot ;).

Hmm, recall, did you try hacking the ASoC driver at the same commit d8376cc482b241701f7606c81ad578b90853e175 where older driver still exists and works? There has been ASoC OMAP fixes and changes since then but nothing which can explain why it doesn't work now for 1510.

There we would know that clock framework, register access etc. works for McBSP on 1510.

Hmm, recall, did you try hacking the ASoC driver at the same commit d8376cc482b241701f7606c81ad578b90853e175 where older driver still exists and works? There has been ASoC OMAP fixes and changes since then but nothing which can explain why it doesn't work now for 1510.

There we would know that clock framework, register access etc. works for McBSP on 1510.

Quoted 11 lines · Peter Ujfalusi

Quoted 10 lines · On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote:

Quoted 2 lines · Janusz Krzysztofik

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on.

Quoted 7 lines

Hmmm, this is quite unexpected.
Can you access to mcbsp2 or 3 registers, or only the mcbsp1 registers are not accessible?
One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510).
I have to check it further what this actually means...

Hmmm, do you have the DSP code compiled (and loaded)?

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

Quoted 11 lines · Peter Ujfalusi

Quoted 10 lines · On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote:

Quoted 2 lines · Janusz Krzysztofik

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on.

Quoted 4 lines

Hmmm, this is quite unexpected.
Can you access to mcbsp2 or 3 registers, or only the mcbsp1 registers are not accessible?
One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510). I have to check it further what this actually means...

Hmmm, do you have the DSP code compiled (and loaded)?

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

Quoted 20 lines · Tony Lindgren

Quoted 18 lines · Peter Ujfalusi

Quoted 10 lines · On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote:

Quoted 2 lines · Janusz Krzysztofik

After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.

I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on.

Hmmm, this is quite unexpected.
Can you access to mcbsp2 or 3 registers, or only the mcbsp1 registers are not accessible?
One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510).
I have to check it further what this actually means...

Quoted 4 lines

Hmmm, do you have the DSP code compiled (and loaded)?

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all. For several weeks I was trying to do what was impossible :/. But fortunatelly, I have learned a lot ;).

Quoted 6 lines · Jarkko Nikula

Hmm, recall, did you try hacking the ASoC driver at the same commit d8376cc482b241701f7606c81ad578b90853e175 where older driver still exists and works? There has been ASoC OMAP fixes and changes since then but nothing which can explain why it doesn't work now for 1510.

Quoted 2 lines

There we would know that clock framework, register access etc. works for McBSP on 1510.

Yes, after realizing that possible lack of OMAP1510 McBSP1/3 / DSP support in the mainline tree could be the reason of my problem, I got back to omap tree. First I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen hangup. I found that it was omap_mcbsp_request() never returning back from.

Then I retired the same on the commit d8376cc482b241701f7606c81ad578b90853e175 and got similiar hangup. Next, I moved mcbsp initialization to a boot time hook and finally heard a sound and got my first DMA interrupt!

So it seams I have finally managed to take all necessary steps back, and now I can go forward, I hope :).

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

Quoted 6 lines · Jarkko Nikula

Hmm, recall, did you try hacking the ASoC driver at the same commit d8376cc482b241701f7606c81ad578b90853e175 where older driver still exists and works? There has been ASoC OMAP fixes and changes since then but nothing which can explain why it doesn't work now for 1510.

Quoted 2 lines

There we would know that clock framework, register access etc. works for McBSP on 1510.

Yes, after realizing that possible lack of OMAP1510 McBSP1/3 / DSP support in the mainline tree could be the reason of my problem, I got back to omap tree. First I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen hangup. I found that it was omap_mcbsp_request() never returning back from.

Then I retired the same on the commit d8376cc482b241701f7606c81ad578b90853e175 and got similiar hangup. Next, I moved mcbsp initialization to a boot time hook and finally heard a sound and got my first DMA interrupt!

So it seams I have finally managed to take all necessary steps back, and now I can go forward, I hope :).

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

Quoted 6 lines · Janusz Krzysztofik

Quoted 2 lines · Tony Lindgren

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all. For several weeks I was trying to do what was impossible :/. But fortunatelly, I have learned a lot ;).

We at least used to have code to power and idle the DSP even without the dspgateway compiled in.. Sorry I don't remember the details. But most likely you need to have the dspgateway patch enabled.

Quoted 3 lines · Janusz Krzysztofik

... I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen hangup. I found that it was omap_mcbsp_request() never returning back from.

I faced the same issue while writing ASoC driver for tlv320aic23b codec.

You can have a look at this thread:
http://www.mail-archive.com/[email protected]/msg03852.html

It may help.

Quoted 4 lines · Janusz Krzysztofik

Quoted 2 lines · Tony Lindgren

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all. For several weeks I was trying to do what was impossible :/. But fortunatelly, I have learned a lot ;).

We at least used to have code to power and idle the DSP even without the dspgateway compiled in.. Sorry I don't remember the details. But most likely you need to have the dspgateway patch enabled.

Quoted 3 lines · Janusz Krzysztofik

... I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen hangup. I found that it was omap_mcbsp_request() never returning back from.

I faced the same issue while writing ASoC driver for tlv320aic23b codec.

You can have a look at this thread:
http://www.mail-archive.com/[email protected]/msg03852.html

It may help.

Quoted 8 lines · Tony Lindgren

Quoted 6 lines · Janusz Krzysztofik

Quoted 3 lines · Tony Lindgren

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

Quoted 7 lines

Quoted 3 lines

AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all. For several weeks I was trying to do what was impossible :/. But fortunatelly, I have learned a lot ;).

We at least used to have code to power and idle the DSP even without the dspgateway compiled in.. Sorry I don't remember the details. But most likely you need to have the dspgateway patch enabled.

Tony,
Thanks for clarifying things.

Quoted 15 lines · Arun K S

Quoted 6 lines · Janusz Krzysztofik

... I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen
hangup. I found that it was omap_mcbsp_request() never returning back from.

I faced the same issue while writing ASoC driver for tlv320aic23b codec.

You can have a look at this thread:
http://www.mail-archive.com/[email protected]/msg03852.html

Quoted 1 line

It may help.

Arun,
Thanks, it's good to hear not only me having this problem ;). So what is the current status of your osk driver? What tree do you use, what extra patches do you apply to make it actually working?

---------------------------

After all, could someone please give me an advise, what tree, even with buggy omap1510 mcbsp/dsp support, should I base my work on for best results? Omap? Sound? Mainline? I mean not only easy getting the driver working, but also giving it the best possible path into the mainline.

Thanks,
Janusz

Quoted 8 lines · Tony Lindgren

Quoted 6 lines · Janusz Krzysztofik

Quoted 3 lines · Tony Lindgren

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

Quoted 7 lines

Quoted 3 lines

AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all. For several weeks I was trying to do what was impossible :/. But fortunatelly, I have learned a lot ;).

We at least used to have code to power and idle the DSP even without the dspgateway compiled in.. Sorry I don't remember the details. But most likely you need to have the dspgateway patch enabled.

Tony,
Thanks for clarifying things.

Quoted 15 lines · Arun K S

Quoted 6 lines · Janusz Krzysztofik

... I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen
hangup. I found that it was omap_mcbsp_request() never returning back from.

I faced the same issue while writing ASoC driver for tlv320aic23b codec.

You can have a look at this thread:
http://www.mail-archive.com/[email protected]/msg03852.html

Quoted 1 line

It may help.

Arun,
Thanks, it's good to hear not only me having this problem ;). So what is the current status of your osk driver? What tree do you use, what extra patches do you apply to make it actually working?

---------------------------

After all, could someone please give me an advise, what tree, even with buggy omap1510 mcbsp/dsp support, should I base my work on for best results? Omap? Sound? Mainline? I mean not only easy getting the driver working, but also giving it the best possible path into the mainline.

Thanks,
Janusz

Then I retired the same on the commit d8376cc482b241701f7606c81ad578b90853e175 and got similiar hangup. Next, I moved mcbsp initialization to a boot time hook and finally heard a sound and got my first DMA interrupt!

Then I retired the same on the commit d8376cc482b241701f7606c81ad578b90853e175 and got similiar hangup. Next, I moved mcbsp initialization to a boot time hook and finally heard a sound and got my first DMA interrupt!

Quoted 2 lines · Janusz Krzysztofik

After all, could someone please give me an advise, what tree, even with buggy omap1510 mcbsp/dsp support, should I base my work on for best results?

You have to use current omap tree with the patches from current sound tree(ASoC omap platform drivers changes) for
testing the driver.

Quoted 8 lines · Janusz Krzysztofik

Quoted 7 lines · Arun K S

Quoted 5 lines · Janusz Krzysztofik

... I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen
hangup. I found that it was omap_mcbsp_request() never returning back from.

Quoted 4 lines

Quoted 4 lines

I faced the same issue while writing ASoC driver for tlv320aic23b codec.

You can have a look at this thread:
http://www.mail-archive.com/[email protected]/msg03852.html

Initially i used to add the omap_mcbsp_request()
at the boot time, other wise it hangs up. ...
I believe there are some patches from Russel
for the DSP memory mapping during
2.6.29 kernel.

Quoted 2 lines · On Thu, 18 Jun 2009 13:40:56 +0200 Janusz Krzysztofik <[email protected]>…

Then I retired the same on the commit d8376cc482b241701f7606c81ad578b90853e175 and got similiar hangup.

Can you move this boot time initialization moment around with xxx_initcall variants to see what is the point where block is not anymore accessable? Basically around the DSP power up and idle code (were there such code for older audio drivers?) and where unused clocks are disabled (functions clk_disable_unused and omap1_clk_disable_unused).

Quoted 12 lines · Janusz Krzysztofik

Quoted 11 lines · Tony Lindgren

Quoted 9 lines · Peter Ujfalusi

Quoted 5 lines · On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote:

Quoted 1 line · Janusz Krzysztofik

... got the answer from

omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all.

One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510).

Quoted 4 lines

Quoted 2 lines

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all.

We at least used to have code to power and idle the DSP even without the dspgateway compiled in.. Sorry I don't remember the details. But most likely you need to have the dspgateway patch enabled.

Quoted 2 lines · Janusz Krzysztofik

After all, could someone please give me an advise, what tree, even with buggy omap1510 mcbsp/dsp support, should I base my work on for best results?

You have to use current omap tree with the patches from current sound tree(ASoC omap platform drivers changes) for
testing the driver.

Quoted 8 lines · Janusz Krzysztofik

Quoted 7 lines · Arun K S

Quoted 5 lines · Janusz Krzysztofik

... I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen
hangup. I found that it was omap_mcbsp_request() never returning back from.

Quoted 4 lines

Quoted 4 lines

I faced the same issue while writing ASoC driver for tlv320aic23b codec.

You can have a look at this thread:
http://www.mail-archive.com/[email protected]/msg03852.html

Initially i used to add the omap_mcbsp_request()
at the boot time, other wise it hangs up. ...
I believe there are some patches from Russel
for the DSP memory mapping during
2.6.29 kernel.

Quoted 1 line · On Thu, 18 Jun 2009 13:40:56 +0200 Janusz Krzysztofik <[email protected]>…

Then I retired the same on the commit d8376cc482b241701f7606c81ad578b90853e175 and got similiar hangup.

Can you move this boot time initialization moment around with xxx_initcall variants to see what is the point where block is not anymore accessable? Basically around the DSP power up and idle code (were there such code for older audio drivers?) and where unused clocks are disabled (functions clk_disable_unused and omap1_clk_disable_unused).

Quoted 10 lines · Janusz Krzysztofik

Quoted 9 lines · Tony Lindgren

Quoted 7 lines · Peter Ujfalusi

Quoted 5 lines · On Wednesday 17 June 2009 17:12:38 ext Janusz Krzysztofik wrote:

Quoted 1 line · Janusz Krzysztofik

... got the answer from

omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0xffff. So it looks like I simply get no acccess to mcbsp1 at all.

One thing that I have noticed is that the McBSP1 (and 3) is under the DSP Public Peripherals, while McBSP2 is under MPU Public Peripherals (in OMAP1510).

Quoted 3 lines

Quoted 2 lines

On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up.

AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all.

We at least used to have code to power and idle the DSP even without the dspgateway compiled in.. Sorry I don't remember the details. But most likely you need to have the dspgateway patch enabled.