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

[alsa-devel] [PATCH] cs4236: detect chip in one pass
by Krzysztof Helt 05 Nov '09

05 Nov '09

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> The cs4236 was two step detection with call to the snd_wss_free() between two steps. The snd_wss_free() did not free a sound device created in the snd_wss_create(). This caused an OOPS during module removal as the same sound device was released twice. The same OOPS happened if the cs4236 module loading failed. Fix this by adapting the snd_cs4236_create() to correctly work with chips less capable then cs4236. The snd_cs4236_create() behaves the same as the snd_wss_create() if the chip is less capable than the cs4236. Signed-off-by: Krzysztof Helt <krzysztof.h1(a)wp.pl> --- This is the third version of the patch with less code indented (smaller change). include/sound/wss.h | 1 - sound/isa/cs423x/cs4236.c | 13 ++-------- sound/isa/cs423x/cs4236_lib.c | 50 +++++++++++++++++++++++++--------------- sound/isa/wss/wss_lib.c | 3 +- 4 files changed, 35 insertions(+), 32 deletions(-) diff --git a/include/sound/wss.h b/include/sound/wss.h index 6d65f32..fd01f22 100644 --- a/include/sound/wss.h +++ b/include/sound/wss.h @@ -154,7 +154,6 @@ int snd_wss_create(struct snd_card *card, unsigned short hardware, unsigned short hwshare, struct snd_wss **rchip); -int snd_wss_free(struct snd_wss *chip); int snd_wss_pcm(struct snd_wss *chip, int device, struct snd_pcm **rpcm); int snd_wss_timer(struct snd_wss *chip, int device, struct snd_timer **rtimer); int snd_wss_mixer(struct snd_wss *chip); diff --git a/sound/isa/cs423x/cs4236.c b/sound/isa/cs423x/cs4236.c index a076a6c..93fa672 100644 --- a/sound/isa/cs423x/cs4236.c +++ b/sound/isa/cs423x/cs4236.c @@ -394,21 +394,15 @@ static int __devinit snd_cs423x_probe(struct snd_card *card, int dev) return -EBUSY; } - err = snd_wss_create(card, port[dev], cport[dev], + err = snd_cs4236_create(card, port[dev], cport[dev], irq[dev], dma1[dev], dma2[dev], WSS_HW_DETECT3, 0, &chip); if (err < 0) return err; + + acard->chip = chip; if (chip->hardware & WSS_HW_CS4236B_MASK) { - snd_wss_free(chip); - err = snd_cs4236_create(card, - port[dev], cport[dev], - irq[dev], dma1[dev], dma2[dev], - WSS_HW_DETECT, 0, &chip); - if (err < 0) - return err; - acard->chip = chip; err = snd_cs4236_pcm(chip, 0, &pcm); if (err < 0) @@ -418,7 +412,6 @@ static int __devinit snd_cs423x_probe(struct snd_card *card, int dev) if (err < 0) return err; } else { - acard->chip = chip; err = snd_wss_pcm(chip, 0, &pcm); if (err < 0) return err; diff --git a/sound/isa/cs423x/cs4236_lib.c b/sound/isa/cs423x/cs4236_lib.c index 38835f3..1b1ad1c 100644 --- a/sound/isa/cs423x/cs4236_lib.c +++ b/sound/isa/cs423x/cs4236_lib.c @@ -87,6 +87,7 @@ #include <sound/core.h> #include <sound/wss.h> #include <sound/asoundef.h> +#include <sound/initval.h> /* * @@ -264,7 +265,10 @@ static void snd_cs4236_resume(struct snd_wss *chip) } #endif /* CONFIG_PM */ - +/* + * This function does no fail if the chip is not CS4236B or compatible. + * It just an equivalent to the snd_wss_create() then. + */ int snd_cs4236_create(struct snd_card *card, unsigned long port, unsigned long cport, @@ -281,21 +285,17 @@ int snd_cs4236_create(struct snd_card *card, *rchip = NULL; if (hardware == WSS_HW_DETECT) hardware = WSS_HW_DETECT3; - if (cport < 0x100) { - snd_printk(KERN_ERR "please, specify control port " - "for CS4236+ chips\n"); - return -ENODEV; - } + err = snd_wss_create(card, port, cport, irq, dma1, dma2, hardware, hwshare, &chip); if (err < 0) return err; - if (!(chip->hardware & WSS_HW_CS4236B_MASK)) { - snd_printk(KERN_ERR "CS4236+: MODE3 and extended registers " - "not available, hardware=0x%x\n", chip->hardware); - snd_device_free(card, chip); - return -ENODEV; + if ((chip->hardware & WSS_HW_CS4236B_MASK) == 0) { + snd_printd("chip is not CS4236+, hardware=0x%x\n", + chip->hardware); + *rchip = chip; + return 0; } #if 0 { @@ -308,9 +308,16 @@ int snd_cs4236_create(struct snd_card *card, idx, snd_cs4236_ctrl_in(chip, idx)); } #endif + if (cport < 0x100 || cport == SNDRV_AUTO_PORT) { + snd_printk(KERN_ERR "please, specify control port " + "for CS4236+ chips\n"); + snd_device_free(card, chip); + return -ENODEV; + } ver1 = snd_cs4236_ctrl_in(chip, 1); ver2 = snd_cs4236_ext_in(chip, CS4236_VERSION); - snd_printdd("CS4236: [0x%lx] C1 (version) = 0x%x, ext = 0x%x\n", cport, ver1, ver2); + snd_printdd("CS4236: [0x%lx] C1 (version) = 0x%x, ext = 0x%x\n", + cport, ver1, ver2); if (ver1 != ver2) { snd_printk(KERN_ERR "CS4236+ chip detected, but " "control port 0x%lx is not valid\n", cport); @@ -321,13 +328,17 @@ int snd_cs4236_create(struct snd_card *card, snd_cs4236_ctrl_out(chip, 2, 0xff); snd_cs4236_ctrl_out(chip, 3, 0x00); snd_cs4236_ctrl_out(chip, 4, 0x80); - snd_cs4236_ctrl_out(chip, 5, ((IEC958_AES1_CON_PCM_CODER & 3) << 6) | IEC958_AES0_CON_EMPHASIS_NONE); + reg = ((IEC958_AES1_CON_PCM_CODER & 3) << 6) | + IEC958_AES0_CON_EMPHASIS_NONE; + snd_cs4236_ctrl_out(chip, 5, reg); snd_cs4236_ctrl_out(chip, 6, IEC958_AES1_CON_PCM_CODER >> 2); snd_cs4236_ctrl_out(chip, 7, 0x00); - /* 0x8c for C8 is valid for Turtle Beach Malibu - the IEC-958 output */ - /* is working with this setup, other hardware should have */ - /* different signal paths and this value should be selectable */ - /* in the future */ + /* + * 0x8c for C8 is valid for Turtle Beach Malibu - the IEC-958 + * output is working with this setup, other hardware should + * have different signal paths and this value should be + * selectable in the future + */ snd_cs4236_ctrl_out(chip, 8, 0x8c); chip->rate_constraint = snd_cs4236_xrate; chip->set_playback_format = snd_cs4236_playback_format; @@ -339,9 +350,10 @@ int snd_cs4236_create(struct snd_card *card, /* initialize extended registers */ for (reg = 0; reg < sizeof(snd_cs4236_ext_map); reg++) - snd_cs4236_ext_out(chip, CS4236_I23VAL(reg), snd_cs4236_ext_map[reg]); + snd_cs4236_ext_out(chip, CS4236_I23VAL(reg), + snd_cs4236_ext_map[reg]); - /* initialize compatible but more featured registers */ + /* initialize compatible but more featured registers */ snd_wss_out(chip, CS4231_LEFT_INPUT, 0x40); snd_wss_out(chip, CS4231_RIGHT_INPUT, 0x40); snd_wss_out(chip, CS4231_AUX1_LEFT_INPUT, 0xff); diff --git a/sound/isa/wss/wss_lib.c b/sound/isa/wss/wss_lib.c index 5d2ba1b..aab44e7 100644 --- a/sound/isa/wss/wss_lib.c +++ b/sound/isa/wss/wss_lib.c @@ -1682,7 +1682,7 @@ static void snd_wss_resume(struct snd_wss *chip) } #endif /* CONFIG_PM */ -int snd_wss_free(struct snd_wss *chip) +static int snd_wss_free(struct snd_wss *chip) { release_and_free_resource(chip->res_port); release_and_free_resource(chip->res_cport); @@ -1705,7 +1705,6 @@ int snd_wss_free(struct snd_wss *chip) kfree(chip); return 0; } -EXPORT_SYMBOL(snd_wss_free); static int snd_wss_dev_free(struct snd_device *device) { -- 1.6.4 ------------------------------------------------------------------------------ Mapa fotoradarow! Pobierz >> http://link.interia.pl/f2413

2 1

[alsa-devel] ALSA/ASoC crash in pm_qos_remove_requirement()?
by Daniel Mack 05 Nov '09

05 Nov '09

Has anyone seen a similar crash to the one below recently? It happened to us on PXA300 embedded platforms. Any pointers appreciated. Thanks, Daniel [ 882.823660] Unable to handle kernel paging request at virtual address 62696c2f [ 882.830853] pgd = c6000000 [ 882.833536] [62696c2f] *pgd=00000000 [ 882.837081] Internal error: Oops: 3 [#3] [ 882.840971] last sysfs file: /sys/devices/platform/spi_gpio.0/spi0.2/value [ 882.847793] Modules linked in: eeti_ts libertas_sdio pxamci ds2760_battery w1_ds2760 wire [ 882.855926] CPU: 0 Tainted: G D (2.6.32-rc6 #1) [ 882.861483] PC is at pm_qos_remove_requirement+0x78/0xb8 [ 882.866773] LR is at snd_pcm_hw_params+0x258/0x2e4 [ 882.871535] pc : [<c006da64>] lr : [<c02685ec>] psr: 60000093 [ 882.871546] sp : c7fa1da0 ip : 00000001 fp : bea08668 [ 882.882938] r10: c793b534 r9 : 00000001 r8 : c04dbd10 [ 882.888125] r7 : 60000013 r6 : c7f57000 r5 : 00000000 r4 : 62696c2f [ 882.894604] r3 : c03548f0 r2 : 005893bc r1 : c793b534 r0 : 00000001 [ 882.901085] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 882.908260] Control: 0000397f Table: a6000018 DAC: 00000015 [ 882.913962] Process p0-renderer (pid: 1235, stack limit = 0xc7fa0278) [ 882.920355] Stack: (0xc7fa1da0 to 0xc7fa2000) [ 882.924691] 1da0: c7f56000 00000000 c7f57000 00000001 c793b534 c7fa0000 c7f9f480 c02685ec [ 882.932822] 1dc0: c7f57000 c25c4111 bea08668 c793b500 bea08668 c0268a0c 00000000 00000000 [ 882.940954] 1de0: 00000000 c7f66160 c7fa1e04 00000000 c7f66160 c0090d1c 00000000 c004a0d0 [ 882.949078] 1e00: c7fbd880 c7f661dc 00000080 00000000 00000000 c76920ac 00000046 00000046 [ 882.957203] 1e20: 00000000 c0605660 00000000 a65b330f c0605660 00000000 00000000 c0093974 [ 882.965326] 1e40: 00000000 00000000 00000200 c7f78934 00000000 00000046 4044d000 c0605660 [ 882.973452] 1e60: 00000000 00000000 c6001010 c7f66160 00000000 4044d000 c7f78934 c7f80634 [ 882.981584] 1e80: c7f80600 c00941e8 00000046 00000000 00000000 40007000 3048c51d 0000004d [ 882.989708] 1ea0: c6000000 00000202 00000134 00000359 c05266a0 c0070834 3048c51d 00000000 [ 882.997834] 1ec0: c7fa1eec c7f66160 c7fea000 c7f9f480 c25c4111 bea08668 c793b500 bea08668 [ 883.005966] 1ee0: c7fa0000 4062a608 bea08668 c0269eb0 c04d6624 bea08268 00000005 c7fa1fb0 [ 883.014100] 1f00: 4044da44 c7f9f480 c25c4111 bea08668 c7f9f480 c00b207c 00000012 c7f9f480 [ 883.022232] 1f20: 00000012 c00b2780 c04d9d60 c006d164 c7fa1f5c c7f9401c c7fea000 00000015 [ 883.030366] 1f40: 00000000 c7fea000 c7f80780 c7f80600 c7fa1fac c7fa1f60 c0351fec c0052f54 [ 883.038498] 1f60: 00000000 c005b5c8 00000012 bea08668 c25c4111 c7f9f480 c00440c4 c7fa0000 [ 883.046631] 1f80: 4062a608 c00b2820 40005030 00000001 03368914 bea08668 404b1674 00063a20 [ 883.054764] 1fa0: 00000036 c0043f40 bea08668 404b1674 00000012 c25c4111 bea08668 00020001 [ 883.062896] 1fc0: bea08668 404b1674 00063a20 00000036 00063778 00000000 4062a608 bea08668 [ 883.071021] 1fe0: 404b19c0 bea08198 404593fc 40759234 20000010 00000012 00000000 00000000 [ 883.079172] [<c006da64>] (pm_qos_remove_requirement+0x78/0xb8) from [<c02685ec>] (snd_pcm_hw_params+0x258/0x2e4) [ 883.089292] [<c02685ec>] (snd_pcm_hw_params+0x258/0x2e4) from [<c0268a0c>] (snd_pcm_common_ioctl1+0x22c/0xf00) [ 883.099241] [<c0268a0c>] (snd_pcm_common_ioctl1+0x22c/0xf00) from [<c0269eb0>] (snd_pcm_playback_ioctl1+0x3d0/0x3f4) [ 883.109713] [<c0269eb0>] (snd_pcm_playback_ioctl1+0x3d0/0x3f4) from [<c00b207c>] (vfs_ioctl+0x2c/0x70) [ 883.118971] [<c00b207c>] (vfs_ioctl+0x2c/0x70) from [<c00b2780>] (do_vfs_ioctl+0x4f4/0x55c) [ 883.127275] [<c00b2780>] (do_vfs_ioctl+0x4f4/0x55c) from [<c00b2820>] (sys_ioctl+0x38/0x5c) [ 883.135592] [<c00b2820>] (sys_ioctl+0x38/0x5c) from [<c0043f40>] (ret_fast_syscall+0x0/0x28) [ 883.143978] Code: eb00d3da e3a03001 ea000006 e1a04006 (e5946000) [ 883.150212] ---[ end trace 9912192a230e6312 ]---

2 2

[alsa-devel] Trying to get unsupported CODEC to work
by Alex Austin 05 Nov '09

05 Nov '09

HelloI have an MSI Media Live DIVA motherboard. It has an AMD SB600 HD Audio controller, and two CODECs on the HDA bus. First is an ALC888 Second is an Intersil DAE-3. Two alsa-info outputs in different circumstances http://www.alsa-project.org/db/?f=20c86e755fdbbdbc8761c8c2f4de76bce2ea0c11 http://www.alsa-project.org/db/?f=15c5e5eab0104622a84b2dd0df03f26c17c7242d Output of codecgraph with "modprobe hda-intel probe_mask=2" http://pastebin.com/f54b6a9b8 What's the next step to get this supported? -- - Alex Austin (651) 238-9273 "...and then I visited Wikipedia ...and the next 8 hours are a blur."

3 13

Re: [alsa-devel] Conexant CX20561 - Microphone problems
by Takashi Iwai 05 Nov '09

05 Nov '09

At Thu, 5 Nov 2009 06:34:36 -0500, Shawn Starr wrote: > > > > The interference is coming from: ALSA Capture on default (seems to be the > > > digital device), yet HDA Intel [CONEXANT Analog] has no such > > > interference. > > > > I don't understand what you mean here at all.... > > > I'm not understanding what 'default' is in this case. How many capture > (microphone) inputs does this device have? It really seems strange to me > that one capture input has so much interference. I just don't know what it is > using. > > **** List of CAPTURE Hardware Devices **** > card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog] > Subdevices: 0/1 > Subdevice #0: subdevice #0 So, you have only this PCM stream for capture. > **** List of PLAYBACK Hardware Devices **** > card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog] > Subdevices: 0/1 > Subdevice #0: subdevice #0 > card 0: Intel [HDA Intel], device 1: Conexant Digital [Conexant Digital] > Subdevices: 1/1 > Subdevice #0: subdevice #0 These are for playback, not capture. Takashi

1 0

[alsa-devel] Seg. fault when using Salsa 0.0.25
by Mogens Lindholdt Lauridsen 05 Nov '09

05 Nov '09

Hi, I got an application which uses Salsa 0.0.25. When I quit this application, it ends with a seg. fault. I don't know if this is caused by my application using Salsa wrongly, or a problem in Salsa. However, I got a fix for it. When my application closes, "hctl_elem_event_handler" is called. And since "helem->private_data" is null, this causes a seg. fault: snd_mixer_elem_t *elem = helem->private_data; snd_mixer_t *mixer = elem->mixer; It seems like: if (!elem) return 0; should have been before: snd_mixer_t *mixer = elem->mixer; An easy way to fix/avoid this is to remove "snd_mixer_t *mixer = elem->mixer;" and replace "mixer" with "elem->mixer" in the function. Like this: static int hctl_elem_event_handler(snd_hctl_elem_t *helem, unsigned int mask) { snd_mixer_elem_t *elem = helem->private_data; //MLN fix: snd_mixer_t *mixer = elem->mixer; int err; if (!elem) return 0; if (mask == SND_CTL_EVENT_MASK_REMOVE) { err = _snd_mixer_elem_throw_event(elem, mask); if (err < 0) return err; remove_simple_element(helem, 1); return 0; } if (mask & SND_CTL_EVENT_MASK_INFO) { remove_simple_element(helem, 0); add_simple_element(helem, elem->mixer); // MLN fix: "mixer" substituted by "elem->mixer" err = snd_mixer_elem_info(elem); if (err < 0) return err; snd_mixer_sort(elem->mixer); // MLN fix: "mixer" substituted by "elem->mixer" } if (mask & SND_CTL_EVENT_MASK_VALUE) { err = update_simple_element(helem, elem); if (err < 0) return err; if (err) { err = snd_mixer_elem_value(elem); if (err < 0) return err; } } return 0; } Kind regards, Mogens

2 1

Re: [alsa-devel] [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard
by Wu Fengguang 05 Nov '09

05 Nov '09

On Thu, Nov 05, 2009 at 05:06:22PM +0800, David Härdeman wrote: > On Thu, November 5, 2009 08:47, Wu Fengguang wrote: > > On Thu, Nov 05, 2009 at 08:46:55AM +0800, David wrote: > >> Currently doing some testing with sticky stream id and format. > >> > >> Could you test the attached patch (applies to alsa git repo, without > >> your patchset) and see if you get the initial 0.5s silence with your > >> receiver? > > > > Yes it worked! > > Worked as in you get no 0.5s of initial silence? Or worked as in you at > least got some audio and the computer didn't crash? :) no 0.5s :) > > However something is broken when > > > > CONFIG_SND_HDA_POWER_SAVE=y > > CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1 In the above config, you need to restart playback within 1s to avoid losing the first 0.5s samples. (Otherwise power save will kick in.) > I was kind of expecting my patch to break both power save and > suspend/resume given that it expects the stream format and id to survive > from pcm_close to pcm_prepare (which they probably won't if power saving Don't worry, I fixed that in my implementation :) > and/or resume/suspend kicks in). Power save also seems to mess up some > other parts of the driver even without my patch (haven't really looked > into that yet...power save might be tricky with HDMI from what I've seen > so far). Yes, HDMI power save is inherently not possible given that the sink devices have the more than 1s delays.. > The patch was just a test case to see if it was enough to fix the 0.5s > silence on receivers which are less picky than mine (it still doesn't fix > the 0.5s silence on my receiver but it fixes the > silence-for-the-duration-of-a-track problem). > > Next up, more testing with VCFG when I have more time. I have actually > tried setting that bit but it didn't change anything. Comments in > setup_dig_out_stream from hda_codec.c seems to suggest that it's a bit > more complex than just setting the right bit. No worry, I guess that's realtek specific problem (spdif_status_reset is only set by it). > > Attached is my updated patchset, which includes the sticky > > stream/infoframe features. > > Thanks, I'll take a look at it as soon as possible. Thanks, Fengguang

1 0

[alsa-devel] Intel HDA - AD1883 Codec - Jack Sense / Detect
by Alan Bennett 05 Nov '09

05 Nov '09

Hello; We have a custom motherboard Intel HDA / AD1883. For output, we connect the headphone jack and the mono / front speaker. We are unable to get audio in Linux (Windows is fine) that activates the front/mono speaker. The headphones work without a problem. However, none of the 4 "model=" strings improve the situation. The headphones always work, but no configuration will activate the onboard front/mono speaker. Is there a way to query the live status of the AD1883 / jack-detect/sense? -Alan

2 1

[alsa-devel] [PATCH] ALSA: intel8x0: Mute External Amplifier by default for another Sony model
by Dan Chen 05 Nov '09

05 Nov '09

Hi, Attached is a patch against current sound-2.6 HEAD adding the SSID of another Sony model that requires the inv_eapd quirk. Thanks, Dan

2 1

[alsa-devel] VIA VT1828S hda_intel errors
by Robert Hancock 05 Nov '09

05 Nov '09

I've been using the VT1828S codec support from ALSA git for the last few weeks. It seems to work fine, but there are some problems showing up in dmesg: Oct 25 20:46:14 newcastle kernel: ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x02af0900 Oct 25 20:46:15 newcastle kernel: ALSA sound/pci/hda/hda_intel.c:698: azx_get_response timeout, switching to polling mode: last cmd=0x02af0900 It seems like the cmd isn't always the same, previously it was 0x024f0c00. Is there something bad about this command that could be causing the response timeout? Also, disabling MSI for one occurrence of this seems a bit paranoid.. Also saw one of these: Oct 26 21:13:20 newcastle kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. and PulseAudio also complained: Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

2 6

[alsa-devel] [PATCH 3/7] S3C64XX PCM: Define PCM Controller base registers
by Jassi Brar 05 Nov '09

05 Nov '09

Signed-off-by: Jassi Brar <jassi.brar(a)samsung.com> --- arch/arm/mach-s3c6400/include/mach/map.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s3c6400/include/mach/map.h b/arch/arm/mach-s3c6400/include/mach/map.h index fc8b223..866be31 100644 --- a/arch/arm/mach-s3c6400/include/mach/map.h +++ b/arch/arm/mach-s3c6400/include/mach/map.h @@ -48,6 +48,8 @@ #define S3C64XX_PA_IIS1 (0x7F003000) #define S3C64XX_PA_TIMER (0x7F006000) #define S3C64XX_PA_IIC0 (0x7F004000) +#define S3C64XX_PA_PCM0 (0x7F009000) +#define S3C64XX_PA_PCM1 (0x7F00A000) #define S3C64XX_PA_IISV4 (0x7F00D000) #define S3C64XX_PA_IIC1 (0x7F00F000) -- 1.6.2.5

1 0