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

[alsa-devel] 2.6.34-rc: sound hungs (ice1724)
by Alexander Beregalov 06 Jun '10

06 Jun '10

Hi Takashi Could you please help me how to debug an issue. Sometimes soung hungs, it happens few days (up to a week) after boot. I have no idea how to reproduce it or how to debug it. That's why it is very hard to bisect, I have not tried, the better way should exist. The problem appeared somewhere after 2.6.33. Card is M-Audio Revo 5.1 (1412:1724). After it hungs ALSA continues to play last sound frame forever. When I try to play something else playing frame changes. Only reboot heals it. rmmod hungs at INFO: task rmmod:30356 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. rmmod D db281e7c 0 30356 2345 0x00000004 db281e8c 00000086 00000002 db281e7c cc2d7b90 00000000 c14e8b80 09c3638a c10252a0 00000001 c14e2000 c14e2000 c14e8b80 c14e8b80 cc2d7a00 db281e8c 00000246 db281e8c c1043d23 00000001 f6923000 f69231b4 db281e9c db281ebc Call Trace: [<c10252a0>] ? __wake_up+0x40/0x50 [<c1043d23>] ? prepare_to_wait+0x43/0x70 [<f8ce328d>] snd_card_free+0x5d/0x90 [snd] [<c1043af0>] ? autoremove_wake_function+0x0/0x40 [<f9ebcaa6>] snd_vt1724_remove+0x13/0x25 [snd_ice1724] [<c11cddb9>] pci_device_remove+0x19/0x40 [<c1239f3e>] __device_release_driver+0x3e/0x90 [<c123a017>] driver_detach+0x87/0x90 [<c1239323>] bus_remove_driver+0x63/0xa0 [<c123a526>] driver_unregister+0x46/0x80 [<c10d616d>] ? sysfs_remove_file+0xd/0x10 [<c11cdfed>] pci_unregister_driver+0x2d/0x80 [<f9ebca91>] alsa_card_ice1724_exit+0xd/0xf [snd_ice1724] [<c1057bee>] sys_delete_module+0x15e/0x210 [<c107f91f>] ? remove_vma+0x3f/0x60 [<c1080902>] ? do_munmap+0x202/0x2d0 [<c1002b50>] sysenter_do_call+0x12/0x26 CONFIG_SOUND=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_VMASTER=y CONFIG_SND_DMA_SGBUF=y CONFIG_SND_AC97_CODEC=m CONFIG_SND_PCI=y CONFIG_SND_ICE1724=m

2 3

[alsa-devel] [PATCH v2 1/4] imx-ssi.c: add new choices to platform configuration
by Eric Bénard 03 Jun '10

03 Jun '10

* introduce 3 new flags to allow a more detailed configuration of the SSI link : IMX_SSI_NET : enable Network Mode IMX_SSI_SYN : enable Synchronous Mode IMX_SSI_USE_I2S_SLAVE : enable I2S Slave Mode * new platform can use these settings without breaking actual platforms. Signed-off-by: Eric Bénard <eric(a)eukrea.com> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg(a)slimlogic.co.uk> --- arch/arm/plat-mxc/include/mach/ssi.h | 3 +++ sound/soc/imx/imx-ssi.c | 11 +++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-mxc/include/mach/ssi.h b/arch/arm/plat-mxc/include/mach/ssi.h index c34ded5..63f3c28 100644 --- a/arch/arm/plat-mxc/include/mach/ssi.h +++ b/arch/arm/plat-mxc/include/mach/ssi.h @@ -10,6 +10,9 @@ struct imx_ssi_platform_data { unsigned int flags; #define IMX_SSI_DMA (1 << 0) #define IMX_SSI_USE_AC97 (1 << 1) +#define IMX_SSI_NET (1 << 2) +#define IMX_SSI_SYN (1 << 3) +#define IMX_SSI_USE_I2S_SLAVE (1 << 4) void (*ac97_reset) (struct snd_ac97 *ac97); void (*ac97_warm_reset)(struct snd_ac97 *ac97); }; diff --git a/sound/soc/imx/imx-ssi.c b/sound/soc/imx/imx-ssi.c index 80b4fee..50f5162 100644 --- a/sound/soc/imx/imx-ssi.c +++ b/sound/soc/imx/imx-ssi.c @@ -83,8 +83,6 @@ static int imx_ssi_set_dai_tdm_slot(struct snd_soc_dai *cpu_dai, /* * SSI DAI format configuration. * Should only be called when port is inactive (i.e. SSIEN = 0). - * Note: We don't use the I2S modes but instead manually configure the - * SSI for I2S because the I2S mode is only a register preset. */ static int imx_ssi_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt) { @@ -99,6 +97,10 @@ static int imx_ssi_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt) /* data on rising edge of bclk, frame low 1clk before data */ strcr |= SSI_STCR_TFSI | SSI_STCR_TEFS | SSI_STCR_TXBIT0; scr |= SSI_SCR_NET; + if (ssi->flags & IMX_SSI_USE_I2S_SLAVE) { + scr &= ~SSI_I2S_MODE_MASK; + scr |= SSI_SCR_I2S_MODE_SLAVE; + } break; case SND_SOC_DAIFMT_LEFT_J: /* data on rising edge of bclk, frame high with data */ @@ -143,6 +145,11 @@ static int imx_ssi_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt) strcr |= SSI_STCR_TFEN0; + if (ssi->flags & IMX_SSI_NET) + scr |= SSI_SCR_NET; + if (ssi->flags & IMX_SSI_SYN) + scr |= SSI_SCR_SYN; + writel(strcr, ssi->base + SSI_STCR); writel(strcr, ssi->base + SSI_SRCR); writel(scr, ssi->base + SSI_SCR); -- 1.6.3.3

4 13

[alsa-devel] ASoC: Hooking a TI CODEC to a i.MX27 MCU
by Stuart Longland 03 Jun '10

03 Jun '10

Hi all, I'm trying to write a new machine driver and CODEC driver for a device we're building, and as yet, haven't figured out the magic that gets ALSA to enumerate all the devices on the board. I hope to be able to release any code here back to the community, but I probably need to clear it with a few people first (and it'd be nice to contribute _working_ code). Scenario: MCU is a Freescale i.MX27 processor on a Ka-Ro TX27 module CODEC is a Texas Instruments TLV320AIC3204, control via I²C, data via I²S. Chip ID for this CODEC is locked at 0x18. Kernel is 2.6.34, userland is Gentoo/ARM via root-over-NFS. My goal: Just to get audio being transmitted along the I²S bus. (Don't care about mixers, etc.) So far my only means of debugging everything is to sprinkle the code liberally with printk's everywhere... crude, but it gives me some idea what's going on. The CODEC driver is at this moment, an empty shell based on the TLV320AIC3x driver already in the tree. I've tried basing a machine driver on the rx51 driver -- substituting the TLV320AIC3x driver for my own shell driver, and swapping the original cpu_dai configuration for the i.MX driver. I suspect this machine driver is giving me grief. My machine code setup is as follows: /* Digital audio interface glue - connects codec <--> CPU */ static struct snd_soc_dai_link jem3_dai[] = { { .name = "TLV320AIC3204", .stream_name = "AIC3204", .cpu_dai = &imx_ssi_pcm_dai[0], .codec_dai = &aic3204_dai, .init = jem3_aic3204_init, .ops = &jem3_ops, }, }; /* Audio private data */ static struct aic3204_setup_data jem3_aic3204_setup = { .gpio_func[0] = AIC3204_GPIO1_FUNC_DISABLED, .gpio_func[1] = AIC3204_GPIO2_FUNC_DIGITAL_MIC_INPUT, }; /* Audio card */ static struct snd_soc_card jem3_sound_card = { .name = "JEM3", .dai_link = jem3_dai, .num_links = ARRAY_SIZE(jem3_dai), .platform = &imx_soc_platform, }; /* Audio subsystem */ static struct snd_soc_device jem3_snd_devdata = { .card = &jem3_sound_card, .codec_dev = &soc_codec_dev_aic3204, .codec_data = &jem3_aic3204_setup, }; static struct platform_device *jem3_snd_device; static int __init jem3_soc_init(void) { int err; printk( KERN_INFO "%s: hello...\n", __FUNCTION__ ); jem3_snd_device = platform_device_alloc("soc-audio", -1); printk( KERN_INFO "%s: jem3_snd_device = %p\n", __FUNCTION__, jem3_snd_device ); if (!jem3_snd_device) { err = -ENOMEM; goto err1; } printk( KERN_INFO "%s: calling platform_set_drvdata( %p, %p )\n", __FUNCTION__, jem3_snd_device, &jem3_snd_devdata ); platform_set_drvdata(jem3_snd_device, &jem3_snd_devdata); jem3_snd_devdata.dev = &jem3_snd_device->dev; printk( KERN_INFO "%s: calling platform_device_add(%p)\n", __FUNCTION__, jem3_snd_device ); err = platform_device_add(jem3_snd_device); printk( KERN_INFO "%s: platform_device_add(%p) = %d\n", __FUNCTION__, jem3_snd_device, err ); if (err) goto err2; printk( KERN_INFO "%s = 0 (success)\n", __FUNCTION__ ); return 0; err2: platform_device_put(jem3_snd_device); err1: printk( KERN_INFO "%s = %d\n", __FUNCTION__, err ); return err; } Now this compiles... but when I go to load it; one of two things happens... either practically nothing (at this stage; no modules are loaded prior to calling modprobe): 192 / # modprobe snd-soc-jem3 aic3204_i2c_init: adding driver at bf068f9c aic3204_i2c_init: i2c_add_driver(bf068f9c) = 0 jem3_soc_init: hello... jem3_soc_init: jem3_snd_device = c3c600a0 jem3_soc_init: calling platform_set_drvdata( c3c600a0, bf07a780 ) jem3_soc_init: calling platform_device_add(c3c600a0) jem3_soc_init: platform_device_add(c3c600a0) = 0 jem3_soc_init = 0 (success) 192 / # mount /proc 192 / # cat /proc/asound/cards --- no soundcards --- ... Or it goes kaboom... particularly if I rmmod the snd-soc-jem3 module, but leave snd-soc-tlv320aic3204 in place... 192 / # rmmod snd-soc-jem3 jem3_soc_exit: unregistering... jem3_soc_exit: goodbye 192 / # modprobe snd-soc-jem3 jem3_soc_init: hello... jem3_soc_init: jem3_snd_device = c3c600a0 jem3_soc_init: calling platform_set_drvdata( c3c600a0, bf080780 ) jem3_soc_init: calling platform_device_add(c3c600a0) Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c3e44000 [00000008] *pgd=a3e62031, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT last sysfs file: Modules linked in: snd_soc_jem3(+) snd_soc_imx snd_soc_tlv320aic3204 snd_soc_core snd_pcm snd_timer snd soundcore snd_page_alloc ac97_bus [last unloaded: snd_soc_jem3] CPU: 0 Not tainted (2.6.34-jacques-jem3 #16) PC is at snd_soc_instantiate_cards+0x2c/0x7b4 [snd_soc_core] LR is at 0x0 pc : [<bf0513d8>] lr : [<00000000>] psr: 20000013 sp : c3e33db0 ip : bf05906c fp : bf059074 r10: 00000001 r9 : bf058fd0 r8 : 00000000 r7 : bf07a790 r6 : c3c600a8 r5 : bf072960 r4 : bf059074 r3 : 00000000 r2 : 00000000 r1 : bf072960 r0 : bf059074 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: a3e44000 DAC: 00000015 Process modprobe (pid: 278, stack limit = 0xc3e32270) Stack: (0xc3e33db0 to 0xc3e34000) 3da0: c3e33dec 00000001 c3c600a8 00000000 3dc0: bf0687c8 00000000 c034f1c8 00000000 c3e32000 c0167c18 c02eee78 c3e33e34 3de0: c3e33e6c c3c0e7a8 00000000 c0275b24 c3c15040 c003a008 c3c15040 000000d0 3e00: c02e2fbc c3e32000 c3eae9c8 c3e85428 c3e33e34 00000008 c034f1dc c3eafac0 3e20: c3eafac0 c3e85428 c3eae9c8 c00f2674 00000000 0000072d c3e33e60 c3eae9c8 3e40: c3e85428 c00f2724 c0355190 00000000 c3eae9c8 bf080790 bf080798 c3c600a8 3e60: 00000000 c3c600b0 00000000 c033ec88 00000000 bf052ed0 c0355190 c3c600a8 3e80: c3e33eb0 bf059020 c0355190 c01ac47c bf059020 c01ab394 c3c600a8 00000000 3ea0: c3e33eb0 c3c600a8 c01ab548 c01aa628 c3c044e8 c3e76ad4 c02de99c c3c600a8 3ec0: c3c600a8 c3c600dc 00000000 c01ab5f4 c3c600a8 c3c600a8 00000000 c01aa5a8 3ee0: 00000000 c01a8c20 bf080870 c3c600b0 c3c600b0 00000000 00000000 c0168c18 3f00: c3c600a8 c3c600a8 c3c600a0 00000000 bf083000 c0021b88 00000000 c034578c 3f20: 000192dc c01acaa0 c3c600a8 bf0809ac fffffff4 bf080780 bf083000 bf083090 3f40: 000020f1 bf080864 c3e32000 c0021374 00000000 00000000 00000000 000020f1 3f60: bf080864 00021388 000020f1 bf080864 00021388 00000000 c0021b88 c3e32000 3f80: 00000000 c006e48c 00000001 00000000 00019738 0000cf60 000190b0 00019330 3fa0: 00000080 c00219e0 0000cf60 000190b0 00021388 000020f1 00019370 00019370 3fc0: 0000cf60 000190b0 00019330 00000080 00000000 bec39994 00000000 000192dc 3fe0: 000192d0 bec39524 0000bc98 4010ab44 60000010 00021388 00ffff00 00ffff00 [<bf0513d8>] (snd_soc_instantiate_cards+0x2c/0x7b4 [snd_soc_core]) from [<bf052ed0>] (soc_probe+0x74/0xb0 [snd_soc_core]) [<bf052ed0>] (soc_probe+0x74/0xb0 [snd_soc_core]) from [<c01ac47c>] (platform_drv_probe+0x1c/0x24) [<c01ac47c>] (platform_drv_probe+0x1c/0x24) from [<c01ab394>] (driver_probe_device+0x88/0x180) [<c01ab394>] (driver_probe_device+0x88/0x180) from [<c01aa628>] (bus_for_each_drv+0x60/0x8c) [<c01aa628>] (bus_for_each_drv+0x60/0x8c) from [<c01ab5f4>] (device_attach+0x5c/0x74) [<c01ab5f4>] (device_attach+0x5c/0x74) from [<c01aa5a8>] (bus_probe_device+0x30/0x50) [<c01aa5a8>] (bus_probe_device+0x30/0x50) from [<c01a8c20>] (device_add+0x1f4/0x4c0) [<c01a8c20>] (device_add+0x1f4/0x4c0) from [<c01acaa0>] (platform_device_add+0xf0/0x194) [<c01acaa0>] (platform_device_add+0xf0/0x194) from [<bf083090>] (jem3_soc_init+0x90/0x110 [snd_soc_jem3]) [<bf083090>] (jem3_soc_init+0x90/0x110 [snd_soc_jem3]) from [<c0021374>] (do_one_initcall+0x2c/0x1a8) [<c0021374>] (do_one_initcall+0x2c/0x1a8) from [<c006e48c>] (sys_init_module+0xc4/0x1f8) [<c006e48c>] (sys_init_module+0xc4/0x1f8) from [<c00219e0>] (ret_fast_syscall+0x0/0x2c) Code: e1530002 0a000021 e597203c e5973010 (e5922008) ---[ end trace 2b2b9768e2c2da90 ]--- The address mentioned there makes me think there's an uninitialised pointer to a struct somewhere... but I've never been able to figure out which one. If I reboot, and try to make it oops like before by loading the CODEC driver then machine driver, everything is serine as one would expect: 192 / # modprobe snd-soc-tlv320aic3204 aic3204_i2c_init: adding driver at bf068f9c aic3204_i2c_init: i2c_add_driver(bf068f9c) = 0 192 / # modprobe snd-soc-jem3 jem3_soc_init: hello... jem3_soc_init: jem3_snd_device = c3dbb2a0 jem3_soc_init: calling platform_set_drvdata( c3dbb2a0, bf07a780 ) jem3_soc_init: calling platform_device_add(c3dbb2a0) jem3_soc_init: platform_device_add(c3dbb2a0) = 0 jem3_soc_init = 0 (success) ...but very quiet... 192 / # mount /proc 192 / # cat /proc/asound/cards --- no soundcards --- Queries: - I notice in old drivers, the I²C chip address of the CODEC could be passed in via the same means that is used here for GPIO configuration. How is this done now? Or how do I tell the kernel to only look at address 0x18? - Despite duplicating what I can see being done in other drivers, I still don't see a sound device created. What am I missing to make an audio device appear? - How does one determine what line foo_bar+0x12/0x34 refers to? As you can tell, I'm a newcomer to kernel hacking, so my appologies if these have been answered elsewhere... I've spent many days looking and haven't stumbled upon the answers as yet, hence why I ask here. Thanks in advance. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere.

5 19

Re: [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
by Clemens Ladisch 03 Jun '10

03 Jun '10

Frederick V Heitkamp wrote: > Repeatable Hard Crash. > What else do I need to provide? > > [ 5484.995249] WriteControlReg: not written, no change > [ 5485.069621] divide error: 0000 [#1] pcm_hw_params ok > [ 5485.070159] Prepare rate=44100 format=2 channels=2 > [ 5485.070161] set_audio_format[14] = 5 > [ 5485.070166] Prepare rate=44100 format=2 channels=2 > [ 5485.070167] set_audio_format[14] = 5 > [ 5485.070003] PREEMPT SMP > ... > [ 5485.070003] EIP is at pcm_pointer+0x37/0x70 [snd_echo3g] > ... > [ 5485.965788] [<c10041c0>] ? do_divide_error+0x0/0x90 > [ 5485.980619] [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g] > [ 5485.998047] [<c104764e>] ? run_timer_softirq+0x17e/0x2e0 > [ 5486.014175] [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g] > [ 5486.033940] [<c107a5d5>] ? handle_IRQ_event+0x45/0x190 bytes_to_frames() divides by runtime->frame_bits which is not set until after the hw_params callback has succeeded, but the corresponding chip->substream[] entry is set in that callback, by init_engine(). It should probably have been set in the prepare callback. Frederick, please try the patch below. Takashi, is there any reason why the runtime-> fields are initialized after the hw_params callback? Regards, Clemens --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -403,12 +403,6 @@ if (err < 0) goto _error; - if (substream->ops->hw_params != NULL) { - err = substream->ops->hw_params(substream, params); - if (err < 0) - goto _error; - } - runtime->access = params_access(params); runtime->format = params_format(params); runtime->subformat = params_subformat(params); @@ -446,6 +440,13 @@ runtime->boundary *= 2; snd_pcm_timer_resolution_change(substream); + + if (substream->ops->hw_params != NULL) { + err = substream->ops->hw_params(substream, params); + if (err < 0) + goto _error; + } + runtime->status->state = SNDRV_PCM_STATE_SETUP; pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,

6 10

[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

[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

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

31 May '10

On Sun, 30 May 2010, VDR User wrote: > On Sun, May 30, 2010 at 8:37 AM, Jaroslav Kysela <perex(a)perex.cz> wrote: >> Thanks. The wallclock register seems working OK. Please, use value 29 for >> the xrun_debug file to do more accurate inspection what's going wrong (as I >> suggested in my first reply): > > Attached is my full syslog with xrun_debug 29. Thanks. Could you try this patch? diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 170610e..ac3dbab 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1910,7 +1910,7 @@ 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; ----- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.

2 2

[alsa-devel] [PATCH 1/9] ALSA: usb-audio: UAC2: clean up parsing of bmaControls
by Daniel Mack 31 May '10

31 May '10

Introduce two new static inline functions for a more readable parsing of UAC2 bmaControls. Signed-off-by: Daniel Mack <daniel(a)caiaq.de> --- include/linux/usb/audio-v2.h | 10 ++++++++++ sound/usb/mixer.c | 8 ++++---- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/include/linux/usb/audio-v2.h b/include/linux/usb/audio-v2.h index 92f1d99..8f91be3 100644 --- a/include/linux/usb/audio-v2.h +++ b/include/linux/usb/audio-v2.h @@ -18,6 +18,16 @@ /* v1.0 and v2.0 of this standard have many things in common. For the rest * of the definitions, please refer to audio.h */ +static inline bool uac2_control_is_readable(u32 bmControls, u8 control) +{ + return (bmControls >> (control * 2)) & 0x1; +} + +static inline bool uac2_control_is_writeable(u32 bmControls, u8 control) +{ + return (bmControls >> (control * 2)) & 0x2; +} + /* 4.7.2.1 Clock Source Descriptor */ struct uac_clock_source_descriptor { diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index 03ce971..43d6417 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -1188,9 +1188,9 @@ static int parse_audio_feature_unit(struct mixer_build *state, int unitid, void for (j = 0; j < channels; j++) { unsigned int mask = snd_usb_combine_bytes(bmaControls + csize * (j+1), csize); - if (mask & (1 << (i * 2))) { + if (uac2_control_is_readable(mask, i)) { ch_bits |= (1 << j); - if (~mask & (1 << ((i * 2) + 1))) + if (!uac2_control_is_writeable(mask, i)) ch_read_only |= (1 << j); } } @@ -1198,9 +1198,9 @@ static int parse_audio_feature_unit(struct mixer_build *state, int unitid, void /* FIXME: the whole unit is read-only if any of the channels is marked read-only */ if (ch_bits & 1) /* the first channel must be set (for ease of programming) */ build_feature_ctl(state, _ftr, ch_bits, i, &iterm, unitid, !!ch_read_only); - if (master_bits & (1 << i * 2)) + if (uac2_control_is_readable(master_bits, i)) build_feature_ctl(state, _ftr, 0, i, &iterm, unitid, - ~master_bits & (1 << ((i * 2) + 1))); + !uac2_control_is_writeable(master_bits, i)); } } -- 1.7.1

2 12

[alsa-devel] [PATCH] ASoC: spdif: Add codec driver to use spdif stand-alone
by Seungwhan Youn 31 May '10

31 May '10

This patch adds spdif dummy codec driver for using spdif-dit as a stand-alone. Until this, spdif-dit can be used only with other codecs like tlv320aci3x in davinci platform. Signed-off-by: Seungwhan Youn <sw.youn(a)samsung.com> --- sound/soc/codecs/spdif_transciever.c | 93 +++++++++++++++++++++++++++++++++- 1 files changed, 92 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/spdif_transciever.c b/sound/soc/codecs/spdif_transciever.c index a631911..f0945ab 100644 --- a/sound/soc/codecs/spdif_transciever.c +++ b/sound/soc/codecs/spdif_transciever.c @@ -18,6 +18,7 @@ #include <linux/moduleparam.h> #include <sound/soc.h> #include <sound/pcm.h> +#include <sound/initval.h> #include "spdif_transciever.h" @@ -26,6 +27,48 @@ MODULE_LICENSE("GPL"); #define STUB_RATES SNDRV_PCM_RATE_8000_96000 #define STUB_FORMATS SNDRV_PCM_FMTBIT_S16_LE +static struct snd_soc_codec *spdif_dit_codec; + +static int spdif_dit_codec_probe(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec; + int ret; + + if (spdif_dit_codec == NULL) { + dev_err(&pdev->dev, "Codec device not registered\n"); + return -ENODEV; + } + + socdev->card->codec = spdif_dit_codec; + codec = spdif_dit_codec; + + ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1); + if (ret < 0) { + dev_err(codec->dev, "failed to create pcms: %d\n", ret); + goto err_create_pcms; + } + + return 0; + +err_create_pcms: + return ret; +} + +static int spdif_dit_codec_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + + snd_soc_free_pcms(socdev); + + return 0; +} + +struct snd_soc_codec_device soc_codec_dev_spdif_dit = { + .probe = spdif_dit_codec_probe, + .remove = spdif_dit_codec_remove, +}; EXPORT_SYMBOL_GPL(soc_codec_dev_spdif_dit); + struct snd_soc_dai dit_stub_dai = { .name = "DIT", .playback = { @@ -40,13 +83,61 @@ EXPORT_SYMBOL_GPL(dit_stub_dai); static int spdif_dit_probe(struct platform_device *pdev) { + struct snd_soc_codec *codec; + int ret; + + if (spdif_dit_codec) { + dev_err(&pdev->dev, "Another Codec is registered\n"); + ret = -EINVAL; + goto err_reg_codec; + } + + codec = kzalloc(sizeof(struct snd_soc_codec), GFP_KERNEL); + if (codec == NULL) + return -ENOMEM; + + codec->dev = &pdev->dev; + + mutex_init(&codec->mutex); + + INIT_LIST_HEAD(&codec->dapm_widgets); + INIT_LIST_HEAD(&codec->dapm_paths); + + codec->name = "spdif-dit"; + codec->owner = THIS_MODULE; + codec->dai = &dit_stub_dai; + codec->num_dai = 1; + + spdif_dit_codec = codec; + + ret = snd_soc_register_codec(codec); + if (ret < 0) { + dev_err(codec->dev, "Failed to register codec: %d\n", ret); + goto err_reg_codec; + } + dit_stub_dai.dev = &pdev->dev; - return snd_soc_register_dai(&dit_stub_dai); + ret = snd_soc_register_dai(&dit_stub_dai); + if (ret < 0) { + dev_err(codec->dev, "Failed to register dai: %d\n", ret); + goto err_reg_dai; + } + + return 0; + +err_reg_dai: + snd_soc_unregister_codec(codec); +err_reg_codec: + kfree(spdif_dit_codec); + return ret; } static int spdif_dit_remove(struct platform_device *pdev) { snd_soc_unregister_dai(&dit_stub_dai); + snd_soc_unregister_codec(spdif_dit_codec); + kfree(spdif_dit_codec); + spdif_dit_codec = NULL; return 0; } -- 1.6.2.5

4 4

[alsa-devel] i.MX SSI Kconfig fixes
by Sascha Hauer 31 May '10

31 May '10

Hi, Two small fixes for i.MX SSI. Sascha The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://git.pengutronix.de/git/imx/linux-2.6.git imx-ssi-fixes Sascha Hauer (2): i.MX ssi: MX31ads sound support should depend on MACH_MX31ADS i.MX ssi: Add missing Kconfig entry for Phytec boards sound/soc/imx/Kconfig | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-)

3 8