Janusz Krzysztofik wrote:

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

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.

Jarkko Nikula wrote:

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.

Peter Ujfalusi wrote:

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.

My port of the original driver is still very generic. There are no mux setups. It containes only two simple hardware pin setup calls that make it working, those are invoked from two callback functions, omap_alsa_codec_config.codec_clock_on() and omap_alsa_codec_config.codec_clock_off(), as below:

----------------------------------- int vc_clock_on(void) { if (clk_get_usecount(vc_mclk) > 0) { /* MCLK is already in use */ printk(KERN_WARNING "MCLK in use at %d Hz. We change it to %d Hz\n", (uint) clk_get_rate(vc_mclk), CODEC_CLOCK); } clk_enable(vc_mclk);

printk(KERN_DEBUG "MCLK = %d [%d], usecount = %d\n", (uint) clk_get_rate(vc_mclk), CODEC_CLOCK, clk_get_usecount(vc_mclk));

/* Now turn the audio on */ ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH2_MODEM_NRESET); return 0; }

int vc_clock_off(void) { if (clk_get_usecount(vc_mclk) > 0) { if (clk_get_rate(vc_mclk) != CODEC_CLOCK) { printk(KERN_WARNING "MCLK for audio should be %d Hz. But is %d Hz\n", (uint) clk_get_rate(vc_mclk), CODEC_CLOCK); }

clk_disable(vc_mclk); }

ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH2_MODEM_CODEC); return 0; } ... static int __init snd_omap_alsa_vc_probe(struct platform_device *pdev) { ... struct omap_alsa_codec_config *codec_cfg; ... codec_cfg->codec_clock_on = vc_clock_on; codec_cfg->codec_clock_off = vc_clock_off; ... }

static struct platform_driver omap_alsa_driver = { .probe = snd_omap_alsa_vc_probe, ... };

static int __init omap_alsa_vc_init(void) { int err;

err = platform_driver_register(&omap_alsa_driver); return err; } ----------------------------------

Jarkko Nikula wrote:

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.

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?

---------------------------------- diff -uprN linux-2.6.27/sound/arm/omap/omap-alsa.c linux-2.6.27-sound/sound/arm/omap/omap-alsa.c --- linux-2.6.27/sound/arm/omap/omap-alsa.c 2009-05-30 21:27:09.000000000 +0000 +++ linux-2.6.27-sound/sound/arm/omap/omap-alsa.c 2009-05-30 22:12:12.000000000 +0000 @@ -52,6 +52,8 @@ #include <mach/omap-alsa.h> #include "omap-alsa-dma.h"

+#include <asm/mach-types.h> + MODULE_AUTHOR("Mika Laitio"); MODULE_AUTHOR("Daniel Petrini"); MODULE_AUTHOR("David Cohen"); @@ -210,7 +212,7 @@ static int audio_start_dma_chain(struct * irq from DMA after the first transfered/played buffer. * (invocation of callback_omap_alsa_sound_dma() method). */ - if (cpu_is_omap1510()) + if (cpu_is_omap1510() && !machine_is_ams_delta()) omap_stop_alsa_sound_dma(s);

dma_start_pos = (dma_addr_t)runtime->dma_area + offset; diff -uprN linux-2.6.27/sound/arm/omap/omap-alsa-dma.c linux-2.6.27-sound/sound/arm/omap/omap-alsa-dma.c --- linux-2.6.27/sound/arm/omap/omap-alsa-dma.c 2009-05-30 21:27:09.000000000 +0000 +++ linux-2.6.27-sound/sound/arm/omap/omap-alsa-dma.c 2009-05-30 22:12:12.000000000 +0000 @@ -70,6 +70,8 @@

#include <asm/arch/omap-alsa.h>

+#include <asm/mach-types.h> + #undef DEBUG

#define ERR(ARGS...) printk(KERN_ERR "{%s}-ERROR: ", __FUNCTION__);printk(ARGS); @@ -350,7 +352,7 @@ static int audio_start_dma_chain(struct omap_start_dma(channel); s->started = 1; s->hw_start(); /* start McBSP interface */ - } else if (cpu_is_omap310()) + } else if (cpu_is_omap310() || machine_is_ams_delta()) omap_start_dma(channel); /* else the dma itself will progress forward with out our help */ FN_OUT(0); ----------------------------------

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:

---------------------------------- static int ams_delta_startup(struct snd_pcm_substream *substream) { ams_delta_latch2_write(AMS_DELTA_LATCH_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH_MODEM_NRESET); return clk_enable(cx20442_mclk); }

static void ams_delta_shutdown(struct snd_pcm_substream *substream) { clk_disable(cx20442_mclk); ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, AMS_DELTA_LATCH2_MODEM_CODEC); } ... static struct snd_soc_ops ams_delta_ops = { .startup = ams_delta_startup, .hw_params = ams_delta_hw_params, .shutdown = ams_delta_shutdown, }; ... /* Digital audio interface glue - connects codec <--> CPU */ static struct snd_soc_dai_link ams_delta_dai = { ... .ops = &ams_delta_ops, };

/* Audio machine driver */ static struct snd_soc_card snd_soc_card_ams_delta = { .name = "AMS_DELTA", .platform = &omap_soc_platform, .dai_link = &ams_delta_dai, .num_links = 1, };

/* Audio subsystem */ static struct snd_soc_device ams_delta_snd_devdata = { .card = &snd_soc_card_ams_delta, .codec_dev = &soc_codec_dev_cx20442, }; -----------------------------------------------------

When applied on top of linux-2.6.27, omap or mainline, my patch causes system hangup on sound device first access, exactly as I have already reported it for linux-omap.git revision 90e758af52ba803cba233fabee81176d99589f09.

However, when applied on top of linux-2.6.30-rc5, I still get a working system with non-functional sound device. DMA interrupt counters stay at 0.

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.

Jarkko Nikula wrote:

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.

Cheers, Janusz

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

Hi Jarkko,

Jarkko Nikula wrote:

On Mon, 1 Jun 2009 21:04:13 +0300 Jarkko Nikula jhnikula@gmail.com 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 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 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.

The original patch had no extra omap_dma_stop(), but extra unconditional (form ams-delta point of view) omap_dma_start() inside omap_start_alsa_sound_dma(). Later on, there was an extra omap_stop_alsa_sound_dma() call introduced in audio_process_dma() as a workaround for a similiar problem found on other omap1510 machines, that cleared the flag preventing omap_start_alsa_sound_dma() from calling omap_dma_start(). I found that with the latter, the old driver happened to stop working after a while or two.

Could you try to add following line in omap-pcm.c does it help? However this doesn't explain why you are not getting any interrupts.

@@ -68,6 +68,7 @@ static void omap_pcm_dma_irq(int ch, u16 stat, void *data) if (prtd->period_index >= 0) { if (++prtd->period_index == runtime->periods) { prtd->period_index = 0;

• 		omap_stop_dma(prtd->dma_ch);
  	omap_start_dma(prtd->dma_ch);
  }
  

  }

OK, I will.

...

...

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 :-)

And we know mcbsp settings that make it working.

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.

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.

Cheers, Janusz

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

Hello Janusz,

On Saturday 06 June 2009 20:42:12 ext Janusz Krzysztofik wrote:

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

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

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 have been looking for clues around the net, and it seams that the codec in question has stereo 16 bit format.

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?

Without actual OMAP1510 HW it is really hard to tell what can be the problem. What I would do, if I had a HW: 1) See if the DMA actually was running and it is 'just' about the missing interrupt: --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -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. I know, this is a long shot, but at least we can be sure, that the problem is in the ASoC McBSP/DMA integration or it is something else.

Meanwhile I'll try to locate one OMAP1510 based board to try to help with this issue.

On Tuesday 09 June 2009 18:17:42 ext Janusz Krzysztofik wrote:

Peter Ujfalusi wrote:

...

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.

...

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.

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

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

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

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.

---

...

--- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -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...

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.

Hmm, this means that the DMA was not running at all (since it has not been progressed). So you might have the missing DMA interrupt problem, but first we should get the DMA to actually run. Looking at the dma code for clues... Even bigger Hmmm... For OMAP1 the DMA synchronization is not configured. I just wonder how this supposed to be working on OMAP1 platforms. Anyway, can you try the following patch (and please keep the previous printk in the omap-pcm.c):

--- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -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));

in the if (cpu_class_is_omap1()) { path...

The interesting thing is the following: the old ALSA implementation configured the DMA in this way: omap_set_dma_transfer_params(channel, dt, cen, cfn, 0x00, 0, 0); Meaning, no DMA synchronization, which is fair, since the DMA code for OMAP1 does not configured it anyway.

...

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.

There seams to be no major difference between the 2.6.28 and the latest arch/arm/plat-omap/dma.c and mcbsp.c 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.

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)

...

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.

...

--- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -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));
  

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

I would have guessed this, since even when the DMA was not HW synced, it did not sent a single bit to the McBSP DXR1 register...

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

--- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -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.

...

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.

I'm not sure if it could prove anything at the end. There are - I think - other moving parts, which can break things.

Thanks, Janusz

Wednesday 10 June 2009 12:53:42 Peter Ujfalusi napisał(a):

On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote: Just out of curiosity, can you try this one as well:

--- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -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.

Peter,

I am not sure how did you expect me to see this pattern. On a scope screen? Unforunatelly I had to return the scope this morning.

I have further modified the code like this:

@@ -25,6 +25,7 @@ #include <linux/init.h> #include <linux/module.h> #include <linux/device.h> +#include <linux/random.h> #include <sound/core.h> #include <sound/pcm.h> #include <sound/pcm_params.h> @@ -186,7 +186,7 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream *substream, int cmd, struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai->private_data); - int err = 0; + int i, err = 0;

switch (cmd) { case SNDRV_PCM_TRIGGER_START: @@ -191,6 +191,8 @@ 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); + for (i = 8000; i > 0; i--) + omap_mcbsp_pollwrite(mcbsp_data->bus_id, (u16)random32 ()); break;

case SNDRV_PCM_TRIGGER_STOP:

in hope I should be able to hear a noise for one second, shouldn't I.

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.

Now aplay returns 1 second later than before, so I conclude the loop is processed correctly. However, I am not able to hear a single ripple nor see any error messages from omap_mcbsp_pollwrite() :(, so it looks like the latter is more probable.

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

Hello Janusz,

On Tuesday 02 June 2009 13:50:50 ext Janusz Krzysztofik wrote:

Hi Jarkko,

Jarkko Nikula wrote:

...

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.

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:

diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 6454e15..2df1792 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -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;

This is on top of sound-2.6:topic/asoc, but l-o should not be that different. Call the omap_stop_dma before actually starting the dma, and call stop also before restarting it.

Hi Mark,

Wednesday 27 May 2009 12:47:11 Mark Brown wrote:

On Tue, May 26, 2009 at 03:17:23PM +0200, Janusz Krzysztofik wrote:

...

+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);
• 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.

Tired with solving tha main problem of not getting any DMA interrupts, I have followed your advices and modified my codec driver. I have used your wm8400 code as a template. The driver compiles and loads without errors, however I have no way to verify if and how it works as long as the DMA issue persists. I think the code is probably far from complete, but could you please have a look at it for possible problems?

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

Thanks, Janusz

Signed-off by: Janusz Krzysztofik jkrzyszt@tis.icnet.pl ------------------------------- diff -Npru a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig --- a/sound/soc/codecs/Kconfig 2009-05-12 21:13:59.000000000 +0200 +++ b/sound/soc/codecs/Kconfig 2009-06-01 22:31:15.000000000 +0200 @@ -18,6 +18,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AK4104 if SPI_MASTER select SND_SOC_AK4535 if I2C select SND_SOC_CS4270 if I2C + select SND_SOC_CX20442 select SND_SOC_PCM3008 select SND_SOC_SSM2602 if I2C select SND_SOC_TLV320AIC23 if I2C @@ -84,6 +85,9 @@ config SND_SOC_AC97_CODEC bool depends on SND_SOC_CS4270

+config SND_SOC_CX20442 + tristate + config SND_SOC_L3 tristate

diff -Npru a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile --- a/sound/soc/codecs/Makefile 2009-05-12 21:13:59.000000000 +0200 +++ b/sound/soc/codecs/Makefile 2009-06-01 22:33:32.000000000 +0200 @@ -5,6 +5,7 @@ snd-soc-ak4104-objs := ak4104.o snd-soc-ak4535-objs := ak4535.o snd-soc-cs4270-objs := cs4270.o +snd-soc-cx20442-objs := cx20442.o snd-soc-l3-objs := l3.o snd-soc-pcm3008-objs := pcm3008.o snd-soc-ssm2602-objs := ssm2602.o @@ -37,6 +38,7 @@ snd-soc-wm9713-objs := wm9713.o obj-$(CONFIG_SND_SOC_AK4104) += snd-soc-ak4104.o obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o +obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o obj-$(CONFIG_SND_SOC_PCM3008) += snd-soc-pcm3008.o obj-$(CONFIG_SND_SOC_SSM2602) += snd-soc-ssm2602.o diff -Npru a/sound/soc/codecs/cx20442.c b/sound/soc/codecs/cx20442.c --- a/sound/soc/codecs/cx20442.c 1970-01-01 01:00:00.000000000 +0100 +++ b/sound/soc/codecs/cx20442.c 2009-06-01 21:26:20.000000000 +0200 @@ -0,0 +1,224 @@ +/* + * cx20442.c -- CX20442 ALSA Soc Audio driver + * + * Based on wm8400.c + * Copyright 2008, 2009 Wolfson Microelectronics PLC. + * Author: Mark Brown broonie@opensource.wolfsonmicro.com + * + * Copyright 2009 Janusz Krzysztofik jkrzyszt@tis.icnet.pl + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include <linux/module.h> +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/soc.h> +#include <sound/soc-dapm.h> +#include <sound/initval.h> + +#include "cx20442.h" + +struct cx20442_priv { + struct snd_soc_codec codec; + struct work_struct work; +}; + +static int cx20442_add_controls(struct snd_soc_codec *codec) +{ + return 0; +} + +static int cx20442_add_widgets(struct snd_soc_codec *codec) +{ + snd_soc_dapm_new_widgets(codec); + return 0; +} + +static int cx20442_set_bias_level(struct snd_soc_codec *codec, + enum snd_soc_bias_level level) +{ + codec->bias_level = level; + return 0; +} + +#define CX20442_RATES SNDRV_PCM_RATE_8000 + +#define CX20442_FORMATS SNDRV_PCM_FMTBIT_S16_LE + +struct snd_soc_dai cx20442_dai = { + .name = "CX20442", + .playback = { + .stream_name = "Playback", + .channels_min = 1, + .channels_max = 2, + .rates = CX20442_RATES, + .formats = CX20442_FORMATS, + }, + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 2, + .rates = CX20442_RATES, + .formats = CX20442_FORMATS, + }, +}; +EXPORT_SYMBOL_GPL(cx20442_dai); + +static struct snd_soc_codec *cx20442_codec; + +static int cx20442_probe(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec; + int ret; + + if(!cx20442_codec) { + dev_err(&pdev->dev, "cx20442 not yet discovered\n"); + return -ENODEV; + } + codec = cx20442_codec; + + socdev->card->codec = codec; + + /* register pcms */ + ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1); + if (ret < 0) { + dev_err(&pdev->dev, "failed to create pcms\n"); + goto pcm_err; + } + + cx20442_add_controls(codec); + cx20442_add_widgets(codec); + + cx20442_set_bias_level(codec, SND_SOC_BIAS_STANDBY); + + ret = snd_soc_init_card(socdev); + if (ret < 0) { + dev_err(&pdev->dev, "failed to register card\n"); + goto card_err; + } + + return ret; + +card_err: + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); +pcm_err: + return ret; +} + +/* power down chip */ +static int cx20442_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); + + return 0; +} + +struct snd_soc_codec_device soc_codec_dev_cx20442 = { + .probe = cx20442_probe, + .remove = cx20442_remove, +}; + +static int cx20442_codec_probe(struct platform_device *dev) +{ + struct cx20442_priv *priv; + int ret; + struct snd_soc_codec *codec; + + priv = kzalloc(sizeof(struct cx20442_priv), GFP_KERNEL); + if (priv == NULL) + return -ENOMEM; + + codec = &priv->codec; + codec->private_data = priv; + codec->control_data = dev->dev.driver_data; + + codec->dev = &dev->dev; + cx20442_dai.dev = &dev->dev; + + codec->name = "CX20442"; + codec->owner = THIS_MODULE; + codec->bias_level = SND_SOC_BIAS_OFF; + codec->set_bias_level = cx20442_set_bias_level; + codec->dai = &cx20442_dai; + codec->num_dai = 1; + mutex_init(&codec->mutex); + INIT_LIST_HEAD(&codec->dapm_widgets); + INIT_LIST_HEAD(&codec->dapm_paths); + + cx20442_codec = codec; + + ret = snd_soc_register_codec(codec); + if (ret != 0) { + dev_err(&dev->dev, "Failed to register codec: %d\n", ret); + goto err; + } + + ret = snd_soc_register_dai(&cx20442_dai); + if (ret != 0) { + dev_err(&dev->dev, "Failed to register DAI: %d\n", ret); + goto err_codec; + } + + return 0; + +err_codec: + snd_soc_unregister_codec(codec); +err: + cx20442_codec = NULL; + kfree(priv); + return ret; +} + +static int __exit cx20442_codec_remove(struct platform_device *dev) +{ + struct cx20442_data *priv = cx20442_codec->private_data; + + snd_soc_unregister_dai(&cx20442_dai); + snd_soc_unregister_codec(cx20442_codec); + + kfree(priv); + + cx20442_codec = NULL; + + return 0; +} + +static struct platform_driver cx20442_codec_driver = { + .driver = { + .name = "cx20442-codec", + .owner = THIS_MODULE, + }, + .probe = cx20442_codec_probe, + .remove = __exit_p(cx20442_codec_remove), +}; + +static int __init cx20442_init(void) +{ + return platform_driver_register(&cx20442_codec_driver); +} +module_init(cx20442_init); + +static void __exit cx20442_exit(void) +{ + platform_driver_unregister(&cx20442_codec_driver); +} +module_exit(cx20442_exit); + +EXPORT_SYMBOL_GPL(soc_codec_dev_cx20442); + +MODULE_DESCRIPTION("ASoC CX20442 driver"); +MODULE_AUTHOR("Janusz Krzysztofik"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS("platform:cx20442-codec"); diff -Npru a/sound/soc/codecs/cx20442.h b/sound/soc/codecs/cx20442.h --- a/sound/soc/codecs/cx20442.h 1970-01-01 01:00:00.000000000 +0100 +++ b/sound/soc/codecs/cx20442.h 2009-06-01 21:25:46.000000000 +0200 @@ -0,0 +1,23 @@ +/* + * cx20442.h -- audio driver for CX20442 + * + * Based on wm8400.h + * Copyright 2008 Wolfson Microelectronics PLC. + * Author:Mark Brown broonie@opensource.wolfsonmicro.com + * + * Copyright 2009 Janusz Krzysztofik jkrzyszt@tis.icnet.pl + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#ifndef _CX20442_CODEC_H +#define _CX20442_CODEC_H + +extern struct snd_soc_dai cx20442_dai; +extern struct snd_soc_codec_device soc_codec_dev_cx20442; + +#endif