From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Fwd: Problems with hda_intel, Santa Rosa, and suspend Date: Thu, 05 Jul 2007 13:03:44 +0200 Message-ID: References: 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 mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 9CC86103871 for ; Thu, 5 Jul 2007 13:03:44 +0200 (CEST) In-Reply-To: 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: Matt Mullins Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Wed, 4 Jul 2007 15:37:22 -0500, Matt Mullins wrote: > > On a whim, I decided to extract the sound/pci/hda from vanilla 2.6.20 > kernel sources and compile it under 2.6.22-rc5 (yes, I know, I > probably shouldn't have done that). I had to add a typedef to > patch_sigmatel.c to get it to compile. When I loaded the modules, I > did *not* get the "switching to single_cmd" error, but I haven't > gotten sound yet, either, probably because I'm using pieces of two > different versions of ALSA. However, this suggests to me that perhaps > there is a problem with the hda_intel driver, and not necessarily an > ACPI problem. That's possible. It might be that an access to an unsupported widget may trigger the unexpected behavior of the codec chip and the communication is disturbed. Maybe it's worth to trace which verb call triggers the communication breakage. (BTW, for testing, you should concentrate only on audio codec, so skip modem codec via probe_mask option.) Takashi