- Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v4 5/5] ASoC: omap-mcbsp: Place correct constraints for streams
by Peter Ujfalusi 01 Jun '10

01 Jun '10

OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Use the second method to place hw_rule on buffer size, and in threshold mode to period size. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- Hello, The only change since v3 is the removal of blank line from the end of omap_mcbsp_hwrule_min_buffersize function. This patch should replace the one in the v3 series. Peter sound/soc/omap/omap-mcbsp.c | 98 +++++++++++++++++++++++++++++++++--------- 1 files changed, 77 insertions(+), 21 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index b06d8f1..aebd3af 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -173,6 +173,50 @@ static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream) omap_mcbsp_set_rx_threshold(mcbsp_data->bus_id, words); } +static int omap_mcbsp_hwrule_min_buffersize(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct snd_interval *buffer_size = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_BUFFER_SIZE); + struct snd_interval *channels = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_CHANNELS); + struct omap_mcbsp_data *mcbsp_data = rule->private; + struct snd_interval frames; + int size; + + snd_interval_any(&frames); + size = omap_mcbsp_get_fifo_size(mcbsp_data->bus_id); + + frames.min = size / channels->min; + frames.integer = 1; + return snd_interval_refine(buffer_size, &frames); +} + +static int omap_mcbsp_hwrule_max_periodsize(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct snd_interval *period_size = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_PERIOD_SIZE); + struct snd_interval *channels = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_CHANNELS); + struct snd_pcm_substream *substream = rule->private; + 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); + struct snd_interval frames; + int size; + + snd_interval_any(&frames); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + size = omap_mcbsp_get_max_tx_threshold(mcbsp_data->bus_id); + else + size = omap_mcbsp_get_max_rx_threshold(mcbsp_data->bus_id); + + frames.max = size / channels->min; + frames.integer = 1; + return snd_interval_refine(period_size, &frames); +} + static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { @@ -185,33 +229,45 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, if (!cpu_dai->active) err = omap_mcbsp_request(bus_id); + /* + * OMAP3 McBSP FIFO is word structured. + * McBSP2 has 1024 + 256 = 1280 word long buffer, + * McBSP1,3,4,5 has 128 word long buffer + * This means that the size of the FIFO depends on the sample format. + * For example on McBSP3: + * 16bit samples: size is 128 * 2 = 256 bytes + * 32bit samples: size is 128 * 4 = 512 bytes + * It is simpler to place constraint for buffer and period based on + * channels. + * McBSP3 as example again (16 or 32 bit samples): + * 1 channel (mono): size is 128 frames (128 words) + * 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) + * 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) + */ if (cpu_is_omap343x()) { int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id); - int max_period; /* - * McBSP2 in OMAP3 has 1024 * 32-bit internal audio buffer. - * Set constraint for minimum buffer size to the same than FIFO - * size in order to avoid underruns in playback startup because - * HW is keeping the DMA request active until FIFO is filled. - */ - if (bus_id == 1) - snd_pcm_hw_constraint_minmax(substream->runtime, - SNDRV_PCM_HW_PARAM_BUFFER_BYTES, - 4096, UINT_MAX); - - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - max_period = omap_mcbsp_get_max_tx_threshold(bus_id); - else - max_period = omap_mcbsp_get_max_rx_threshold(bus_id); - - max_period++; - max_period <<= 1; + * The first rule is for the buffer size, we should not allow + * smaller buffer than the FIFO size to avoid underruns + */ + snd_pcm_hw_rule_add(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_CHANNELS, + omap_mcbsp_hwrule_min_buffersize, + mcbsp_data, + SNDRV_PCM_HW_PARAM_BUFFER_SIZE, -1); + /* + * In case of threshold mode, the rule will ensure, that the + * period size is not bigger than the maximum allowed threshold + * value. + */ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) - snd_pcm_hw_constraint_minmax(substream->runtime, - SNDRV_PCM_HW_PARAM_PERIOD_BYTES, - 32, max_period); + snd_pcm_hw_rule_add(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_CHANNELS, + omap_mcbsp_hwrule_max_periodsize, + substream, + SNDRV_PCM_HW_PARAM_PERIOD_SIZE, -1); } return err; -- 1.7.1

1 0

[alsa-devel] [RFC PATCH 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
by Peter Ujfalusi 01 Jun '10

01 Jun '10

Hello, This series aims to correct how the McBSP FIFO is viewed, and handled. Introduction of the problem: OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Since now the McBSP codec supports not only 16bit samples (32biut has been recently added), the FIFO size handling is no longer correct, since it has been hard wired for 16bit word length. The series changes how the users of McBSP are configuring the FIFO: It used to be 0 based (0 meant 1 word threshold). After this series users can configure the threshold in 1 base mode (1 means 1 word threshold). The platform code now provides the _full_ size of the FIFO in words, instead of the already limited value used in the past. In ASoC omap-mcbsp code hw_rule based constraint refinement is going to be used instead of the hardwired static constraint, which was correct only in case of 16bit word length. The hw_rule is refining the minimum buffer size based on the channel number going to be used by the coming stream. In case of threshold mode additional hw_rule refines the maximum allowed period size. The series are generated agains Takashi's sound-2.6: topic/asoc branch. CCing also Eduardo, and Eero since they have worked on the original FIFO/threshold implementation. All commetns and testers are welcome! Peter --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP3: McBSP: Change the way how the FIFO is handled OMAP3: McBSP: Use the port's buffer_size when calculating tx delay ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h | 2 + arch/arm/plat-omap/mcbsp.c | 31 ++++++--- sound/soc/omap/omap-mcbsp.c | 112 +++++++++++++++++++++++------- 4 files changed, 114 insertions(+), 41 deletions(-)

3 17

Re: [alsa-devel] [PATCH] ASoC/kirkwood: the 'break' is useless
by Mark Brown 01 Jun '10

01 Jun '10

On Tue, Jun 01, 2010 at 12:56:11PM +0800, Wan ZongShun wrote: > Dear Mark, > > The 'break' is useless here, I think it should be removed. > > Thanks! > > Signed-off-by: Wan ZongShun<mcuos.com(a)gmail.com> Just to emphasise my previous comments about patch formatting it's particularly important to get stuff like that right with cleanup patches like this - with simple updates the effort required to apply the patch (cleaning up the commit message and so on) can be greater than the effort required to make the original change.

1 0

Re: [alsa-devel] [PATCH 1/3] ALSA/NUC900: Fix some codes according to Liam for nuc900 alsa driver.
by Mark Brown 01 Jun '10

01 Jun '10

On Tue, Jun 01, 2010 at 10:48:19AM +0800, Wan ZongShun wrote: > Dear Liam & Mark, > > This patch is to fix some codes according to > Liam for nuc900 alsa driver. So, these changes look like they're fine but since you've not provided a changelog it's hard to tell for sure. It also looks like you've got two different changes in here, some of the code is adjusting the delays used between register writes in reset while other bits change the code over to using the standard method for checking for substream type. As I said to you yesterday please do read and follow the instructions in Documentation/SubmittingPatches - in particular, you need to include a proper changelog in your mail and you shouldn't have any "Dear X" or similar. > Signed-off-by: Wan ZongShun<mcuos.com(a)gmail.com> You're missing a space between your name and the e-mail address too.

1 0

Re: [alsa-devel] [PATCH 3/3] ASoC/NUC900: Fix a typo for nuc900 alsa driver.
by Liam Girdwood 01 Jun '10

01 Jun '10

On Tue, 2010-06-01 at 10:52 +0800, Wan ZongShun wrote: > Dear all, > > This patch is to fix a typo for nuc900 alsa driver. > The changes look fine here, just the commit message and subject is missing information about renaming the file. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

1 0

Re: [alsa-devel] [PATCH 2/3] ALSA/NUC900: Fix a while loop bug for nuc900 alsa driver
by Liam Girdwood 01 Jun '10

01 Jun '10

On Tue, 2010-06-01 at 10:50 +0800, Wan ZongShun wrote: > Dear all, > > This patch is to fix a while loop bug for nuc900 alsa driver. Which bug ? It's best to say the bug you are fixing when submitting a patch like this. Thanks Liam > > Signed-off-by: Wan ZongShun<mcuos.com(a)gmail.com> > --- > sound/soc/nuc900/nuc900-ac97.c | 10 ++++------ > 1 files changed, 4 insertions(+), 6 deletions(-) > > diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c > index 5b864f9..db7fc13 100644 > --- a/sound/soc/nuc900/nuc900-ac97.c > +++ b/sound/soc/nuc900/nuc900-ac97.c > @@ -66,9 +66,8 @@ static unsigned short nuc900_ac97_read(struct snd_ac97 *ac97, > udelay(100); > > /* polling the AC_R_FINISH */ > - val = AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON); > - val &= AC_R_FINISH; > - while (!val && timeout--) > + while (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_R_FINISH) > + && timeout--) > mdelay(1); > > if (!timeout) { > @@ -121,9 +120,8 @@ static void nuc900_ac97_write(struct snd_ac97 *ac97, unsigned > short reg, > udelay(100); > > /* polling the AC_W_FINISH */ > - tmp = AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON); > - tmp &= AC_W_FINISH; > - while (tmp && timeout--) > + while ((AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_W_FINISH) > + && timeout--) > mdelay(1); > > if (!timeout)

1 0

Re: [alsa-devel] [PATCH 1/3] ALSA/NUC900: Fix some codes according to Liam for nuc900 alsa driver.
by Liam Girdwood 01 Jun '10

01 Jun '10

On Tue, 2010-06-01 at 10:48 +0800, Wan ZongShun wrote: > Dear Liam & Mark, > > This patch is to fix some codes according to > Liam for nuc900 alsa driver. > > Signed-off-by: Wan ZongShun<mcuos.com(a)gmail.com> The changes here looks fine. Can you resend and add a summary of the changes to the commit message. It's also good practice to split into a new patch for every issue you are fixing, i.e. in this case I would have one patch for the AC97 delays and another patch for the PCM_TX removal. Thanks Liam > > --- > sound/soc/nuc900/nuc900-ac97.c | 20 +++++--------------- > sound/soc/nuc900/nuc900-auido.h | 4 ---- > sound/soc/nuc900/nuc900-pcm.c | 18 ++++++++++-------- > 3 files changed, 15 insertions(+), 27 deletions(-) > > diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c > index f7b44e0..5b864f9 100644 > --- a/sound/soc/nuc900/nuc900-ac97.c > +++ b/sound/soc/nuc900/nuc900-ac97.c > @@ -149,7 +149,7 @@ static void nuc900_ac97_warm_reset(struct snd_ac97 *ac97) > val |= AC_W_RES; > AUDIO_WRITE(nuc900_audio->mmio + ACTL_ACCON, val); > > - udelay(1000); > + udelay(100); > > val = nuc900_checkready(); > if (!!val) > @@ -170,40 +170,30 @@ static void nuc900_ac97_cold_reset(struct snd_ac97 *ac97) > val |= ACTL_RESET_BIT; > AUDIO_WRITE(nuc900_audio->mmio + ACTL_RESET, val); > > - udelay(1000); > - > val = AUDIO_READ(nuc900_audio->mmio + ACTL_RESET); > val &= (~ACTL_RESET_BIT); > AUDIO_WRITE(nuc900_audio->mmio + ACTL_RESET, val); > > - udelay(1000); > - > /* reset AC-link interface */ > > val = AUDIO_READ(nuc900_audio->mmio + ACTL_RESET); > val |= AC_RESET; > AUDIO_WRITE(nuc900_audio->mmio + ACTL_RESET, val); > > - udelay(1000); > - > val = AUDIO_READ(nuc900_audio->mmio + ACTL_RESET); > val &= ~AC_RESET; > AUDIO_WRITE(nuc900_audio->mmio + ACTL_RESET, val); > > - udelay(1000); > - > /* cold reset AC 97 */ > val = AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON); > val |= AC_C_RES; > AUDIO_WRITE(nuc900_audio->mmio + ACTL_ACCON, val); > > - udelay(1000); > - > val = AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON); > val &= (~AC_C_RES); > AUDIO_WRITE(nuc900_audio->mmio + ACTL_ACCON, val); > > - udelay(1000); > + udelay(100); > > mutex_unlock(&ac97_mutex); > > @@ -222,7 +212,7 @@ static int nuc900_ac97_trigger(struct snd_pcm_substream > *substream, > int cmd, struct snd_soc_dai *dai) > { > struct nuc900_audio *nuc900_audio = nuc900_ac97_data; > - int ret, stype = SUBSTREAM_TYPE(substream); > + int ret; > unsigned long val, tmp; > > ret = 0; > @@ -231,7 +221,7 @@ static int nuc900_ac97_trigger(struct snd_pcm_substream > *substream, > case SNDRV_PCM_TRIGGER_START: > case SNDRV_PCM_TRIGGER_RESUME: > val = AUDIO_READ(nuc900_audio->mmio + ACTL_RESET); > - if (PCM_TX == stype) { > + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { > tmp = AUDIO_READ(nuc900_audio->mmio + ACTL_ACOS0); > tmp |= (SLOT3_VALID | SLOT4_VALID | VALID_FRAME); > AUDIO_WRITE(nuc900_audio->mmio + ACTL_ACOS0, tmp); > @@ -254,7 +244,7 @@ static int nuc900_ac97_trigger(struct snd_pcm_substream > *substream, > case SNDRV_PCM_TRIGGER_STOP: > case SNDRV_PCM_TRIGGER_SUSPEND: > val = AUDIO_READ(nuc900_audio->mmio + ACTL_RESET); > - if (PCM_TX == stype) { > + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { > tmp = AUDIO_READ(nuc900_audio->mmio + ACTL_ACOS0); > tmp &= ~(SLOT3_VALID | SLOT4_VALID); > AUDIO_WRITE(nuc900_audio->mmio + ACTL_ACOS0, tmp); > diff --git a/sound/soc/nuc900/nuc900-auido.h b/sound/soc/nuc900/nuc900-auido.h > index 95ac4ef..3038f51 100644 > --- a/sound/soc/nuc900/nuc900-auido.h > +++ b/sound/soc/nuc900/nuc900-auido.h > @@ -96,10 +96,6 @@ > #define RESET_PRSR 0x00 > #define AUDIO_WRITE(addr, val) __raw_writel(val, addr) > #define AUDIO_READ(addr) __raw_readl(addr) > -#define PCM_TX 0 > -#define PCM_RX 1 > -#define SUBSTREAM_TYPE(substream) \ > - ((substream)->stream == SNDRV_PCM_STREAM_PLAYBACK ? PCM_TX : PCM_RX) > > struct nuc900_audio { > void __iomem *mmio; > diff --git a/sound/soc/nuc900/nuc900-pcm.c b/sound/soc/nuc900/nuc900-pcm.c > index 32a503c..445a180 100644 > --- a/sound/soc/nuc900/nuc900-pcm.c > +++ b/sound/soc/nuc900/nuc900-pcm.c > @@ -47,7 +47,7 @@ static int nuc900_dma_hw_params(struct snd_pcm_substream > *substream, > { > struct snd_pcm_runtime *runtime = substream->runtime; > struct nuc900_audio *nuc900_audio = runtime->private_data; > - unsigned long flags, stype = SUBSTREAM_TYPE(substream); > + unsigned long flags; > int ret = 0; > > spin_lock_irqsave(&nuc900_audio->lock, flags); > @@ -57,8 +57,9 @@ static int nuc900_dma_hw_params(struct snd_pcm_substream > *substream, > return ret; > > nuc900_audio->substream = substream; > - nuc900_audio->dma_addr[stype] = runtime->dma_addr; > - nuc900_audio->buffersize[stype] = params_buffer_bytes(params); > + nuc900_audio->dma_addr[substream->stream] = runtime->dma_addr; > + nuc900_audio->buffersize[substream->stream] = > + params_buffer_bytes(params); > > spin_unlock_irqrestore(&nuc900_audio->lock, flags); > > @@ -72,7 +73,7 @@ static void nuc900_update_dma_register(struct > snd_pcm_substream *substream, > struct nuc900_audio *nuc900_audio = runtime->private_data; > void __iomem *mmio_addr, *mmio_len; > > - if (SUBSTREAM_TYPE(substream) == PCM_TX) { > + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { > mmio_addr = nuc900_audio->mmio + ACTL_PDSTB; > mmio_len = nuc900_audio->mmio + ACTL_PDST_LENGTH; > } else { > @@ -167,18 +168,19 @@ static int nuc900_dma_prepare(struct snd_pcm_substream > *substream) > { > struct snd_pcm_runtime *runtime = substream->runtime; > struct nuc900_audio *nuc900_audio = runtime->private_data; > - unsigned long flags, val, stype = SUBSTREAM_TYPE(substream);; > + unsigned long flags, val; > > spin_lock_irqsave(&nuc900_audio->lock, flags); > > nuc900_update_dma_register(substream, > - nuc900_audio->dma_addr[stype], nuc900_audio->buffersize[stype]); > + nuc900_audio->dma_addr[substream->stream], > + nuc900_audio->buffersize[substream->stream]); > > val = AUDIO_READ(nuc900_audio->mmio + ACTL_RESET); > > switch (runtime->channels) { > case 1: > - if (PCM_TX == stype) { > + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { > val &= ~(PLAY_LEFT_CHNNEL | PLAY_RIGHT_CHNNEL); > val |= PLAY_RIGHT_CHNNEL; > } else { > @@ -188,7 +190,7 @@ static int nuc900_dma_prepare(struct snd_pcm_substream > *substream) > AUDIO_WRITE(nuc900_audio->mmio + ACTL_RESET, val); > break; > case 2: > - if (PCM_TX == stype) > + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) > val |= (PLAY_LEFT_CHNNEL | PLAY_RIGHT_CHNNEL); > else > val |= (RECORD_LEFT_CHNNEL | RECORD_RIGHT_CHNNEL);

1 0

[alsa-devel] snd_hda_intel : broken microphone
by mutenmaster＠tiscali.it 01 Jun '10

01 Jun '10

hi there, I'd like to report a possible bug. After this kernel linux commit: f5271101faf1655d862849f42518c2a88ef394fb my front microphone stopped working, and as of the most recent version, the front microphone still doesn't work. Doing $ arecord -f cd prova.wav produces a mere 44 bytes long file. some versions after the commit pointed above create a file that is bigger than 44 bytes, but plays nothing at all. I just checked the rear microphone,and the result is the same. I attached my codec0 and lspci -vvv output, please let me know if you need anything else. best, vasilis Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 14,95 € al mese. Gratis la Sim Tiscali Mobile con 25 euro di traffico! L'offerta è valida solo se attivi entro il 03/06/10 http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT…

1 0

Re: [alsa-devel] Problem with snd_hda_intel from 05-27-2010 snapshot
by Jaroslav Kysela 01 Jun '10

01 Jun '10

On Mon, 31 May 2010, VDR User wrote: > On Mon, May 31, 2010 at 1:43 PM, Jaroslav Kysela <perex(a)perex.cz> wrote: >>> I've got a bit of a strange result. With the above patch (and the >>> wallclk logging patch from your previous email), sound does not work. >>> However, it _does_ start working only if I `echo 29 > >>> /proc/asound/card1/pcm3p/xrun_debug`. I tested these results with a >>> reboot in between each attempt just to make sure I'm working with a >>> clean boot. I can't imagine what's causing this weird condition. Any >>> ideas? >> >> Try to disable jiffies check (value 25 for xrun_debug). Please, post your >> log for value 29 for inspection. Thanks. > > With xrun_debug 25 I get sound for about 1 second and then it > disappears. 29 of course works fine as mentioned previously. Thanks. Here is next correction: diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 170610e..b6ba210 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1910,11 +1910,11 @@ static int azx_position_ok(struct azx *chip, struct azx_dev *azx_dev) if (WARN_ONCE(!azx_dev->period_bytes, "hda-intel: zero azx_dev->period_bytes")) return -1; /* this shouldn't happen! */ - if (wallclk <= azx_dev->period_wallclk && + if (wallclk < (azx_dev->period_wallclk * 3) / 2 && pos % azx_dev->period_bytes > azx_dev->period_bytes / 2) /* NG - it's below the first next period boundary */ return bdl_pos_adj[chip->dev_index] ? 0 : -1; - azx_dev->start_wallclk = wallclk; + azx_dev->start_wallclk += wallclk; return 1; /* OK, it's fine */ } Jaroslav ----- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.

2 1

[alsa-devel] [RFC PATCH 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
by Peter Ujfalusi 01 Jun '10

01 Jun '10

Hello, This series aims to correct how the McBSP FIFO is viewed, and handled. Introduction of the problem: OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Since now the McBSP codec supports not only 16bit samples (32biut has been recently added), the FIFO size handling is no longer correct, since it has been hard wired for 16bit word length. The series changes how the users of McBSP are configuring the FIFO: It used to be 0 based (0 meant 1 word threshold). After this series users can configure the threshold in 1 base mode (1 means 1 word threshold). The platform code now provides the _full_ size of the FIFO in words, instead of the already limited value used in the past. In ASoC omap-mcbsp code hw_rule based constraint refinement is going to be used instead of the hardwired static constraint, which was correct only in case of 16bit word length. The hw_rule is refining the minimum buffer size based on the channel number going to be used by the coming stream. In case of threshold mode additional hw_rule refines the maximum allowed period size. The series are generated agains Takashi's sound-2.6: topic/asoc branch. CCing also Eduardo, and Eero since they have worked on the original FIFO/threshold implementation. All commetns and testers are welcome! Peter --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP3: McBSP: Change the way how the FIFO is handled OMAP3: McBSP: Use the port's buffer_size when calculating tx delay ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h | 2 + arch/arm/plat-omap/mcbsp.c | 31 ++++++--- sound/soc/omap/omap-mcbsp.c | 112 +++++++++++++++++++++++------- 4 files changed, 114 insertions(+), 41 deletions(-)

2 8