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@xxxxxxx>:
> 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@xxxxxxx>:
>>
>> > 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
>
--
Sincerely,
Jyo
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
