Commit 52987656 authored by Takashi Iwai's avatar Takashi Iwai Committed by Jaroslav Kysela

[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: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
parent 192b8e39
......@@ -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;
};
/*
......
......@@ -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 */
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) {
......
......@@ -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;
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment