From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [Fwd: [Alsa-user] Intel Poulsbo(SCH) chipset does not recognize Adi 1986 codec under linux]] Date: Tue, 01 Jul 2008 12:22:56 +0200 Message-ID: References: <1e8a3dd0806241840m76069ad8sa35058ad8ddb843b@mail.gmail.com> <1e8a3dd0806250500p6f7a343u89b11d42f556347@mail.gmail.com> <1e8a3dd0806300620i2be727afibc932c1df6744f7f@mail.gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by alsa0.perex.cz (Postfix) with ESMTP id 59F2024345 for ; Tue, 1 Jul 2008 12:22:57 +0200 (CEST) In-Reply-To: <1e8a3dd0806300620i2be727afibc932c1df6744f7f@mail.gmail.com> 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: Kan-I Jyo Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Mon, 30 Jun 2008 22:20:17 +0900, Kan-I Jyo wrote: > > Dear Takashi, > > Thank you for your kind help all the time. > > 2008/6/25 Takashi Iwai : > > The hardware sets the corresponding bits to this register when the > > codec is found on the slot. So, this seems really like a hardware > > problem. > > For all my try these days have all led to a non-working audio device, > I can not help thinking the high possibility of a hardware problem. > Just want to make sure that I have made good efforts before blaming on > hardware side. > > > > > Or, if it's a timing issue, you can try to add some delays in > > azx_reset()... > > Considering this kind of issue, I have increased the "msleep" in > azx_reset() from 1 to 1000. > With no luck, stiil there the "no codecs found" message. > > Moreover, I have changed the "msleep" to "ssleep" with a even larger > value. As you may have expected, no recognization of the ADi 1986A > codec at all. Then it implies that the hardware doesn't set this bit. It's supposed to be mandatory, and this probing mechanism works well for other hundreds of devices. Thus I think something still wrong in your device setup. 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. Takashi