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

[alsa-devel] [PATCH 1/1] Do not write to invalid registers on the wm9712.
by Eric Millbrandt 23 Dec '09

23 Dec '09

This patch fixes a bug where "virtual" registers were being written to the ac97 bus. This was causing unrelated registers to become corrupted (headphone 0x04, touchscreen 0x78, etc). This patch duplicates protection that was included in the wm9713 driver. Signed-off-by: Eric Millbrandt <emillbrandt(a)dekaresearch.com> --- sound/soc/codecs/wm9712.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c index 0ac1215..e237bf6 100644 --- a/sound/soc/codecs/wm9712.c +++ b/sound/soc/codecs/wm9712.c @@ -463,7 +463,8 @@ static int ac97_write(struct snd_soc_codec *codec, unsigned int reg, { u16 *cache = codec->reg_cache; - soc_ac97_ops.write(codec->ac97, reg, val); + if (reg < 0x7c) + soc_ac97_ops.write(codec->ac97, reg, val); reg = reg >> 1; if (reg < (ARRAY_SIZE(wm9712_reg))) cache[reg] = val; -- 1.6.3.1 This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email.

3 4

Re: [alsa-devel] Mic not working on Dell Vostro 1700 by default
by Takashi Iwai 23 Dec '09

23 Dec '09

At Wed, 23 Dec 2009 14:51:25 +0100, Anisse Astier wrote: > > On Wed, 23 Dec 2009 08:31:40 +0100, Takashi Iwai <tiwai(a)suse.de> wrote : > > > At Tue, 22 Dec 2009 18:50:28 +0100, > > Anisse Astier wrote: > > > > > > On Tue, 22 Dec 2009 18:44:04 +0100, Anisse Astier <anisse(a)astier.eu> wrote : > > > > > > > Hi, > > > > > > > > (i'm not subscribed to the list, please cc me in replies) > > > > > > > > So I'm on a Dell Vostro 1700 with latest BIOS (A07). In the default > > > > configuration, the mic is not working. > > > > > > > > But if I append model=dell-m42 when loading snd-hda-intel, it works. > > > > > > > > My alsa-info: > > > > http://www.alsa-project.org/db/?f=8d6f7d613b909c0eef67f93e0e86bf13476e9e54 > > > > > > > > alsa-info with option model=dell-m42 > > > > http://www.alsa-project.org/db/?f=233cee7ffea01b9f46451e64c95c4fc482ab4ee4 > > > > > > > > I don't know if dell-m42 is enough, I chose it because it was used for the > > > > Dell Vostro 1500, for which there was a pci quirk in patch_sigmatel.c, > > > > and that seemed close enough. Everything seems to work properly though. > > > > > > > > I don't know if it's possible to add the same pci-quirk (or a similar one) > > > > in patch_sigmatel.c , or any dmi-based quirk, but I'd like to help in > > > > doing so. > > > > > > > > I compiled a working hda-verb should some remote debugging be needed. > > > > > > > > > > I forgot to add that this is also working with dell-m44. A pointer: > > > https://wiki.ubuntu.com/InstallingUbuntuOnADellVostro1700#AUDIO : > > > suggestion to add this option by default on ubuntu. > > > > So, which is better, m42 or m44? > > This can be checked only with a real hardware... > > > > I did some tests today, and I'm unable to tell. Both behave the same with > external headphones, internal speakers, external mic, internal mic. Jack > detection works flawlessly with both. From time to time the codec will > timeout and driver switch to polling mode, but it's independent from the > option model. > I really don't know what else to test. Maybe the different is either the digital I/O or the docking station. > But IMO, we should go with m42. According to patch_sigmatel.c dell-m42 is > made for Vostro 1500, and this should be tho closest to the 1700. It > seems they have the same motherboard. I attached a diff between the two > laptops' lspci. Only the graphics card changes. OK, then let's take dell-m42. thanks, Takashi

1 0

Re: [alsa-devel] [2.6.33-rc1] [SOUND] HDA: high cpu usage, noise
by Takashi Iwai 23 Dec '09

23 Dec '09

At Wed, 23 Dec 2009 15:27:08 +0100, Éric Piel wrote: > > Op 22-12-09 10:17, Takashi Iwai schreef: > : > >>> Another thing to try is to replace the whole HD-audio stack with the > >>> last working one (was it 2.6.32?), and check whether it works with > >>> 2.6.32 core. > >> Could you give more details on how to do this? > >> Does it consist in taking the sound/ directory of 2.6.32 and copying it > >> over 2.6.33-rc1 ? Or less files? > > > > I'd try first only sound/pci/hda/* files. > > > Brute-force reverting these files to the version of 2.6.32.2 does fix > the problem. OK, that's good to know. > When I find time, I'll try to git bisect on this particular directory... > but anyone willing to try to beat me at this is welcome, as Christmas is > going to keep me rather busy ;-) bisecting would be indeed helpful. It needs to be done only in the above directory, so there shouldn't be much. thanks, Takashi

1 0

[alsa-devel] HDA model specification and a topic/hda bug?
by Paul "TBBle" Hampson 23 Dec '09

23 Dec '09

Hi, I've a couple of questions. Firstly, I've been through "MORE NOTES ON HD-AUDIO DRIVER" and was able to use codecgraph and hda-analyzer to identify non-disabled speakers on my laptop (the laptop claims four speakers plus a subwoofer, Alsa's autodetect only enables the subwoofer for output) but I'm having trouble working out how to convert this knowledge into either changes to patch_realtek.c or even a patch file to feed the driver, so that it comes up correctly by default. I do have a printout of the Intel HDA spec's codec layout chapter, but I haven't read it yet. I'm hoping not to have to, but I suspect I will. Anyway, I've been tracking topic/hda from the Alsa git repository, hoping it'll magically fix my sound-card detection, but I'm having a problem with 5b0cb1d850c26893b1468b3a519433a1b7a176be (ALSA: hda - add more NID->Control mapping) which I believe is part of the 1.0.22 release. For reference, it's an MSI GT725 laptop... Basically, snd_hda_add_nids is being called with an array of three nids, the third of which is 0. I've been throwing snd_kprintd statements at it, and it seems that I see input_mux->num_items as 3 (which I _think_ is correct, I have a buit-in microphone, microphone jack and line-in jack) but I only have two analog aud_in nodes (0x8 and 0x9, 0x7 is a vendor node). _From the look of it, this call to snd_hda_add_nids is wrong: err = snd_hda_add_nids(codec, kctl, i, spec->capsrc_nids, spec->input_mux->num_items); it maybe should be err = snd_hda_add_nids(codec, kctl, i, spec->capsrc_nids, spec->num_adc_nids); if I'm understanding patch_alc882 correctly, although that looks wrong in pretty much every other use I can see. It's prolly me not understanding how the HDA stuff ties together very well, but right now the inbuilt sound fails to load with a -22 (-EINVAL) error, which is snd_hda_add_nid rejecting a nid <= 0. I suspect http://bugs.gentoo.org/show_bug.cgi?id=297454 is the same problem, and https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4846 looks like it too. On searching, https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4841 is exactly the same problem, and the same model laptop as mine. I'm happy to do debugging and whatnot, since I hope to actually work out the correct patch overrides to get my laptop speakers properly working so any debugging I do for this problem will hopefully improve my understanding of the HDA driver.

2 1

Re: [alsa-devel] Mic not working on Dell Vostro 1700 by default
by Takashi Iwai 23 Dec '09

23 Dec '09

At Tue, 22 Dec 2009 18:50:28 +0100, Anisse Astier wrote: > > On Tue, 22 Dec 2009 18:44:04 +0100, Anisse Astier <anisse(a)astier.eu> wrote : > > > Hi, > > > > (i'm not subscribed to the list, please cc me in replies) > > > > So I'm on a Dell Vostro 1700 with latest BIOS (A07). In the default > > configuration, the mic is not working. > > > > But if I append model=dell-m42 when loading snd-hda-intel, it works. > > > > My alsa-info: > > http://www.alsa-project.org/db/?f=8d6f7d613b909c0eef67f93e0e86bf13476e9e54 > > > > alsa-info with option model=dell-m42 > > http://www.alsa-project.org/db/?f=233cee7ffea01b9f46451e64c95c4fc482ab4ee4 > > > > I don't know if dell-m42 is enough, I chose it because it was used for the > > Dell Vostro 1500, for which there was a pci quirk in patch_sigmatel.c, > > and that seemed close enough. Everything seems to work properly though. > > > > I don't know if it's possible to add the same pci-quirk (or a similar one) > > in patch_sigmatel.c , or any dmi-based quirk, but I'd like to help in > > doing so. > > > > I compiled a working hda-verb should some remote debugging be needed. > > > > I forgot to add that this is also working with dell-m44. A pointer: > https://wiki.ubuntu.com/InstallingUbuntuOnADellVostro1700#AUDIO : > suggestion to add this option by default on ubuntu. So, which is better, m42 or m44? This can be checked only with a real hardware... thanks, Takashi

1 0

Re: [alsa-devel] Installing a "different" version of Alsa
by Brian Welch 23 Dec '09

23 Dec '09

Message: 1 Date: Sun, 20 Dec 2009 12:47:28 +0000 From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Subject: Re: [alsa-devel] Installing a "different" version of Alsa To: Brian Welch <Brian-Welch(a)cox.net> Cc: alsa-devel(a)alsa-project.org Message-ID: <20091220124727.GA2881(a)sirena.org.uk> Content-Type: text/plain; charset=us-ascii On Sat, Dec 19, 2009 at 09:48:16PM -0700, Brian Welch wrote: >> When I use kbuild to build my custom sound hardware driver against the >> SDK >> in the kernel, it always trys to pick up the older ALSA header files that >> are in the >> SDK, but I want to use the newer versions that are in the directory with >> the newer >> version of ALSA. What the best way to make sure I get the correct >> headers? >> Is what I'm trying "dangerous" and should I be going about this a >> different way? > The best way of integrating with the toolchain you're using will usually > depend on the toolchain - you'll generally be able to get better advice > about how to work with the toolchain by asking people who work with the > toolchain. I guess I don't understand exactly what you mean by "toolchain." I've already contacted the people that package up the SDK and they said I should solve it myself. I originally hoped that I could just re-build the kernel without Alsa built-in, then add my new version of Alsa, but they claim that causes other issues (i.e. no sound at all).

2 3

[alsa-devel] ASoC updates for 2.6.33
by Mark Brown 22 Dec '09

22 Dec '09

The following changes since commit 48c03ce72f2665f79a3fe54fc6d71b8cc3d30803: Guennadi Liakhovetski (1): ASoC: wm8974: fix a wrong bit definition are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.33 Guennadi Liakhovetski (1): ASoC: add missing parameter to mx27vis_hifi_hw_free() Uwe Kleine-König (1): ASoC: sh: FSI:: don't check platform_get_irq's return value against zero sound/soc/imx/mx27vis_wm8974.c | 3 ++- sound/soc/sh/fsi.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-)

2 1

Re: [alsa-devel] [2.6.33-rc1] [SOUND] HDA: high cpu usage, noise
by Takashi Iwai 22 Dec '09

22 Dec '09

At Tue, 22 Dec 2009 16:15:57 +0100, Éric Piel wrote: > > Op 22-12-09 10:17, Takashi Iwai schreef: > : > >>> It shouldn't. The polling mode doesn't give any behavioral change, > >>> and the CPU usage can't be that high. > >>> > >>> Try is to pass bdl_pos_adj=0 option. This should reduce the CPU hog, > >>> at least. But it doesn't mean it's the right fix... > >> I'll try > Just tried: it doesn't have any effect, as enable_msi=0. Still 25% of > the CPU used, as before. > $ cat bdl_pos_adj > 0,-1,-1,-1,-1,-1,-1,-1 > > Could it be coming from the beeper? Also, just in case it can help, > attached is my .config . Do you have multiple HD-audio devices? See /proc/asound/cards. If there are multiple, you need to pass a value for each. Takashi

1 0

[alsa-devel] [PATCH 7/7] ASoC: sh: FSI:: don't check platform_get_irq's return value against zero
by Uwe Kleine-König 22 Dec '09

22 Dec '09

platform_get_irq returns -ENXIO on failure, so !irq was probably always true. Better use (int)irq <= 0. Note that a return value of zero is still handled as error even though this could mean irq0. This is a followup to 305b3228f9ff4d59f49e6d34a7034d44ee8ce2f0 that changed the return value of platform_get_irq from 0 to -ENXIO on error. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Cc: David Vrabel <dvrabel(a)arcom.com> Cc: Greg Kroah-Hartman <gregkh(a)suse.de> Cc: Liam Girdwood <lrg(a)slimlogic.co.uk> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.de> Cc: Kuninori Morimoto <morimoto.kuninori(a)renesas.com> Cc: Paul Mundt <lethal(a)linux-sh.org> Cc: alsa-devel(a)alsa-project.org --- sound/soc/sh/fsi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c index 9c49c11..42813b8 100644 --- a/sound/soc/sh/fsi.c +++ b/sound/soc/sh/fsi.c @@ -876,7 +876,7 @@ static int fsi_probe(struct platform_device *pdev) res = platform_get_resource(pdev, IORESOURCE_MEM, 0); irq = platform_get_irq(pdev, 0); - if (!res || !irq) { + if (!res || (int)irq <= 0) { dev_err(&pdev->dev, "Not enough FSI platform resources.\n"); ret = -ENODEV; goto exit; -- 1.6.5.2

3 3

Re: [alsa-devel] [PATCH] ASoC: add missing parameter to mx27vis_hifi_hw_free()
by Mark Brown 22 Dec '09

22 Dec '09

On Tue, Dec 22, 2009 at 09:26:10AM +0100, Guennadi Liakhovetski wrote: > Commit 2ccafed4 added an extra parameter to the DAI .set_pll() method, but > it missed this call in sound/soc/imx/mx27vis_wm8974.c. Appled, thanks.

1 0