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

[alsa-devel] Problem about developing WM8974 audio driver for MX27ipcam
by Jie Jiang 08 May '10

08 May '10

Hi all, I'm developing a driver for wm8974 codec with Freescale mx27ipcam board with linux kernel 2.6.19.2. Our work is based on the mx27vis-wm8974 driver available in alsa-driver-1.0.22. After installing all necessary driver modules, when I trying to playback some wav file using "cat xx.wav > /dev/dsp" command, I got the following error message: "ALSA pcm_lib.c:1709: playback write error (DMA or IRQ trouble?)". This seems to be caused by the full of the transmitting buffer since I can check that "hw_ptr=0x800/buffer_size=0x4000/appl_ptr=0x4800". The hw_ptw doesn't update anymore. It seems that there is something wrong with the DMA operation. Actually, the DMA dest. address is the SSI1's TX0 FIFO. On the other hand, SSI1's SFCSR=0x440844, which indicates that there are 8 bytes data in the TX0 FIFO, which will not generate DMA request as the FIFO empty watermark is 4. It is very possible that the SSI1 does not shift data from the FIFO, which causes no DMA request generated and thus DMA freezes. Our board connects wm8974 codec to mx27 gpio PC20~23 pins (signal name are SSI1_XXX). On these io pins, we can check the FS and bit clock have been generated. The PC20~PC23 gpio pins have been configure as SSI function. My driver also configures AUDMUX host port1(HP1,wired to SSI1 internally) to peripheral port 1(PP1). But I'm not sure whether PP1 is mapped to PC20~23. Is this configuration right? If this map is wrong, the FS and Bit Clock generated by wm8974 can not be routed to SSI1 module, which is the potential reason for no data are shifted. Who can shed some light on the map between mx27 AUDMUX port and GPIO pins? Any more possible reasons which will freeze DMA transfer? Regards, Jie

2 1

[alsa-devel] [PATCH 1/2] es1968: Clear interrupts before enabling them
by Ville Syrjala 08 May '10

08 May '10

From: Ville Syrjälä <syrjala(a)sci.fi> Avoid spurious interrupts when initializing the device. Signed-off-by: Ville Syrjälä <syrjala(a)sci.fi> --- sound/pci/es1968.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index aa973ce..23a58f0 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -2401,6 +2401,7 @@ static void snd_es1968_start_irq(struct es1968 *chip) w = ESM_HIRQ_DSIE | ESM_HIRQ_HW_VOLUME; if (chip->rmidi) w |= ESM_HIRQ_MPU401; + outb(w, chip->io_port + 0x1A); outw(w, chip->io_port + ESM_PORT_HOST_IRQ); } -- 1.6.4.4

2 2

[alsa-devel] ASoC updates for 2.6.35
by Mark Brown 08 May '10

08 May '10

The following changes since commit aeb29a82de7c80d4d0253b042f17eb1f725b08f1: Takashi Iwai (1): Merge branch 'for-2.6.35' of git://git.kernel.org/.../lrg/asoc-2.6 into topic/asoc are available in the git repository at: git://opensource.wolfsonmicro.com/linux-2.6-asoc for-2.6.35 Note the change in git server - master.kernel.org appears to be having issues at the minute. Jassi Brar (12): ASoC: S3C: I2Sv2: Move defines closer to driver ASoC: SAMSUNG: I2S: Add bit definitions ASoC: S3C2412: I2S: Debug IMS field ASoC: S3C2412: I2S: Return correct source clock ASoC: S3C: I2Sv2: Discard redundant field iis_clk ASoC: S3C: I2Sv2: Unify i2s_get_clock callback ASoC: S3C64XX: I2S: Use s3c2412 defines ASoC: S3C: I2Sv2: New field for controller feature ASoC: S3C: I2S: Move set_sysclk to common code ARM: S3C2412: DMA: Remove I2S FIFO address ASoC: S3C64XX: IISv4: Add CPU driver ASoC: SMDK64XX: Switch to IISv4 CPU driver Mark Brown (2): ASoC: Add debug output tracing all cache register writes Merge branch 'topic/asoc' of git://git.kernel.org/.../tiwai/sound-2.6 into for-2.6.35 Peter Ujfalusi (3): ASoC: core: Support for limiting the volume Revert "ASoC: tpa6130a2: Support for limiting gain" ASoC: tpa6130a2: Fix for the custom kcontrol functions arch/arm/mach-s3c2412/dma.c | 3 - .../plat-samsung/include/plat/regs-s3c2412-iis.h | 82 -------- include/sound/soc.h | 2 + include/sound/tpa6130a2-plat.h | 1 - sound/soc/codecs/tpa6130a2.c | 90 ++------- sound/soc/s3c24xx/Kconfig | 12 +- sound/soc/s3c24xx/Makefile | 2 + sound/soc/s3c24xx/jive_wm8750.c | 2 +- sound/soc/s3c24xx/regs-i2s-v2.h | 115 +++++++++++ sound/soc/s3c24xx/s3c-i2s-v2.c | 87 ++++++--- sound/soc/s3c24xx/s3c-i2s-v2.h | 11 +- sound/soc/s3c24xx/s3c2412-i2s.c | 41 +---- sound/soc/s3c24xx/s3c2412-i2s.h | 2 - sound/soc/s3c24xx/s3c64xx-i2s-v4.c | 209 ++++++++++++++++++++ sound/soc/s3c24xx/s3c64xx-i2s.c | 57 +----- sound/soc/s3c24xx/s3c64xx-i2s.h | 3 +- sound/soc/s3c24xx/smdk64xx_wm8580.c | 6 +- sound/soc/soc-cache.c | 12 ++ sound/soc/soc-core.c | 39 ++++ 19 files changed, 484 insertions(+), 292 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-s3c2412-iis.h create mode 100644 sound/soc/s3c24xx/regs-i2s-v2.h create mode 100644 sound/soc/s3c24xx/s3c64xx-i2s-v4.c

2 1

[alsa-devel] [PATCH 0/2] ASoC: tpa6130a2: Use the core to set the gain limit
by Peter Ujfalusi 07 May '10

07 May '10

Hello, Core will receive support for limiting the volume on controls, so the custom way of doing it in the tpa driver is no longer needed. There was also a problem within the tpa driver when custom limit has been configured. The second patch fixes that. The combination of the snd_soc_limit_volume, and this series works really nicely together. --- Peter Ujfalusi (2): Revert "ASoC: tpa6130a2: Support for limiting gain" ASoC: tpa6130a2: Fix for the custom kcontrol functions include/sound/tpa6130a2-plat.h | 1 - sound/soc/codecs/tpa6130a2.c | 90 +++++++-------------------------------- 2 files changed, 16 insertions(+), 75 deletions(-)

2 3

[alsa-devel] [PATCH] ASoC: tpa6130a2: Support for limiting gain
by Peter Ujfalusi 07 May '10

07 May '10

Add support for platform dependent gain limiting on the tpa6130a2 (and tpa6140a2) Headset amplifier. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- include/sound/tpa6130a2-plat.h | 1 + sound/soc/codecs/tpa6130a2.c | 76 +++++++++++++++++++++++++++++++++++---- 2 files changed, 69 insertions(+), 8 deletions(-) diff --git a/include/sound/tpa6130a2-plat.h b/include/sound/tpa6130a2-plat.h index e29fde6..426f627 100644 --- a/include/sound/tpa6130a2-plat.h +++ b/include/sound/tpa6130a2-plat.h @@ -31,6 +31,7 @@ enum tpa_model { struct tpa6130a2_platform_data { enum tpa_model id; int power_gpio; + int limit_gain; }; #endif diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c index 0cf3e38..31f67b5 100644 --- a/sound/soc/codecs/tpa6130a2.c +++ b/sound/soc/codecs/tpa6130a2.c @@ -46,6 +46,9 @@ static const char *tpa6140a2_supply_names[TPA6130A2_NUM_SUPPLIES] = { "AVdd", }; +#define TPA6130A2_GAIN_MAX 0x3f +#define TPA6140A2_GAIN_MAX 0x1f + /* This struct is used to save the context */ struct tpa6130a2_data { struct mutex mutex; @@ -54,6 +57,7 @@ struct tpa6130a2_data { int power_gpio; unsigned char power_state; enum tpa_model id; + int gain_limit; }; static int tpa6130a2_i2c_read(int reg) @@ -176,6 +180,40 @@ exit: return ret; } +static int tpa6130a2_info_volsw(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + struct soc_mixer_control *mc = + (struct soc_mixer_control *)kcontrol->private_value; + struct tpa6130a2_data *data; + + BUG_ON(tpa6130a2_client == NULL); + data = i2c_get_clientdata(tpa6130a2_client); + + mutex_lock(&data->mutex); + switch (mc->reg) { + case TPA6130A2_REG_VOL_MUTE: + if (data->gain_limit != mc->max) + mc->max = data->gain_limit; + break; + default: + dev_err(&tpa6130a2_client->dev, + "Invalid register: 0x02%x\n", mc->reg); + goto out; + } + if (unlikely(mc->max == 1)) + uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; + else + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; + + uinfo->count = 1; + uinfo->value.integer.min = 0; + uinfo->value.integer.max = mc->max; +out: + mutex_unlock(&data->mutex); + return 0; +} + static int tpa6130a2_get_reg(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { @@ -239,6 +277,15 @@ static int tpa6130a2_set_reg(struct snd_kcontrol *kcontrol, return 1; } +#define SOC_SINGLE_EXT_TLV_TPA(xname, xreg, xshift, xmax, xinvert, tlv_array) \ +{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \ + .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ |\ + SNDRV_CTL_ELEM_ACCESS_READWRITE,\ + .tlv.p = (tlv_array), \ + .info = tpa6130a2_info_volsw, \ + .get = tpa6130a2_get_reg, .put = tpa6130a2_set_reg, \ + .private_value = SOC_SINGLE_VALUE(xreg, xshift, xmax, xinvert) } + /* * TPA6130 volume. From -59.5 to 4 dB with increasing step size when going * down in gain. @@ -258,10 +305,9 @@ static const unsigned int tpa6130_tlv[] = { }; static const struct snd_kcontrol_new tpa6130a2_controls[] = { - SOC_SINGLE_EXT_TLV("TPA6130A2 Headphone Playback Volume", - TPA6130A2_REG_VOL_MUTE, 0, 0x3f, 0, - tpa6130a2_get_reg, tpa6130a2_set_reg, - tpa6130_tlv), + SOC_SINGLE_EXT_TLV_TPA("TPA6130A2 Headphone Playback Volume", + TPA6130A2_REG_VOL_MUTE, 0, TPA6130A2_GAIN_MAX, 0, + tpa6130_tlv), }; static const unsigned int tpa6140_tlv[] = { @@ -272,10 +318,9 @@ static const unsigned int tpa6140_tlv[] = { }; static const struct snd_kcontrol_new tpa6140a2_controls[] = { - SOC_SINGLE_EXT_TLV("TPA6140A2 Headphone Playback Volume", - TPA6130A2_REG_VOL_MUTE, 1, 0x1f, 0, - tpa6130a2_get_reg, tpa6130a2_set_reg, - tpa6140_tlv), + SOC_SINGLE_EXT_TLV_TPA("TPA6140A2 Headphone Playback Volume", + TPA6130A2_REG_VOL_MUTE, 1, TPA6140A2_GAIN_MAX, 0, + tpa6140_tlv), }; /* @@ -454,16 +499,31 @@ static int __devinit tpa6130a2_probe(struct i2c_client *client, case TPA6130A2: for (i = 0; i < ARRAY_SIZE(data->supplies); i++) data->supplies[i].supply = tpa6130a2_supply_names[i]; + if (pdata->limit_gain > 0 && + pdata->limit_gain < TPA6130A2_GAIN_MAX) + data->gain_limit = pdata->limit_gain; + else + data->gain_limit = TPA6130A2_GAIN_MAX; break; case TPA6140A2: for (i = 0; i < ARRAY_SIZE(data->supplies); i++) data->supplies[i].supply = tpa6140a2_supply_names[i];; + if (pdata->limit_gain > 0 && + pdata->limit_gain < TPA6140A2_GAIN_MAX) + data->gain_limit = pdata->limit_gain; + else + data->gain_limit = TPA6140A2_GAIN_MAX; break; default: dev_warn(dev, "Unknown TPA model (%d). Assuming 6130A2\n", pdata->id); for (i = 0; i < ARRAY_SIZE(data->supplies); i++) data->supplies[i].supply = tpa6130a2_supply_names[i]; + if (pdata->limit_gain > 0 && + pdata->limit_gain < TPA6130A2_GAIN_MAX) + data->gain_limit = pdata->limit_gain; + else + data->gain_limit = TPA6130A2_GAIN_MAX; } ret = regulator_bulk_get(dev, ARRAY_SIZE(data->supplies), -- 1.7.1

3 4

[alsa-devel] [Patches_v2] Reforming S3C I2S towards supporting I2Sv4
by Jassi Brar 07 May '10

07 May '10

I am going to resubmit pending last 11 patches of the original series http://mailman.alsa-project.org/pipermail/alsa-devel/2010-March/025920.html No changes have been made other than moving dma_data from snd_soc_dai to snd_soc_pcm_stream in the new I2Sv4 controller driver.

4 5

Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems
by Daniel Mack 07 May '10

07 May '10

On Fri, May 07, 2010 at 01:47:56PM +0200, Oliver Neukum wrote: > Am Freitag, 7. Mai 2010 13:42:34 schrieb Oliver Neukum: > > Am Freitag, 7. Mai 2010 11:47:37 schrieb Clemens Ladisch: > > > > In the particular case of audio drivers, though, the contents of the > > > > buffers are likely to change after the submission. What we do here > > > > is that we map the audio stream buffers which are used by ALSA to > > > > the output URBs, so they're filled asychronously. Once the buffer is > > > > actually sent out on the bus, it is believed to contain proper audio > > > > date. If it doesn't, that's due to too tight audio timing or other > > > > problems. This breaks once buffers are magically bounced in the > > > > background. > > > > > > At least the audio class and ua101 drivers don't do this and fill the > > > buffers before they are submitted. > > > > > > > So - long story short: these audio buffers need to be DMA coherent. > > > > > > Does the USB API actually guarantee that all controllers use DMA, i.e., > > > that the buffers can be filled after submission? > > > > No, you must not touch buffers after submission. This does not even > > work if we use DMA, because on some architectures this violates > > guarantees to the dma primitives. It cannot be done. We do such tricks on other OS where IRQ latency as high as some tens of milliseconds. So we queue EHCI transfers well in advance and update access their contents (for both input and output) from audio context. I considered implementing this idea to the Linux USB audio driver as well. > Or to be precise it could be done with coherent memory, but you'd risk > transfering partially updated buffers, as you cannot know when DMA will > be done and we don't guarantee that DMA will be done right as we transfer. If the memory is coherent, it should be possible. And if buffers are only partially updated, the audio buffer scheduling is too tight. IOW, the configured buffer size of audio clients in userspace is too small. This is OT now I believe, I will start another thread for this topic once I have something to show. Thanks, Daniel

1 0

Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems
by Daniel Mack 07 May '10

07 May '10

On Tue, Apr 20, 2010 at 01:16:58AM +0100, Pedro Ribeiro wrote: > On 15 April 2010 16:20, Alan Stern <stern(a)rowland.harvard.edu> wrote: > > On Thu, 15 Apr 2010, Pedro Ribeiro wrote: > > > >> I enabled CONFIG_DMAR_BROKEN_GFX_WA=y and the result is the same. A > >> delay in the boot process and usb devices don't work properly, > >> including my USB mouse. > >> > >> Strange, since you have the same platform as me. The extra usb devices > >> you were seeing are because of my docking station - but it makes no > >> difference whether I'm docked or not for the purposes of the original > >> bug or this situation right now. The dmesg I'm attaching is without > >> the computer being docked. > > > > It's not possible to determine the reason for the timeout errors > > between timestamps 16 and 53 from the small amount of debugging > > information in the log. Clearly something is going wrong with the > > communication between the computer and the EHCI controller. And > > clearly the kernel config changes are responsible. > > > > But I don't know what to do to track it down any farther. > > > > Alan Stern > > > > > > I guess this is pretty much a dead end until anyone else can reproduce it! Hmm, I think I finally found the reason for all this confusion. No idea why I didn't come up with the following explanation any earlier. The problem is again (summarized): On 64bit machines, with 4GB or more, the allocated buffers for USB transfers might be beyond the 32bit boundary. In this case, the IOMMU should take care and install DMA bounce buffer to copy over the buffer before the transfer actually happens. The problem is, however, that this copy mechanism takes place when the URB with its associated buffer is submitted, not when the EHCI will actually do the transfer. In the particular case of audio drivers, though, the contents of the buffers are likely to change after the submission. What we do here is that we map the audio stream buffers which are used by ALSA to the output URBs, so they're filled asychronously. Once the buffer is actually sent out on the bus, it is believed to contain proper audio date. If it doesn't, that's due to too tight audio timing or other problems. This breaks once buffers are magically bounced in the background. So - long story short: these audio buffers need to be DMA coherent. The patch below does that, and Pedro excessively tested this patch for weeks now :) It was just the final explanation _why_ it does the right thing that was yet missing. If nobody has objections, can we still squeeze it into .34? Thanks, Daniel

2 2

[alsa-devel] [PATCH RFC v1] ASoC: core: Support for limiting the volume
by Peter Ujfalusi 07 May '10

07 May '10

Add support for the core to limit the maximum volume on an existing control. The function will modify the soc_mixer_control.max value of the given control. The new value must be lower than the original one (chip maximum) If there is a need for limiting a gain on a given control, than machine drivers can do the following in their snd_soc_dai_link.init function: snd_soc_limit_volume(codec, "TPA6140A2 Headphone Playback Volume", 21); This will modify the original 31 (chip maximum) to 21, so user space will not be able to set the gain higher than this. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- Hello Mark, Liam, So this is my proposed way of doing the volume limiting within the core. By looking around the code, this should be safe. With this simple function all machine driver can limit gains on a given control in a way, that the codec/amp driver does not need to be involved. What do you think? --- Peter include/sound/soc.h | 2 ++ sound/soc/soc-core.c | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 0 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 01e9c66..9f306f0 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -326,6 +326,8 @@ int snd_soc_get_volsw_s8(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); int snd_soc_put_volsw_s8(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol); +int snd_soc_limit_volume(struct snd_soc_codec *codec, + const char *name, int max); /** * struct snd_soc_jack_pin - Describes a pin to update based on jack detection diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index d59076e..5968499 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2238,6 +2238,44 @@ int snd_soc_put_volsw_s8(struct snd_kcontrol *kcontrol, EXPORT_SYMBOL_GPL(snd_soc_put_volsw_s8); /** + * snd_soc_limit_volume - Set new limit to an existing volume control. + * + * @codec: where to look for the control + * @name: Name of the control + * @max: new maximum limit + * + * Return 0 for success, else error. + */ +int snd_soc_limit_volume(struct snd_soc_codec *codec, + const char *name, int max) +{ + struct snd_card *card = codec->card; + struct snd_kcontrol *kctl; + struct soc_mixer_control *mc; + int found = 0; + int ret = -EINVAL; + + /* Sanity check for name and max */ + if (unlikely(!name || max <= 0)) + return -EINVAL; + + list_for_each_entry(kctl, &card->controls, list) { + if (!strncmp(kctl->id.name, name, sizeof(kctl->id.name))) { + found = 1; + break; + } + } + if (found) { + mc = (struct soc_mixer_control *)kctl->private_value; + if (max < mc->max) + mc->max = max; + ret = 0; + } + return ret; +} +EXPORT_SYMBOL_GPL(snd_soc_limit_volume); + +/** * snd_soc_dai_set_sysclk - configure DAI system or master clock. * @dai: DAI * @clk_id: DAI specific clock ID -- 1.7.1

2 4

[alsa-devel] [PATCH][BUGFIX for .33 and .34] hda - fix DG45ID SPDIF output
by Wu Fengguang 07 May '10

07 May '10

This reverts part of commit 52dc438606d1e, in order to fix a regression: broken SPDIF output on Intel DG45FC motherboard (IDT 92HD73E1X5 codec). --- DG45FC-IDT-codec-2.6.32 (SPDIF OK) +++ DG45FC-IDT-codec-2.6.33 (SPDIF broken) Node 0x22 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x00000010: OUT - Pin Default 0x40f000f0: [N/A] Other at Ext N/A - Conn = Unknown, Color = Unknown - DefAssociation = 0xf, Sequence = 0x0 - Pin-ctls: 0x00: + Pin Default 0x014510a0: [Jack] SPDIF Out at Ext Rear + Conn = Optical, Color = Black + DefAssociation = 0xa, Sequence = 0x0 + Pin-ctls: 0x40: OUT Connection: 3 0x25* 0x20 0x21 Node 0x23 [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x00000010: OUT - Pin Default 0x01451140: [Jack] SPDIF Out at Ext Rear + Pin Default 0x074510b0: [Jack] SPDIF Out at Ext Rear Panel Conn = Optical, Color = Black - DefAssociation = 0x4, Sequence = 0x0 - Misc = NO_PRESENCE - Pin-ctls: 0x40: OUT + DefAssociation = 0xb, Sequence = 0x0 + Pin-ctls: 0x00: Connection: 3 0x26* 0x20 0x21 CC: <stable(a)kernel.org> CC: Alexey Fisher <bug-track(a)fisher-privat.net> Tested-by: David Härdeman <david(a)hardeman.nu> Signed-off-by: Wu Fengguang <fengguang.wu(a)intel.com> --- sound/pci/hda/patch_sigmatel.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- sound-2.6.orig/sound/pci/hda/patch_sigmatel.c 2010-05-06 18:10:30.000000000 +0800 +++ sound-2.6/sound/pci/hda/patch_sigmatel.c 2010-05-06 19:34:48.000000000 +0800 @@ -1544,11 +1544,9 @@ static unsigned int alienware_m17x_pin_c 0x904601b0, }; -static unsigned int intel_dg45id_pin_configs[14] = { +static unsigned int intel_dg45id_pin_configs[13] = { 0x02214230, 0x02A19240, 0x01013214, 0x01014210, - 0x01A19250, 0x01011212, 0x01016211, 0x40f000f0, - 0x40f000f0, 0x40f000f0, 0x40f000f0, 0x014510A0, - 0x074510B0, 0x40f000f0 + 0x01A19250, 0x01011212, 0x01016211 }; static unsigned int *stac92hd73xx_brd_tbl[STAC_92HD73XX_MODELS] = {

2 1