7 Jan
2009
7 Jan
'09
2:07 p.m.
At Wed, 7 Jan 2009 12:57:57 +0100, Salvatore Filippone wrote:
On Wed, Jan 7, 2009 at 12:45 PM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 29 Dec 2008 19:45:25 +0100, Nigel Henry wrote: > > UPDATE: Salvatore has found a workaround, so that both codecs are detected > correctly. Any help from alsa developers for a permanent fix would be > appreciated. See workaround at bottom of post. > (snip) > <Quoting Salvatore> > Saturday 16:05:58 > > Ok, I finally found a workaround. > According to the thread starting at > http://thread.gmane.org/gmane.linux.alsa.devel/58849 > I grabbed the latest source code alsa-driver-1.0.18a.17.g27a32.139.g6e583/ > compiled with --with-debug=verbose and got the message > Dec 27 15:13:06 localhost kernel: ALSA > /mnt/travel/ALSA/alsa-driver-1.0.18a.17.g27a32.139.g6e583/pci/hda/../../ alsa-kernel/pci/hda/hda_intel.c:779: > codec_mask = 0x2 > > I then figure out that the sound device was at codec#0 when it worked, > therefore I changed snd_hda_intel.c by forcing codec_mask > if (!chip->codec_mask) { > chip->codec_mask = azx_readw(chip, STATESTS); > chip->codec_mask=0x03; > snd_printdd("codec_mask = 0x%x\n", chip->codec_mask); > } > > And now the sound works correctly. > Of course this opens the question of why azx_readw does not return a > correct mask; Well, this implies a BIOS bug. This value is set by BIOS to indicate which codec slot is available. > maybe the developers will be interested and/or will suggest a > fix that is a little more elegant/widely applicable? And why did the base > code work just once, for no clear reason ? (I did not have debug=verbose at > that time, so I don't have detailed messages in the system log). Not sure about this as I didn't track this bug. When did it work once? Is the device enabled by BIOS properly?
To summarize:
- It always did work with FC7.
I guess it worked likely just casually. The old driver didn't clear the register bit before probing, so it got uninitialized bits.
Takashi