From: Takashi Iwai <tiwai@suse.de>
Date: Wed, 16 Jan 2008 15:09:47 +0000 (+0100)
Subject: [ALSA] hda-intel - Add workarounds for STAC codecs
X-Git-Tag: v2.6.25-rc1~1127^2~91
X-Git-Url: https://err.no/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=52987656fb3d43192639a7d585feb564c075c864;p=linux-2.6

[ALSA] hda-intel - Add workarounds for STAC codecs

Some machines with STAC codecs seem to have problems (e.g. no audible
playback) when the delay in codec-read routine is too short.
I still don't figure out which command sequence causes this problem
(due to lack of test hardware), but it's known that increasing the
delay fixes.  So, added a stupid workaround here temporarily...

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
---

diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index 20be776156..719e46f6fb 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -464,6 +464,9 @@ struct hda_bus {
 	struct hda_bus_unsolicited *unsol;
 
 	struct snd_info_entry *proc;
+
+	/* misc op flags */
+	unsigned int needs_damn_long_delay :1;
 };
 
 /*
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 5f2c3ca863..fe07bdff60 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -559,8 +559,12 @@ static unsigned int azx_rirb_get_response(struct hda_codec *codec)
 		}
 		if (!chip->rirb.cmds)
 			return chip->rirb.res; /* the last value */
-		udelay(10);
-		cond_resched();
+		if (codec->bus->needs_damn_long_delay)
+			msleep(2); /* temporary workaround */
+		else {
+			udelay(10);
+			cond_resched();
+		}
 	} while (time_after_eq(timeout, jiffies));
 
 	if (chip->msi) {
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 1d643b9771..24137bc975 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -3472,6 +3472,18 @@ static int patch_stac927x(struct hda_codec *codec)
 
 	codec->patch_ops = stac92xx_patch_ops;
 
+	/*
+	 * !!FIXME!!
+	 * The STAC927x seem to require fairly long delays for certain
+	 * command sequences.  With too short delays (even if the answer
+	 * is set to RIRB properly), it results in the silence output
+	 * on some hardwares like Dell.
+	 *
+	 * The below flag enables the longer delay (see get_response
+	 * in hda_intel.c).
+	 */
+	codec->bus->needs_damn_long_delay = 1;
+
 	return 0;
 }