Dear Takhashi,
After having some discussions with the hardware vender and reviewing some technical specifiction documents on Intel's website, this issue has now been fixed by a rework of the hardware.
I would like to say thank you for all your kind support on this issue.
2008/7/4 Takashi Iwai tiwai@suse.de:
At Thu, 3 Jul 2008 14:42:16 +0900, Kan-I Jyo wrote:
Dear Takashi,
Thank you for your reply.
2008/7/1 Takashi Iwai tiwai@suse.de:
If you know the slot number of the codec beforehand, you can modify to force to set chip->codec_mask in azx_reset(). Then the driver will continue to probe the codec.
By changing the "chip->codec_mask", amazingly the codec chip is now recognized.
<hda_intel.c.diff> --- hda_intel.c.orig 2008-07-02 13:27:14.699908463 +0900 +++ hda_intel.c 2008-07-02 13:27:48.303899618 +0900 @@ -750,7 +750,8 @@ static int azx_reset(struct azx *chip)
/* detect codecs */ if (!chip->codec_mask) {
chip->codec_mask = azx_readw(chip, STATESTS);
/* chip->codec_mask = azx_readw(chip, STATESTS); */chip->codec_mask = 1; snd_printdd("codec_mask = 0x%x\n", chip->codec_mask); }<ends here>
I do not consider this as a good way to solve this issue, this is quite a progress to me. Thank you for your advise, Takashi.
Regardless of being recognized and been configurable by alsamixer, there is no sound output from the speaker. I have tried all the model option listed in Documentation/sound/alsa/ALSA-Configuration.txt for AD1986A and none provides a sound output.
By switching to different models, it results some similar log output in both dmesg and /var/log/messages have some info like this:
<dmesg>
--snip-- ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:601: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:608: hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0000
If this happens, usually it means that the device access is pretty ragged. Does /proc/asound/card0/codec#* show the correct values?
ALSA /root/alsa-driver-1.0.17rc3/pci/hda/hda_codec.c:2334: hda_codec: model '6stack' is selected ALSA /root/alsa-driver-1.0.17rc3/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:1196: snd_hda_codec_new() results is 0
<ends here>
When trying to apply the "position_fix" module option to values other than the default "0", I got following ouput from dmesg.
<dmesg>
--snip-- ALSA /root/alsa-driver-1.0.17rc3/acore/../alsa-kernel/core/pcm_lib.c:1540: playback write error (DMA or IRQ trouble?)
This error is fatal, and implies that the IRQ isn't triggered properly. Doesn't this happen if you set position_fix=0? Still weird...
<ends here>
And in /var/log/messages, I have following messages complaining that the position buffer is invalid.
</var/log/messages>
--snip-- Jan 2 18:34:03 localhost kernel: hda-intel: Invalid position buffer, using LPIB read method instead. Jan 2 18:34:03 localhost kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
On Intel devices, we choose the 1 sample position fix while 32 samples for other controller chips. This might be a wrong assumption, but I'd like to check all other cases first.
And, this basically is no fatal error. This may lead to higher CPU load (for busy wait) but the playback should still work.
Takashi