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