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

[alsa-devel] ASoC updates for 2.6.35
by Mark Brown 02 Jun '10

02 Jun '10

The following changes since commit 1fab79b8a1bf0d46a7c7e6a1c06dbed1803f403c: Merge branch 'for-2.6.36' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6 into topic/asoc (2010-05-31 18:13:20 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.35 Simple Kconfig fixes, should only affect the relevant platforms. Sascha Hauer (2): ASoC: Add missing Kconfig entry for Phytec boards ASoC: MX31ads sound support should depend on MACH_MX31ADS_WM1133_EV1 sound/soc/imx/Kconfig | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-)

2 1

Re: [alsa-devel] [PATCH v2 2/4]AsoC/nuc900: patch for modifing the ac97 delays to minimum
by Liam Girdwood 02 Jun '10

02 Jun '10

On Wed, 2010-06-02 at 13:57 +0800, Wan ZongShun wrote: > This patch is to modify the ac97 delays to minimum, all these 1000 micro > seconds delays seem over spec for the AC97 interface. > > I deleted some unnecessary delays here and changed the AC97 cold and warm reset > delays from 1000ms to 100ms. > I think you mean "from 1000µs to 100µs" here as ms is milliseconds. Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

2 2

Re: [alsa-devel] [PATCH v2 1/3]AsoC/nuc900: patch for SUBSTREAM_TYPE', 'PCM_TX' and 'PCM_RX' removal
by Wan ZongShun 02 Jun '10

02 Jun '10

I am sorry for wrong subject. It should be [PATCH v2 1/4]. > This patch is to remove the 'SUBSTREAM_TYPE','PCM_TX' and 'PCM_RX' definition. > > There is no need to redefine SNDRV_PCM_STREAM_PLAYBACK as PCM_TX, > the SUBSTREAM_TYPE(substream) can be deleted too, the playback or record can be > judged by 'if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)' directly rather > than 'if (PCM_TX == stype)', which makes the codes easy to read. > > Signed-off-by: Wan ZongShun<mcuos.com(a)gmail.com> > > --- > sound/soc/nuc900/nuc900-ac97.c | 6 +++--- > sound/soc/nuc900/nuc900-auido.h | 4 ---- > sound/soc/nuc900/nuc900-pcm.c | 18 ++++++++++-------- > 3 files changed, 13 insertions(+), 15 deletions(-)

1 0

[alsa-devel] [PATCH] regression 2.6.35-rc1+ hda realtek missing beep 10ec0883
by David Fries 02 Jun '10

02 Jun '10

From: David Fries <david(a)fries.net> The PC-Spekaer Beep control worked in 2.6.34, but not 2.6.35-rc1, this is the patch that modified that behavior. "ALSA: hda - Add parse customize define function for Realtek codecs" regression in commit da00c24493bf6ae3772dfe7343dca033ebc75955. Debug output (after this patch), HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16 SKU: Nid=0x0 sku_cfg=0x0000140d SKU: port_connectivity=0x0 SKU: enable_pcbeep=0x0 SKU: check_sum=0x00000000 SKU: customization=0x00000000 SKU: external_amp=0x1 SKU: platform_type=0x1 SKU: swap=0x0 SKU: override=0x1 hda_codec: ALC883: BIOS auto-probing. autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) hp_outs=0 (0x0/0x0/0x0/0x0/0x0) mono: mono_out=0x0 dig-out=0x1e/0x0 inputs: mic=0x18, fmic=0x0, line=0x1a, fline=0x0, cd=0x1c, aux=0x0 realtek: Enabling init ASM_ID=0x140d CODEC_ID=10ec0883 input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:14.2/input/input16 Signed-off-by: David Fries <david(a)fries.net> Cc: Kailang Yang <kailang(a)realtek.com> Cc: Takashi Iwai <tiwai(a)suse.de> --- My patch restores both the Beep volume and mute. I'll let someone else determine if this is the correct solution or not. sound/pci/hda/patch_realtek.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 17d4548..c31c8b9 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10611,7 +10611,7 @@ static int patch_alc882(struct hda_codec *codec) set_capture_mixer(codec); - if (spec->cdefine.enable_pcbeep) + if (spec->cdefine.enable_pcbeep || codec->vendor_id == 0x10ec0883) set_beep_amp(spec, 0x0b, 0x05, HDA_INPUT); if (board_config == ALC882_AUTO) -- 1.7.1

1 0

Re: [alsa-devel] [RFC PATCH 2/5] OMAP3: McBSP: Change the way how the FIFO is handled
by Peter Ujfalusi 02 Jun '10

02 Jun '10

On Monday 31 May 2010 20:41:12 ext Nishanth Menon wrote: > On 05/31/2010 11:16 AM, Peter Ujfalusi wrote: > > Use the actual FIFO size in words as buffer_size on OMAP2. > > Change the threshold configuration to use 1 based numbering, when > > specifying the allowed threshold maximum or the McBSP threshold value. > > Set the default maximum threshold to (buffer_size - 0x10) intialy. > > > >> From users of McBSP, now it is expected to use this method. > > > > Asking for threshold 1 means that the value written to threshold > > registers are going to be 0, which means 1 word threshold. > > just a 2cent minor comment: maybe omap_mcbsp_platform_data needs > structure documentation.. it might be difficult for folks to figure that > out from commit ID itself.. I can add comments in the mach-omap2/mcbsp.c like this: > > > Signed-off-by: Peter Ujfalusi<peter.ujfalusi(a)nokia.com> > > --- > > > > arch/arm/mach-omap2/mcbsp.c | 10 +++++----- > > arch/arm/plat-omap/mcbsp.c | 10 ++++++---- > > 2 files changed, 11 insertions(+), 9 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c > > index 016fe60..9139958 100644 > > --- a/arch/arm/mach-omap2/mcbsp.c > > +++ b/arch/arm/mach-omap2/mcbsp.c > > @@ -132,7 +132,7 @@ static struct omap_mcbsp_platform_data > > omap34xx_mcbsp_pdata[] = { > > > > .rx_irq = INT_24XX_MCBSP1_IRQ_RX, > > .tx_irq = INT_24XX_MCBSP1_IRQ_TX, > > .ops =&omap2_mcbsp_ops, > > > > - .buffer_size = 0x6F, > > + .buffer_size = 0x80, + .buffer_size = 0x80, /* The FIFO has 128 locations */ > > > > }, > > { > > > > .phys_base = OMAP34XX_MCBSP2_BASE, > > > > @@ -142,7 +142,7 @@ static struct omap_mcbsp_platform_data > > omap34xx_mcbsp_pdata[] = { > > > > .rx_irq = INT_24XX_MCBSP2_IRQ_RX, > > .tx_irq = INT_24XX_MCBSP2_IRQ_TX, > > .ops =&omap2_mcbsp_ops, > > > > - .buffer_size = 0x3FF, > > + .buffer_size = 0x500, + .buffer_size = 0x500, /* The FIFO has 1024 + 256 locations */ > > > > }, > > { > > > > .phys_base = OMAP34XX_MCBSP3_BASE, > > > > @@ -152,7 +152,7 @@ static struct omap_mcbsp_platform_data > > omap34xx_mcbsp_pdata[] = { > > > > .rx_irq = INT_24XX_MCBSP3_IRQ_RX, > > .tx_irq = INT_24XX_MCBSP3_IRQ_TX, > > .ops =&omap2_mcbsp_ops, > > > > - .buffer_size = 0x6F, > > + .buffer_size = 0x80, + .buffer_size = 0x80, /* The FIFO has 128 locations */ > > > > }, > > { > > > > .phys_base = OMAP34XX_MCBSP4_BASE, > > > > @@ -161,7 +161,7 @@ static struct omap_mcbsp_platform_data > > omap34xx_mcbsp_pdata[] = { > > > > .rx_irq = INT_24XX_MCBSP4_IRQ_RX, > > .tx_irq = INT_24XX_MCBSP4_IRQ_TX, > > .ops =&omap2_mcbsp_ops, > > > > - .buffer_size = 0x6F, > > + .buffer_size = 0x80, > > > > }, > > { > > > > .phys_base = OMAP34XX_MCBSP5_BASE, > > > > @@ -170,7 +170,7 @@ static struct omap_mcbsp_platform_data > > omap34xx_mcbsp_pdata[] = { > > > > .rx_irq = INT_24XX_MCBSP5_IRQ_RX, > > .tx_irq = INT_24XX_MCBSP5_IRQ_TX, > > .ops =&omap2_mcbsp_ops, > > > > - .buffer_size = 0x6F, > > + .buffer_size = 0x80, > > > > }, > > > > }; > > #define OMAP34XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap34xx_mcbsp_pdata) > > > > diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c > > index 51d8abf..6462968 100644 > > --- a/arch/arm/plat-omap/mcbsp.c > > +++ b/arch/arm/plat-omap/mcbsp.c > > @@ -497,7 +497,8 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16 > > threshold) > > > > } > > mcbsp = id_to_mcbsp_ptr(id); > > > > - MCBSP_WRITE(mcbsp, THRSH2, threshold); > > + if (threshold&& threshold<= mcbsp->max_tx_thres) > > + MCBSP_WRITE(mcbsp, THRSH2, threshold - 1); > > > > } > > EXPORT_SYMBOL(omap_mcbsp_set_tx_threshold); > > > > @@ -519,7 +520,8 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16 > > threshold) > > > > } > > mcbsp = id_to_mcbsp_ptr(id); > > > > - MCBSP_WRITE(mcbsp, THRSH1, threshold); > > + if (threshold&& threshold<= mcbsp->max_rx_thres) > > + MCBSP_WRITE(mcbsp, THRSH1, threshold - 1); > > > > } > > EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold); > > > > @@ -1696,8 +1698,8 @@ static inline void __devinit > > omap34xx_device_init(struct omap_mcbsp *mcbsp) > > > > { > > > > mcbsp->dma_op_mode = MCBSP_DMA_MODE_ELEMENT; > > if (cpu_is_omap34xx()) { > > > > - mcbsp->max_tx_thres = max_thres(mcbsp); > > - mcbsp->max_rx_thres = max_thres(mcbsp); > > + mcbsp->max_tx_thres = max_thres(mcbsp) - 0x10; > > + mcbsp->max_rx_thres = max_thres(mcbsp) - 0x10; > > > > /* > > > > * REVISIT: Set dmap_op_mode to THRESHOLD as default > > * for mcbsp2 instances. Is this sufficient? -- Péter

2 1

[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