[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>
This commit is contained in:
Takashi Iwai 2008-01-16 16:09:47 +01:00 committed by Jaroslav Kysela
parent 192b8e3922
commit 52987656fb
3 changed files with 21 additions and 2 deletions

View File

@ -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;
};
/*

View File

@ -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) {

View File

@ -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;
}