From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kan-I Jyo" Subject: Re: [Fwd: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux]] Date: Fri, 1 Aug 2008 12:30:54 +0900 Message-ID: <1e8a3dd0807312030r215d7d00qa0c4fc08ddf5c63f@mail.gmail.com> References: <1e8a3dd0806241840m76069ad8sa35058ad8ddb843b@mail.gmail.com> <1e8a3dd0806250500p6f7a343u89b11d42f556347@mail.gmail.com> <1e8a3dd0806300620i2be727afibc932c1df6744f7f@mail.gmail.com> <1e8a3dd0807022242sd33c315xa4613da95d039f38@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by alsa0.perex.cz (Postfix) with ESMTP id E9B2F24501 for ; Fri, 1 Aug 2008 05:30:54 +0200 (CEST) Received: by mu-out-0910.google.com with SMTP id g7so869878muf.2 for ; Thu, 31 Jul 2008 20:30:54 -0700 (PDT) In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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 : > 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 : >> >> > 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.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); >> } >> >> >> >> 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: >> >> >> >> --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 >> >> >> >> When trying to apply the "position_fix" module option to values other >> than the default "0", I got following ouput from 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... > >> >> >> >> And in /var/log/messages, I have following messages complaining that >> the position buffer is invalid. >> >> >> >> --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